Home

Engenharia de Software - Informática

1. dados fun es e comportamento sendo que para cada uma dessas dimens es um tipo de modelo usado a saber e Diagrama de Entidades e Relacionamentos DER um modelo conceitual utilizada para representar os dados a serem armazenados em um sistema de informa o tendo sido desenvolvida originalmente para dar suporte ao projeto de bancos de dados e Diagramas de Fluxos de Dados DFDs s o diagramas usados para a modelagem funcional de sistemas representando um sistema como uma rede de processos interligados entre si por fluxos de dados e dep sitos de dados e Diagramas de Estados representam o comportamento de entidades ao longo do tempo Tipicamente constr i se um diagrama de estados para cada entidade ou relacionamento com atributo do DER que possuir comportamento significativo isto possuir mais de um estado ao longo de seu ciclo de vida Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 66 Usando esses modelos o Modelo Comportamental da An lise Essencial representa o que o interior do sistema deve fazer para atender aos eventos apontados pelo Modelo Ambiental sendo o principal produto da an lise de requisitos quando esse m todo adotado Conforme definido na proposta da An lise Essencial 5 o modelo comportamental cont m os seguintes artefatos como mostra a figura 5 3 a Diagrama de Entidades e Re
2. o como uma segunda entidade se e O elemento em quest o tem atributos pr prios e A segunda entidade resultante relevante para a organiza o 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 5 23 Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 78 1 1 13 N Figura 5 23 Departamento como Nova Entidade Particionamento de Entidades Muitas vezes inst ncias de entidades do mundo real se subdividem em categorias com atributos e 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 5 24 mostra um exe
3. Conforme discutido anteriormente os modelos de ciclo de vida se at m apenas s atividades b sicas do processo de desenvolvimento e suas inter rela es Eles se constituem em 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 que um processo de qualidade deve considerar Dentre essas normas e modelos destacam se as normas NBR ISO 9000 2000 6 NBR ISO IEC 12207 7 ISO IEC 15504 8 e os modelos CMM 9 CMMI 10 e MPS BR 11 A S rie ISO 9000 2000 As normas da fam lia NBR ISO 9000 6 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 2000 s o e NBR ISO 9000 descreve os fundamentos de sistemas de gest o da qualidade e estabelece a terminologia para esses sistemas e NBR ISO 9001 especifica os requisitos para um sistema de gest o da qualidade com enfoque na sati
4. Embora tenha fraquezas ele significativamente melhor do que uma abordagem casual para o desenvolvimento de software De fato para problemas bastante pequenos e bem definidos onde os desenvolvedores conhecem bem o dom nio do problema e os requisitos podem ser claramente estabelecidos esse modelo indicado uma vez que f cil de ser gerenciado 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 3 como mostra a figura 2 3 Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 10 An lise e mmes Especifica o de Teste de Aceita o Requisitos Entrega e Implanta o Projeto da Teste de Arquitetura Sistema Projeto Detalhado Testes de Unidade e Integra o D Implementa o Figura 2 3 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 implemen
5. que ser a adotada neste texto Atrav s da utiliza o desses quatro componentes podemos representar satisfatoriamente os processos e intera es entre os elementos de um sistema Processos Fluxos de Dados Entidades Externas Dep sitos de Dados Figura 5 28 Nota o b sica para constru o de DFDs Al m dos Diagramas de Fluxos de Dados s o necess rios para uma completa modelagem das fun es e Dicion rio de Dados 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 Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 84 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 dado de entrada no conte do de um dado de sa da sem armazenamento interno no sistema figura 5
6. 2 2 1 Modelos Seqjiienciais Como o nome indica os modelos segiienciais organizam o processo em uma sequ ncia linear de fases O principal modelo desta categoria o modelo em cascata a partir do qual diversos outros modelos foram propostos inclusive a maioria dos modelos incrementais e evolutivos 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 2 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 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 de configura o Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 9 An lise e Especifica o de Requisitos Implementa o e Teste de Unidade Entrega e Implanta o Figura 2 2 O Modelo em
7. Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 89 Essas nota es s o exce es regra de que os dados n o devem fluir diretamente entre uma entidade externa e um dep sito de dados sem passar por um processo respons vel pela transfer ncia dos dados Fora as situa es anteriormente descritas devemos 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 ou terminadores 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 cliente 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 um mesmo terminador mais de uma vez para se
8. 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 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 vis
9. Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 85 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 Esta descri o n o deve ser confundida com o detalhamento integral da l gica do processo que dever ser feito na fase de projeto mas deve servir de base para essa outra etapa 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 processos em um DFD Por outro lado se a descri o da l gica do processo necessitar de quatro 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
10. 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 Engenharia de Software Cap tulo 7 Implementa o e Testes Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 129 Figura 7 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 todos os m dulos chamados por 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 3 Neste caso apenas stubs s o necess rios Tomando o exemplo da figura 7 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 rios 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 3 que considera uma camada alvo no meio da hierarquia e utiliza as abordagens ascendente e de
11. SIN Tratamento de Clientes 2 X Tratamento Normal X Tratamento de Clientes 2 Atraso de pagamento registrado N INIS S Tempo de trabalho gt 20 anos SINISIN Tratamento Priorit rio XIXIX Tratamento Normal X Figura 5 48 Tabelas Encadeadas 5 8 4 Modelagem Funcional com DFDs e a An lise Essencial Quando empregamos a filosofia da An lise Essencial na modelagem funcional um DFD contendo um nico processo constru do para cada um dos eventos listados na lista de eventos Caso o evento seja complexo demais e mere a ser decomposto em outros processos ent o as t cnicas de fiss o ou explos o devem ser aplicadas Constru dos os DFDs para os eventos espec ficos os mesmos podem ser agrupados dando origem a DFDs de n vel superior at se chegar a um DFD de n vel O e por fim a um DFD de Contexto Contudo importante ressaltar que a maior parte dos eventos em uma lista de eventos pode ser simples e que representar tais eventos por meio de DFDs pode n o trazer ganhos substanciais para o desenvolvimento Muito pelo contr rio pode gerar uma quantidade desnecess ria de DFDs aumentando muito a documenta o do sistema com pouca utilidade Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 99 Assim recomendamos a elabora o de DFDs apenas para o
12. Universidade Federal do Esp rito Santo 33 An lise de Pontos de Fun o Refer ncias 6 7 A An lise de Pontos de Fun o APF um m todo padr o para a medi o do desenvolvimento manuten o ou tamanho de uma aplica o de software visando estabelecer uma medida de tamanho do software em Pontos de Fun o PFs com base na quantifica o da funcionalidade solicitada ou forncecida sob o ponto de vista do usu rio Os objetivos da APF s o 7 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 3 3 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 6 Determinar o Tipo de Contagem Identificar o Escopo de Contagem e a 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 3 3 O Processo de Contagem de Pontos de Fun o Engenharia de Software Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 34 e D
13. 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 3 4 3 Estimativas de Esfor o Refer ncias 1 Cap 5 se es 5 6 e 5 7 2 Cap 23 se o 23 1 3 Cap 3 se o 3 3 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 tipicamente usando t cnicas de decomposi o ou podem ser computadas a partir de dados de tamanho ou de dados hist ricos Quando as estimativas de esfor o s o feitas com base apenas no julgamento dos especialistas uma tabela como a Tabela 3 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 unidades de esfor o necess rio para completar um
14. a seguir 2 2 2 Modelos Incrementais H muitas situa es em que os requisitos s o razoavelmente bem definidos mas o tamanho do sistema a ser desenvolvido impossibilita a ado o de um modelo segiiencial sobretudo pela necessidade de disponibilizar rapidamente uma vers o para o usu rio Nesses casos um modelo incremental indicado la Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 11 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 Vale destacar que a defini o das vers es e a correspondente segmenta o e atribui o dos requisitos a essas vers es realizada antes do desenvolvimento da primeira vers o O Modelo 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 ser produzida e entregue para uso ou avalia o detalhada do cliente Para tal requisitos t m de ser minimame
15. cil a identifica o das fun es e entidades que comp em o sistema 5 A An lise Essencial de Sistemas atrav s da t cnica de particionamento por eventos oferece uma boa estrat gia para modelar o comportamento do sistema visando satisfazer os requisitos do usu rio pressupondo se que dispomos de tecnologia perfeita e que ela pode ser obtida a custo zero 7 A An lise Essencial preserva todos os modelos da An lise Estruturada De fato embora diferentes a melhor maneira de encarar a An lise Essencial consider la uma evolu o da An lise Estruturada Isso porque a An lise Essencial introduz novos conceitos e abordagens dentre eles tecnologia perfeita requisitos verdadeiros e falsos eventos e respostas atividades essenciais e mem ria essencial discutidos a seguir 5 2 1 Conceitos da An lise Essencial Tecnologia Perfeita Durante a fase de an lise o analista deve abstrair a tecnologia que ser utilizada na implementa o do sistema Para orientar essa abstra o a An lise Estruturada recomenda que o analista durante a fase de an lise concentre se apenas nos aspectos l gicos do sistema evitando pensar nos aspectos f sicos O problema dessa abordagem que a diferen a entre aspectos l gicos e f sicos n o clara Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 56 Partindo do princ pio
16. deseja se saber se uma pessoa est com seu peso ideal ou n o Para tal duas medidas s o importantes altura H e peso P Ao medir essas dimens es est se efetuando uma medi o A m trica ndice de massa corporal IMC calculada segundo a seguinte f rmula IMC P H A partir dessa m trica 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 Engenharia de Software Cap tulo 4 Ger ncia da Qualidade de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 49 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 suas medidas para altura e peso A partir delas pode calcular a m trica 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 processo de alimenta o obtendo melhorias reais para sua sa de Uma vez que a medi o de software se preocupa em obter valores num ricos medidas para alguns atributos de um produto ou de um processo uma quest o importante passa a ser Que atributos medir O mode
17. grupo de a es fim enquanto Exemplo enquanto existir notas fa a ler nota consistir dados fim enquanto 3 repita grupo de a es at que lt condi o seja verdadeira gt Exemplo repita ler nota consistir dados at que todas as notas tenham sido processadas Uma especifica o de processo em Portugu s Estruturado deve possuir as seguintes caracter sticas gerais e deve ser clara concisa completa e livre de ambigiiidades e todos os dados citados na especifica o que estejam definidos no dicion rio de dados devem estar em it lico incluindo dep sitos de dados e os dados definidos localmente s o escritos em fonte normal e sempre que um comando de sele o ou repeti o for utilizado os comandos do bloco interno grupo de a es devem estar identados de modo a dar a clareza de que esses comandos fazem parte das a es da sele o ou repeti o 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 cada a o Como podemos notar pelo exemplo da figura 5 43 uma rvore de Decis o muito boa para representar a l gica dec
18. implementado An lise e Especifica o de Requisitos o que Dom nio do Problema Mundo Real Projeto como Dom nio da Solu o Implementa o Figura 6 1 Vis o Geral da Atividade de Projeto O projeto de software um processo iterativo Inicialmente o projeto representado em um n vel alto de abstra o A medida que itera es ocorrem os refinamentos conduzem a representa es de menores n veis de abstra o Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 103 Uma especifica o de projeto deve e Contemplar todos os requisitos expl citos contidos no modelo de an lise e todos os requisitos impl citos desejados pelo cliente e Ser um guia leg vel e compreens vel para aqueles que ir 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 No projeto de sistemas um modelo de projeto tipicamente gerado 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 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
19. lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 51 Cap tulo 5 Levantamento e An lise de Requisitos Uma vez estudadas as atividades de ger ncia de projetos cap tulo 3 e de garantia de qualidade cap tulo 4 podemos passar a discutir as atividades do processo de desenvolvimento de software ou seja aquelas atividades que contribuem diretamente para o desenvolvimento do produto de software a ser entregue ao cliente e que portanto formam a espinha dorsal do desenvolvimento No que tange s atividades t cnicas do desenvolvimento de software a primeira coisa a ser feita capturar os requisitos que o sistema a ser desenvolvido tem de tratar Um completo entendimento dos requisitos do software essencial para o sucesso de um esfor o de desenvolvimento de software A Engenharia de Requisitos um processo de descoberta refinamento modelagem e especifica o O escopo do software definido no planejamento do projeto refinado em detalhe as fun es e o desempenho do software s o especificados as interfaces com outros sistemas s o indicadas e restri es que o software deve atender s o estabelecidas Modelos dos dados requeridos do controle e do comportamento operacional s o constru dos Finalmente crit rios para a avalia o da qualidade em atividades subsequentes s o estabelecidos Este o objeto de estudo deste cap tulo 5 1 Engenharia de Requisitos de Software
20. lise de Requisitos visa a estabelecer um conjunto acordado de requisitos consistentes e sem ambigiidades que possa ser usado como base para o desenvolvimento do software Para tal diversos tipos de modelos s o constru dos Geralmente a an lise de requisitos inclui tamb m a negocia o para resolver conflitos detectados 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 Verifica o e Valida o de Requisitos A verifica o de requisitos avalia se o documento de Especifica o de Requisitos est sendo constru do de forma 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 esse documento est correto ou seja se os requisitos e modelos documentados atendem s reais necessidades e requisitos dos usu rios cliente Ger ncia de Requisitos se preocupa em gerenciar as mudan as nos requisitos j acordados manter uma trilha dessas mudan as gerenciar os relacionamentos entre os requisitos e as depend ncias entre o documento de requisitos e os demais artefatos produzidos no processo de software de forma a garantir que mudan as nos requisitos sejam feitas de maneira controlada e documentada poss vel notar que das cinco atividades do
21. maturidade da organiza o J a representa o cont nua mapeia n veis de capacita o de cada rea de processo procurando se alinhar com a norma ISO IEC 15504 Ambas as representa es cont m reas de Processos antigas reas chave de Processo do CMM comuns Por m na representa o em est gio as reas de Processos s o agrupadas em n veis de maturidade enquanto na representa o cont nua as mesmas reas de Processo est o divididas em categorias Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 20 O Modelo de Refer ncia Brasileiro MPS BR O MPS BR Melhoria de Processo do Software Brasileiro 11 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 O MPS BR tamb m define regras para sua implementa o e avalia o dando sustenta o e garantia de que empregado de forma coerente com as suas defini es A base t cnica utilizada para a constru o do MPS BR composta pelas normas NBR ISO IEC 12207 e suas emendas 1 e 2 e a ISO IEC 15504 estando totalmente aderente a essas normas Al m dis
22. o mostrada na figura 6 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 Figura 6 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 6 24 No exemplo os m dulos B e C s o chamados repetidas vezes pelo m dulo 4 Figura 6 24 Chamada Iterativa Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 119 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 6 25 Cadastrar cliente EA v lido cpf ji cpf v lido Validar cpf Figura 6 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 Cada m dulo s deve aparecer uma nica vez no diagrama Para se evitar cruzamento de linhas deve se usar conectores N o segmentar demais Al m dessas
23. o ou explos o como estudaremos mais frente Como regra geral os fluxos de erro e exce o n o devem ser mostrados nos diagramas mas apenas na descri o da l gica dos processos Essa regra s deve ser desrespeitada quando tais fluxos forem muito significativos para a comunidade usu ria 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 dado ou 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 5 32 um mesmo conjunto de informa es sobre um cliente tem significados diferentes quando passa pelos flux
24. processo de software e apresenta alguns dos modelos de processo discutidos anteriormente No entanto por ser uma edi o antiga veja refer ncia la algumas considera es n o s o v lidas Assim sendo recomenda se a leitura dos cap tulos 2 e 3 da 6 edi o ainda n o traduzida para o portugu s No cap tulo 2 da 6 edi o al m de uma discuss o sobre o que processo de software h tamb m uma apresenta o do modelo CMMI O Cap tulo 3 dessa edi o por sua vez apresenta os principais modelos de processo O Cap tulo 31 Engenharia de Software Apoiada por Computador da 5 edi o trata da automatiza o do processo de software J a 6 edi o la n o tem um cap tulo explicitamente dedicado a esse tema 2 I Sommerville Engenharia de Software S o Paulo Addison Wesley 6 edi o 2003 O Cap tulo 3 Processo de Software discute o que processo de software e apresenta os principais modelos de processo discutidos anteriormente Este cap tulo tem tamb m uma se o a se o 3 7 dedicada ao tema apoio automatizado ao processo de software 3 S L Pfleeger Engenharia de Software Teoria e Pr tica S o Paulo Prentice Hall 2 edi o 2004 Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 24 O Cap tulo 2 Modelagem do Processo e Ciclo de Vida discute o que processo de software e apresenta alguns do
25. 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 e artefatos necess rios e produzidos A escolha de um modelo de ciclo de vida ou modelo de processo o ponto de partida para a defini o de um processo de desenvolvimento de software Um modelo de ciclo de vida geralmente organiza as macro atividades b sicas do processo estabelecendo preced ncia e depend ncia entre as mesmas Para a defini o completa do processo cada atividade descrita no modelo de ciclo de vida deve ser decomposta e para suas sub atividades devem ser associados m todos t cnicas ferramentas e crit rios de qualidade entre outros formando uma base s lida para o desenvolvimento Adicionalmente outras atividades tipicamente de cunho gerencial devem ser definidas entre elas atividade de ger ncia de projetos e de controle e garantia da qualidade Os seguintes fatores influenciam a defini o de um processo e por conseguinte a escolha do modelo de processo a ser usado como base tipo de software p ex sistema de informa o sistema de tempo real etc paradigma de desenvolvimento estruturado orientado a objetos
26. 4 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 4 Engenharia de Software Cap tulo 7 Implementa o e Testes Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 127 primeira vista pode parecer que realizando testes caixa branca rigorosos poder amos chegar a programas corretos Contudo conforme anteriormente mencionado isso n o pr tico uma vez que todas as combina es poss veis de caminhos e valores de vari veis teriam de ser exercitadas o que imposs vel 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 independentesf He um m dulo tenham sido exercitados pelo menos uma vez 1 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 Dentre elas podem ser citadas 1 e Testes de estrutura de controle como o pr prio nome diz enfocam as estruturas de controle de um m dulo tais como comandos condi es e la os Teste de condi o um tipo de teste de estrutura de controle que exercita as condi es l gicas contidas em um m dulo Um teste de fluxo de dados por sua vez seleciona caminhos de teste tomando por base a localiza o das def
27. 4 4 3 Cap 3 se o 3 4 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 e incerteza um risco pode ou n o acontecer isto n o existe nenhum risco 100 prov vel e 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
28. Cascata 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 1 Projetos reais muitas vezes n o seguem o fluxo sequencial que o modelo prop 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 cascat requer isto e tem dificuldade de acomodar a incerteza natural que existe no in cio de muitos projetos O usu rio precisa ser paciente Uma vers o operacional do software n o estar dispon vel at o final do projeto 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 feedback 3
29. Esp rito Santo 126 O processo de teste envolve quatro atividades principais 3 4 e Planejamento de Testes trata da defini o 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 e 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 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 e Execu o dos testes consiste na execu o dos casos de teste e registro de seus resultados e Avalia o dos resultados detectadas falhas os defeitos dever o ser procurados N o detectadas falhas deve se fazer uma avalia o final da qualidade dos casos de teste e definir pelo encerramento ou n o de uma atividade de teste 7 2 1 T cnicas de Teste Para testar um m dulo necess rio definir um caso de teste executar o m dulo com os dados de entrada definidos por esse caso de teste e analisar a s
30. Essencial e a An lise Estruturada est na estrat gia para atacar o problema a primeira defende uma abordagem baseada em eventos onde a an lise de eventos passa a ser um passo fundamental a segunda baseada apenas na decomposi o top down da funcionalidade do sistema Lista de Eventos Modelo Diagrama de Ambiental Contexto Prop sito e Descri o do Mini Modelo mundo Essencial Diagramas de Fluxo de Dados Diagrama de Entidades e Modelo Relacionamentos Comportamental mo Ohp gt ZzOHMAHDO Mini Especifica es Diagramas de Estados novro Figura 5 3 A Organiza o do Modelo Essencial 5 6 Modelagem de Dados A primeira atividade realizada no processo de constru o do Modelo Comportamental da An lise Essencial de Sistemas deve ser a modelagem de dados e para tal o modelo de Entidades e Relacionamentos ER utilizado O modelo ER uma t cnica utilizada para representar os dados a serem armazenados em um sistema tendo sido desenvolvida originalmente para dar suporte ao projeto de bancos de dados 9 10 Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 68 5 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
31. Santo 21 Tabela 2 1 N veis de Maturidade e Processos do MPS BR N veis de Maturidade Processos A Inova o e Implanta o na Organiza o An lise e Resolu o de Causas B Desempenho do Processo Organizacional Ger ncia Quantitativa do Projeto C An lise de Decis o e Resolu o Ger ncia de Riscos D Desenvolvimento de Requisitos Solu o T cnica Integra o do Produto Instala o do Produto Libera o do Produto Verifica o Valida o E Treinamento Avalia o e Melhoria do Processo Organizacional Defini o do Processo Organizacional Adapta o do Processo para Ger ncia de Projeto F Medi o Ger ncia de Configura o Aquisi o Garantia da Qualidade G Ger ncia de Requisitos Ger ncia de Projeto 2 4 Processo Padr o da Organiza o e Processos Padr o Especializados V rios dos modelos e normas de qualidade de processo discutidos anteriormente 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 sub processos atividades sub atividades 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 padr o de
32. Uma boa fonte para identificar casos de uso s o os eventos externos Pense sobre todos os eventos do mundo externo para os quais o sistema deve reagir Identificar esses eventos pode ajud lo a identificar os casos de uso Para sistemas grandes pode ser dif cil propor uma lista de casos de uso Nessas situa es mais f cil chegar primeiro a uma lista de atores e tentar elaborar os casos de uso para cada ator Para cada curso completo de a es com um ator um caso de uso identificado Nem sempre est claro qual funcionalidade deve ser colocada em casos de uso separados ou o que apenas uma variante de um caso de uso A priori se as diferen as forem pequenas elas podem ser descritas como variantes ou cursos alternativos do caso de uso caso contr rio devem ser descritas como casos de uso separados Qualquer que seja a abordagem utilizada devemos sempre identificar os atores de um caso de uso descobrir qual o objetivo real do usu rio e considerar modos alternativos de satisfazer esses objetivos 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 ut
33. abreviados de intera o Cap tulo 6 Projeto de Sistemas 111 3 Considerar aspectos gerais de projeto de interface tais como tempo de resposta facilidades de ajuda mensagens de erro tipos de comandos entre outros 4 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 como mostra abaixo Entretanto 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 5 Avaliar o resultado Coletar dados qualitativos e quantitativos question rios distribu dos aos usu rios do prot tipo Projeto Preliminar Constru o do 1 Prot tipo o Pao n Prot tipo Avalia o do Usu rio Constru o do Modifica es do Projeto de Interface Estudo da Avalia o pelo Projetista Projeto de Interface Completo Figura 6 15 Abordagem Iterativa para o Projeto de Interface com o Usu rio 6 3 Projeto Modular de Programas A tarefa de constru o de sistemas computadorizados requer uma organiza o das id ias 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 trabalho
34. 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 5 19 0 fornece raz o social Figura 5 19 Atributo de relacionamento cnpj c digo descri o Na pr tica apenas os atributos de relacionamentos N N s o caracterizados como atributos de relacionamentos No caso de relacionamentos 1 N ou N l os atributos do relacionamento podem ser perfeitamente caracterizados como atributos da entidade cuja a cardinalidade m xima 1 No exemplo da figura 5 20 o atributo data de lota o pode ser perfeitamente caracterizado como atributo da entidade Funcion rio j que um funcion rio est lotado em apenas um departamento Logo a data de lota o do funcion rio a data de lota o dele no departamento ao qual est associado Departamento Figura 5 20 Atributo de relacionamento caracterizado como atributo de uma das entidades Quando o relacionamento N N h um teste que pode ser aplicado para se deduzir se um atributo de um dos dois conjuntos de entidades ou se do relacionamento Seja o exemplo da figura 5 21 0 N LN lt gt fornece Figura 5 21 Relacionamento N N com atributos Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Es
35. com a ger ncia da configura o do software conforme discutido a seguir importante notar que o planejamento da documenta o tem uma estreita rela o com o processo de software definido para o projeto Ou seja os documentos a serem gerenciados s o aqueles previstos como sa das das atividades do processo Assim tendo sido definido o processo do projeto o planejamento da sua documenta o consiste apenas em selecionar quais artefatos dentre os muitos produzidos ao longo do processo ser o efetivamente submetidos ger ncia de configura o de software e ao controle e garantia da qualidade Engenharia de Software Cap tulo 4 Ger ncia da Qualidade de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 44 4 2 Controle e Garantia da Qualidade Refer ncias 1 Cap 8 se es 8 3 84 e 8 11 2 Cap 24 se es 24 1 24 2 24 3 Durante o processo de desenvolvimento de software ocorrem enganos interpreta es err neas e outras faltas defeitos ou erros principalmente provocados por problemas na comunica o e transforma o da informa o que podem resultar em mau funcionamento do sistema produzido Assim muito importante detectar esses defeitos o quanto antes preferencialmente na atividade em que foram cometidos como forma de diminuir retrabalho e por conseguinte custos de altera es As atividades que se preocupam com essa quest o s o coletivamente denominadas atividad
36. com o objetivo de mostrar o comportamento do mesmo ao longo do seu tempo de vida Diagramas de Estado descrevem todos os poss veis estados pelos quais uma entidade relacionamento pode passar e as transi es dos estados como resultado de eventos est mulos que atingem o mesmo A figura 5 27 mostra a nota o b sica para diagramas de estado Estado Inicial Evento Condi o A o Estado 1 atividade A1 Estado Final Estado 2 e 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 pode conter al m de seu nome uma indica o de que o estado possui uma atividade associada a ele cuja sintaxe atividade O r tulo de uma transi o pode ter at tr s partes todas elas opcionais Evento condi o a 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 e a a o realizada A entidade passa ent o para um novo estado Se neste estado uma atividade deve ser realizada ela iniciada O fato de uma transi o n o possuir um evento associado indica que a transi o ocorrer t o logo a atividade associada ao dado estado tiver sido conclu da desde que a condi o seja verdadeira Quando uma transi o n o possuir uma condi o associada
37. da Consulta Externa Externa Externa Entrada Externa Sa da Externa Arquivo L gico Consulta Externa Arquivo de Interface Interno 2 Externa Aplica o sendo contada Outras aplica es Figura 3 4 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 pouco produtivo utilizar o m todo da APF integralmente para realizar as primeiras estimativas A APF antes de mais nada um m 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 6 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 Engenharia de S
38. de Entrada Ampliada Uma condi o pode ter mais de dois valores poss veis diferentes como no exemplo da figura 5 46 Cobran a de Fretes Meio de Transporte F F F FIRIRIRIRIM M M M Tipo de Entrega R N RIRININ Peso DRE DEE RS ENE R 100 Kg X X R 50 Kg X X X X X R 10 Kg X X X X X Meio de Transporte Ferrovi rio F Rodovi rio R Mar timo M Tipo de Entrega R pida R at 5 dias teis Normal N at 30 dias Peso Leve L lt 100kg Pesado P gt 100Kg Figura 5 46 Tabela de Entrada Ampliada Muitas vezes grupos de condi es levam mesma a o Para estes casos podemos utilizar tabelas compactadas como a do exemplo 5 47 Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 98 Tratamento de Clientes Volume de Neg cios gt R 1 milh o SISI SIN Atraso de pagamento registrado N S S Tempo de trabalho gt 20 anos So dA NE E Tratamento Priorit rio XIX Tratamento Normal X X Figura 5 47 Tabela Compactada Quando uma nica tabela se tornar muito grande ou complexa podemos utilizar tabelas encadeadas onde uma tabela faz refer ncia a outras como mostra o exemplo da figura 5 48 Tratamento de Clientes 1 Volume de Neg cios 2 R 1 milh o
39. desenvolvimento de software Processos para projetos espec ficos podem ent o ser definidos a partir da Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 22 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 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 2 9 ilustra essa abordagem de defini o de processos de software em n veis 4 Uma vez que objetivo das normas e modelos de qualidade apontar caracter sticas q
40. dio de3a7 Alto de 7a 9 Muito Alto de 9a 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 Engenharia de Software Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 41 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 dos 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 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 no plano de riscos Esse plano servir de base para a atividade de monitoramento dos riscos quando os riscos t m de ser monitorados para se verificar se
41. 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 Entretanto desejamos representar de fato conjuntos de entidades isto grupos de entidades que t m caracter sticas semelhantes No modelo ER conjuntos de entidades s o representados graficamente por ret ngulos como mostra a figura 5 4 Livro Cliente Funcion rio Figura 5 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 representa todos os livros de uma biblioteca Para estabelecermos uma padroniza o neste texto usaremos nomes de conjuntos de entidades sempre no singular e escritos com a primeira letra mai scula No entanto isto n o representa efetivamente uma regra Al m disso usaremos o termo entidade para referenciar tanto entidades quanto conjuntos 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 conjunto de entidades ou de uma entidade espec fica Relacionamentos Um relacionamento uma a
42. do prot tipo sistema pode aumentar o conhecimento sobre o produto e melhorar o entendimento que se tem acerca dos requisitos Entretanto necess ria uma forte ger ncia do projeto e de configura o Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 14 O Modelo Espiral O modelo espiral mostrado na figura 2 6 um dos modelos evolutivos mais difundidos An lise Especifica o de Requisitos Projeto Implementa o Entrega e Implanta o Testes Figura 2 6 O Modelo Espiral Usando o modelo espiral o sistema desenvolvido em ciclos sendo que nos primeiros ciclos nem sempre todas as atividades s o realizadas Por exemplo o produto resultante do primeiro ciclo pode ser uma especifica o do produto ou um estudo de viabilidade As passadas subsegiientes 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 la 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 modelo
43. 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 5 41 Clientes Clientes A Figura 5 41 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 percebermos que em algum ponto do sistema 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 os terminadores s o externos ao sistema os fluxos de dados que os interligam aos diversos processos representam a interface entre o sistema e o mundo externo Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 90 5 8 1 Rela es entre DFDs e DERs Conforme discutido anteriormente dep sitos de dados s o representa es em um DFD para entidades e relacionam
44. 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 144 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 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 n
45. m dulo Assim os modelos do projeto estruturado de programas s o organizados como uma hierarquia de m dulos A id ia 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 computadorizada 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 partir de uma declara o bem definida do problema Oferece um conjunto de crit rios para avalia o da qualidade de um determinado projeto 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 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 organizando esses hierarquicamente O sistema subdividido em caixas pretas que s o organizadas em uma hierarquia conveniente A
46. m tricas associadas revis es e inspe es e a ger ncia de configura o de software Cap tulo 5 Especifica o e An lise de Requisitos s o discutidos o que um requisito de software e tipos de requisitos A seguir s o abordadas a especifica o e a an lise de requisitos O m todo da An lise Essencial de Sistemas e a t cnica de Modelagem de Casos de Uso s o apresentados Cap tulo 6 Projeto de Sistema aborda os conceitos b sicos de projeto de sistemas tratando da arquitetura do sistema a ser desenvolvido e do projeto de seus m dulos segundo a abordagem do Projeto Estruturado de Sistemas Cap tulo 7 Implementa o e Testes 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 teste de valida o e teste de sistema Cap tulo 8 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 a atividade de manuten o do sistema Refer ncias e S L Pfleeger Engenharia de Software Teoria e Pr tica S o Paulo Prentice Hall 2 edi o 2004 Cap tulo 1 Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 5 Cap tulo 2 Processo de Software Para se construir um produto ou sistema seja de que natureza f
47. ncia de requisitos Planejamento do projeto de software Acompanahmento e supervis o do projeto de software Ger ncia de subcontratos de software Garantia da qualidade do software lnicial N vel 1 Ger ncia de configura o do software Figura 2 8 Os n veis de maturidade do CMM e suas reas chave de Processo O modelo SEI CMM tornou se um modelo de maturidade de processos conhecido usado e respeitado Baseado no sucesso do SW CMM CMM para software outros modelos foram criados procurando cobrir outras reas de interesse tais como CMM para Aquisi o de Software CMM para Engenharia de Sistemas incluindo hardware e software e CMM para Pessoas ger ncia de recursos humanos O CMMI CMM Integration 10 surgiu com o objetivo de integrar esses modelos de maturidade em um s modelo evitando assim o confronto de defini es e a sobreposi o de reas de processos O projeto tamb m se preocupou em tornar o CMM compat vel com a norma ISO 15504 de modo que avalia es em um modelo pudessem ser reconhecidas como equivalentes s do outro Vale destacar que apesar de prover um novo modelo o CMMI procura preservar ao m ximo os investimentos feitos em melhoria de processos baseadas no CMM O CMMI oferece duas abordagens diferentes para a melhoria de processos conhecidas como o modelo continuo e o modelo em est gios A representa o em est gio j presente no CMM visa uma abordagem relativa
48. o atrav s da chegada desses que o Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 58 sistema toma conhecimento da ocorr ncia do evento Os eventos temporais podem ser nomeados da seguinte forma lt Indica o de tempo gt lt a o gt lt complemento gt Ex Mensalmente emitir relat rio de vendas Atividades Essenciais S o todas as tarefas que o sistema deve executar para atender completamente ao seu prop sito mesmo considerando que ele ser implementado em uma tecnologia perfeita Uma atividade essencial deve executar todo o conjunto de a es necess rias para responder completamente a um e somente um evento As atividades essenciais subdividem se em e Atividades Fundamentais produzem uma informa o que parte do prop sito declarado do sistema Assim sendo o prop sito do sistema atendido pelas atividades fundamentais e Atividades Custodiais criam e mant m a mem ria necess ria execu o das atividades fundamentais tipicamente adquirindo dados do ambiente externo ao sistema e os armazenando nos dep sitos de dados Como as atividades essenciais respondem completamente a um e somente um evento a comunica o entre elas ser feita sempre via mem ria e nunca diretamente Essa caracter stica da comunica o entre atividades essenciais torna o particionamento por eventos uma abordagem adequ
49. 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 Outras restri es de integridade pass veis de representa o nos diagramas ER s o aquelas envolvidas nos conectores ou opcional e ou exclusivo conforme discutido anteriormente Entretanto h outras situa es que n o conseguimos capturar Seja o exemplo da figura 5 25 0 N 0 N Disciplina p s requisito cursou Figura 5 25 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 Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 80 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
50. 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 1 mostra a rela o entre esses tipos de atividades Atividades de Ger ncia RR A Atividades de Desenvolvimento Produto de Software E E ql Atividades de Garantia da Qualidade Figura 1 1 Atividades do Processo de Software Engenharia de Software Cap tulo 1 Introdu o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 4 1 2 A Organiza o deste Texto Nesta disciplina procuramos oferecer uma vis o geral da Engenharia de Software discutindo as principais atividades do processo e como realiz las Nos cap tulos que se seguem os seguintes temas s o abordados Cap tulo 2 Processo de Software enfoca os processos de software os elementos que comp em um processo a defini o de processos para projetos modelos de processo normas e modelos de qualidade de processo de software e a automatiza o do processo de software Cap tulo 3 Planejamento e Ger ncia de Projetos s o abordadas as principais atividades da ger ncia de projetos a saber defini o do escopo do projeto estimativas an lise de riscos elabora o de cronograma elabora o do plano de projeto e acompanhamento de projetos Cap tulo 4 Ger ncia da Qualidade trata de algumas atividades relacionadas garantia da qualidade incluindo a medi o e
51. objetivo ter v rias formas para realizar estimativas e usar seus resultados para se chegar a estimativas mais precisas Engenharia de Software Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 31 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 3 4 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 m tricas 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 6 Mas n
52. orienta es o projeto estruturado fornece duas estrat gias de projeto para guiar a elabora o de DEMSs a an lise de transforma o e a an lise de transa o Essas duas estrat gias fornecem dois modelos de estrutura que podem ser usados isoladamente ou em combina o para derivar um projeto estruturado 4 A an lise de transforma o um modelo de fluxo de informa es centrado na filosofia entrada processamento sa da Assim o DEM correspondente tende a espelhar esta mesma estrutura podendo ser decomposto em tr s grandes ramos como mostra a figura 6 26 M dulo Principal entrada v lida Ramo de Entrada Ramo de Sa da Processar Dados O sa da formatada sa da sa da Qu formatada Formatar Emitir Sa da Gravar Sa da Validar Ramo de Entrada Entrada Processamento Figura 6 26 An lise de Transforma o Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 120 O ramo de entrada cont m os m dulos que tratam da leitura e valida o dos dados de entrada bem como de uma eventual transforma o para um formato adequado para o processamento O ramo de processamento cont m o processamento essencial e deve ser independente de considera es f sicas de entrada e sa da Finalmente o ramo de sa da trata da transforma o dos dados de sa da de um formato interno para um formato adequado pa
53. 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 3 6 Elabora o do Plano de Projeto Refer ncias 1 Cap 7 se o 7 10 2 Cap 4 se o 4 2 3 Cap 3 se o 3 5 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 todos os projetos da organiza o contenham as informa es consideradas relevantes Refer ncias 1 R S Pressman Engenharia de Software Rio de Janeiro McGraw Hill 5 edi o 2002 O cap tulo 3 d uma vis o geral da ger ncia de projetos de software com discuss es sobre pessoal e forma o de equipes se o 3 2 defini o do escopo do software se o 3 3 estrutura de divis o do trabalho se o 3 4 O cap tulo 4 aborda o tema de medi o e m tricas nas se es 4 1 e 4 3 O cap tulo 5 trata com mais detalhes do planejamento do projeto com destaque para a determina o do escopo se o 5 3 estimativas se es 5 1 5 5 5 6 e 5 7 e recursos se o 5 4 O cap tulo 6 trata da ger ncia de riscos Finalmente o cap tulo 7 aborda a elabora o e o acompanhamento do cronograma 2 I Sommerville Engenharia de Sof
54. pacote inteiro de informa o ou m ltiplas inst ncias do pacote inteiro est o trafegando pelo fluxo e se o r tulo de um fluxo nomeado for diferente do r tulo do dep sito ent o as informa es que est o trafegando s o um ou mais componentes partes de um ou mais pacotes e estar o definidas no dicion rio de dados Muitas vezes diferentes sistemas compartilham uma mesma base de dados e portanto v rios sistemas poder o estar lendo e atualizando os conte dos de um mesmo dep sito de dados interessante mostrar este fato explicitamente no DFD e nesse caso podemos notar tr s situa es distintas e O sistema em quest o apenas l as informa es do dep sito de dados n o sendo respons vel por qualquer altera o de seu conte do Neste caso utilizamos a nota o da figura 5 38 Sistema Mantenedor DD compartilhado Figura 5 38 Sistema apenas acessando dep sito de dados mantido por outro sistema e O sistema em quest o apenas gera as informa es que s o utilizadas por outros sistemas Representamos essa situa o segundo a nota o da figura 5 38 Atualizar dados Outro Sistema Figura 5 39 Sistema atualizando dados utilizados por outro sistema e Ambos os sistemas atualizam o dep sito de dados A nota o para esta situa o mostrada na figura 5 40 Atualizar dados Outro Sistema Figura 5 40 Ambos os sistemas atualizando dados de um mesmo dep sito
55. poss vel Um baixo acoplamento pode ser obtido eliminando rela es desnecess rias enfraquecendo a depend ncia das rela es necess rias Podemos citar como raz es para se 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 Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 121 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 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 Entretanto vale a pena r
56. projeto ou m dulo descrito em unidades de tamanho Assim uma organiza o pode coletar dados de v rios projetos e estabelecer por exemplo quantos em homens hora uma unidade de esfor o s o necess rios para desenvolver 1000 LOCs KLOC ou 1 PF unidades 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 Engenharia de Software Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 37 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 3 estabelece a seguinte f rmula para se obter o esfor o necess rio em pessoas m s para desenvolver um projeto tomando por base o tamanho do mesmo em KLOC E 5 5 0 73 KLOC Outros modelos s o apresentados em 3 e 2 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 resul
57. que Engenharia de Software Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 28 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 j Processo de Desenvolvimento Q L gt Q9 Q9 Q9 OS Q9 Q9 Q9 Planejamento Encerramento Acompanhamento Determina o do Escopo do Software Defini o do Processo de Software do Projeto Realiza o de Estimativas Estimativa de Tamanho Estimativa de Esfor o Estimativa Aloca o de Recursos Estimativa de Dura o Elabora o do Cronograma do Projeto Estimativa de Custos Ger ncia de Riscos Elabora o do Plano de Projeto Figura 3 1 O Processo de Ger ncia de Projetos As atividades relacionadas no quadro na parte inferior na figura 3 1 s o realizadas diversas vezes ao longo do projeto Tipicamente no 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 Essa
58. que possa ser validada por analistas e usu rios Entretanto encontramos muitos problemas na descri o de forma narrativa entre os quais podemos citar Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 93 e Uso de express es do tipo mas todavia a menos que Por exemplo qual a diferen a entre as declara es abaixo Somar A e B a menos que A seja menor que B onde neste caso subtrair A de B Somar A e B Entretanto se A for menor que B a resposta ser a diferen a entre B e A Somar A e B mas subtrair A de B quando A for menor que B Total a soma de B e A Somente quando A for menor que B que a diferen a deve ser usada como o total Ao analisarmos essas frases notamos que n o existe diferen a l gica entre elas entretanto as formas narrativas apresentadas mascaram a semelhan a existente Se ao inv s de usarmos uma forma narrativa usarmos uma forma padr o do tipo se ent o sen o teremos maior clareza e valida o seA lt B ent o TOTAL B A sen o TOTAL A B fim se e Uso de comparativos como Maior que Menor que Mais de Menos de Seja a seguinte declara o At 20 unidades sem desconto Mais de R 20 5 de desconto E exatamente 20 unidades que tratamento deve ser dado e Ambig idades do E OU Seja a seguinte declara o Clientes que gerarem mais de um mi
59. s o suficientes para representar a perspectiva funcional de um sistema De fato h muita cr tica aos DFDs exatamente por misturarem perspectivas pelo uso de dep sitos de dados bem como pelo n vel de detalhe a que se prop em chegar por exemplo usando mini especifica es em portugu s estruturado Assim quando no levantamento de requisitos for elaborado um modelo de casos de uso os artefatos da modelagem funcional DFDs particionados por eventos DFDs organizados em n veis hier rquicos e especifica o da l gica dos processos passam a ser desnecess rios Neste caso o modelo de an lise pode conter apenas a Diagramas de Entidades e Relacionamentos a Diagramas de Estados a Dicion rio de Dados Outra importante quest o a ser levantada o problema da nota o dos diagramas em quest o DER e Diagramas de Estado Conforme citado anteriormente a An lise Essencial n o definiu um padr o de nota o para a elabora o desses diagramas Entretanto mais recentemente foi definida uma linguagem de modelagem unificada a UML 8 que estabeleceu nota es padr o para diversos tipos de diagramas dentre eles os Diagramas de Estados Assim a nota o apresentada na se o 5 7 j segue esse padr o Ainda que a UML n o tenha definido um padr o para diagramas de entidades e relacionamentos usando os diagramas de classes e os mecanismos de extens o oferecidos pela UML poss vel definir uma nota o que propicie uma in
60. 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 pois 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 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 Um processo de s
61. vantagem do uso da caixa preta est no fato de Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 113 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 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 Organizando M dulos Hierarquicamente Antes de iniciarmos uma discuss o sobre Projeto Modular de Programas passe
62. 29 entrada Figura 5 29 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 5 30 entrada Figura 5 30 Armazenamento de dados e transforma es de dados previamente armazenados no conte do de um dado de sa da como mostra a figura 5 31 RE entrada Figura 5 31 Gera o de dados de sa da a partir de dados armazenados Um processo representado por um c rculo com uma senten a simples verbo objetos em seu interior e opcionalmente um identificador n mero A senten a deve tentar descrever o melhor poss vel a fun o a ser desempenhada sem ambigiiidades Devem ser evitados nomes muito f sicos p ex gravar imprimir etc ou muito t cnicos p ex apagar fazer backup etc Os processos representados em um DFD n o precisam ser necessariamente fun es a serem informatizadas Muitas vezes para se prover um entendimento mais completo do sistema processos manuais ou mistos parte manual parte informatizada s o representados 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 Por outro lado devemos observar se um mesmo fluxo de dados entra e sai de um processo sem modifica o j que todo processo transforma dados Engenharia de Software Cap tulo 5
63. 3 2 5 Automatiza o do 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 a 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 1 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 automatizar os 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 1 R S Pressman Engenharia de Software Rio de Janeiro McGraw Hill Tradu o da 5 edi o 2002 la R S Pressman Sofiware Engineering A Practitioner s Approach McGraw Hill 6 edition 2005 O Cap tulo 2 Processo de Software da 5 edi o discute o que
64. 34 Fluxo ramificado Quando for necess rio cruzar fluxos de dados em um DFD devemos utilizar um arco como mostra a figura 5 35 Figura 5 35 Fluxos de dados que se cruzam em um diagrama Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 87 E importante real ar que DFDs n o indicam a sequ ncia na qual fluxos de dados entram ou saem de um processo Essa sequ ncia descrita apenas na especifica o do processo 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 Sem nos comprometermos quanto ao aspecto f sico 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 5 36 D clientes DI clientes Figura 5 36 Nota o para dep sitos de dados Um dep sito de dados n o se a
65. Entrega de Refei es 6 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 tarefas que definem as tarefas realizadas no n vel precedente 4 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 no 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 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Fed
66. Evite desenhar DFDs complexos Cuidado com os processos sem fluxos de dados de entrada ou de sa da a cai RD Cuidado com os dep sitos de dados que s possuem fluxos de dados de entrada ou de sa da 6 Dep sitos de dados permanentes devem manter estreita rela o com os conjuntos de entidades e de relacionamentos do modelo ER 7 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 8 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 9 Mostre um dep sito de dados no n vel mais alto em que ele faz a sincroniza o entre dois ou mais processos Passe a represent lo em todos os n veis inferiores que detalham os processos envolvidos 10 N o represente no DFD fluxos de controle ou de material Como o nome indica DFDs representam fluxos de dados 11 S especifique a l gica de processos primitivos ou seja aqueles que n o s o detalhados em outros diagramas 5 8 3 T cnicas de Especifica o de Processos Quando 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
67. H um l der do projeto e a comunica o entre ele e os demais membros da equipe vertical Por fim 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 Produto Refer ncias 1 Cap 3 se o 3 3 Cap 5 se o 5 3 3 Cap 3 se o 3 1 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 de requisitos inicial Neste contexto ganha for a a id ia 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 sub m 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 Estrutura de Divis o do Trabalho Refer ncias 1 Cap 3 se o 3 4 2 Cap 2
68. Para se controlar a qualidade em um projeto de software uma abordagem bastante usada consiste em se realizar revis es Nas revis es processos documentos e outros artefatos s o revisados por um grupo de pessoas com o objetivo de verificar 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 em rela o ao conte do e apont los aos respons veis pela sua elabora o O processo de revis o come a com o planejamento da revis o quando uma equipe de revis o formada tendo frente um l der A equipe de revis o deve incluir os membros da equipe que possam 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 Dando in cio ao processo de revis o propriamente dito normalmente o autor do artefato apresenta o mesmo e descreve a perspectiva utilizada para a sua constru o Al m disso o prop sito da revis o deve ser previamente informado e o material a ser revisado deve 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 re
69. Refer ncias 1 Cap 11 2 Cap 5 3 Cap 4 Uma das principais medidas do sucesso de um software o grau no qual ele atende aos objetivos e requisitos para os quais foi constru do De forma geral a Engenharia de Requisitos de Software o processo de identificar todos os envolvidos descobrir seus objetivos e necessidades e document los de forma apropriada para an lise comunica o e posterior implementa o 4 Mas antes de voltar a aten o para as atividades do processo de Engenharia de Requisitos importante entender o que um requisito 5 1 1 Requisito e Tipos de Requisitos As descri es das fun es que um sistema deve incorporar e das restri es que devem ser satisfeitas s o os requisitos para o sistema Isto os requisitos de um sistema definem o que o sistema deve fazer e as circunst ncias sob as quais deve operar Em outras palavras os requisitos definem os servi os que o sistema deve fornecer e disp em sobre as restri es opera o do mesmo 2 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 fornecer e como o sistema deve se comportar em determinadas situa es 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 Alguns requisitos n o funcionais dizem respeito ao sistema
70. ST 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 Baixa Coes o F brica de Garrafas Pl sticas Alta Coes o Conjunto Habitacional da CST Figura 6 29 Coes o e Acomplamento Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 123 Refer ncias Bibliogr ficas 1 R S Pressman Engenharia de Software Rio de Janeiro McGraw Hill 5 edi o 2002 2 I Sommerville Engenharia de Software S o Paulo Addison Wesley 6 edi o 2003 3 S L Pfleeger Engenharia de Software Teoria e Pr tica S o Paulo Prentice Hall 2 edi o 2004 4 J Martin C McClure T cnicas Estruturadas e CASE Makron Books S o Paulo 1991 5 C M S Xavier C Portilho Projetando com Qualidade a Tecnologia de Sistemas de Informa o Livros T cnicos e Cient ficos Editora 1995 Engenharia de Software Cap tulo 7 Implementa o e Testes Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 124 Cap tulo 7 Implementa o e Testes Uma vez projetado o sistema necess rio escrever os programas que implementem esse projeto e test los 7 1 Implementa o Ainda que um projeto bem elaborado facilite sobremaneira a implementa o essa tarefa n o necessariam
71. UFES Universidade Federal do Esp rito Santo Engenharia de Software Notas de Aula Ricardo de Almeida Falbo E mail falbo vinf ufes br 2005 Engenharia de Software 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 conhecimento 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 nico algor
72. a 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 2 3 Modelos Evolutivos ou Evolucion rios 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 la 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 incrementais 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 deve se optar por um modelo evolutivo A avalia o ou o uso
73. a Assim sendo para distinguir um requisito l gico de um requisito f sico utilizando a abstra o de tecnologia perfeita formule a seguinte pergunta ao identificar um requisito qualquer Para atender ao seu prop sito o sistema necessitar possuir essa capacidade ou essa caracter stica mesmo considerando que ele ser implementado em uma tecnologia perfeita Se a resposta for sim esse requisito verdadeiro e deve ser modelado Requisito Verdadeiro e Requisito Falso Uma caracter stica ou capacidade que um sistema deve possuir para atender ao seu prop sito mesmo considerando que ser implementado em uma tecnologia perfeita dita um requisito verdadeiro O conjunto de requisitos verdadeiros compreende a ess ncia do sistema Um requisito falso por outro lado uma capacidade ou caracter stica que o sistema n o precisa possuir para atender ao seu prop sito caso ele disponha de uma tecnologia de implementa o perfeita Evento Est mulo A o e Resposta Evento e resposta s o nomes gen ricos de intera es entre o ambiente externo e o sistema Um evento pode ser definido informalmente como um acontecimento do mundo exterior que requer do sistema uma resposta Corresponde a alguma mudan a no ambiente externo que funcionar como um est mulo para o sistema isto o sistema deve responder a esse est mulo para atender ao seu prop sito Uma resposta o resultado da execu o de um conjunto de a es no sistem
74. a como conseqii ncia do reconhecimento pelo sistema de que um evento ocorreu Uma resposta tipicamente pode ser 5 um fluxo de dados saindo do sistema para uma entidade externa uma mudan a de estado em um dep sito de dados inclus o exclus o ou altera o um fluxo de controle saindo de uma fun o para ativar uma outra Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 57 Respostas que s o direcionadas para fora do sistema s o ditas respostas externas Respostas que provocam altera es no estado interno do sistema s o ditas respostas internas Quando um evento ocorre produzido um est mulo para o sistema Ao receber o est mulo o sistema compreende que o evento ocorreu e ativa os processos realiza as a es necess rios para produzir a resposta Os eventos s o classificados em tr s tipos diferentes dependendo da maneira como ocorrem e da natureza do est mulo que produzem 5 e Evento orientado por fluxo de dados provocado por uma entidade externa a qual envia dados para o sistema O est mulo produzido por esse tipo de evento a chegada de um fluxo de dados que vai ativar uma fun o Esses eventos s o nomeados da seguinte forma lt Entidade externa que provocou o evento gt lt a o verbo na voz ativa gt lt est mulo fluxo de dados enviado ao sistema gt Ex Cliente env
75. a da Um teste um conjunto limitado de casos de teste definido a partir do objetivo do teste 3 Diversas t cnicas de teste t m sido propostas visando apoiar o projeto de casos de teste Essas t cnicas podem ser classificadas segundo a origem das informa es utilizadas para estabelecer os objetivos de teste em dentre outras categorias t cnicas funcional estrutural ou baseadas em m quinas de estado 4 Os testes funcionais ou caixa preta utilizam as especifica es de requisitos an lise e projeto para definir os objetivos do teste e portanto para guiar o projeto de casos de teste O conhecimento sobre uma determinada implementa o n o usado 4 Assim os testes s o conduzidos na interface do software 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 1 Os testes estruturais ou caixa branca estabelecem os objetivos do teste com base em uma determinada implementa o verificando detalhes do c digo Caminhos l gicos internos s o testados definindo casos de testes que exercitem conjuntos espec ficos de condi es ou la os 1 Os testes baseados em m quinas de estado s o projetados utilizando o conhecimento subjacente estrutura de uma m quina de estados para determinar os objetivos do teste
76. a de desenvolvimento deve ser elaborada isto um plano de projeto deve ser elaborado configurando o processo a ser utilizado no desenvolvimento de software medida que o projeto progride o planejamento deve ser detalhado e atualizado regularmente Pelo menos ao final de cada uma das fases do desenvolvimento an lise e especifica o de requisitos projeto implementa o e testes o planejamento como um todo deve ser revisto e o planejamento da etapa seguinte deve ser detalhado O planejamento e o acompanhamento do progresso fazem parte do processo de ger ncia de projeto An lise e Especifica o de Requisitos Nesta fase o processo de levantamento de requisitos intensificado O escopo deve ser refinado e os requisitos mais bem definidos 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 Uma vez capturados os requisitos do sistema a ser desenvolvido estes devem ser modelados avaliados e documentados Uma parte vital desta fase a constru o de um modelo descrevendo o que o software tem de fazer e n o como faz lo Projeto Esta fase respons vel por incorporar requisitos tecnol gicos aos requisitos essenciais do sistema modelados na fase anterior e portanto requer que a plataforma de implementa o seja conhecida Basicamente envolve duas grandes etapas projeto da arquitetura do sistema
77. a a 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 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 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 pemo pisa focais 7 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 ATEs Cada uma dessas fun es de dados deve ser classificada segundo sua complexidade funcional Essa complexidade definida com base em d
78. 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 inter pessoal etc importantes para a forma o de equipes s o igualmente relevantes para a aloca o de recursos humanos a atividades 3 4 5 Estimativa de Dura o e Elabora o de Cronograma Refer ncias 1 Cap 7 2 Cap 4 se o 4 3 3 Cap 3 se o 3 1 De posse das estimativas de esfor o e realizando em paralelo a 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 Engenharia de Software Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 38 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 distribui 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 3 3 1 Tabela 3 3 Distribui o de Esfor o pelas Principais Ativ
79. a com base no n mero de arquivos referenciados e dos itens de dados manipulados pela fun 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 Delas Desais 0oul 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 0o0ul 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 137 1 Para cada um
80. a 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 2 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 Uma classifica o poss vel considera os seguintes grupos e Usu rio Novato n o conhece os mecanismos de intera o requeridos para utilizar a interface eficientemente n o est habituado a usar computadores ou mecanismos espec ficos de intera o com os sistemas computacionais e conhece pouco a aplica o em si isto entende pouco as fun es e objetivos do sistema sem ntica da aplica o e Instru do mas intermitente possui um conhecimento razo vel da sem ntica da aplica o mas tem relativamente pouca lembran a das informa es necess rias para utilizar bem a interface Engenharia de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo e Instru do e fregiiente possui bom conhecimento da aplica o e domina bem os mecanismos de intera o Geralmente usu rios desse tipo buscam atalhos e modos
81. abela de Decis o A constru o de uma tabela de decis o envolve os seguintes passos Levantar as a es do processo Identificar as condi es que determinam estas a es Identificar os estados poss veis de cada condi o Identificar as combina es dos estados das condi es Construir uma coluna para cada combina o de condi es Preencher cada coluna com as regras das a es correspondentes Verificar se o entendimento foi correto Alterar a tabela at obter total concord ncia dos usu rios No DOE amoo ON RARE O LED A Se poss vel compactar a tabela Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 97 Em fun o do tipo das condi es temos dois tipos de tabelas e Tabela de Entrada Limitada os valores de uma condi o se limitam a dois Exemplos t picos deste tipo de tabelas s o as tabelas cujas condi es s o escritas sob a forma de perguntas de modo que as respostas sejam sim ou n o como mostra o exemplo da figura 5 45 Tratamento de Clientes Volume de Neg cios gt R 1 milh o S S S SININ NIN Atraso de pagamento registrado NINIS SININ S Tempo de trabalho gt 20 anos SINI S I INISINI ISIJN Tratamento Priorit rio XIXIX Tratamento Normal XIXIXIXIX Figura 5 45 Tabela de Entrada Limitada e Tabela
82. ada e Especifica o de Sistemas Editora Campus 1983 C Gane Desenvolvimento R pido de Sistemas Livros T cnicos e Cient ficos Editora 1988 Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 102 Cap tulo 6 Projeto de Sistemas O projeto 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 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 1 Enquanto a atividade de an lise pressup e que dispomos de tecnologia perfeita capacidade ilimitada de processamento com velocidade instant nea capacidade ilimitada de armazenamento custo zero e n o pass vel de falha 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 6 1 Assim o objetivo do 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
83. ada para dividir o problema em partes independentes Mem ria Essencial A mem ria essencial corresponde ao conjunto m nimo de dados que deve ser armazenado pelo sistema para atender ao seu prop sito considerando que ele ser implementado em uma tecnologia perfeita O modelo normalmente utilizado para modelar a mem ria essencial o Modelo de Entidades e Relacionamentos MER Nos Diagramas de Fluxo de Dados DFDs a mem ria essencial tamb m representada neste caso pelos dep sitos de dados Assim ao se considerar a mem ria essencial de um sistema essas duas vis es da mesma t m de estar consistentes Para garantir essa consist ncia a seguinte regra deve ser observada cada dep sito de dados de um DFD deve corresponder a uma entidade ou a um relacionamento com atributos do MER Para levar em conta a abstra o da tecnologia perfeita os dep sitos de dados entidades n o devem considerar a forma como os relacionamentos entre eles s o estabelecidos Por exemplo quando se utilizam bancos de dados relacionais chaves estrangeiras atributos determinantes transpostos entre entidades s o armazenadas para representar um relacionamento entre entidades Entretanto deve se ressaltar que essa uma caracter stica espec fica dos bancos de dados relacionais uma tecnologia nada perfeita Lembre se que na fase de an lise a tecnologia de implementa o ainda n o foi selecionada e deve ser considerada perfeita Engenharia de S
84. adas 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 Rad ND 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 biling e contar como 4 itens Suporte multiling e contar como 6 itens Pontua o Nenhum dos itens descritos De um a tr s itens descritos De quatro a cinco dos itens descritos Mais de cinco dos itens descritos mas n o h requisitos espec ficos do usu rio quanto a usabilidade do
85. agrama 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 sub sistemas e m dulos e a lista de eventos e descri es associadas devem ser a base para a constru o dos DHFs Cada execut vel deve dar origem a um DHF 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 refei es cujo escopo o seguinte e Subsistema Controle de Card pio envolvendo macro fun es para Cadastrar Refei es Sobremesas 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
86. amada an lise de sistemas por outro lado enfoca a estrutura interna do sistema Ou seja procura se definir o que o sistema tem de ter internamente 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 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 os componentes da equipe de desenvolvimento e clientes e usu rios e possibilitar a discuss o de corre es e modifica es com o usu rio e formar a documenta o do sistema Um modelo enfatiza um conjunto de caracter sticas da realidade que corresponde dimens o do modelo Al m da dimens o que um modelo enfatiza modelos possuem n veis de abstra o O n vel de abstra o de um modelo diz respeito ao grau de detalhamento com que as caracter sticas do sistema s o representadas Em cada n vel h uma nfase seletiva nos detalhes representados No caso do desenvolvimento de sistemas geralmente s o considerados tr s n veis O conceitual considera caracter sticas do sistema independentes do ambiente computacional ha
87. ar 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 um cronograma de execu o Todas essas informa es s o registradas em um documento chamado Plano de Projeto que deve ser sistematicamente revisado ao longo 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 3 1 Projeto de Software e Ger ncia de Projetos de Software Refer ncias 1 Cap 3 2 Cap 4 3 Cap 3 se o 3 2 Projeto como definido pelo PMBOK um empreendimento tempor rio com o objetivo de criar um produto ou servi o nico 4 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 5 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 pessoas e custos Assim sendo a Ger ncia de Projetos d
88. 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 Procedimental Detalhado tem por objetivo refinar e detalhar a descri o procedimental dos componentes estruturais da arquitetura do software A seguir cada uma dessas sub atividades do projeto de sistemas discutida luz do paradigma estruturado 6 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 hier rquico por exemplo um modelo hier rquico deve ser produzido adequando a modelagem de entidades e relacionamentos a essa plataforma de implementa o Atualmente a plataforma mais difundida para armazenamento de dados a dos Bancos de Dados Relacionais e portanto neste texto discutiremos apenas o projeto l gico de bancos de dados relacionais Em um modelo de dados relacional os conjuntos de dados s o representados por tabelas de valores Cada tabela bidimensional sendo organizada em linhas e colunas Para se realizar o mapeamento de um modelo de entidades e relacionamentos em um model
89. as 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 qualidade 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
90. as sem os desvios observados na modalidade por homem hora A quest o passa a ser ent o que unidade 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 m trica e o tempo necess rio para se desenvolver um sistema Entretanto o uso dessa m trica 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 uma m trica que pouco significativa para o cliente Visando possibilitar a realiza o de estimativas de tamanho mais cedo no processo de software e sem os problemas de depend ncia em rela o tecnologia foram propostas outras m tricas em um n vel de abstra o mais alto O exemplo mais conhecido a contagem de 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 Engenharia de Software Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES
91. asos de uso 5 4 2 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 de um modelo de casos de uso atores e casos de uso A figura 5 2 mostra a nota o b sica da Linguagem de Modelagem Unificada Unified Modeling Language UML 8 para diagramas de casos de uso m Ator Caso de Uso 1 Aor C gt z Caso de Uso Caso de Uso 3 Ator 2 Caso de Uso 2 Figura 5 2 Nota o B sica da UML para Diagramas de Casos de Uso Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 65 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 8 5 4 3 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 co
92. bstra o de uma associa o entre duas ou mais entidades Por exemplo podemos querer registrar que o funcion rio Jo o uma entidade do conjunto Funcion rio est lotado um relacionamento no departamento de Vendas uma entidade do conjunto 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 com as entidades estamos mais interessados em modelar conjunto de relacionamentos Um 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 5 5 Al m disso assim como fizemos com entidades usaremos indistintamente o termo relacionamento para designar tanto relacionamentos entre entidades espec ficas como para referenciar o conjunto de relacionamentos que existem entre conjuntos de entidades Opcionalmente usaremos o termo inst ncia tanto de entidades quanto de relacionamentos Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 69 para referenciar um elemento do conjunto de entidades e de relacionamentos respectivamente Departamento Funcion rio lota lota c df d e Departamento e fe Funcion rio Figura 5 5 Representa o gr f
93. c ficos Entretanto os ensinamentos desses projetos e contratos contribuem para a melhoria da organiza o S o processos organizacionais os processos de Ger ncia Infra estrutura Melhoria Recursos Humanos Ger ncia de Ativos Ger ncia de Programa de Reuso e Engenharia de Dom nio A Norma ISO IEC 15504 Desenvolvida pela comunidade internacional em um projeto denominado SPICE Software Process Improvement and Capability dEtermination a Norma ISO IEC 15504 Information Technology Process Assessment 8 Tecnologia da Informa o Avalia o de Processos um padr o internacional ISO para avalia o de processos de software 8 A ISO IEC 15504 prov uma abordagem estruturada para avalia o de processos de software com os seguintes objetivos 1 permitir o entendimento por ou em favor de uma organiza o do estado dos seus processos visando estabelecer melhorias 11 determinar a adequa o dos processos de uma organiza o para atender a um requisito particular ou classe de requisitos iii determinar a adequa o de processos da organiza o para um contrato ou classe de contratos Essa norma pode ser usada tanto por adquirentes de software para determinar a capacidade dos processos de software de seus fornecedores quanto por fornecedores para determinar a capacidade de seus pr prios processos ou para identificar oportunidades de melhoria composta de cinco partes e Part 1 Concepts and Vocabula
94. cial adotada uma vez que os eventos constituem uma parte fundamental da abordagem desse m todo De fato o primeiro passo na especifica o de um sistema identificar a quais eventos do mundo exterior ele dever responder Uma vez identificados til elaborar uma descri o de como o sistema responder a cada um desses eventos Finalmente uma vez definidos os eventos poss vel construir o Diagrama de Contexto do sistema mostrando como esse sistema responde a todos os eventos externos relevantes 5 3 1 Lista de Eventos Refer ncia 5 Cap tulo 15 Dado que a Lista de Eventos o principal produto do levantamento de requisitos segundo a An lise Essencial vale um exame mais cuidadoso desse artefato Um formato largamente utilizado o mostrado na tabela 5 1 que apresenta parte de uma lista de eventos para um sistema de biblioteca Tabela 5 1 Exemplo de uma lista de eventos Evento Tipo Est mulo A o Resposta Bibliotec rio cadastra dados FD dados livro Cadastrar livro cadastrado de livro Livro Diariamente cancelar reservas T Cancelar reservas vencidas vencidas Reservas exclu das Usu rio consulta livros C solicita o de Consultar dados livros consulta Livro par metro da consulta t tulo autor ou assunto Nas duas primeiras colunas o evento a ser tratado descrito segundo as regras de nomea o de eventos anteriormente apresentadas e classificado
95. cidade 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 CMM 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 A obten o de uma certifica o CMM uma demonstra o da capacidade do processo tomando por base o n vel de maturidade atingido Cada n vel de maturidade com exce o do n vel 1 composto de v rias reas chave de processo key process areas KPAs como mostra a figura 2 8 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 estimativas de custo e 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 Repet vel 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 to
96. 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 6 No que tange ger ncia de projetos estabelecer classes de projetos e coletar algumas m tricas 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 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 a ser realizada Engenharia de Software Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 32 3 4 2 Estimativa de Tamanho Refer ncias 1 Cap 5 se o 5 6 2 Cap 23 se o 23 1 3 Cap 3 se o 3 3 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 c
97. cionados 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 engenharia de software inicialmente o problema a ser tratado deve ser analisado e decomposto em partes menores em uma abordagem dividir para conquistar Para cada uma dessas partes uma solu o deve ser elaborada Solucionados os sub problemas isoladamente necess rio integrar as solu es Para tal uma arquitetura deve ser estabelecida Para apoiar a resolu o de problemas Engenharia de Software Cap tulo 1 Introdu o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 2 procedimentos m todos t cnicas roteiros etc devem ser utilizados bem como ferramentas para parcialmente automatizar o trabalho Neste cen rio muitas vezes n o poss vel conduzir o desenvolvimento 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 su
98. colocar a chave de A A em B e Se ambos forem totais pode se trabalhar com uma nica tabela escolhendo uma das chaves A ou B como chave prim ria como mostra o exemplo da figura 6 4 e Caso contr rio melhor transpor a chave que dar origem a uma coluna mais densa isto que ter menos valores nulos RR e ER HB HA Diagrama Relacional gt gt O gt HA 4B ar B Figura 6 2 Tradu o de Relacionamentos 1 1 do Diagrama E R para o Relacional Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 105 erencia Diagrama E R l 1 1 E 0 1 Funcion rio e Departamento Fun 4Dep Fun Diagrama ria Relacional Funcion rio OH Departamento Figura 6 3 Exemplo de Relacionamento 1 1 Drs Mistura M quina Combust vel Uma m quina emprega necessariamente uma mistura combust vel e vice versa Diagrama E R Maq ou fMCo Diagrama Relacional M quina Mistura Combust vel Figura 6 4 Exemplo de um relacionamento 1 1 total em ambos os lados Relacionamentos 1 N Neste caso deve se transpor a chave da tabela correspondente entidades de cardinalidade m xima N para a tabela que representa a entidade cuja cardinalidade m xima 1 como mostra a figura 6 5 o e qu A HB HA Diagrama Relacional Q O Figura 6 5 Tradu o de Relacionamentos 1 N do Diagrama E R para o Relacional Um 4 pode
99. como um todo e n o a funcionalidade espec fica Dependendo da natureza os requisitos n o funcionais Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 52 podem ser classificados de diferentes maneiras tais como requisitos de desempenho requisitos de portabilidade requisitos legais requisitos de conformidade etc 2 5 1 2 O Processo da Engenharia de Requisitos O processo de descobrir analisar documentar e verificar validar requisitos chamado de processo de engenharia de requisitos 2 Os processos de engenharia de requisitos variam muito de uma organiza o para outra mas de maneira geral a maioria dos processos de Engenharia de Requisitos composta das seguintes atividades 4 Levantamento ou Descoberta ou Elicita o 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 descobrir articular e entender a organiza o como um todo o dom nio da aplica o os processos de neg cio espec ficos 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 e restri es existentes os problemas a serem resolvidos o desempenho requerido e as restri es tamb m devem ser levantados An
100. contendo e Prop sito do Sistema enuncia a finalidade do sistema Pode ser acompanhado de uma breve descri o do contexto do sistema mini mundo e Diagramas de Casos de Uso diagramas mostrando os potenciais usu rios do sistema atores e as funcionalidades que lhes s o teis casos de uso e Descri es dos Casos de Uso para cada caso de uso modelado nos Diagramas de Casos de Uso uma descri o especificando o comportamento do sistema no mesmo Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 62 5 4 1 Modelagem de Casos de Uso Vis o Geral e Conceitos Refer ncia 8 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 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 s
101. 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 1 i estabelecer uma escala que reflita a probabilidade de um risco 11 avaliar as consequ ncias dos 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 8 prop e os valores quantitativos mostrados nas tabelas 3 4 e 3 5 para as escalas acima Tabela 3 4 Categorias de Probabilidade 8 Probabilidade Faixa de Valores Baixa at 30 M dia 30 a 70 Alta acima de 70 Tabela 3 5 Categorias de Impacto 8 Impacto Faixa de Valores Baixo de0 a 3 M
102. 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 Os itens mais relevantes para serem submetidos ger ncia de configura o s o aqueles mais usados durante o ciclo de vida os mais gen ricos os mais importantes para seguran a os projetados para reutiliza o e os que podem ser modificados por v rios desenvolvedores ao mesmo tempo 6 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 ser 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 evolu o de cada vers o dos itens 1 6 Ap s a identifica o dos itens de configura o 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 itens de configura o devem ser identificados analisados corrigidos aprovados e armazenados em um local sob controle de acesso denominado reposit rio central base de dados de pr
103. do 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 bastante utilizadas do modelo incremental s o apresentadas na figura 2 4 b e c Na figura 2 4 b 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 1a Dentre as vantagens do modelo incremental podem ser citadas 5 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 5 e Se os requisitos
104. 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 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 Engenharia de Software Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 40 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 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
105. dos altera es no ambiente de processamento necessidade de modifica es em fun es existentes e necessidade de inclus o de novas capacidades Ao contr rio do que podemos pensar a manuten o n o uma atividade 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 Engenharia de Software Cap tulo 8 Entrega e Manuten o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 132 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 maior ou menor dependendo do tipo de manuten o a ser realizada Pfleeger 1 aponta os seguintes tipos de manuten o e 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 sist
106. dos cinco tipos de fun o ALI ATE EE SE e CE s o computados os totais de pontos de fun o NPF segundo a seguinte express o 3 NPF ba NCi E Ci j l 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 gt NPF i l sendo que i varia de 1 a 5 segundo os tipos de fun o existentes AIL AIE EE SE e CE 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 Engenharia de Software Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 138 Comunica o de Dados Processamento de Dados Distribu do Desempenho Utiliza o do Equipamento Rest
107. dos 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 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 fronteiras quantificadas N vel 5 Otimizado A organiza o possui uma base para melhoria continua 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 Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 19 Otimizado N vel 5 Preven o de defeitos Ger ncia de mudan a de tecnologia Ger ncia de mudan a de processo Gerenciado N vel 4 Ger ncia quantitativa do processo Ger ncia de qualidade do software Definido N vel 3 Foco nos processos da organiza o Defini o do processo da organiza o Programa de treinamento Ger ncia do software integrado Engenharia de produto de software Coordena o inter grupos sRepetit vel N vel 2 Revis es Ger
108. dos que comp em os dep sitos de dados fluxos de dados ou estruturas de dados A figura 5 26 apresenta a nota o adotada neste texto para elabora o de Dicion rios de Dados Significado 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 Es atributo determinante Figura 5 26 Nota o para Dicion rios de Dados 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 Cliente cpf nome endere o telefone comercial telefone residencial telefone comercial telefone residencial Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 82 5 7 Modelagem de Estados Diagramas de Estados s o utilizados para descrever o comportamento de uma entidade ou de um relacionamento
109. e 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 para uma implementa o concreta e operacional 1 Uma vez que o processo foi objeto de estudo no cap tulo 2 acreditamos que o leitor j est convencido de sua import ncia para o sucesso de um projeto de software Passemos ent o a considera es sobre as pessoas e o produto Pessoas Refer ncias 1 Cap 3 se o 3 2 2 Cap 22 3 Cap 3 se o 3 2 Em um projeto de software h v rias pessoas envolvidas exercendo diferentes pap is tais como Gerente de Projeto Desenvolvedor Analistas Projetistas Programadores Engenheiros de Testes Gerente da Qualidade Clientes Usu rios O n mero de pap is e suas denomina es podem ser bastante diferentes dependendo da organiza o e at mesmo do projeto 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 luc
110. e 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 4 E 3 1 a x 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 140 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 pelo 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
111. e 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 componente 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 Implementa o 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 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 e os resultados documentados A seguir os diversos componentes devem ser integrados sucessivamente at se obter o sistema Finalmente o sistema como um todo deve ser testado Entrega e Implanta o 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 desta fase Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES U
112. ecessidade 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 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 Sof
113. ectos que julgamos fundamentais para o desenvolvimento de software com qualidade Vale destacar que embora apresentados coletivamente como parte da ger ncia da garantia da qualidade eles t m uma import ncia t o destacada que as principais normas e modelos de qualidade vide cap tulo 2 os tratam como processos individualmente Assim no modelo MPS BR 7 por exemplo garantia da qualidade ger ncia de configura o e medi o s o processos do n vel F Refer ncias 1 R S Pressman Engenharia de Software Rio de Janeiro McGraw Hill 5 edi o 2002 2 I Sommerville Engenharia de Software S o Paulo Addison Wesley 6 edi o 2003 3 S L Pfleeger Engenharia de Software Teoria e Pr tica S o Paulo Prentice Hall 2 edi o 2004 4 R Sanches Documenta o de Software In Qualidade de Software Teoria e Pr tica Eds A R C Rocha J C Maldonado K Weber Prentice Hall 2001 5 J C Maldonado S C P F Fabbri 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 6 R Sanches 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 2001 7 SOFTEX MPS BR Melhoria de Processo do Software Brasileiro Guia Geral Vers o 1 0 2005 Engenharia de Software Cap tulo 5 Levantamento e An
114. ega A entrega n o meramente uma formalidade No momento em que o sistema 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 1 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 ajuda help preferencialmente on line e guias de refer ncia r pida 1 8 2 Manuten o O desenvolvimento de um sistema termina quando o produto entregue 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 2 H muitas causas para a manuten o dentre elas 2 falhas no processamento devido a erros no software falhas de desempenho altera es no ambiente de da
115. egras de tradu o de relacionamentos como mostram os exemplos das figuras 6 9 e 6 10 0 N Diagrama E R est subordinada a Unidade Organizacional UO HUO Superior Diagrama Relacional O Unidade Organizacional NZ Figura 6 9 Exemplo de auto relacionamento 1 N 0 N Diagrama E R Pr l Dis Dis Pr Req Dis Diagrama Relacional Pr Requisito BO Ss Figura 6 10 Exemplo de auto relacionamentos N N Relacionamentos entre uma Entidade e um Agregado J discutimos como fazer a tradu o de um agregado para o modelo relacional Um relacionamento entre uma entidade e um agregado ter o mesmo tratamento que um relacionamento entre entidades considerando agora o agregado como uma entidade Tomemos como exemplo um relacionamento 1 N entre uma entidade e um agregado como mostra o exemplo da figura 6 11 Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 108 Registro Hist rico Diagrama E R Disciplina HAI Al Dis HPer odo HSit HDis Diagrama E doe Relacional Disciplina S HSit Figura 6 11 Exemplo de relacionamento 1 N entre uma entidade e um agregado Relacionamento 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 6 12 Assim como no caso de agregados se existirem a
116. elo 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 devem ser providas 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 sejam de processo sejam de produto s o muito importantes pois eles fornecem um meio de capturar as melhores 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 conforme j sugerido para a defini o de processos padr o 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 4 2 2 Revis es
117. ema funcionando Quando esse for o caso mudan as mais complexas podem ser implementadas posteriormente e 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 e Manuten o perfectiva consiste em realizar mudan as para melhorar algum aspecto do sistema mesmo quando nenhuma das mudan as for consegii ncia de defeitos Isso inclui a adi o de novas capacidades bem como amplia es gerais e 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 1 S L Pfleeger Engenharia de Software Teoria e Pr tica S o Paulo Prentice Hall 2 edi o 2004 2 R Sanches Processo de Manuten o In Qualidade de Software Teoria e Pr tica Eds A R C Rocha J C Maldonado K Weber Prentice Hall 2001 Refer ncia 1 Caps 10 e 11 Engenharia de Software Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 133 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 im
118. ent o ela ocorrer sempre quando o evento ocorrer Embora ambos os termos a o e atividade denotem processos eles n o devem ser confundidos A es s o associadas a transi es e s o consideradas processos instant neos isto ocorrem muito rapidamente n o sendo pass veis de interrup o Atividades s o associadas a estados podendo durar bastante tempo Assim uma atividade pode ser interrompida por algum evento Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 83 5 8 Modelagem Funcional A partir deste momento passaremos a nos preocupar com a modelagem das fun es que o sistema dever executar para atender aos anseios dos usu rios do sistema A t cnica mais difundida para esta finalidade a utiliza o de Diagramas de Fluxo de Dados DFDs proposta por Gane e Sarson em 11 e por De Marco em 12 Muitos outros autores citam esta t cnica em suas obras sendo que destacamos como refer ncias 13 e 6 Um Diagrama de Fluxo de Dados um instrumento para a modelagem de processos que representa 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 5 28 mostra a nota o usada por Yourdon 6
119. ente 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 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 3 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 Por fim o uso de n
120. entos em um modelo ER Entretanto em um DFD n o h uma representa o expl cita dos relacionamentos entre 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 5 42 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 5 42 Acessos a dep sitos de dados 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 5 8 2 Construindo DFDs Como j mencionado no estudo sobre processos uma boa pr tica 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 ou pelo n mero de
121. 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 fun 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 5 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 Conforme apontado anteriormente um aspecto bastante relevante para se especificar o que um sistema deve fazer consiste em decidir como efetuar uma boa divis o do problema A An lise Estruturada prop e que essa divis o seja obtida por meio de uma abordagem top down Embora essa seja uma boa maneira de se atacar um problema complexo partir da vis o geral e ir descendo em uma vis o hier rquica a n veis de detalhes cada vez maiores na pr tica essa abordagem n o se mostrou eficiente como estrat gia para a decomposi o de sistemas A An lise Essencial prop e uma outra forma de particionamento a qual baseada nos eventos e que mostrou ser mais efetiva do que a abordagem top down pois torna mais f
122. eral do Esp rito Santo 117 programas tal como portugu s estruturado tabelas de decis o e rvores de decis o discutidos no cap tulo 5 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 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 5 M dulo Em um DEM um m dulo representado por um ret ngulo dentro do qual est contido seu nome como mostra a figura 6 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 6 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
123. es de garantia da qualidade de software e devem ser realizadas ao longo de todo o processo de desenvolvimento de software 5 Dentre as atividades de controle e garantia da qualidade est o as atividades de Verifica o Valida o e Testes VV amp T 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 de produto e processo 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 atendem ao uso espec fico proposto Por fim os testes de software s o atividades de valida o e verifica o que consistem da an lise din mica do mesmo isto envolvem a execu o do produto de software Uma vez que as atividades de VV amp T s o t o importantes elas devem ser cuidadosamente planejadas dando origem a um Plano de Garantia da Qualidade 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 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 uma quest o imprescind vel para a ger ncia da qualidade a de
124. es tecnol gicas e Modelo de Implementa o passa a considerar as restri es tecnol gicas impostas pela plataforma de hardware e software a ser utilizada para implementar o sistema Podemos perceber que o modelo de implementa o n o corresponde a um modelo de an lise propriamente dito uma vez que considera aspectos de implementa o caracter stica marcante da fase de projeto De fato na abordagem da An lise Essencial esse modelo corresponde a uma esp cie de zona nebulosa entre as fases de an lise e de projeto Por considerarmos que um modelo considerando aspectos da plataforma de implementa o melhor caracterizado na fase de projeto neste texto n o trataremos do modelo de implementa o A An lise Essencial de fato uma evolu o da An lise Estruturada de Sistemas mais especificamente da An lise Estruturada Moderna 6 Os conceitos introduzidos pela An lise Essencial endere avam inicialmente as duas principais dificuldades que os analistas Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 55 enfrentavam com a aplica o da An lise Estruturada a distin o entre requisitos l gicos e f sicos e a aus ncia de uma abordagem para dividir o sistema em partes t o independentes quanto poss vel de modo a facilitar o processo de an lise Durante muito tempo no paradigma estruturado houve grandes debates
125. essaltar 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 Seja o exemplo da figura 6 28 Obter dados Ji O registro A e EOF Ler Registro de Arquivo Figura 6 28 Clareza na comunica o Neste caso n o indicado mover brancos para o registro e se o registro estiver em branco porque acabou o arquivo EOF Com esse artif cio estar se ia mascarando o fluxo de controle De maneira geral n o adianta melhorar dois desses aspectos se estivermos piorando o terceiro Muitas vezes o acoplamento resultante poder ser maior S devemos fazer altera es que melhorem um dos aspectos sem afetar os demais As seguintes orienta es podem servir para apoiar a tomada de decis o 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 ut
126. essos para automatizar a recupera o foram incluidos 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 Aa E a 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 143 10 Reusabilidade a preocupa o com 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 re
127. 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 para B A figura 6 6 mostra um exemplo desta situa o Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 106 lota Diagrama E R 1 1 0 N Departamento o Funcion rio Dep Fun Dep Diagrama Ta Relacional Departamento O Funcion rio Figura 6 6 Exemplo de um relacionamento 1 N Relacionamentos N N No caso de relacionamentos N N agregados ou n o deve se criar uma terceira tabela transpondo as chaves prim rias das duas tabelas que participam do relacionamento N N como mostra a figura 6 7 Se existirem atributos do relacionamento agregado 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 correspondendo ao agregado como ilustra o exemplo da figura 6 8 Diagrama E R Diagrama Relacional Figura 6 7 Tradu o de Relacionamentos N N do Diagrama E R para o Relacional Registro Hist rico Diagrama E R HAI Al 4Dis HPer odo HDis Diagrama Relacional Figura 6 8 Exemplo de relacionamento N N Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 107 Auto Relacionamentos Os auto relacionamentos devem seguir as mesmas r
128. etc dom nio da aplica o tamanho e complexidade do sistema estabilidade dos requisitos caracter sticas da equipe etc 2 2 Modelos de Ciclo de Vida ou Modelos de Processo Um modelo de ciclo de vida ou modelo de processo pode ser visto como uma representa o abstrata de um esqueleto de processo incluindo tipicamente algumas atividades principais a ordem de preced ncia entre elas e opcionalmente artefatos requeridos e produzidos 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 Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 7 projeto deve ser conduzido mas a sua ado o n o o suficiente para guiar e controlar um projeto de software na pr tica Ainda que os processos tenham de ser definidos caso a caso de maneira geral o ciclo de vida de um software envolve pelo menos as seguintes fases Planejamento O objetivo do planejamento de projeto fornecer uma estrutura que possibilite ao gerente fazer estimativas razo veis de recursos custos e prazos Uma vez estabelecido o escopo de software com os requisitos esbo ados uma propost
129. eterminar 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 os usu rios e outras aplica es O escopo de contagem define a parte do sistema funcionalidades a ser contada e 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 o de dados e transacionais bem como sua complexidade simples m dia ou complexa e Contar as 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 ma
130. evento orientado por fluxo de dados FD orientado por controle C e evento temporal T Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 61 Na terceira coluna s o listados os est mulos que apontam para o sistema a ocorr ncia do evento No caso dos eventos orientados por fluxo de dados tipicamente um fluxo de dados representa o est mulo Para os eventos temporais a passagem do tempo considerado um est mulo impl cito n o sendo portanto necess rio represent lo Para os eventos orientados por controle um fluxo de controle informando a solicita o feita ao sistema o principal est mulo Vale lembrar que tanto no caso dos eventos temporais quanto dos eventos orientados a controle fluxos de dados auxiliares podem tamb m fazer parte do est mulo Neste caso eles tamb m devem aparecer na lista o que n o muda a classifica o do evento Por fim as duas ltimas colunas registram a a o a ser feita pelo sistema e a resposta produzida Quando a resposta for interna ao sistema ela escrita entre par nteses Para sistemas de m dio a grande porte a lista de eventos pode ser muito extensa Um bom recurso para tratar a complexidade nesse caso pode ser a constru o de listas de eventos separadas para cada um dos subsistemas identificados Al m disso atividades custodiais que apenas cadastram dados no sistema abran
131. ezes 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 Engenharia de Software Cap tulo 7 Implementa o e Testes Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 130 de teste diferente do local em que ser instalado necess rio realizar testes de instala o Refer ncias 1 R S Pressman Engenharia de Software Rio de Janeiro McGraw Hill 5 edi o 2002 2 I Sommerville Engenharia de Software S o Paulo Addison Wesley 6 edi o 2003 3 S L Pfleeger Engenharia de Software Teoria e Pr tica S o Paulo Prentice Hall 2 edi o 2004 4 J C Maldonado S C P F Fabbri Teste de Software In Qualidade de Software Teoria e Pr tica Eds A R C Rocha J C Maldonado K Weber Prentice Hall 2001 Refer ncias 1 Cap 17 e 18 2 Cap 20 3 Cap 7 e 8 Engenharia de Software Cap tulo 8 Entrega e Manuten o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 131 Cap tulo 8 Entrega e Manuten o Conclu dos os testes 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 eventuais mudan as sejam de car ter corretivo sejam de car ter de evolu o caracterizam se como uma manuten o 8 1 Entr
132. fini o de padr es organizacionais 4 2 1 Padr es Organizacionais Uma vez que a ger ncia da qualidade envolve tanto a qualidade do processo quanto a qualidade do produto devem ser estabelecidos padr es organizacionais de produto e de processo Os padr es de processo s o os ditos processos padr o ou processos padr o especializados discutidos no cap tulo 2 Os padr es de produto por sua vez s o padr es que se aplicam a artefatos produzidos ao longo do processo de software Podem ser dentre outros modelos de documentos roteiros e normas 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 sub se 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 Especifica o de Requisitos e 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 Engenharia de Software Cap tulo 4 Ger ncia da Qualidade de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 45 Quando n o poss vel ou desej vel estabelecer uma estrutura r gida como um mod
133. gendo a inclus o de um novo item altera o de dados de um item existente consulta b sica ao item e exclus o de um item podem ser tratadas como um nico evento Cadastrar Item classificado como orientado a fluxo de dados ainda que a consulta e a exclus o sejam tipicamente eventos orientados por controle A premissa para essa simplifica o que na maioria dos sistemas haver um grande n mero de eventos dessa natureza e que seguem um comportamento bastante padr o e conhecido n o sendo necess rio portanto detalh lo 5 4 Modelagem de Casos de Uso como uma T cnica Alternativa Conforme apontado anteriormente o Modelo Ambiental da An lise Essencial procura representar o que o sistema deve fazer para atender ao seu prop sito segundo uma perspectiva externa vis o de cliente usu rio Esse tamb m o prop sito da Modelagem de Casos de Uso 8 e portanto um modelo de casos de uso pode perfeitamente cumprir os objetivos do modelo ambiental da An lise Essencial 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 9 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 Usando a modelagem de casos de uso podemos ent o substituir o Modelo Ambiental por um Modelo de Casos de Uso
134. gt Entidade1 2 Figura 5 49 Diagrama ER usando a nota o da UML Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo 11 12 13 UFES Universidade Federal do Esp rito Santo 101 Refer ncias 1 R S Pressman Engenharia de Software Rio de Janeiro McGraw Hill 5 edi o 2002 2 I Sommerville Engenharia de Software S o Paulo Addison Wesley 6 edi o 2003 3 S L Pfleeger Engenharia de Software Teoria e Pr tica S o Paulo Prentice Hall 2 edi o 2004 4 D F Togneri Apoio Automatizado Engenharia de Requisitos Cooperativa Disserta o de Mestrado Mestrado em Inform tica da UFES 2002 5 S Pompilho An lise Essencial Guia Pr tico de An lise de Sistemas IBPI Press Editora Infobook Rio de Janeiro 1995 6 E Yourdon An lise Estruturada Moderna Editora Campus 1990 7 C M S Xavier C Portilho Projetando com Qualidade a Tecnologia de Sistemas de Informa o Livros T cnicos e Cient ficos Editora 1995 G Booch J Rumbaugh I Jacobson UML Guia do Usu rio Editora Campus 2000 9 P Chen Gerenciando Banco de Dados A Abordagem Entidade Relacionamento para Projeto L gico McGraw Hill 1990 10 W Setzer Bancos de Dados 2 Edi o Editora Edgard Bl cher 1987 C Gane T Sarson An lise Estruturada de Sistemas Livros T cnicos e Cient ficos Editora 1983 T De Marco An lise Estrutur
135. ham 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 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 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 Exemplo se N mero de Dependentes O ent o Sal rio Fam lia 0 sen o Sal rio Fam lia Sal rio M nimo 3 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 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 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 Exemplo para cada Aluno fa a M dia Prova 1 Prova 2 2 imprima M dia fim para Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 95 2 enquanto lt condi o for verdadeira gt fa a
136. ia pedido Cliente cancela pedido e Evento orientado por controle o est mulo provocado por este tipo de evento a chegada ao sistema de um fluxo de controle o qual apenas notifica o sistema da ocorr ncia do evento Pode haver fluxos de dados complementares associados ao fluxo de controle mas n o por meio da chegada do fluxo de dados que o sistema toma conhecimento da ocorr ncia do evento Esse tipo de evento pode ser nomeado de duas maneiras tendo por base a origem do evento Caso 1 Uma entidade externa envia um comando fluxo de controle para o interior do sistema ativando uma fun o lt Entidade externa que provocou o evento gt lt a o verbo na voz ativa gt lt complemento gt Ex Gerente solicita rela o de clientes Diretoria autoriza o pagamento de uma fatura Caso 2 Uma fun o ativada por um fluxo de controle oriundo de outra fun o interna do sistema lt Sujeito gt lt a o verbo na voz passiva gt Ex N vel de reabastecimento do estoque de um produto atingido e Evento temporal aquele em que o est mulo a chegada ao sistema da informa o de haver passado um determinado intervalo de tempo Esses eventos estimulam as a es que o sistema tem de executar em datas previamente conhecidas isto diariamente mensalmente etc o tempo passa e chega o momento do sistema fazer alguma coisa Pode haver fluxos de dados complementares associados ao evento mas n
137. ica 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 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 ser considerada no modelo ER e ela registrada usando se cardinalidades como mostra a figura 5 6 1 1 Departamento Professor lota Figura 5 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 Relacionamentos podem ser classificad
138. idades do Processo de Software Planejamento Especifica o e Projeto Implementa o Teste e Entrega An lise de Requisitos At 3 De 10a 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 3 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 mesmo para um membro da equipe do projeto 3 4 6 Estimativa de Custo Refer ncias 1 Cap 5 se es 5 6 e 5 7 2 Cap 23 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
139. igura 5 17 nem todo contrato financiado Mas se um contrato for financiado ele ser financiado ou por um banco ou por um fornecedor Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 75 0 N Contrato financia e 0 1 financia Fornecedor Figura 5 17 Exemplo de Conector Ou Opcional Atributos Os atributos s o utilizados para descrever caracter sticas ou propriedades relevantes de entidades e relacionamentos O conjunto de atributos de uma entidade ou relacionamento deve ser e completo deve abranger todas as informa es pertinentes e fatorado cada atributo deve capturar um aspecto em separado e independente os dom nios de valores de atributos devem ser independentes uns dos outros 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 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 mai
140. ilizados como base para a elabora o de casos de teste principalmente nos testes de integra o e de sistema 8 Casos de uso t m dois pap is principais 1 Eles capturam os requisitos funcionais de um sistema Um modelo de caso de uso define o comportamento de um sistema e a informa o associada atrav s de um conjunto de casos de uso O ambiente do sistema definido pela descri o dos diferentes atores Esses atores utilizam ou se comunicam com o sistema atrav s de um n mero de casos de uso 2 Eles oferecem uma abordagem para a modelagem de sistemas Para gerenciar a complexidade de sistemas reais comum apresentar os modelos do sistema em um Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 64 n mero de diferentes vis es Em uma abordagem guiada por casos de uso pode se construir uma vis o para cada caso de uso isto em cada vis o s o modelados apenas aqueles elementos que participam de um caso de uso espec fico Um particular elemento pode claro participar de v rios casos de uso Isto significa que um modelo do sistema completo s visto atrav s de um conjunto de vis es uma por caso de uso Todas as responsabilidades de um elemento de modelo s o encontradas olhando todos os casos de uso onde este tem um papel Al m de serem um instrumento importante na captura dos requisitos de um sistema caso
141. ilizar vari veis locais E inadimiss vel que um m dulo se refira a uma parte interna de outro Em suma para minimizar o acoplamento devemos Passar o menor n mero poss vel de par metros e de prefer ncia apenas dados Quando for necess rio passar fluxos de controle faz lo apenas de baixo para cima Ter pontos nicos de entrada e sa da em um m dulo Sempre que poss vel utilizar programas compilados separadamente Engenharia de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo Coes o define como as atividades de um m dulo est o relacionadas umas com as outras 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 6 29 procura mostrar este fato No projeto modular de programas os m dulos devem ter alta coes o isto seus Cap tulo 6 Projeto de Sistemas 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 capacidade 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 Baixa Coes o F brica de Refrigerantes Tate Vila Velha Conjunto Habitacional da C
142. imples 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 8 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 8 Em ess ncia um caso de uso uma intera o t pica entre um ator usu rio humano outro sistema computacional
143. in 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 4 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 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 4 Assim o objetivo projetar testes que potencialmente descubram diferentes classes de erros e faz lo com uma quantidade m nima de esfor o 1 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 id ia 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 3 S o importantes princ pios de testes a serem observados 1 3 e Teste completo n o poss vel ou seja mesmo para sistemas de tamanho moderado pode ser imposs ve
144. ini es e dos usos das vari veis nos m dulos Testes de ciclo ou la o focalizam exclusivamente os la os loops e Teste de caminho b sico define uma medida de complexidade l gica de um m dulo e usa essa medida como guia para definir um conjunto b sico de caminhos de execu o Assim como h diversas t cnicas de teste caixa branca o mesmo acontece em rela o ao teste caixa preta Dentre as diversas t cnicas de teste caixa preta podem ser citadas 1 e 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 A meta minimizar o n mero de casos de teste ficando apenas com um caso de teste para cada classe uma vez que a princ pio todos os elementos de uma mesma classe devem se comportar de maneira equivalente e An lise de valor limite 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 a an lise de valor limite leva sele o de casos de teste que exercitem os valores lim trofes 7 2 2 Estrat gias de Teste O projeto efetivo de casos de teste importante mas n o suficiente para o sucesso da atividade de testes A estrat gia isto a s rie planejada de realiza o dos testes tamb m crucial 1 Basicamente h tr s grandes fases de teste 4 e Teste de Unidade tem por objetivo testar a menor unidade do pr
145. ionamentos N 1 ou I N normalmente n o s o necess rias Em relacionamentos desta natureza cada entidade cuja cardinalidade m xima 1 Y s aparece no m ximo uma nica vez no relacionamento e consequentemente j representa o par que eventualmente possa ocorrer Assim as duas vers es apresentadas nas figuras 5 14 e 5 15 s o equivalentes quanto s informa es apresentadas e preferimos utilizar sempre a vers o da figura 5 15 representando agrega es apenas em relacionamentos N N Figura 5 14 Agregado em relacionamento 1 N Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 74 0 1 RED 0 N Figura 5 15 Solu o mais apropriada Condicionantes As vezes quer se representar um car ter opcional no que diz respeito totalidade dos relacionamentos Essa restri o pode ser de dois tipos e Ou obrigat rio Apenas um dos relacionamentos ocorre efetivamente mas sempre um deles ocorre No exemplo da figura 5 16 todo contrato financiado n o existe contrato que n o seja financiado mas pode ser financiado ou por um banco ou por um fornecedor Contrato financia 1 1 qu o casi m 0 N financia Fornecedor Figura 5 16 Exemplo de Conector Ou Obrigat rio e Ou opcional Apenas um dos relacionamentos ocorre efetivamente mas pode ser que nenhum dos dois ocorra No exemplo da f
146. is ria Entretanto 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 deve ser preterida em favor do portugu s estruturado ou combinada a ele Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 96 Sem atraso de Tratamento agamento Ee skorpa dO Priorit rio Volume de Tempo de Pioit tio neg cios gt trabalho gt R 1 milh o Com atraso 20 anos de pagamento registrado Tempo de trabalho lt Normal Volume de 20 anos neg cios lt gt gt gt gt Normal R 1 milh o Figura 5 43 Exemplo de rvore de Decis o Tabelas de Decis o Tabelas de decis o s o usadas em aplica es semelhantes s das rvores de decis o As rvores de decis o s o mais indicadas quando o n mero de decis es for pequeno e nem todas as combina es de condi es forem poss veis As tabelas de decis o aplicam se melhor a situa es em que o n mero de a es grande e ocorrem muitas combina es de condi es Tamb m devemos utilizar tabelas de decis o se existirem d vidas de que a rvore de decis o n o mostra toda a complexidade do problema O formato b sico de uma tabela de decis o mostrado na figura 5 44 Nome da Tabela Figura 5 44 Formato b sico de uma T
147. is 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 Contar as 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 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 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 lc
148. itmo 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 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 de 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 acabamento etc 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 trata de aspectos rela
149. itos problemas de altera es do mesmo item de configura o com inten es diferentes e s vezes conflitantes 6 4 4 Medi o e M tricas Refer ncias 1 Cap 4 se es 4 1 4 2 e 4 3 2 Cap 24 se o 24 4 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 1 Quando se trata de avalia o quantitativa quatro conceitos muitas vezes usados equivocadamente com o mesmo sentido s o importantes medida medi o m trica e indicador 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 Quando os dados de um nico ponto s o coletados uma medida estabelecida p ex quantidade de erros descobertos em uma revis o Medi o o ato de medir isto de determinar uma medida J uma m trica procura relacionar medidas individuais com o objetivo de se ter uma id ia da efic cia do processo do projeto ou do produto sendo medido Por fim desenvolve se m tricas para se obter indicadores isto para se ter uma compreens o do processo produto ou projeto sendo medido Seja o seguinte exemplo
150. l 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 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 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 Engenharia de Software Cap tulo 7 Implementa o e Testes Ricardo de Almeida Falbo UFES Universidade Federal do
151. laborado 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 um cronograma e da identifica o e tratamento dos riscos associados ao projeto 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 elaborado medida que o trabalho avan a 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 fundamental acompanhar o progresso do trabalho refinar escopo e estimativas alterar o processo do projeto e o cronograma al m de monitorar riscos e tomar a es corretivas Assim sendo as atividades realizadas sumarizadas na figura 3 1 no planejamento s o novamente consideradas no acompanhamento do projeto que tipicamente se d nos marcos definidos no projeto 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
152. lacionamentos DER geralmente elaborado para o sistema como um todo ou dividido por subsistemas dependendo da complexidade do sistema a Diagramas de Estados Para cada entidade ou relacionamento com atributo do DER que possuir comportamento significativo isto possuir mais de um estado ao longo de seu ciclo de vida um diagrama de estados deve ser elaborado a Diagramas de Fluxos de Dados DFDs Particionados por Eventos Para cada evento do sistema um DFD pode ser elaborado Assim a quantidade de diagramas pode chegar ao n mero de eventos na lista O Diagramas de Fluxos de Dados Organizados em N veis Hier rquicos representa os processos em n veis hier rquicos a partir do diagrama zero Os processos do diagrama zero s o obtidos atrav s do agrupamento de atividades essenciais dos DFDs particionados por eventos Um crit rio de agrupamento bastante razo vel considerar o grau de coes o e acoplamento entre atividades essenciais As seguintes heur sticas podem ser utilizadas em conjunto ou em separado Procurar agrupar em um nico processo todas as atividades essenciais que acessam um determinado dep sito de dados verificando se o processo resultante desse agrupamento adequado para representar uma das fun es do sistema Agrupar todas as atividades custodiais referentes a um mesmo dep sito de dados Procurar identificar uma fun o do sistema agrupando atividades essenciais que interagem com uma mesma en
153. lbo UFES Universidade Federal do Esp rito Santo 63 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 consegiientemente a sua funcionalidade completa Um bom caso de uso compreende uma segii 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
154. lh o de reais em neg cios por ano e possu rem um bom hist rico de pagamentos ou que estiverem conosco h mais de 20 anos devem receber tratamento priorit rio Quem dever receber tratamento priorit rio Clientes com mais de 1 milh o em neg cios por ano que possu rem bom hist rico de pagamentos Clientes com mais de 20 anos Clientes com mais de 1 milh o e ou bom hist rico ou mais de 20 anos Note que pela declara o n o fica claro quando dever ser aplicado o tratamento priorit rio e Uso de Adjetivos Indefinidos Na declara o do item anterior o que um bom hist rico de pagamentos Devemos tomar cuidado ao utilizarmos adjetivos indefinidos Quando o fizermos devemos tomar o cuidado de defini los Para administrar os problemas oriundos da narrativa s o utilizadas t cnicas de especifica o de processos entre as quais podemos citar e Portugu s Estruturado e Tabelas de Decis o e rvores de Decis o e Combina o das t cnicas acima Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 94 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 Instru es de Segii ncia grupo de instru es a serem executadas que n o ten
155. lise Essencial adotada Esse modelo representa o que o sistema deve fazer para atender ao seu prop sito segundo uma perspectiva externa ou seja do usu rio sendo composto dos seguintes artefatos e Prop sito do Sistema enuncia a finalidade do sistema Pode ser acompanhado de uma breve descri o do contexto do sistema mini mundo Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 60 e Lista de Eventos lista de eventos aos quais o sistema deve responder Deve conter pelo menos o nome do evento o est mulo e a resposta externa do sistema e Descri es dos Eventos para cada evento listado na Lista de Eventos uma descri o de como o sistema responder a esse evento ou seja da a o do sistema como uma resposta ocorr ncia do evento deve ser provida e Diagrama de Contexto representa o sistema como um nico processo e suas intera es com o ambiente Pode ser acompanhado de um dicion rio de dados A declara o de prop sito objetivos do sistema deve ser elaborada em poucas frases simples e precisas em linguagem destitu da de vocabul rio t cnico pass vel de entendimento pelos clientes e usu rios do sistema e pela administra o da empresa em geral N o deve fornecer detalhes sobre como o sistema vai operar A lista de eventos o produto principal do levantamento de requisitos quando a An lise Essen
156. lo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 110 Cli Cli Num telefone Figura 6 14 Mapeamento Geral de Atributos Multi valorados 6 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 capta 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 s o apenas algumas das muitas quest es que devem ser levantadas durante o projeto da interface com o usu rio 1 De maneira geral o projeto de interfaces com o usu rio segue o seguinte processo global como mostra a figura 6 15 1 Delinear as tarefas necess rias par
157. lo de qualidade definido na norma ISO IEC 9126 1 trata dessa quest o estando sub dividido em dois modelos o modelo de qualidade para caracter sticas externas e internas e o modelo de qualidade para qualidade em uso O modelo de qualidade para caracter sticas externas e internas 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 sub caracter sticas As sub caracter sticas podem ser desdobradas em mais n veis at se ter sub caracter sticas diretamente mensur veis para as quais m tricas s o aplicadas As normas ISO IEC 9126 2 e 9126 3 apresentam respectivamente m tricas externas e internas Esse modelo de qualidade que preconiza a an lise de caracter sticas de qualidade a partir de suas sub caracter sticas de forma recursiva at que se tenham m tricas para coletar dados aplic vel n o somente a produto 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 objeto em quest o produto ou processo 2 Para cada caracter stica de qualidade selecionada definir sub caracter sticas de qualidade relevantes que tenham influ ncia sobre a mesma estabelecendo um modelo ou f rmula de computar a caracter stica a pa
158. ltera 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 uma 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 5 37 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 5 37 Sem ntica dos acessos a dep sitos de dados em um DFD Quando examinamos fluxos de dados que entram ou saem de um dep sito surge uma d vida o fluxo representa um nico pacote m ltiplos pacotes partes de um pacote ou partes Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 88 de v rios pacotes de dados Em algumas situa es essas d vidas podem ser respondidas pelo simples exame do r tulo do fluxo e para tal adotamos a seguinte conven o e se um fluxo n o possuir r tulo ou tiver o mesmo r tulo do dep sito de dados ent o um
159. m controladas estabelecendo linhas b sicas 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 Engenharia de Software Cap tulo 4 Ger ncia da Qualidade de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 47 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 es nos itens as ltimas vers es dos mesmos e identificadores de libera o 4 3 1 O Processo de GCS O primeiro passo do processo de ger ncia de configura o de software a confec o de um plano de ger ncia
160. ma caixa preta trocando informa es fluxos de dados com entidades externas ao sistema Define o escopo de abrang ncia do sistema indicando que se est renunciando possibilidade de examinar qualquer coisa al m da fronteira definida pelas entidades externas parte integrante do modelo ambiental segundo a An lise Essencial e 0 Zero Geral ou de Sistema uma decomposi o do diagrama de contexto mostrando o funcionamento do sistema em quest o isto as grandes fun es do sistema e as interfaces entre elas Os processos nesse diagrama recebem os n meros 1 2 3 etc necess rio assegurar a coer ncia entre os diagramas C e 0 isto assegurar que os fluxos de dados entrando ou saindo do diagrama 0 efetivamente reproduzem as entradas e sa das do diagrama C No diagrama 0 devem aparecer os dep sitos de dados necess rios para a sincroniza o dos processos e N Detalhe Uma diagrama de detalhe representa a decomposi o de um dos processos do diagrama 0 e portanto nomeado com o n mero e o nome do processo que est sendo detalhado A princ pio dever o ser elaborados diagramas N para os processos do diagrama 0 que sejam complexos e portanto care am de decomposi o necess rio resguardar a coer ncia entre o diagrama 0 e cada diagrama detalhado elaborado Os processos em um diagrama N s o numerados com o n mero do processo que est sendo detalhado p ex 2 e um n mero sequencial se
161. ma 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 o Essas informa es s o capturadas em um DEM e por isso mesmo o DEM empregado no projeto detalhado de m dulos enquanto o DHF usado para o projeto da arquitetura do sistema Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 115 6 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 4 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 di
162. ma 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 plano de projeto plano de qualidade etc registrando requisitos e modelos do sistema documentos de especifica o de requisitos an lise e projeto e apoiando o uso do sistema gerado manual do usu rio ajuda on line tutoriais etc 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 cria o da documenta o t o importante quanto a cria o do software em si 4 H portanto a necessidade de se definir um processo para controlar a documenta o de uma organiza o dito processo de documenta o incluindo atividades de planejamento an lise aprova o ou reprova o identifica o de altera es situa o da revis o atual disponibilidade das vers es pertinentes de documentos aplic veis dentre outras Algumas dessas atividades est o relacionadas com o controle e a garantia da qualidade de software outras
163. 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 2 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 computado em dobro Engenharia de Software Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 39 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 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 custo do projeto e o pre o cotado para o cliente normalmente n o t o simples assim 2 3 5 Ger ncia de Riscos Refer ncias 1 Cap 6 2 Cap 4 se o
164. mo e quando o caso de uso inicia e termina quando o caso de uso interage com os atores e outros casos de uso e quais s o as informa es transferidas e o fluxo b sico e os fluxos alternativos do comportamento 8 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 Conforme discutido no cap tulo 4 a padroniza o da documenta o fundamental para a garantia da qualidade Assim muito importante que haja um padr o de descri o de casos de uso As seguintes informa es devem constar em um padr o desta natureza descri o sucinta do prop sito do caso de uso cursos b sicos do caso de uso cursos alternativos do caso de uso e entidades necess rias para tratar o caso de uso Essa ltima informa o til para permitir rastrear os modelos de casos de uso e os modelos de an lise 5 5 An lise de Requisitos na An lise Essencial Refer ncia 5 Se o 17 2 Conforme discutido na se o 5 2 o m todo da An lise Essencial preconiza que de maneira geral um sistema deve ser modelado atrav s de tr s dimens es
165. mos a observar os exemplos das figuras 6 16 6 17 e 6 18 que mostram tr s organogramas de empresas Presidente Figura 6 16 Organograma da Empresa 1 Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 114 Presidente Funcion rio 1 Funcion rio 2 Funcion rio N Figura 6 17 Organograma da Empresa 2 Figura 6 18 Organograma da Empresa 3 Como podemos notar no organograma da empresa 1 o vice presidente 4 e os gerentes X e Y possuem tarefas triviais pois cada um deles tem como responsabilidade gerenciar apenas um subordinado Neste caso todo servi o seria realizado pelo funcion rio Z Poder amos sugerir ent o acabar com as ger ncias Por outro lado o presidente da empresa 2 est sobrecarregado uma vez que ele gerencia funcion rios demais A empresa 3 parece apresentar um organograma mais equilibrado no qual cada gerente gerencia um n mero apropriado de subordinados As estruturas de um programa ou de um sistema podem ser discutidas de maneira an loga quest o dos organogramas Ou seja 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 4 Neste texto ser o explorados dois deles o Diagra
166. mostra quem chama quem Portanto m dulos devem estar conectados No exemplo da figura 6 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 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 Resultado M dulo Chamado Figura 6 21 Conex o entre m dulos Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 118 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 6 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 fal Liga o de Dados cpf O O dados cliente a x E E 1 cliente inexistente al Liga o de Controle Pesquisar cliente por cpf Figura 6 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
167. mplo de particionamento 1 1 LN lota Engenheiro Secret ria crea l ngua matr cula habilita o Projeto participa de Figura 5 24 Particionamento de um Conjunto de Entidades Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 79 Vale a pena observar que a simbologia utilizada na representa o de entidades relacionamentos e atributos mostrada neste texto n o padronizada isto n o foi definido um padr o nico a ser seguido por todos que utilizam o Modelo ER Assim diferentes textos podem utilizar simbologias diferentes 5 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 ser ocorrer se determinada restri o for satisfeita Um exemplo de restri o de integridade s
168. 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 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 1a 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 nica entrega feita como mostra a figura 2 5 Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 13 Implementa o e Testes An lise Projeto Equipe 1 Implementa o e Testes Especifica o An lise Projeto de Requisitos Entrega e isErie o Implanta o Implementa o e Sistema Testes An lise 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 integr
169. ngenharia de Software Cap tulo 4 Ger ncia da Qualidade de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 48 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 1 6 Por m mesmo com os mecanismos de controle mais bem sucedidos 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 no processo de GCS 1 Essas atividades de garantia da qualidade tentam descobrir omiss es ou erros na configura o e se os procedimentos padr es regulamenta es ou guias foram devidamente aplicados no processo e no produto 6 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 i O que aconteceu ii Quem fez iii Quando aconteceu iv O que mais ser afetado O acesso r pido s informa es agiliza o processo de desenvolvimento e melhora a comunica o entre as pessoas evitando assim mu
170. niversidade Federal do Esp rito Santo 8 estabelecer que o software satisfaz os requisitos dos usu rios Isto feito instalando o software e conduzindo testes de aceita o Quando o software tiver demonstrado prover as capacidades requeridas ele pode ser aceito e a opera o iniciada e Opera o nesta fase o software utilizado pelos usu rios no ambiente de produ o e Manuten o Indubitavelmente o software sofrer mudan as ap s ter sido entregue para o usu rio 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 essa fase pode requerer a defini o de um novo processo onde cada uma das fases precedentes re aplicada no contexto de um software existente ao inv s de um novo Os modelos de processo de maneira geral contemplam as fases 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 Assim importante conhecer alguns modelos de ciclo de vida e em que situa es s o aplic veis Os principais modelos de ciclo de vida podem ser agrupados em tr s categorias principais modelos segiienciais modelos incrementais e modelos evolutivos
171. nte 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 subseq entes 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 4 mostra as principais possibilidades Levantamento An lise e Preliminar de Especifica o Requisitos de Requisitos Unidade Planejamento Entrega e Testes Implanta o Projeto Vers o Operacional a j Especifica o de Requisitos Entrega e Implanta o An lise Teste de Testes Unidade Vers o b Operacional An lise e Especifica o de Requisitos Entrega e Implanta o Projeto da Testes Arquitetura Detalhado Unidade Vers o c Operacional Figura 2 4 Varia es do Modelo Incremental Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 12 Na figura 2 4 a 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 Conclu do o primeiro ciclo todas as atividades s o novamente realizadas para o segun
172. 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 um 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 valores 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 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
173. o basta coletar dados aleatoriamente Para que possam ser usados eficientemente esses 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 m tricas 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 teriamos uma m trica 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 m trica 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 natureza os resultados da medi o permitem uma comunica o efetiva com os v rios interessados no desenvolvimento A falta de m tricas 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 m tricas 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
174. 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 criticos 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 g Ze Nenhuma restri o operacional expl cita ou mesmo impl cita foi inclu da Existem restri es operacionais leves N o necess rio esfor o especial para atender s restri es Algumas considera 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
175. o para da figura 5 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 muito menos corriqueiros Um relacionamento tern rio por exemplo s se caracteriza pelo terno como mostra a figura 5 9 Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 71 Os relacionamentos tern rios normalmente s o dificeis de se dar um nome e por isso usual represent los pelas iniciais das tr s entidades envolvidas como mostra o exemplo da figura 5 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 gt C Rc a b c ac A be B ce C Figura 5 9 Relacionamento Tern rio 0 N 0 N Material Fornecedor Figura 5 10 Exemplo de Relacionamento Tern rio Alguns relacionamentos s o t o importantes que assumem o status de entidades No modelo ER esses relacionamentos s o chamados de agrega o ou agregados Assim uma agrega o uma abs
176. o relacional pode se utilizar como ponto de partida as seguintes diretrizes e Entidades e agregados devem dar origem a tabelas e Uma inst ncia de uma entidade ou de um agregado deve ser representada como uma linha da tabela correspondente Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 104 e Um atributo de uma entidade ou agregado 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 ou agregado 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 exemplo da figura 6 2 ambas as solu es s o igualmente v lidas Deve se observar para cada caso contudo a melhor solu o considerando os seguintes aspectos 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 6 3 e Se B for total em R todo B est associado a um A melhor
177. o02 pdfl ltimo acesso 13 05 2004
178. 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 tem de ser temporalmente posterior sua data de admiss o Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 81 5 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 de todos os itens de dados manipulados pelo sistema Esta listagem cont m em ordem alfab tica as seguintes defini es e entidades e relacionamentos com atributos de um DER e dep sitos de dados e fluxos de dados dos DFDs sendo que os primeiros devem corresponder s entidades e relacionamentos do DER e estruturas de dados que comp em os dep sitos de dados ou fluxos de dados e elementos de da
179. oftware em uma abordagem de Engenharia de Software envolve diversas atividades que podem ser classificadas quanto ao seu prop sito em Atividades de Desenvolvimento ou T cnicas ou de Constru o s o as atividades diretamente relacionadas ao processo de desenvolvimento do software ou seja que contribuem diretamente para o desenvolvimento do produto de software a ser entregue ao cliente S o exemplos de atividades de desenvolvimento especifica o e an lise de requisitos projeto e implementa o Atividades de Ger ncia de Projeto s o aquelas relacionadas ao planejamento e acompanhamento gerencial do projeto tais como realiza o de estimativas elabora o de cronogramas an lise dos riscos do projeto etc Atividades de Garantia da Qualidade s o aquelas relacionadas com a garantia da qualidade do produto em desenvolvimento e do processo de software utilizado tais como revis es e inspe es de produtos intermedi rios ou finais do desenvolvimento As atividades de desenvolvimento formam a espinha dorsal do desenvolvimento e de maneira geral s o realizadas segundo uma ordem estabelecida no planejamento As atividades de ger ncia e de controle da qualidade s o muitas vezes ditas atividades de apoio pois 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 Essas atividades normalmente s o realizadas ao longo de todo
180. oftware Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 36 identificados ou seja o n mero de PFs n o ajustados dado por nPF 35 nALI 15 nATE 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 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 nPF 7 4 nALI 5 5 nAIE 4 3 nEE 5 4 nSE 3 8 nCE No caso da Contagem Estimativa da NESMA os pesos s o um pouco diferentes sendo o n mero de PFs n o ajustados dado por nPF 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
181. oftware Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 59 5 2 2 Especifica o da Ess ncia do Sistema Refer ncia 5 Cap tulo 17 A An lise Essencial sugere a constru o de dois modelos principais o modelo essencial e o modelo de implementa o Conforme discutido anteriormente entendemos que apenas o modelo essencial deve ser objeto da fase de an lise e assim discutiremos apenas a especifica o da ess ncia do sistema A especifica o da ess ncia do sistema produto das atividades de levantamento e an lise de requisitos composta de dois modelos como mostra a figura 5 1 e Modelo Ambiental define a fronteira entre o sistema e o resto do mundo Oferece uma perspectiva externa do sistema e o principal produto da atividade de levantamento de requisitos e Modelo Comportamental define o comportamento do sistema necess rio para interagir com o ambiente Explora caracter sticas internas do sistema e o principal produto da atividade de an lise de requisitos An lise Essencial Modelo Modelo de Essencial Implementa o Modelo Modelo Ambiental Comportamental Figura 5 1 A An lise Essencial e seus Modelos 5 3 Levantamento de Requisitos e An lise Essencial Refer ncia 5 Se o 17 1 Conforme apontado acima o Modelo Ambiental o principal produto da atividade de levantamento de requisitos quando a An
182. ois conceitos registros l gicos e itens de dados Registros L gicos 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 ALI ATE 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 ATE 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 136 Tabela A 1 Tabela de Identifica o da Complexidade das Fun es de Dados N mero de Itens de Dados Referenciados N mero de Registros L gicos De 1a 19 De 20 a 50 51 ou mais 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 feit
183. ojeto um componente de software que n o pode ser subdividido procurando identificar erros de l gica e de implementa o em cada m dulo separadamente No paradigma estruturado a menor unidade refere se a um procedimento ou fun o 3 r r g r Um caminho independente qualquer caminho ao longo de um m dulo que introduz pelo menos um novo comando de processamento ou condi o 1 Engenharia de Software Cap tulo 7 Implementa o e Testes Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 128 e Teste de Integra o visa a descobrir erros associados s interfaces entre os m dulos quando esses s o integrados para formar estrutura do produto de software e Teste de Sistema tem por objetivo identificar erros de fun es requisitos funcionais e caracter sticas de desempenho requisito n o funcional que n o estejam de acordo com as especifica es Tomando por base essas fases a atividade de teste pode ser estruturada de modo que em cada fase diferentes tipos de erros e aspectos do software sejam considerados 4 Tipicamente os primeiros testes focalizam componentes individuais e aplicam testes caixa branca e caixa preta para descobrir erros 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 alto n vel executada
184. ojeto ou biblioteca de projeto Assim quaisquer altera es nos itens da em diante s poder o ser realizadas atrav s de procedimentos formais de controle de modifica o 1 6 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 itens de configura o que s o criados durante o processo de software 1 6 A id ia que a cada modifica o que ocorra em um item de configura o 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 6 Talvez a mais importante atividade do processo de GCS o controle de altera es que combina procedimentos humanos e ferramentas automatizadas para o controle das altera es realizadas nos itens de configura o 1 Assim que uma altera o solicitada o impacto em outros itens de configura o e o custo para a modifica o devem ser avaliados Um respons vel deve decidir se a altera o poder 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 itens de configura o 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 E
185. omes significativos para vari veis indicando sua utiliza o e significado 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 3 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 3 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 deva ter certa flexibilidade para implement lo como c digo 3 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 Engenharia de Software Cap tulo 7 Implementa o e Testes Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 125 7 2 Testes Uma vez implementado o c digo de uma aplica o o mesmo deve ser testado para descobrir tantos defeitos quanto poss vel antes da entrega do produto de software ao seu cliente Conforme discutido no cap tulo 4 o teste uma atividade de verifica o e valida o do software e consiste na an lise d
186. ontrata o de servi os de desenvolvimento e manuten o de software Dois modelos de contrata o s o bastante difundidos atualmente 6 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 esses 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 baseado 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 6 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 m
187. or necess rio seguir uma s rie de passos previs veis isto um guia que ajude a chegar a um resultado de qualidade dentro do tempo previsto la No caso do desenvolvimento de software esse guia o processo de software 2 1 O que um processo de software Um processo de software pode ser visto como o conjunto de atividades m todos pr ticas e transforma es que guiam pessoas 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 Elementos que comp em um processo de software Os processos de software s o geralmente decompostos em diversos processos 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 sub atividades as atividades que devem preced las pr atividades os artefatos de entrada insumos e de sa da produtos da atividade os recursos necess rios humanos hardware software etc e os procedimentos m todos t cnicas modelos de documento etc a serem utilizados na sua realiza o A figura 2 1 mostra os elementos que comp em um processo de forma esquem tica P
188. or 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 Assim sendo as atividades de levantamento e an lise de requisitos s o conduzidas tomando por base esse paradigma mais especificamente utilizando os conceitos da An lise Essencial de Sistemas 5 2 An lise Essencial de Sistemas Refer ncia B sica 5 O m todo da An lise Essencial de Sistemas 5 preconiza que de uma forma geral um sistema deve ser modelado atrav s de tr s dimens es e dados diz respeito aos aspectos est ticos e estruturais do sistema e controle leva em conta aspectos temporais e comportamentais do sistema e fun es considera a transforma o de valores Em rela o ao grau de abstra o a An lise Essencial considera dois n veis o n vel essencial e o n vel de implementa o representados respectivamente pelos seguintes modelos e Modelo Essencial representa o sistema num grau de abstra o completamente independente de restri
189. os 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 Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 86 dados novo Setor de cliente Cadastrar Pessoal cliente dados cliente clientes Figura 5 32 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 5 32 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 5 33 dados novo Setor de cliente Cadastrar Pessoal cliente clientes Figura 5 33 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 Setas ramificadas significam que o mesmo fluxo de dados est indo de uma fonte para dois destinos diferentes isto c pias do mesmo pacote de dados est o sendo enviadas para diferentes partes do sistema como mostra a figura 5 34 ES Figura 5
190. os em rela o cardinalidade m nima em relacionamentos totais e parciais Dizemos que R um relacionamento total em A se e somente se VaeA4 JbeB a b e R isto todo elemento de A tem de participar obrigatoriamente de R e consegiientemente a cardinalidade m nima de R em rela o a A 1 Por outro lado dizemos que R um relacionamento parcial em A see somente se IJ ae A VW be B a b gR isto nem todo elemento de A participa de R e consegiuentemente a cardinalidade m nima de R em rela o a A 0 Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 70 E importante frisar que entre duas entidades podem existir v rios relacionamento diferentes como mostra o exemplo da figura 5 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 5 8 1 1 13 N Disciplina pr requisito para p s requisito Figura 5 8 Exemplo de auto relacionamento No caso de auto relacionamentos til distinguir qual 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 requisit
191. 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 Nada mais externo ao sistema deve ter impacto sobre o sistema 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 Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Fa
192. p rito Santo 77 1 Fixa se um produto por exemplo impressora e varia se os fornecedores desse produto Evidentemente o valor do atributo pode mudar Por exemplo a Casa do Analista vende uma impressora 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 uma impressora por R 350 e um microcomputador por R 1 700 Como o valor do atributo variou para 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 conjuntos de entidades como mostra a figura 5 22 0 N LN lt R fornece Figura 5 22 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
193. parados por um ponto p ex 2 1 2 2 etc e E Detalhe Expandido um diagrama deste tipo representa a decomposi o de um dos processos do diagrama N Esse n vel de decomposi o pode vir a ser necess rio caso um processo do n vel N ainda for muito complexo Esse n vel pode ser desdobrado sucessivamente at se atingir o grau necess rio de simplicidade Entretanto se muitos n veis forem necess rios cuidado Provavelmente o Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 92 contexto funcional da aplica o diagrama de contexto est muito abrangente e merece revis o Fiss o ou Explos o Recomenda se o uso da fiss o para sistemas de pequeno a m dio porte em que a leitura do diagrama n o fica prejudicada pelo aparecimento de mais alguns processos no diagrama de sistema 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 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 Os processos devem ser numerados de acordo com o diagrama a que pertencem
194. plementada sob o ponto de vista do usu rio Os 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 134 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 funcionalidade
195. processador dedicado para executar a aplica o Al m das caracter sticas 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 2 0S N o est o previstos periodos 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 141 6 Entrada de dados on line 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 0 Todas as transa es s o processadas em modo batch De 1 a 7 das transa es s o entr
196. processo de Engenharia de Requisitos anteriormente listadas as tr s ltimas s o na realidade instancia es para a Engenharia de Requisitos de atividades gen ricas j discutidas no cap tulo 4 a saber documenta o garantia da qualidade e ger ncia de configura o Assim sendo neste cap tulo somente as duas primeiras atividades Levantamento e An lise de Requisitos s o discutidas Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 53 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 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 elas devem satisfazer A an lise de requisitos muitas vezes ch
197. processos em um diagrama Se tal n vel de complexidade for superado devemos utilizar uma das seguintes t cnicas para decompor o DFD fiss o ou explos o Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 91 Fiss o Na fiss o o processo complexo deve ser substitu do no pr prio DFD do sistema por um n mero de processos mais simples Por exemplo se um processo requer 8 p ginas de especifica o de l gica ele pode ser substitu do por 4 processos cada um deles tendo aproximadamente 2 p ginas O problema na utiliza o dessa t cnica a sobrecarga a que o diagrama poder ficar sujeito dificultando sua leitura 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 Quando a explos o utilizada alguns aspectos importantes devem ser observados O primeiro deles diz respeito ao n mero de n veis que devem ser esperados em um sistema A priori esse n mero n o deve ser pr fixado mas lembre se que o n mero total de processos cresce exponencialmente quando se passa de um n vel para o imediatamente inferior Tipicamente s o quatro os n veis de representa o e C Contexto mostra o sistema como u
198. quando o sistema estiver operacional visando a descobrir erros nos requisitos 1 3 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 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 4 A abordagem de integra o de m dulos pode ter impacto na quantidade de drivers e stubs a ser constru da Sejam as seguintes abordagens e Integra o ascendente ou bottom up Nessa abordagem primeiramente cada m dulo no n vel inferior da hierarquia do sistema testado individualmente 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 3 Neste caso apenas drivers s o necess rios Seja o exemplo da figura 7 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
199. que os aspectos f sicos de um sistema est o ligados tecnologia de implementa o a An lise Essencial com o objetivo de facilitar a identifica o dos detalhes l gicos do sistema adota uma abstra o da tecnologia de implementa o denominada tecnologia perfeita A tecnologia perfeita n o possui limita es isto existe um processador perfeito capaz de executar qualquer processamento de forma instant nea sem qualquer custo sem consumir energia sem gerar calor sem jamais cometer erros ou parar de funcionar e um reposit rio perfeito capaz de armazenar quantidades infinitas de dados e de ser acessado instantaneamente por qualquer processador da forma que for mais conveniente Naturalmente n o existe uma tecnologia de implementa o com tais caracter sticas Ent o qual a utilidade dessa abstra o Quando o analista pensa em aspectos f sicos ele est na verdade tentando identificar e resolver as limita es de uma determinada tecnologia Pensamentos t picos do g nero s o quanto de espa o em disco vou precisar Qual o melhor m todo de acesso aos dados considerando as fun es do sistema De que capacidade de processamento devo necessitar Contudo nenhuma dessas preocupa es pr pria da fase de an lise Considerando que a tecnologia a ser utilizada na implementa o do sistema perfeita todas as perguntas anteriores deixam de ter import ncia e portanto n o precisam estar no foco do analist
200. quipe de desenvolvimento 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 desordenadamente As estimativas podem ser consideradas a funda o para todas as outras atividades de planejamento de projeto Para alcan ar boas estimativas de prazo esfor o e custo existem algumas op es 1 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 fase de planejamento do projeto No entanto deve se reconhecer que quanto mais tarde for feita a estimativa maior o conhecimento do projeto e menores as chances de se cometer erros Assim fundamental revisar as estimativas na medida em que o projeto avan a atividades de acompanhamento do projeto T cnicas de decomposi o a segunda op o usam conforme discutido anteriormente 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 p
201. ra o seu registro p ex uma interface com o usu rio ou um registro em bancos de dados A an lise de transa o uma estrat gia de projeto alternativa para a an lise de transforma o Ela til no projeto de programas de processamento de transa es O DEM geral para a an lise de transa o mostrado na figura 6 27 No topo do diagrama est um m dulo centro de transa o que respons vel pela determina o do tipo de transa o e pela chamada do m dulo de transa o apropriado Abaixo dele est o os v rios m dulos de transa o H um m dulo de transa o para cada tipo de transa o 4 M dulo Centro de Transa o lt gt zal transa o Transa o Transa o Transa o dados transa o Ca O dados transa o Da Tipo 1 Tipo 2 Tipo n Figura 6 27 An lise de Transa o 6 3 2 Crit rios de Qualidade de Projetos de Programa 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 Acoplamento 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
202. rativos que congrega profissionais atuando na rea de ger ncia de projetos 5 Engenharia de Software Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 26 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 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 organiza o estrutura da equipe e coordena o Al m disso h diversos fatores que afetam a forma o de equipes relacionamentos inter pessoais tipo do projeto criatividade etc No que se refere organiza o estrutura das equipes h diversos tipos de equipes tais como os citados por Pressman 1 e Democr tica Descentralizada N o tem um l der permanente e as decis es s o tomadas por consenso do grupo A comunica o entre os membros da equipe horizontal e Controlada Descentralizada H um l der do projeto mas a comunica o ainda horizontal e Controlada Centralizada
203. rdware e software no qual o sistema ser implementado Essas caracter sticas s o dependentes unicamente das necessidades do usu rio Modelos conceituais s o constru dos na atividade de an lise de requisitos l gico caracter sticas dependentes de um determinado tipo de sistema computacional Essas caracter sticas s o contudo independentes de produtos espec ficos Tais modelos s o t picos da fase de projeto fisico caracter sticas dependentes de um sistema computacional espec fico isto uma linguagem e um compilador espec fico 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 quanto na fase de implementa o Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 54 Conforme apontado acima 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 Nas etapas posteriores as caracter sticas l gicas e f sicas s o representadas em novos 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 P
204. re 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 139 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 pisema dever o ser descritos de forma global Descrever se a aplica o utiliza protocolos 0 Dg diferentes para recebimento envio das informa es do sistema 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 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 s
205. requisitos n o funcionais tais como desempenho confiabilidade etc Para que o escopo de 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 Um instrumento til para mostrar as funcionalidades do sistema um diagrama de casos de uso Em ess ncia um diagrama de casos de uso mostra o sistema segundo uma perspectiva externa na qual atores usu rios ou outros sistemas aparecem interagindo com as fun es do sistema casos de uso como ilustra a figura 3 2 A t cnica de modelagem de casos de uso ser estudada com mais detalhes no cap tulo 5 Cadastrar Livro C gt Consultar Acervo Bibliotec rio Cadastrar Exemplar C gt Usu rio C gt Cadastrar Assunto Gerar Relat rio Gerencial para Aquisi o de Livro Figura 3 2 Exemplo de um Diagrama de Casos de Uso Preliminar de um Sistema 2 A atividade de levantamento de requisitos ser estudada com mais detalhes no cap tulo 5 Engenharia de Software Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 30 3 4 Estimativas Refer ncias 1 Cap 5 2 Cap 23 3 Cap 3 se o 3 3 Antes mesmo de serem iniciadas as atividades t cnicas de um projeto o gerente e a e
206. ri es de Recursos Computacionais Volume de Transa es Entrada de Dados On line Efici ncia do Usu rio Final Usabilidade 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 DO ON nc da Do 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 NIT 14 NIT 5 GI i 1 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 es instaladas Para projetos de desenvolvimento o c lculo dado por PF PFNA 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 Softwa
207. rocesso Assim a estrutura de divis o de trabalho como a mostrada na Tabela 3 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 ou pontos de fun o 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 podem ser teis como um ponto de partida para organiza es que ainda n o t m dados hist ricos at que a organiza o possa 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 Atrav 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 Vale frisar que essas abordagens n o s o excludentes muito pelo contr rio O
208. rocesso de Software Processos Atividades Pr atividades Sub atividades Artefatos Insumos Produtos Recursos Recursos Humanos Ferramentas de Software Hardware Procedimentos M todos T cnicas Roteiros Figura 2 1 Elementos que comp em um Processo de Software Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 6 Defini o de Processos 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 Um processo de software n o pode ser definido de forma universal Para ser eficaz e conduzir constru o de produtos de boa qualidade um 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 desenvolvido 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 atividades chave desse processo an lise e especifica o de requisitos
209. rtir das sub caracter sticas F rmulas baseadas em peso s o bastante utilizadas cq p scqi Pn sCqn 3 Usar procedimento an logo ao anterior para as sub caracter sticas n o pass veis de mensura o direta 4 Para as sub caracter sticas diretamente mensur veis selecionar m tricas coletar medidas e computar as m tricas segundo a f rmula ou modelo estabelecido 5 Fazer o caminho inverso agora computando sub caracter 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 Vale destacar que especialmente no caso da avalia o da qualidade de software m tricas relacionadas a defeitos s o bastante teis tal como n mero de erros ponto de fun o Engenharia de Software Cap tulo 4 Ger ncia da Qualidade de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 50 O nico modo racional de melhorar um processo medir atributos espec ficos obter um conjunto de m tricas significativas baseadas nesses atributos e usar os valores das m tricas para fornecer indicadores que conduzir o um processo de melhoria 1 4 5 Considera es Finais Neste cap tulo foram discutidos alguns asp
210. ry Conceitos e Vocabul rio prov uma introdu o geral dos conceitos de avalia o de processos e um gloss rio de termos relacionados e Part 2 Performing an Assessment Realizando uma Avalia o estabelece os requisitos m nimos para se realizar uma avalia o Essa parte a nica que tem car ter normativo e Part 3 Guidance on Performing an Assessment Orienta es para se Realizar uma Avalia o prov orienta es para se interpretar os requisitos para realiza o de uma avalia o e Part 4 Guidance on use for Process Improvement and Process Capability Determination Orienta es para Uso em Melhoria de Processo e Determina o da Capacidade de Processo fornece orienta es para utiliza o dos resultados de uma avalia o nos contextos melhoria de processo e determina o da capacidade de processo Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 18 Part 5 An exemplar Process Assessment Model Um Exemplo de Modelo de Avalia o de Processo cont m um exemplo de modelo de avalia o de processo baseado no modelo de refer ncia da ISO IEC 12207 Os Modelos CMM e CMMI O Modelo de Maturidade e Capacidade Capability Maturity Model CMM 9 foi desenvolvido no Instituto de Engenharia de Software Software Engineering Institute SED da Universidade de Carnegie Mellon com o intuito de quantificar a capa
211. s a ser contada e 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 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
212. s al m de atividades e tarefas Os processos da ISO IEC 12207 s o agrupados em tr s categorias de processo a saber Processos Fundamentais Processos de Apoio e Processos Organizacionais Al m desses h um processo de adapta o que como o nome indica trata da adapta o da norma cultura e aos aspectos espec ficos de uma organiza o Os processos fundamentais constituem um conjunto de cinco processos que atendem aos adquirentes fornecedores desenvolvedores operadores e mantenedores do software durante o seu ciclo de vida S o eles os processos de Aquisi o Fornecimento Desenvolvimento Opera o e Manuten o Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 17 Um processo de apoio auxilia um outro processo como parte integrante com um prop sito distinto contribuindo para o sucesso e qualidade do projeto de software Em outras palavras um processo empregado ou executado por outro processo quando necess rio S o processos de apoio Documenta o Ger ncia de Configura o Garantia da Qualidade Verifica o Valida o Revis o Conjunta Auditoria Resolu o de Problemas Usabilidade e Avalia o do Produto Os processos organizacionais s o empregados por uma organiza o para melhorar continuamente a sua estrutura e os seus processos Eles s o tipicamente empregados fora do dom nio de projetos e contratos espe
213. s anteriormente executados O Projeto Modular de Programas oferece uma cole o de orienta es t cnicas estrat gicas e heur sticas procurando conduzir a bons projetos de programas O objetivo desenvolver programas com menor complexidade usando o princ pio dividir para conquistar Como resultados de um bom projeto de programas tem se Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 112 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 manuten o O projeto estruturado de sistemas em sua dimens o de fun es considera que o projeto de programas envolve duas grandes etapas 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
214. s 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 Por exemplo 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 um elemento do conjunto dito um atributo determinante Atributos determinantes s o sublinhados como forma de destaque A figura 5 18 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 Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 76 Funcion rio telefone matr cula Figura 5 18 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 ent o s o v lidas Atributos de relacionamentos s o
215. s de uso t m um papel fundamental no planejamento e controle de projetos iterativos A captura dos casos de uso a primeira atividade a ser realizada no desenvolvimento propriamente dito A maioria dos casos de uso normalmente gerada durante a fase de levantamento de requisitos mas outros casos de uso podem ser descobertos medida que o trabalho prossegue Todo caso de uso um requisito potencial e enquanto um requisito n o capturado n o poss vel planejar como trat lo Usualmente em primeiro lugar casos de uso s o listados e discutidos para s ent o se realizar alguma modelagem Entretanto em alguns casos a modelagem conceitual ajuda a descobrir casos de uso raz o pela qual as atividades de levantamento e an lise de requisitos guardam um certo paralelismo entre si 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 c
216. s eventos da lista que sejam mais complexos e que estejam intimamente ligados ao prop sito do sistema Para os demais as descri es dos eventos providas no modelo ambiental s o suficientes 5 9 Simplificando a An lise de Requisitos Quando modelos de casos de uso s o usados no levantamento de requisitos se o 5 4 j estamos tratando o sistema por uma perspectiva funcional 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 ligados a eles 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 Para a maior parte das situa es modelos de casos de uso
217. s 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 1a 2 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 para ajudar engenheiros de software e clientes a entender o que est sendo constru do quando os Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 15 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 3 An lise e Especifica o de Requisitos Projeto Teste de Unidade A Entrega e Implanta o Figura 2 7 O Modelo em Cascata com Prototipa o 2 3 Normas e Modelos de Qualidade de Processo de Software
218. s modelos de processo discutidos anteriormente 4 A R C Rocha J C Maldonado K C Weber Qualidade de Software Teoria e Pr tica S o Paulo Prentice Hall 2001 O Cap tulo 1 Normas e Modelos de Qualidade de Processo apresenta sucintamente as principais normas ISO IEC 12207 ISO 9000 ISO IEC 15504 e modelos de qualidade de processo CMM J o Cap tulo 12 Automatiza o da Defini o de Processos de Software trata do modelo para defini o de processos de software em n veis 5 M J Christensen R H Thayer The Project Manager s Guide to Software Engineering Best Practices Wiley IEEE Computer Society Press 2002 6 NBR ISO 9000 Sistemas de Gest o da Qualidade ABNT 2000 7 NBR ISO IEC 12207 Tecnologia da Informa o Processos de Ciclo de Vida ABNT 1998 Emenda 1 2002 Emenda 2 2004 8 ISO IEC 15504 Information Technology Process Assessment 2003 2004 9 S T Fiorini A Von Staa R M Baptista Engenharia de Software com CMM Brasport 1998 10 M B Chrissis M Konrad S Shrum CMMI Guidelines for Process Integration and Product Improvement Addison Wesley 2003 11 SOFTEX MPS BR Melhoria de Processo do Software Brasileiro Guia Geral Vers o 1 0 2005 Engenharia de Software Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 25 Cap tulo 3 Ger ncia de Projetos de Software Antes de contrat
219. s 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 Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 29 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 segii ncia cada uma das atividades inerentes ao planejamento e acompanhamento de projetos discutida com exce o da defini o do processo de software do projeto j discutida no cap tulo 2 3 3 Determina o do Escopo do Software A primeira atividade de ger ncia em um projeto de software consiste na determina o do escopo do software a ser desenvolvido 1 Basicamente o escopo do produto composto pela especifica o de um conjunto de funcionalidades requisitos funcionais associada a outras caracter sticas desejadas
220. scendente respectivamente para as camadas localizadas abaixo e acima da camada alvo Outra possibilidade testar individualmente cada m dulo e s depois de testados individualmente integr los teste big band Neste caso 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 3 Uma vez integrados todos os m dulos do sistema parte se para os testes de sistema quando se busca observar se o software funciona conforme esperado pelo cliente Por isso mesmo muitas vezes os testes de sistema s o chamados de testes de valida o Os testes de sistema incluem diversos tipos de teste realizados na seguinte ordem 3 Teste funcional verifica se o sistema integrado realiza as fun es especificadas nos requisitos Teste de desempenho verifica se o sistema integrado atende os requisitos n o funcionais do sistema efici ncia seguran a confiabilidade etc Teste de aceita o os testes funcional e de desempenho s o ainda realizados por desenvolvedores entretanto necess rio que o sistema seja testado pelos clientes No teste de aceita o os clientes 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 queria o cliente Assim o teste de aceita o assegura que o sistema solicitado o que foi constru do Teste de instala o algumas v
221. se o 2 3 3 Cap 3 se o 3 1 Uma boa ger ncia de projetos come a com a fus o das vis es de produto e processo Cada fun o ou m dulo a ser desenvolvido pela equipe do projeto deve passar pelas v rias Engenharia de Software Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 27 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 de divis o do trabalho Work Breakdown Structure WBS considerando essa duas dimens es produto e processo como mostra a Tabela 3 1 Tabela 3 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 3 2 O Processo da Ger ncia de Projetos de Software Conforme discutido no cap tulo 2 o processo de software composto de diversos processos dentre eles o processo de ger ncia de projetos Tipicamente um processo de ger ncia de projetos envolve tr s atividades principais Planejamento no in cio do projeto um plano organizado de como o projeto ser conduzido deve ser e
222. sfa 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 Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 16 e NBR 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 NBR ISO 19011 fornece diretrizes sobre auditoria de sistemas de gest o da qualidade e ambiental A ISO 9000 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 9000 por uma empresa significa que a mesma alcan ou um padr o internacional de qualidade em seus processos 4 O principal problema para se adotar essa norma precisamente o fato dela ser geral Assim quando aplicada ao contexto da ind stria de software mui
223. 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 o sta ia Engenharia de Software Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 142 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 0S 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 arquivos 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 Proc
224. so o MPS BR tamb m cobre o conte do do CMMI 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 conformidade com o MPS BR Define tamb m os n veis de maturidade e da 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 o para melhoria de forma a atender os objetivos de neg cio A Tabela 2 1 mostra os n veis de maturidade do MPS BR e seus processos Engenharia de Software Cap tulo 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito
225. stornos 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 5 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 com as atividades de garantia da qualidade de software As atividades da GCS podem ser resumidas em e Planejamento da GCS Um plano deve ser elaborado descrevendo as atividades da ger ncia de configura o procedimentos e respons veis pela execu o dessas atividades e Identifica o da Configura o refere se identifica o dos itens de software e suas vers es a sere
226. tados 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 clientes valida 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 segiienciais 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 3 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 veremos
227. tados 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 1 3 4 4 Aloca o de Recursos Refer ncias 1 Cap 5 se o 5 4 2 Cap 22 se o 22 3 Estimar os recursos necess rios para realizar o esfor o de desenvolvimento outra importante tarefa Quando falamos em recursos estamos englobando pessoas hardware e software No caso de software devemos pensar em ferramentas de software tais como ferramentas CASE ou software de infra estrutura p ex um sistema operacional 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 software 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
228. 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 refei es sobremesas e bebidas Com base nesse escopo e considerando que cada subsistema deve ser implementado como uma aplica o execut vel poder amos construir o DHF mostrado na figura 6 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 6 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 Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 116 Aplica o Atendimento Controlar Pedido Cadastrar Cliente Incluir Novo Alterar Dados Consultar Excluir Cliente Cliente Cliente Cliente Consultar Card pio Consultar Consultar Consultar Refei es Sobremesas Bebidas Figura 6 19 DHF para o subsistema de Atendimento a Clientes do Sistema de
229. terpreta o mais universal Engenharia de Software Ricardo de Almeida Falbo Cap tulo 5 Levantamento e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 100 ainda que n o padronizada para a elabora o de DERs Isso permite por exemplo o uso de ferramentas CASE com suporte UML no desenvolvimento de sistemas segundo o paradigma estruturado A tabela 5 2 mostra a correspond ncia entre a nota o da UML e a nota o apresentada na se o 5 6 e a figura 5 49 ilustra as nota es da UML j ajustadas para representar DERs Tabela 5 2 Representando DERs com a UML DER Nota o UML Entidade Classe Estereotipada lt lt entidade gt gt Atributo Atributo Relacionamento Associa o Cardinalidades X Y Multiplicidades X Y Agregado Classe Associativa Estereotipada lt lt agregado gt gt Condicionantes Restri es entre Associa es Particionamento de Entidade Generaliza o lt lt agregado gt gt AgregadoE1E2 atributoRelacionamento lt lt entidade gt gt Entidade4 1 lt lt entidade gt gt 0 Entidade1 E 0 0 lt lt entidade gt gt atributo1 Entidade2 Ou exclusivo atributo2 nomeRelacionamento atributoN 0 A lt lt entidade gt gt 1 Entidade3 lt lt entidade gt gt Entidade1 1 lt lt entidade gt
230. tidade externa Representar no DFD zero um processo para cada uma das fun es do neg cio Agrupar as atividades essenciais nos processos para os quais as suas a es mais contribuem Usando essa abordagem para a constru o de diagramas hier rquicos adotamos uma estrat gia middle out do meio para fora na qual a partir dos eventos estabelecemos atividades essenciais meio para depois agrup las em n veis superiores para cima e em seguida especific las e se necess rio explodi las para baixo a Dicion rio de Dados descreve os dados representados no DER nos DFDs e nos Diagramas de Estados a Especifica o da L gica dos Processos descreve a l gica dos processos do DFD que n o foram detalhados em diagramas de n vel inferior l gica dos processos primitivos Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 67 Como se pode perceber a An lise Essencial faz uso praticamente das mesmas t cnicas de modelagem da An lise Estruturada a saber a Modelagem de Dados utilizando diagramas de Entidades e Relacionamentos a Modelagem Funcional utilizando Diagramas de Fluxo de Dados DFDs e a Modelagem de Comportamento utilizando Diagramas de Estados Isso bastante natural j que a An lise Essencial de fato uma extens o da An lise Estruturada Na realidade a principal diferen a entre a An lise
231. tos de Software 3 edi o S o Paulo Editora Erica 2005 Este livro traz uma apresenta o bastante detalhada do m todo da An lise de Pontos de Fun o explorando a import ncia da medi o cap tulo 1 uma vis o geral do processo de contagem cap tulo 3 detalhamento desse processo cap tulos 4 5 6 e 7 e estimativas cap tulo 9 7 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 8 P Jalote CMM in Practice Processes For Executing Software Projects At Infosys Addison Wesley Publishing Company 1999 Engenharia de Software Cap tulo 4 Ger ncia da Qualidade de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 43 Cap tulo 4 Ger ncia da Qualidade de Software Uma das principais metas da Engenharia de Software a produ o de software de qualidade Entretanto qualidade n o algo que se atinge de forma espont nea Qualidade tem de ser constru da em um produto de software e diversos aspectos s o importantes neste contexto Neste cap tulo discutimos alguns desses aspectos aqueles que consideramos mais importantes a saber documenta o controle e garantia da qualidade e ger ncia de configura o de software 4 1 Documenta o A documenta o produzida em um projeto de software de su
232. tos 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 9000 com destaque para a norma NBR ISO IEC 12207 A Norma NBR ISO IEC 12207 A Norma NBR ISO IEC 12207 Tecnologia da Informa o Processos de Ciclo de Vida de Software 7 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 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 Em outubro de 2002 e de 2004 a ISO IEC 12207 recebeu duas emendas emendas 1 e 2 respectivamente para tratar a evolu o da Engenharia de Software e tamb m para harmoniz la com a norma ISO IEC 15504 Basicamente essas melhorias criaram novos ou expandiram o escopo de alguns processos al m de serem adicionados a cada processo o seu prop sito e resultados Assim agora cada processo tem um prop sito e um resultado associado
233. tra o atrav s da qual relacionamentos entre duas entidades s o tratados como entidades em um n vel mais alto ou seja um relacionamento bin rio R e as entidades envolvidas X e Y s o considerados uma nica entidade A agregando todas as informa es Essa nova entidade a agrega o pode ent o relacionar se com outras entidades do modelo como mostra a figura 5 11 Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 72 Ricilwy xeXye Y R2cI xy 27 x ye RI ze Z Figura 5 11 Agrega o A figura 5 12 mostra um exemplo de agrega o no contexto banc rio Nesse exemplo o par Cliente Conta assume o status de um Correntista para o qual um Cart o Magn tico pode ser emitido Correntista LN 0 N T possui 1 1 emitido para 0 1 Cart o Magn tico Figura 5 12 Exemplo de Agrega o Para prover maior facilidade na elabora o dos diagramas ER representaremos a agrega o com um ret ngulo envolvendo apenas o relacionamento como mostra o exemplo da figura 5 13 Engenharia de Software Cap tulo 5 Levantamento e An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 73 Correntista Cart o Magn tico Figura 5 13 Outra representa o para Agregados importante observar que agrega es envolvendo relac
234. tributos 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 Engenharia de Software Cap tulo 6 Projeto de Sistemas Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 109 Diagrama E R Diagrama Relacional Figura 6 12 Tradu o de Relacionamentos Tern rios 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 mostra a figura 6 13 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 Figura 6 13 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 colunas 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 6 14 Engenharia de Software Cap tu
235. tware S o Paulo Addison Wesley 6 edi o 2003 O cap tulo 4 proporciona uma vis o geral da ger ncia de projetos de software abordando atividades da ger ncia se o 4 1 planejamento do projeto se o 4 2 elabora o do cronograma se o 4 3 e ger ncia de riscos se o 4 4 Al m disso tem dois cap tulos 22 e 23 dedicados respectivamente ger ncia de pessoal e estimativas 3 S L Pfleeger Engenharia de Software Teoria e Pr tica S o Paulo Prentice Hall 2 edi o 2004 Engenharia de Software Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 42 O cap tulo 3 dedicado ao planejamento e ger ncia de projetos de software A se o 3 1 trata do escopo estrutura de divis o do trabalho e elabora o do cronograma Na se o 3 2 h uma discuss o a cerca do pessoal necess rio para o projeto e forma o de equipes As se es 3 3 3 4 e 3 5 discutem respectivamente os temas estimativas ger ncia de riscos e plano de projeto 4 M F Vieira Gerenciamento de Projetos de Tecnologia da Informa o Rio de Janeiro Editora Elsevier Campus 2003 5 J C C Martins Gerenciando Projetos de Desenvolvimento de Software com PMI RUP e UML 2 edi o revisada Rio de Janeiro Brasport 2005 6 C E Vazquez G S Sim es R M Albert An lise de Pontos de Fun o Medi o Estimativas e Gerenciamento de Proje
236. tware Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 145 14 Facilidade de mudan as focaliza a preocupa o com a influencia 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 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 Sistemas de Informa o on line Dispon vel em presidentekennedy br resi edicao03 artig
237. ue um bom processo de software tem de apresentar deixando a organiza o livre para estruturar essas caracter sticas segundo sua pr pria cultura elas 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 Qualidade Cultura Organizacional Definic o Tipo de Software Dom nio do Problema DO Paradigma e Especializa o Tecnologia de Desenvolvimento Processo Especializado Processo Especializado 1 n Particularidades do Ciclo de Vida ou Modelo de Processo Processo de Projeto Processo de Projeto 1 m Figura 2 9 Modelo para Defini o de Processos em N veis 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 2 Processo de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 2
238. ulo 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 Engenharia de Software Cap tulo 3 Ger ncia de Projetos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 35 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 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 e o fator de ajuste A figura 3 4 apresenta uma vis o esquem tica dos tipos de fun o que s o considerados na contagem da APF Usu rio Externo Entrada Sa
239. uni 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 Engenharia de Software Cap tulo 4 Ger ncia da Qualidade de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 46 4 3 Ger ncia de Configura o de Software Refer ncias 1 Cap 9 2 Cap 29 3 Cap 3 se o 3 3 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 e processos tamb m podem ser substitu dos por vers es mais recentes ou mesmo por outras no caso de ferramentas Por 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 refletir altera es nos artefatos impactados por um artefato em altera o Esses problemas podem gerar v rios tran
240. utiliza o de c digo C digo reutilizado foi usado somente dentro da aplica o 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 Pa ca 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 na 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

Engenharia de Software - Informática

Contents

Download Pdf Manuals

Related Search

Related Contents

Engenharia de Software - Inform&aacute;tica

Contents

Download Pdf Manuals

Related Search

Related Contents

Engenharia de Software - Informática