UNIVERSIDADE GAMA FILHO POSEAD MARCOS ROGERIO
Contents
1. erre naaacanae anne acer aaa a nana aerea naanaaaaannaaa 55 2 1 3 2 6 Estrat gias e M todos de Design de Software re areeaeercarenaaaraananaaanaaana 57 2 1 3 3 Constru o d Softwares dialer aun Abela Lee dunas ABS ada diga SD an tera 60 2 1 3 3 1 Fundamentos da constru o de SOfWALE eccccceseceeeeeeceeeeeeeeeceaeeeceaeeseaeeecaeeseaeeeseaeeseneesseneeseneeeeees 62 2 1 3 3 2 Gesl o de CONS UC IO e T ces ara aaa den a a a a a e EEEn 64 2 1 3 3 3 Considera es pr ticas mis iii say gsaisani ohare aia ee cael ais cea eon Nea 65 2 1 3 4 Teste d SoTiware ccf icine cs errasmsa si nara nO a E T Airai TO AUA NN LN da e r EE ATE aTe NTa vers 70 2 1 3 4 1 Fundamentos de Teste de Software e ererreaaeacaeareaaaaeacaeareaaaa career a rn eetet 72 2 19 42 Niveiside Teste same a NE E dea SRS da a a T aa 75 2 1 3 4 3 T cnicas de Teste 2s licenccasccscisveveuscussasesecvsisecesveuetacvescyssecasycususydbenssudvesesucuiiaskisyorthverdedsten taiteucaneeddaravsectaan 79 2 1 3 4 4 Medidas Relacionadas ao Teste ooo ee eee cece aa ar a e a 84 2 179 4 5 Processo de TES iy assita eis tugas eset a iia a dE a E eden ad datadas anca ELSA ET ren inata saudosa 87 2 1 3 5 Manuten o de SoftWare Aurrian recuo are SSD Pa LOIRAS a aa E cad ieee E Tas Vo npa a aaa DEEG Ge 94 2 1 3 5 1 Fundamentos da Manuten o de Software rea ceaeeaaaa aerea neeaaananaananaa 95 2 1 32. 6 r ncias picos x refe Figura 18 T 93 2 1 3 5 Manuten o de Software Os esfor os no desenvolvimento de software resultam em uma entrega de um produto de software que satisfa a as necessidades dos utilizadores Consequentemente os produtos de software devem mudar ou evoluir Uma vez em opera o defeitos s o descobertos as opera es de ambientes mudam e as novas necessidades aparecem A fase de manuten o do ciclo de vida come a ap s o per odo de garantia ou ap s a implementa o da entrega do suporte mas as atividades de manuten o ocorrem muito mais cedo A manuten o de software uma parte integral do ciclo de vida do software Entretanto ela n o tem historicamente recebido o mesmo grau de aten o que as outras fases t m Historicamente o desenvolvimento de software tem tido um perfil muito mais elevado do que a manuten o de software na maioria das organiza es Isto agora est mudando como as organiza es se esfor ando para espremer ao o m ximo o seu investimento em desenvolvimento de software para manter a manuten o de software em opera o o maior tempo poss vel Preocupa es sobre o Ano 2000 Y2K geraram uma significativa aten o focada sobre a fase manuten o de software e os paradigmas dos C digos Abertos trouxeram ainda mais aten o quest o dos artefatos de manuten o de software desenvolvida pelos outros No Guia manuten o de software definida com
3. 21 2 1 2 6 KA de Design de Software De acordo com a defini o do IEEE IEEE 610 12 90 design o processo de definir a arquitetura componentes interfaces e outras caracter sticas de um sistema ou componente e tamb m o resultado de processo A KA Design de Software dividida em seis sub reas A primeira sub rea apresenta os Fundamentos de Design de Software que formam uma base subjacente compreens o do papel e do escopo do design de software Existem conceitos de software gen ricos o contexto do design de software o processo de design de software e as t cnicas de autoriza o de design de software A segunda subarea agrupa o conjunto de Quest es chave em Design de Software Essas quest es chaves incluem colabora o controle e tratamento de eventos a distribui o de componentes tratamento de exce es e erros e toler ncia falha intera o e apresenta o e persist ncia de dados A terceira sub rea Estrutura e Arquitetura de Software os t picos da qual s o estruturas de arquiteturas e pontos de vista estilos de arquitetura padr es de design e finalmente as fam lias dos programas e frameworks A quarta sub rea descreve An lise de Qualidade do Design e Avalia o do software Enquanto existe uma KA inteira dedicada qualidade de software esta sub rea apresenta os t picos especificamente relacionados ao design de software Esses aspectos s o atributos de qualidade an lise de qu
4. o Guia identifica o material de refer ncia de cada KA inclusive cap tulos de livros artigos referenciados ou outras fontes reconhecidas de informa o com autoridade Cada descri o da KA tamb m inclui uma matriz que relaciona o material de refer ncia aos t picos enumerados O volume total da literatura pretende se que seja dominado pela realiza o de uma educa o universit ria com mais quatro anos da experi ncia Pode se argumentar que algumas KAs como projeto de software por exemplo merecem mais p ginas de material de refer ncia do que outros Tal modula o pode ser aplicada em futuras edi es do Guia Deve se observar que o Guia n o tenta ser abrangente nas suas cita es Muito material que tanto conveniente quanto excelente n o referenciado O material foi selecionado em parte porque tomado como uma cole o fornece a cobertura dos t picos descritos 2 1 2 3 Profundidade de tratamento De in cio uma pergunta surgiu quanto profundidade do tratamento que o Guia deve fornecer A equipe de projeto adotou uma abordagem que apoia o quinto objetivo do projeto fornecimento de uma base de desenvolvimento de curr culo certifica o e licen a A equipe editorial aplicou o crit rio de conhecimento geralmente aceito a distin o de conhecimento avan ado e de pesquisa com base 18 em maturidade e do conhecimento especializado com base em generalidade da aplica o A defini o ve
5. 2 1 3 7 Ger ncia de Engenharia de Software Ger ncia de Engenharia de Software pode ser definida como a aplica o das atividades de gerenciamento planejamento coordena o mensura o monitora o controle e informa o para garantir que o desenvolvimento e manuten o do software seja sistem tico disciplinado e quantificado IEEE610 12 90 A rea de conhecimento Ger ncia da Engenharia de Software portanto trata o gerenciamento e a mensura o da engenharia de software Embora a mensura o seja um aspecto importante de todas as KAs aqui que o t pico de mensura o de programas apresentado Embora seja verdade que em um sentido deveria ser poss vel gerenciar a engenharia de software da mesma forma que qualquer outro processo complexo existem aspectos espec ficos aos produtos de software e aos processos do ciclo de vida do software que complicam o gerenciamento efetivo apenas alguns dos quais s o os seguintes e A percep o dos clientes tal que frequentemente existe uma falta de reconhecimento da complexidade inerente engenharia de software particularmente em rela o ao impacto das mudan as de requisitos e quase inevit vel que o processo de engenharia de software por ele pr prio gerar a necessidade de requisitos de cliente novos ou mudados e Como resultado o software muitas vezes constru do em um processo iterativo ao inv s de em uma sequ ncia de tarefas fechadas Engenh
6. 99 s5 5 3 2 N o suficiente quer o simples aumento da esperan a de aumentar a 111 qualidade ir resultar na qualidade resultar o da manuten o de software Ela deve ser planejada e implementada para apoiar os processos processo de manuten o As atividades e t cnicas de Seguran a de Qualidade de SQA V amp V opini es e auditorias devem ser selecionadas em conson ncia com todos os outros processos para alcan ar o n vel desejado de qualidade tamb m recomendado que os mantenedores adaptem os processos de desenvolvimento t cnicas e resultados para instituir testes de documenta o e testes de resultados I5014764 99 Mais detalhes podem ser encontrados no Quality Software KA 2 1 3 5 4 T cnicas de Manuten o Este subitem introduz alguns dos m todos geralmente aceitos pelas t cnicas utilizadas na manuten o de software a Programa de Compreens o Os programadores gastam um tempo consider vel na leitura e compreens o dos programas a fim de implementar mudan as Os C digos Navegadores s o instrumentos fundamentais para a compreens o do programa A documenta o clara e concisa pode auxiliar no processo de compreens o do programa Arn92 C14 Dor02 v1c9s1 11 4 Tak97 c3 b Reengenharia Reengenharia definida como a an lise e altera o de software para reconstitui lo em um novo formul rio e inclui a posterior aplica o do novo formul rio Dorfman e Thayer Dor02 indicam que a re
7. M todos formais na ci ncia cognitiva Racioc nio M todos formais na ci ncia cognitiva b Arquitetura cognitiva Cognitivo Al Il aprendendo Funda es da ci ncia cognitiva Extra o de informa o do discurso e do texto Processamento lexical Aquisi o de l ngua computacional A natureza de IHC META Modelos de IHC c Uso e contexto dos computadores Organiza o social e trabalho humano reas de aplica o d Ajuste e Intera o Humano M quina Caracter sticas humanas Processamento de informa o humano Linguagem comunica o intera o Ergonomia e Sistema inform tico e arquitetura da rela o Dispositivos de entrada e de sa da T cnicas do di logo G nero do di logo Gr ficos de computador Arquitetura do di logo f Processo de desenvolvimento Aproxima es do projeto T cnicas da execu o 197 e T cnicas da avalia o Sistemas do exemplo e estudos de caso Uma lista mais focalizada de t picos no projeto de rela o homem m quina chamado unidades e t picos no relat rio para finalidades do curr culo da tecnologia de programa o pode ser encontrada no relat rio de esbo o do volume da tecnologia de programa o do Projeto de computa o dos curr culos 2001 CC2001 2 1 3 11 8 Engenharia de sistemas O Conselho Internacional da Engenharia de Sistemas INCOSE indica que a engenharia de sistemas uma aproxima o interdisciplinar e signifi
8. Nol99 A J Nolan Learning From Success IEEE Software January February 1999 pp 97 105 Off97 R J Offen and R Jeffery Establishing Software Measurement Programs IEEE Software March April 1997 pp 45 53 Par96 K V C Parris Implementing Accountability IEEE Software July August 1996 pp 83 93 Pau94 M Paulk and M Konrad Measuring Process Capability Versus Organizational Process Maturity presented at 4th International Conference on Software Quality 1994 Pfl01 S L Pfleeger Software Engineering Theory and Practice second ed Prentice Hall 2001 Pfl97 S L Pfleeger Assessing Measurement Guest Editor s Introduction IEEE Software March April 1997 pp 25 26 Pfl97a S L Pfleeger et al Status Report on Software Measurement IEEE Software March April 1997 pp 33 43 Pfl99 S L Pfleeger Understanding and Improving Technology Transfer in Software Engineering Journal of Systems and Software vol 47 1999 pp 111 124 PMIOO Project Management Institute Standards Committee A Guide to the Project Management Body of Knowledge PMBOK Project Management Institute 2000 Put97 L H Putman and W Myers Industrial Strength Software Effective Management Using Measurement IEEE Computer Society Press 1997 Rad85 R Radice et al A Programming Process Architecture IBM Systems Journal vol 24 iss 2 1985 pp 79 90 Rag89 S Raghavan and D Chand
9. es e identifica o das linhas de base a ser utilizado juntamente com o procedimento para a aquisi o de uma linha de base sobre os itens Uma configura o de software o conjunto de caracter sticas f sicas e funcionais de software conforme estabelecido na documenta o t cnica ou alcan ado em um produto IEEE610 12 90 Ele pode ser visto como parte de uma configura o geral do sistema Um item de configura o de software SCI uma agrega o de software designado para o gerenciamento de configura o e tratada como uma entidade nica no processo de SCM IEEE610 12 90 Uma variedade de itens al m do pr prio c digo normalmente controlada pelo CSM itens de software com potencial para se tornar SIC incluem planos especifica es e documenta o do projeto 121 ensaios de materiais ferramentas de software de c digo fonte e execut veis bibliotecas de c digo dados e dicion rios de dados e documenta o para instala o manuten o opera o e uso de software Sele o de s tios de import ncia comunit ria um importante processo no qual um equil brio deve ser alcan ado entre dar visibilidade adequada para fins de controle do projeto e fornecendo um n mero razo vel de itens controlados Uma lista de crit rios para a sele o SCI dada em Ber92 As rela es estruturais entre a SIC selecionado e suas partes constituintes afetam as atividades de SCM ou outras tarefas como a cons
10. es gen ricas vs defini es adaptadas descritiva vs prescritivo vs proscritiva Pfl01 V rios elementos de um processo podem ser definidos por exemplo atividades produtos artefatos e os recursos Quadros detalhados que estruturam os tipos de informa es necess rias para definir os processos s o descritos em Mad94 H uma s rie de anota es sendo utilizadas para definir processos SPC92 A grande diferen a entre eles est no tipo de informa es dos quadros mencionados acima definem capturam e usam O engenheiro de software deve estar ciente das seguintes abordagens diagramas de fluxo de dados em termos de processo objetivo e os resultados I5015504 98 como uma lista dos processos constituintes decomposto em atividades e tarefas definidas na linguagem natural IEEE12207 0 96 Esfatechar Har98 ETVX Rad85 modelagem Ator Depend ncia Yu94 SADT nota o Mcg93 redes de Petri Ban95 IDEFO IEEE 1320 1 98 e a regra de base Bar95 Mais recentemente um padr o de modelagem de processo foi publicado pela OMG que visa harmonizar nota es de modelagem Isto denominado o SPEM Software Engineering Process Meta Model especifica o OMG02 d Processo de Adapta o importante notar que mesmo processos predefinidos mais usados devem ser adaptados s necessidades locais por exemplo um contexto organizacional a dimens o dos projetos requisitos regulamentar pr ticas da ind stria e cultu
11. o A terceira sub rea a Avalia o de Processo Os t picos aqui incluem modelos de avalia o de processo e m todos de avalia o do processo A quarta sub rea descreve Mensura o de Produto e Processo O processo de engenharia de software cobre a medi o do produto de processo em geral As mensura es espec ficas de cada KA s o abordadas nas respectivas KA Os t picos s o mensura o do processo mensura o do produto de software a qualidade da mensura o dos resultados modelos de informa o de software e t cnicas de mensura o do processo 2 1 2 13 KA Ferramentas e M todos de Engenharia de Software A KA Ferramentas e M todos para Engenharia de Software inclui como a 26 pr pria descri o apresenta ferramentas para serem aplicadas engenharia de software e tamb m m todos para serem aplicados na engenharia de software A sub rea de Ferramentas para Engenharia de Software usa a mesma estrutura que Guia com um t pico de cada uma das nove KAs de engenharia de software Em um t pico adicional fornecido assuntos sobre ferramentas diversas como ferramentas para t cnicas de integra o que s o potencialmente aplic veis a todas as classes de ferramentas A subarea M todos para Engenharia de Software dividida em quatro subse es m todos heur sticos que tratam com aproxima es informais m todos formais que se baseiam em aproxima es matematicamente e m todos de prototipa o
12. o de mecanismos de exclus o e disciplina no acessar s rie de recursos reutiliz veis incluindo threads ou bloqueios de banco de dados Organiza o de c digo de origem em declara es rotinas classes pacotes ou outras estruturas e Documenta o de c digo e Ajuste de c digo d Testando a Constru o Constru o envolve duas formas de testes que frequentemente s o executadas pelo engenheiro de software que escreveu o c digo Bec99 Hun00 Mag93 McC04 e Testes de unidade e Testes de integra o O objetivo dos testes de constru o visa reduzir a lacuna entre o tempo em que os defeitos s o inseridos no c digo e o tempo que os mesmos s o detectados Em alguns casos testes de constru o s o executados depois de c digo foi escrito Em outros casos os testes podem ser criados antes que c digo seja escrito Testes de constru o envolvem tipicamente um subconjunto de tipos de testes que s o descritos na rea de conhecimento de teste de software Por exemplo testes de constru o normalmente n o incluem testes de sistema testes alfa teste beta stress testing teste de configura o testes de usabilidade ou outros mais tipos especializados dos testes Duas normas foram publicadas sobre o tema padr o IEEE 829 1998 padr o de IEEE para documenta o de teste de software e padr o de IEEE 1008 1987 padr o de IEEE para testes de unidade de software e Reutiliza o Tal como consta a in
13. o do corpo de conhecimento da engenharia de software o SWEBOK Ocorre que o SWEBOK um guia de refer ncia t o importante n o tem o devido status do qual ele merece N o raro encontrar pessoas da rea de desenvolvimento que ainda n o sabem de sua exist ncia Cursos de p s gradua o com nfase em engenharia de software n o fazem men o a este guia Este trabalho se prop e a tradu o e ao detalhamento deste guia em n vel suficiente para que seja evidenciada sua import ncia bem como sua divulga o 1 2 Revis o de Literatura Esta pesquisa influenciada pelos trabalhos de J lio C sar Sampaio do Prado Leite e Roger S Pressman Roger S Pressman uma autoridade internacionalmente reconhecida em melhoria de processo de software e tecnologias de engenharia de software Por mais de tr s d cadas ele trabalhou como engenheiro de software gerente professor autor e consultor com foco em quest es de engenharia de software Dr Pressman atualmente presidente do R S Pressman amp Associates Inc uma empresa de consultoria especializada em m todos de engenharia de software e forma o Dr Pressman tem escrito muitos artigos t cnicos um colaborador regular de revistas da ind stria e autor de seis livros J lio C sar Sampaio do Prado Leite Doutor em Ci ncia da Computa o pela Universidade da Calif rnia Irvine professor do Departamento de Inform tica da PUC RIO e vem realizando pesquisas na r
14. o por m s de pessoa time to market ou satisfa o de cliente medido atrav s de um cliente Esta rela o depende do contexto particular por exemplo o tamanho da organiza o ou o tamanho do projeto Em geral estamos mais preocupados com os resultados do processo No entanto para alcan ar os resultados de processo que n s desejamos por exemplo uma melhor qualidade maior durabilidade uma maior satisfa o dos clientes temos de aplicar os processos adequados Evidentemente n o apenas o processo que tem um impacto sobre os resultados Outros fatores tais como a capacidade do pessoal e as ferramentas que s o utilizadas desempenham um papel importante Quando avaliar o impacto de um processo de mudan a por exemplo importante observar outras influ ncias Al m disso medida em que o processo for institucionalizado isto processo de fidelidade importante pois isso pode explicar porque bom processos n o darem sempre os resultados esperados em um determinada situa o Re sultado de Processo Contexto 159 Figura 24 Rela o entre processos e resultados Medi o de tamanho O tamanho do produto de software mais frequentemente avaliado por medidas de tamanho por exemplo linhas de c digo fonte em um m dulo p ginas em um documento de especifica o de requisitos de software ou funcionalidade por exemplo pontos em uma fun o espec fica Os princ pios do tamanho da funcion
15. 132 fator chave na manuten o e melhoria da produtividade e competitividade Reuso efetivo requer uma vis o estrat gica que reflete a for a nica e as exig ncias desta t cnica Em adi o ao entendimento dos aspectos do gerenciamento que s o unicamente influenciados pelo software engenheiros de software devem ter algum conhecimento dos aspectos mais gen ricos mesmo nos quatro primeiros anos ap s a gradua o que s o rotulados no Guia Comportamento e cultura organizacional e ger ncia funcional da empresa em termos de aquisi es gest o da cadeia de fornecedores marketing vendas e distribui o todos t m influ ncia mesmo que indireta no processo de engenharia de software da organiza o Relevante para esta KA a no o da ger ncia de projeto como a constru o de artefatos de software teis normalmente gerida na forma de talvez programas de projetos individuais Neste sentido encontramos amplo apoio no Guia para o Conjunto de Conhecimentos da Ger ncia de Projetos PMBOK PMIOO o qual por si s inclui as seguintes KA ger ncia de integra o do projeto ger ncia de escopo do projeto ger ncia de tempo do projeto ger ncia de custo do projeto ger ncia da qualidade do projeto ger ncia de recursos humanos do projeto e ger ncia de comunica es do projeto Evidentemente todos esses t picos t m relev ncia direta para a rea de conhecimento de Ger ncia de Engenharia de Software Tentar
16. Modelo de implementa o Modelo de implementa o inclui interpreta o e refinamento de modelos Os modelos ajustados s o aplicados no processo os seus resultados s o interpretados e avaliados no contexto do processo projeto e os modelos s o ent o refinados quando necess rio Fen98 c6 Pfl01 c3 C11 C12 Pre04 C22 Som05 C25 d T cnicas de Medi o de Processo T cnicas de medi o podem ser utilizadas para a an lise da engenharia de processos de software e para identificar pontos fortes e fracos Isto pode ser realizado para iniciar a implementa o e mudan a do processo ou para avaliar as consequ ncias desta implementa o e mudan a A qualidade dos resultados de medi o como a precis o repeti o e reprodutibilidade s o as quest es que n o s o usadas medidas de processos de engenharia de software s o instrumentos baseados em medi es como por exemplo quando os assessores destinam uma grande quantidade para um determinado processo Uma discuss o sobre m todos para atingir qualidade de medi o s o apresentados em Gol99 As t cnicas de medi o de processo foram classificadas em dois tipos gerais anal tica e an lise comparativa Os dois tipos de t cnicas podem ser usados em conjunto por m s o baseado em tipos diferentes de informa o Car91 T cnicas anal ticas As t cnicas anal ticas s o caracterizadas como elementos quantitativos para determinar onde melhorias s o necess
17. Muitas nota es e linguagens existem para representar o design de software e artefatos Algumas s o usadas principalmente para descrever a organiza o estrutural de desenho outras para representar o comportamento de software Certas nota es s o usadas pela maior parte durante o desenho arquitet nico e outros principalmente durante detalhamento do desenho embora algumas nota es possam ser usadas em ambos os passos Al m do mais algumas nota es s o usadas pela maior parte no contexto de m todos espec ficos ver as Estrat gias de Desenho de Software e sub rea de M todos Aqui eles s o categorizados em nota es para descrever a vis o estrutural est tica contra a vis o comportamental din mica a Descri es Estruturais vis o est tica As seguintes nota es pela maior parte do gr fico mas n o sempre descrevem e representam os aspectos estruturais de um design de software isto eles descrevem os componentes principais e como eles s o interligados vis o est tica e Linguagens de descri o de arquitetura ADLs textual muitas vezes formal linguagens usadas para descrever uma arquitetura de software quanto aos componentes e conectores Bas03 c12 55 Diagramas de classe e objeto usado para representar um jogo de classes e objetos e as suas rela es m tuas Boo99 c8 c14 Jal97 c5 c6 Diagramas de componentes usado para representar um jogo de componentes parte f sica e su
18. R deReguetos Models gem Concrtusl Projeto da p Arqudebaree Alora o de Reqastoe Anite de H de Requintos Re e He Especifica o matos S EE Valida o de Considera es Requntos Fr ticas Docu esto de Defiua o do Samt Empredica o de Reqaatosdo aama Espredica o de Reqaatosdo Software Revis es dos Watoreza Heretres Repito Der ncia Sr o Prototapa gem Mu angas Alnbutss de Vabdeciodo TP Requatos Mo rio Melheca e gt Quab sde do Processe Restam ento de Fequatos Teme de e Aceta o Megoca o de Requatos Propnedsdes re e Emergprice re Requatos Quand veis Requaios de He Medi o ad Reguue os de Damate gt Regumos de Software Figura 7 T picos dos Requisitos de software 2 1 3 1 1 Fundamentos de Requisitos de Software a Defini o de Requisito de Software Propriedade que deve ser apresentada pelo software para resolver um problema do mundo real Requisito de Software porque ele se ocupa com problemas endere ados pelo Software Software desenvolvido ou adaptado para resolver um problema em particular Problema pode por exemplo ser automatizar uma tarefa utilizando o software para suportar um processo de neg cio de uma organiza o controlar um dispositivo qualquer Requisitos de software em particular s o tipicamente uma combina o de requisitos de diversa
19. a a ad z NF gt a SMS 8 2 2 F FSS Rass 5 F 28 S FE l asa lela s s e 8 2 lee is 5 3 2 z 2 2 amp g i 2 Z a HE e iE S e 5 Nota es de Design de software c4 c8 5 1 Descri es c8s4 cll estruturais may 812 5 c5s3 e t h cl2sl 14 c6 429 63 DR c10 vis o est tica cl2s2 ao c31 5 2 Descri es c18 P comportamentais c19 c6 c18 vies 506 c7s2 DR cll c8 cll vis o din mica c24 313 6 Estrat gias e M todos de Design de software cs aba 6 1 Estrat gias gerais cio ost 320 cSsL 4 cl3s13 c2s2 2 cSs4 533 oe 539 6 2 Design orientado a 328 PS c6s 5s c fun o estruturado om wle6s4 359 esa 9 610 6 3 Design Orientado vic6s2 429 A cl6 c6s4 D c9 a objetos vic6s3 436 201 6 4 Design centrado cis 210 D na estrutura de dados 514 532 6 5 Design baseado em cll componentes CBD 181 395 x E 2 6 6 Outros m todos c18 i92 407 cll c2s2 C29 Figura 13 T picos x refer ncias 3 2 1 3 3 Constru o de Software O termo constru o de software refere se a cria o trabalho detalhado significativo de software atrav s de combina o de c digos verifica o testes unit rios integra o de teste e depura o A rea de conhecimento constru o de 60 software tem conex o com outra KAs reas de conhecimentos mais firmemente o design de software e testes de so
20. es de Implementa o IEEE Std IEEE Ado o do ISO IEC 14143 Este padr o descreve os conceitos fundamentais de 14143 1 1 1998 Tecnologia da Informa o uma classe de medidas conhecidas coletivamente 200 Medida de Software Medida de como tamanho funcional p A ISO IEC Tamanho Funcional Parte 1 14143 Defini o de Conceitos 1 1998 ISO IEC Tecnologia da Informa o Este documento fornece orienta o no P TR Engenharia de Software estabelecimento de processos e atividades que 14471 199 Direcionamentos para a Ado o de podem ser aplicados na ado o da tecnologia CASE 222 Q a 9 Re ol wae wae wee og ES me Numero 7 sd SE 49 22 8 Se seS 389 389 3355 45 e Nome padr o Descri o Sa 2 zS 9 3 solto 29 e530 so padr o 3 se 8852 58 sea ean 85 850558 J 2 8 8 Bo 8 9 Ferramentas CASE ISO IEC Tecnologia da Informa o A s rie ISO IEC 14598 da uma vis o geral dos 14598 Six Avalia o de Produto de Software processos de avalia o de produtos de software e parts fornece orienta es e requisitos para avalia o em B n vel organizacional ou de projeto Os padr es fornecem m todos de medida estimativa e avalia o ISO IEC Tecnologia da Informa o Este padr o desenvolve o processo de manuten o 14764 199 Manuten o de Software na ISO IEC 12207 Ele fornece orienta o na P 9 aplica o dos requisitos de proces
21. mantenedor a forma o tamb m necess ria Pig97 IEEE 12207 0 96 Kaj01 Atividades de Planejamento da Manuten o IEEE1219 98 A 3 15014764 99 S7 ITIO1 Pig97 C7 C8 Uma atividade importante para a manuten o de software o planejamento e os mantenedores devem resolver as quest es relacionadas com o planejamento com uma serie de perspectivas Planejamento do neg cio n vel organizacional Planejamento da Manuten o n vel de transi o Planejamento da Release vers o n vel de software Pedido individual de um processo de mudan a de n vel solicita o No n vel individual o planejamento realizado durante a an lise de impacto A atividade de planejamento da release vers o exige que o mantenedor ITIO1 e Colher as datas de disponibilidade dos pedidos individuais e Concorde com os usuarios sobre o conte do das subsequentes releases vers es Identifique conflitos potenciais e crie alternativas para san los e Avalie os riscos de uma determinada entrega e desenvolva um plano de back out no caso de problemas surgirem e Informar todas as partes interessadas Considerando que o desenvolvimento de projetos de software geralmente pode passar de alguns meses para um n mero reduzido de anos a fase de manuten o geralmente dura muitos anos Fazer a previs o de recursos um elemento fundamental do planejamento de manuten o Esses recursos devem ser inclu dos nos or amentos do planeja
22. o H um n mero de projetos dentro e fora da Sociedade de Computa o que est o coordenando o seu conte do com o conte do do Guia SWEBOK Mais sobre isso em um momento Algumas corpora es incluindo alguns dos membros do Board do Conselho de projetos industriais adotaram o guia para uso em seus programas internos para educa o e treinamento Em um amplo sentido a comunidade de praticantes de engenharia de software profissionais da comunidade desenvolvedora e comunidade da educa o prestam aten o ao guia do SWEBOK para ajudar a a definir o escopo de seus esfor os Um not vel grupo de parte envolvida s o os titulares de certifica o da Sociedade de computa o Profissional de de Desenvolvimento de Software Certificado porque o escopo do exame CSDP altamente alinhado com o escopo do guia SWEBOK A sociedade de Computa o IEEE e outras organiza es est o agora conduzindo um n mero de projetos que dependem da evolu o do guia SWEBOK O exame CSDP inicialmente desenvolvido em paralelo com o guia SWEBOK ir evoluir para algo mais pr ximo do guia ambos em escopo e material de refer ncia e O curr culo da sociedade de aprendizagem a dist ncia de computa o para 210 engenheiros de software ter o mesmo escopo que o guia SWEBOK Uma vis o geral inicial do curso j est dispon vel Apesar dos objetivos da educa o para estudantes n o graduados difiram um pouco daqueles de desenvolvimento
23. o fica f cil prever que tal ferramenta se torna imprescind vel para o crescimento e estabiliza o dessa relativamente nova disciplina de Engenharia de Software Guias como PMBoK BABOK e outros vem se tornando refer ncia para consulta e instrumento ao qual profissionais das reas correlatas encontram respostas O SWEBOK an logo em significado ao PMBoK tido como o PMI da Engenharia de Software e deve ser assimilado por todas as pessoas afetas a esta rea pois o SWEBOK uma ferramenta bastante completa e est muito a frente de outras iniciativas desta amplitude Finalizando o Guia para para o Corpo de Conhecimento da Engenharia de Software n o deve ser negligenciado pelas institui es de ensino at mesmo por se tratar de uma ferramenta de iniciativa da IEEE que tem como uma de suas finalidades servir de refer ncia global em assuntos considerados de forma generalizada pela comunidade como pertinentes a rea de Engenharia de Software 236 Bibliografia Abr96 A Abran and P N Robillard Function Points Analysis An Empirical Study of its Measurement Processes IEEE Transactions on Software Engineering vol 22 1996 pp 895 909 Bas92 V Basili et al The Software Engineering Laboratory An Operational Software Experience Factory presented at the International Conference on Software Engineering 1992 Bec02 K Beck Test Driven Development by Example Addison Wesley 2002 Bec99 K
24. o objetivo normalmente desenvolver software baseados em projetos com uma escala definida no tempo e or amento O principal destaque a entrega a tempo e dentro do or amento para satisfazer as necessidades do utilizador Em contrapartida a manuten o de software frequentemente tem o objetivo de estender a vida de um software para o maior tempo quanto poss vel Al m disso pode ser motivado pela procuro de utilizador por atualiza es de software e acess rios Em ambos os casos o retorno sobre o investimento n o claro de modo que a vis o a n vel da dire o muitas vezes uma das principais atividades que consomem recursos significativos sem benef cios quantific veis claros para a organiza o Pessoalidade Dek92 10 17 Dor02 v1c9s1 6 Par86 c4s8 c4s11 Lie81 Pessoalidade refere se a forma de atrair e manter software o pessoal da manuten o Manuten o n o frequentemente visto como um trabalho glamoroso Deklava fornece uma lista de problemas com os recursos humanos relacionados com a base em levantamento de dados Dek92 Como resultado o pessoal da manuten o de software s o frequentemente vistos como Cidad os de segunda classe Lie81 com a moral prejudicada Processo Pau93 Ben00 c6sb Dor02 v1c9s1 3 O processo de Software um conjunto de atividades m todos pr ticas e transforma es que as pessoas usam para desenvolver e manter o software e produtos associados Pau93 Pelo n vel do
25. reas do Conhecimento adotem a posi o que embora os temas seguintes sejam comuns atrav s de todas as reas do Conhecimento eles tamb m sejam uma parte integrante de todas as reas do Conhecimento e por isso devem ser incorporados na divis o proposta de t picos de cada rea do Conhecimento Esses temas comuns s o qualidade em geral e medida Por favor observe que o problema de como tratar propriamente essa corrida cruzada ou t picos ortogonais e se eles devem ser tratados de uma maneira diferente ainda n o foi completamente resolvido i As divis es propostas devem ter no maximo dois ou tr s n veis de profundidade Mesmo embora nenhum limite superior ou inferior seja imposto ao n mero de t picos dentro de cada rea do Conhecimento espera se que os Editores Associados das reas do Conhecimento proponham um n mero razo vel e 200 gerenci vel de t picos por rea do Conhecimento Tamb m deve se dar nfase na sele o dos pr prios t picos e n o na sua organiza o em uma hierarquia apropriada Os nomes dos t pico propostos devem ser expressivos o bastante para terem significado mesmo quando citados fora do Guia do Corpo de Conhecimento de Engenharia de Software j A descri o de uma rea do Conhecimento incluir um diagrama na forma de rvore descrevendo a divis o do conhecimento 2 1 4 1 3 Crit rios e exig ncias para descrever T picos A descri o dos t picos deve ser somente a nece
26. Beck Extreme Programming Explained Embrace Change Addison Wesley 1999 Bei90 B Beizer Software Testing Techniques International Thomson Press 1990 Chap 1 3 5 754 10s3 11 13 Boe03 B Boehm and R Turner Using Risk to Balance Agile and Plan Driven Methods Computer June 2003 pp 57 66 Com97 E Comer Alternative Software Life Cycle Models presented at International Conference on Software Engineering 1997 Dav93 A M Davis Software Requirements Objects Functions and States Prentice Hall 1993 60993 J Goguen and C Linde Techniques for Reuirements Elicitation presented at International Symposium on Requirements Engineering San Diego California 1993 Dor02 M Dorfman and R H Thayer eds Software Engineering IEEE Computer Society Press 2002 Vol 1 Chap 6 8 Vol 2 Chap 3 4 5 7 8 EIE99 K El Emam and N Madhavji Elements of Software Process Assessment and Improvement IEEE Computer Society Press 1999 Fen98 N E Fenton and S L Pfleeger Software Metrics A Rigorous amp Practical Approach second ed International Thomson Computer Press 1998 Chap 1 14 Fen98 N E Fenton and S L Pfleeger Software Metrics A Rigorous amp Practical Approach second ed International Thomson Computer Press 1998 Fin94 A Finkelstein J Kramer and B Nuseibeh Software Process Modeling and Technology Research Studies Press Ltd 1994 Fow90
27. Ci ncias da Computa o Gerenciamento da Qualidade Engenharia de Computa o Gerenciamento de Projetos Engenharia de Sistemas Figura 2 Disciplinas relacionadas 2 1 2 1 Organiza o Hier rquica A organiza o das descri es das KAs apoia o terceiro objetivo do projeto uma caracteriza o dos conte dos da engenharia de software Especifica es detalhadas fornecidas pela equipe editorial do projeto aos editores associados quanto aos conte dos das descri es das KAs podem ser encontradas no Ap ndice A 17 O Guia usa uma organiza o hier rquica para decompor cada KA em um conjunto de t picos com t tulos reconhec veis Dois ou tr s n veis de separa o fornecem um modo razo vel de encontrar t picos de interesse O Guia trata os t picos selecionados em uma maneira compat vel com as principais escolas do pensamento e com separa es geralmente encontradas na ind stria e na literatura de engenharia de software e padr es As separa es dos t picos n o presumem determinados dom nios de aplica o usos para neg cios filosofia de ger ncia m todos de desenvolvimento e assim por diante A extens o da descri o de cada t pico somente a necess ria para entender a natureza geralmente aceita dos t picos e para o leitor encontrar com sucesso o material de refer ncia 2 1 2 2 Material de refer ncia e matriz Para fornecer um acesso atual ao conhecimento o quarto objetivo do projeto
28. Existe um padr o IEEE em como classificar anomalias do software IEEE 1044 93 e Densidade de falha Per95 c20 IEEE982 1 88 Lyu96 c9 Um programa sob teste pode ser avaliado pela contagem e classifica o das falhas descobertas pelos seus tipos Para cada classe de falha a densidade da falha medida como a rela o entre o n mero de falhas encontradas e o tamanho do programa e Teste de vida avalia o da confiabilidade Pfl01 c9 Pos96 p146 154 Uma estimativa estat stica da confiabilidade de software que possa ser obtida pela realiza o e pela avalia o da confiabilidade ver sub t pico 2 2 5 pode ser usada para avaliar um produto e para decidir se o teste pode ser parado ou n o Modelos de crescimento da confiabilidade Lyu96 c7 Pfl01 c9 Lyu96 c3 85 c4 Os modelos de crescimento da confiabilidade fornecem uma predi o da confiabilidade baseada nas falhas observadas sob a realiza o e a avalia o da confiabilidade ver o sub t pico 2 2 5 Eles assumem geralmente que as falhas que causaram os fracassos observados foram reparadas embora alguns modelos igualmente aceitam reparos imperfeitos e assim em m dia a confiabilidade do produto exibe uma tend ncia de aumento Existem agora d zias de modelos publicados Muitos s o colocados em algumas suposi es comuns enquanto outros diferem Notavelmente estes modelos s o divididos em modelos de contagem de fracassos e modelos temp
29. IEEE Software March April 1999 pp 61 65 Kit97 B Kitchenham and S Linkman Estimates Uncertainty and Risk IEEE Software May June 1997 pp 69 74 Kit98 B Kitchenham Selecting Projects for Technology Evaluation IEEE TCSE Software Process Newsletter Kra99 H Krasner The Payoff for Software Process Improvement What It Is and How to Get It presented at 239 Elements of Software Process Assessment and Improvement 1999 Kri99 M S Krishnan and M Kellner Measuring Process Consistency Implications for Reducing Software Defects IEEE Transactions on Software Engineering vol 25 iss 6 November December 1999 pp 800 815 Lat98 F v Latum et al Adopting GQM Based Measurement in an Industrial Environment IEEE Software January February 1998 pp 78 86 Leu96 H K N Leung A Risk Index for Software Producers Software Maintenance Research and Practice vol 8 1996 pp 281 294 Lis97 T Lister Risk Management Is Project Management for Adults IEEE Software May June 1997 pp 20 22 Lyu96 M R Lyu Handbook of Software Reliability Engineering Mc Graw Hill IEEE 1996 Mac96 K Mackey Why Bad Things Happen to Good Projects IEEE Software May 1996 pp 27 32 Mac98 K Mackey Beyond Dilbert Creating Cultures that Work IEEE Software January February 1998 pp 48 49 Mad94 N Madhavji et al Elicit A Method for Eliciting Process Models presented
30. Os dados devem ser coletados verificados e armazenado ISO 15939 02 5 3 2 Analise os dados e desenvolva as informa es de produtos Dados podem ser agregados transformados ou registrados como parte do processo de an lise usando um n vel de rigor adequado natureza dos dados e informa es necess rias Os resultados dessas an lises s o tipicamente indicadores que devem ser interpretados resultando em conclus es iniciais a serem apresentadas aos stakeholders Os resultados e conclus es devem ser revisados usando um processo definido pela organiza o o qual pode ser formal ou informal Fornecedores dos dados e usu rios das medidas devem participar na revis o dos 147 dados para garantir que elas s o significativas e acuradas precisas e que elas podem resultar em a es razo veis ISO 15939 02 5 3 3 e Ap ndice G Comunique os resultados As informa es dos produtos devem ser documentadas e comunicadas aos usu rios e stakeholders ISO 15939 02 5 3 4 d Avalie as Medidas Avalie as informa es dos produtos Avalie as informa es dos produtos contra os crit rios de avalia o especificados e determine os pontos fortes e fracos das informa es dos produtos Isto pode ser realizado por um processo interno ou por uma auditoria externa e deve incluir o feedback retorno dos usu rios das medi es Registre as li es aprendidas numa base adequada ISO 15939 02 5 4 1 e Ap ndice D Avalie o processo de
31. Sol98 R v Solingen R Berghout and F v Latum Interrupts Just a Minute Never Is IEEE Software September October 1998 pp 97 103 Som97 I Sommerville and P Sawyer Requirements Engineering A Good Practice Guide John Wiley amp Sons 1997 SPC92 Software Productivity Consortium Process Definition and Modeling Guidebook Software Productivity Consortium SPC 92041 CMC 1992 VIM93 ISO VIM International Vocabulary of Basic and General Terms in Metrology ISO 1993 Vot93 L Votta Does Every Inspection Need a Meeting ACM Software Engineering Notes vol 18 iss 5 1993 pp 107 114 Wei93 G M Weinberg Quality Software Management First Order Measurement Ch 8 Measuring Cost and Value vol 2 1993 Whi95 N Whitten Managing Software Development Projects Formulas for Success Wiley 1995 Wil99 B Wiley Essential System Requirements A Practical Guide to Event Driven Methods Addison Wesley 1999 Yu94 E Yu and J Mylopolous Understanding Why in Software Process Modeling Analysis and Design presented at 16th International Conference on Software Engineering 1994 Zah98 S Zahran Software Process Improvement Practical Guidelines for Business Success Addison Wesley 1998 Zel98 M V Zelkowitz and D R Wallace Experimental Models for Validating Technology Computer vol 31 iss 5 1998 pp 23 31 CMU SEI TR 95 001 1995 em http www sei cmu edu pub document
32. Tak97 c4 Hen01 2 1 3 6 Ger ncia de Configura o de Software Um sistema pode ser definido com uma conjunto de componentes organizados para realizar uma fun o especifica ou um conjunto de fun es IEEE 610 12 90 A configura o de um sistema consiste das caracter sticas funcionais e ou f sicas de hardware firmware ou software ou a combina o destas conforme estabelecida na documenta o t cnica e realiza o de um produto Ela tamb m pode ser pensada como uma cole o de vers es espec ficas de hardware firmware software ou itens combinados de acordo com procedimentos de constru o espec ficos para servir um prop sito particular Gerenciamento de Configura o CM ent o a disciplina de identifica o e configura o de um sistema em pontos distintos no tempo com a finalidade de controlar sistematicamente as altera es na configura o e manuten o da integridade e da rastreabilidade da configura o durante todo o ciclo de vida do sistema Ber97 formalmente definido IEEE610 12 90 como Uma disciplina aplicando t cnicas e administrando dire o e fiscaliza o para identificar e documentar as caracter sticas funcionais e f sicas de uma configura o de item controle de mudan as para estas caracter sticas gravando e relatando mudan as processando e implementando status e verificando conformidade com especifica o de requisitos Ger ncia de Configura o de Software SCM da supo
33. Uma lista parcial dos elementos de informa o importante dada em Ber92 c10 Alguma forma de apoio ferramenta automatizada necess ria para realizar a coleta de dados SCSA e tarefas de comunica o Este poderia ser um recurso de banco de dados ou pode ser uma ferramenta aut noma ou a capacidade de um ambiente maior ferramenta integrada Buc96 C13 IEEE828 98 c4s3 3 b Software de Status de Configura o Reporting Informa es relatadas podem ser usados por v rios elementos da organiza o e do projeto incluindo a equipe de desenvolvimento a equipe de manuten o gerenciamento de projetos e atividades de qualidade de software Relat rios podem assumir a forma de consultas ad hoc para responder a quest es espec ficas ou a produ o peri dica de relat rios predefinidos Algumas informa es produzidas pela atividade cont bil status no decurso do ciclo de vida pode tornar se registos de qualidade Al m de relatar o status atual da configura o as informa es obtidas pela SCSA pode servir como base para v rias medidas de interesse para o desenvolvimento gest o e SCM Exemplos incluem o n mero de solicita es de mudan a por SCI e o tempo m dio necess rio para executar uma solicita o de mudan a Ber92 C10 Buc96 c13 2 1 3 6 5 Auditoria de Configura o de Software A auditoria de software uma atividade realizada de forma independente avaliar a conformidade de produtos de software e processos d
34. as caracter sticas sub caracter sticas de qualidade relacionadas e medidas que s o teis para avaliar a qualidade de produtos de software Sur03 O significado do termo produto estendido para incluir qualquer artefato obtido como sa da de qualquer processo usado para construir o produto final de software Exemplos de um produto incluem mas n o s o limitados a uma especifica o de requisitos de todo o sistema uma especifica o dos requisitos de software para um componente de um sistema um m dulo do projeto c digo documenta o de teste ou relat rios produzidos como um resultado de tarefas de an lise de qualidade 175 Enquanto a maioria dos tratamentos de qualidade descrita em termos do software final e do desempenho do sistema boas pr ticas de engenharia exigem que avalia es em produtos intermedi rios relevantes para a qualidade sejam realizadas durante todo o processo de engenharia de software d Melhoria da Qualidade A qualidade de produtos de software pode ser aperfei oada atrav s de um processo interativo de melhoria cont nua que requer controle de gerenciamento coordena o e avalia o de muitos processos concorrentes 1 O ciclo de vida do processo de software 2 o processo de detec o de defeito erro remo o e preven o e 3 A melhoria da qualidade do processo Kin92 A teoria e os conceitos atr s da melhoria de qualidade como qualidade em constru o atrav s da preven
35. c3 Boe81 C30 Jon98 C27 Pfl01 c11s11 3 Pig97 C8 Foi mencionado an lise de impacto que a avalia o de impacto identifica todos os sistemas e produtos de software afetados por uma mudanga de software e desenvolve um pedido de estimativa dos recursos necessarios para realizar essa mudan a Art88 As estimativas dos custos de manuten o s o afetadas por muitos fatores t cnicos e n o t cnicos ISO IEC14764 afirma que as duas abordagens mais populares para estimar os recursos para manuten o de software s o o uso de modelos param tricos e a utiliza o da experi ncia I5014764 99 s7 4 1 Na maior parte das vezes usada a combina o de ambas Modelos param tricos Ben00 S7 Boe81 C30 Jon98 C27 Pfl01 c11511 3 Alguns trabalhos foram realizados na aplica o param trica para a modelagem do custo de manuten o de software Boe81 Ben00 necess rio frisar que os dados dos ltimos projetos s o necess rios em a fim de se utilizar os modelos Jones Jon98 discute todos os aspectos de estimar os custos incluindo os pontos das fun es IEEE14143 1 00 e oferece um detalhado cap tulo sobre a estima o da manuten o Experi ncia IS014764 00 S7 s7 2 s7 2 1 7 2 4 Pig97 C8 Sta94 A experi ncia na forma de perito acordao usando a t cnica Delphi por exemplo e analogias um trabalho de desagrega o que aborda a estrutura que deveria ser utilizada para aumentar os dados de modelos param tri
36. es pormenorizadas mas em destacar as principais atividades e suas interdepend ncias Exemplos de modelos de ciclo de vida software s o os modelo cascata o modelo prototipagem descart vel desenvolvimento evolucion rio entrega incremental iterativo o modelo espiral o modelo de software 153 reutiliz vel e uma s ntese automatizado de software A compara o destes modelos fornecidos em Com97 Dav88 e um m todo de sele o dentre eles em Ale91 b Ciclo de vida do processo de software Defini es do ciclo de vida de processos software tendem a ser mais detalhados do que os modelos ciclo de vida de software No entanto processos de ciclo de vida de software n o devem tentar ordenar o seu processo em tempo til Isto significa que em princ pio o ciclo de vida do processo software pode ser disposto para caber em qualquer dos modelos de ciclo de vida do software A principal refer ncia nesta rea IEEE EIA 12207 0 Tecnologia da Informa o Software Life Cycle Processes IEEE 12207 0 96 O padr o IEEE 1074 1997 de desenvolvimento de processos de ciclo de vida tamb m fornece uma lista de processos e atividades de desenvolvimento e manuten o de software IEEE1074 97 bem como uma lista de atividades do ciclo de vida que possam ser mapeadas em processos e organizadas no mesmo de modo que todos os modelos de ciclo de vida do software Al m disso identifica outros padr es de software ligados ao IEEE par
37. internacional ou um organismo profissional tais como IEEE EIA 12207 0 IEEE 12207 0 96 Com esta abordagem dados quantitativos n o s o reunidos no processo caso sejam desempenham um papel de suporte Os indiv duos realizando a an lise da defini o do processo usam seus conhecimentos e capacidades para decidir sobre as mudan as necess rias para o resultado do processo Estudos de observa o tamb m podem fornecer feedback til para a identifica o de melhorias no processo Agr99 e Classifica o de Defeito Ortogonal uma t cnica que pode ser utilizada para interligar faltas encontradas com causas potenciais Baseia se em um mapeamento entre os tipos de falhas e erros Chi92 Chi96 A norma IEEE sobre a classifica o de falhas ou anomalias pode ser til neste contexto IEEE Standard da classifica o das Anomalias Software IEEE 1044 983 e Controle de Estat stica do Processo um meio eficaz para identificar a estabilidade ou a falta dela atrav s da utiliza o de gr ficos e controle das interpreta es Uma boa introdu o para o SPC em contexto de engenharia de software apresentado em Flo99 e Processo de Software Pessoal define uma s rie de melhorias para o desenvolvimento de pr ticas em uma determinada ordem Hum95 bottom up no sentido em que prev a recolha de dados pessoais e melhorias baseadas em interpreta es dos dados T cnicas de teste de desempenho de um sistema O segundo
38. m pode ser qualificada como uma t cnica din mica Estas diferen as na tarefa de categoriza o indicam que pessoas com pap is diferentes na organiza o podem considerar e aplicar tais t cnicas de forma diferente Alguns testes podem ser realizados em processos de desenvolvimento processos SQA ou em processos V amp V mais uma vez dependendo da organiza o do projeto Pelo fato dos planejamentos SQM lidarem com testes esta se o inclui alguns coment rios sobre os mesmos A KA Teste de Software fornece discuss es e refer ncias te ricas e t cnicas para teste e automa o Os processos de garantia descritos em SQA e V amp V examinam cada sa da relacionada com a especifica o de requisitos de software com a finalidade de se garantir rastreamento consist ncia completude corretude e performance Esta confirma o tamb m inclui os artefatos de sa da dos processos de desenvolvimento e manuten o coletando analisando e medindo os resultados A SQA garante que tipos apropriados de teste sejam adequadamente planejados desenvolvidos e implementados e a V amp V desenvolve planos de teste estrat gias casos e procedimentos Testes s o discutidos em detalhes na KA Teste de Software Dois tipos de testes podem cair sob a pauta de SQA e V amp V devido sua responsabilidade pela qualidade dos materiais usados no projeto e Avalia o e teste das ferramentas utilizadas no projeto IEEE 1462 98 e Teste de conformidade ou revi
39. o de c digo e t cnicas din micas execu o de c digo Ambas as categorias s o teis Esta rea de Conhecimento focaliza em t cnicas din micas Teste de software tamb m relacionado a constru o de software veja t pico 3 3 Testes de unidade e integra o s o relacionados intimamente com a constru o de software e n o parte disso Ds EE Terminologia Alvo Baseada na intui o Avalia o do relacionada 3 do ena expernbnacia do 3 programa sob Considera es pe ticas a testes Teste engenheiro de o Teste Objetivos Baseada Avalia o dos Atividades de na Testes de Teste Especifica o executados Teste Assuntos chave Rela es de teste com Outras atrnidades C digo baseadas Falha baseadas Uso baseadas Bascadas na natureza da aplica o Selecionando e combinando t cnicas Figura 15 T picos para rea de Conhecimento Teste de Software 2 1 3 4 1 Fundamentos de Teste de Software Muitos termos s o usados na literatura da engenharia de software para descrever um mau funcionamento falha not vel fracasso erro e outros v rios Essa terminologia precisamente definida em IEEE Standard 610 12 1990 Standard Glossary of Software Engineering Terminology IEEE610 90 e isso 12 discutido tamb m na rea de conhecimento Qualidade de Software Isso essencial para distinguir claramente entre a causa de um mau funcionamento para o qual o termo falha ou defe
40. o do projeto Curr culo de Computa o 2001 CC2001 identifica as seguintes listas de areas do conhecimento identificado como reas do relat rio para computa o cient fica Estruturas Discretas Programa o Fundamental 193 Algoritmos e Complexidade Organiza o e Arquitetura Sistemas Operacionais Net Centric Computing Linguagem de Programa o Intera o Humano Computador Computa o Gr fica e Visual Sistemas Inteligentes Gest o de Informa o Quest o Social e Profissional Engenharia de Software Computa o Cient fica e M todos Num ricos 2 1 3 11 3 Gerenciamento As diretrizes europeias do MBA definidas pela associa o europeia de corpos nacionais da abona o EQUAL indicam que o mestre do grau da administra o de neg cio deve incluir a cobertura e a instru o em Finan as Marketing e Vendas Gerenciamento de Opera es Sistemas de Gest o da Informa o Lei Regra Gest o de Recursos Humanos Economia An lise Quantitativa Pol tica e Estrat gia de Neg cio 2 1 3 11 4 Matem tica Duas fontes s o selecionadas para identificar a lista de reas do conhecimento para a matem tica O relat rio intitulou de crit rios de abona o e procedimentos a C mara Canadense de abona o da Engenharia que identificam 194 os elementos apropriados das seguintes reas e devem estar atuais em um curr culo da engenharia de gradua o e Algebra linear e C lcul
41. o engenheiro de software poder ter de enfrentar fatos tais como usu rios podem ter dificuldades em descrever suas tarefas informa es importantes podem ser omitidas pode haver falta de vontade em cooperar e A elicita o n o uma atividade passiva o engenheiro de software geralmente precisa trabalhar duro para elicitar as informa es corretas Principais t cnicas de elicita o utilizadas Entrevistas Forma tradicional de elicita o Possui vantagens e limita es Cen rios Cria o de contextos para a elicita o com usu rios E se Como ficaria Prot tipos Para esclarecer d vidas e simular como seria o funcionamento Reuni o com facilitadores brainstorming consultorias identifica o de conflitos Observa o Imers o no ambiente alvo para captar os aspectos culturais da organiza o e as tarefas nele executadas 2 1 3 1 4 An lise de Requisitos Processo de analisar requisitos para Detectar e resolver conflitos entre requisitos Descobrir as fronteiras do software e como ele deve interagir com o seu ambiente e Elaborar requisitos do sistema para derivar requisitos do software A vis o tradicional da an lise de requisitos faz com que ela se reduza ao modelamento conceitual usando algum m todo de an lise tal como o SADT Deve se ter o cuidado de descrever os requisitos com precis o suficiente para que possam ser validados sua implementa o verificada e seus cust
42. o podem ser satisfeitas no ponto designado no ciclo de vida Um desvio uma autoriza o para afastar se uma disposi o pr via para o desenvolvimento do item A ren ncia uma autoriza o para utilizar um item a seguir o seu desenvolvimento que derroga a disposi o de alguma forma Nestes casos um processo formal usado para obter a aprova o dos desvios ou isen es de as disposi es Ber92 C9 Buc96 c12 2 1 3 6 4 Software de contabilidade do Status da Configura o Software de contabilidade status de configura o SCSA o registo e comunica o de informa es necess rias para uma gest o eficaz da configura o do software a Status de Configura o de Software da Informa o A atividade SCSA projetos e opera um sistema de captura e transmiss o de 126 informa es necess rias como o produto do ciclo de vida Como em qualquer sistema de informa o as informa es de status de configura o a ser gerenciado para a evolu o das configura es devem ser identificadas coletadas e mantidas V rias informa es e as medidas s o necess rias para apoiar o processo de SCM e satisfazer as necessidades de status de configura o de relat rios de gest o engenharia de software e outras atividades relacionadas Os tipos de informa es dispon veis incluem a identifica o configura o aprovada bem como a identifica o e o atual est gio de implanta o das mudan as desvios e isen es
43. rias e se uma iniciativa de melhora foi bem sucedida O tipo anal tico exemplificado pela Quality Improvement Paradigm QIP constitu do por um ciclo da compreens o da avalia o e de embalagens SEL96 As t cnicas apresentadas a seguir se destinam a outros exemplos de t cnicas anal ticas e refletem o que feito na pr tica Fen98 Mus99 Lyu96 Wei93 Zel98 Organiza es espec ficas usam estas t cnicas pelo menos parcialmente na sua maturidade e Estudos experimentais Experimenta o envolve cria o de experimentos controlados na organiza o para avaliar processos McG94 Geralmente um novo processo comparado com o atual e determina se o antigo tem um melhor andamento e Outro tipo de estudo experimental o processo de simula o Este tipo de 162 estudo pode ser utilizado para a an lise do processo de comportamento explorar a melhoria de processos predizer se o atual processo foi alterado e controlar os processos em execu o Dados iniciais sobre o desempenho do atual processo necessitam ser recolhidos contudo como uma base para a simula o e Defini o de Revis o de Processos um meio pelo qual um processo de defini o descritivo prescritivo ou ambos revisto e as efici ncias e melhorias do processo s o identificadas Os exemplos t picos disto s o apresentados em Ban95 Kel98 Uma maneira f cil para analisar um processo compar lo com um padr o existente nacional
44. rios e ger ncia de configura o dos dados ISO 15939 02 5 2 4 Defina os crit rios para a avalia o dos produtos de informa o Crit rios para avalia o s o influenciados pelos objetivos t cnicos e de neg cio da unidade organizacional Produtos de informa o incluem aqueles associados com o produto sendo produzido bem como aqueles associados com os processos em uso para gerenciar e medir o projeto ISO 15939 02 5 2 5 e Ap ndices D e E Revise aprove e forne a recursos para as tarefas de mensura o medi o O plano de medi es deve ser revisado e aprovado pelos stakeholders apropriados Isso inclui todos os procedimentos de coleta de dados armazenamento an lise e procedimentos de divulga o de relat rios crit rios de avalia o cronograma e responsabilidades Crit rios para avalia o desses artefatos devem ser estabelecidos no n vel da unidade organizacional ou n vel superior e devem ser usados como base para essas revis es Tais crit rios devem considerar as experi ncias anteriores a disponibilidade de recursos e o potencial de interrup o do projeto quando mudan as nas pr ticas atuais s o propostas A aprova o demonstra o compromisso com o processo de medi o ISO 15939 02 5 2 6 1 e Ap ndice F Recursos devem ser disponibilizados para a implementa o das tarefas de 146 mensura o medi o planejadas e aprovadas A disponibilidade de recursos pode ser especulada experimentada no
45. tal como prototipagem evolutiva Extreme Programming XP e Scrum Estes tende a abortar e tratar constru o como uma atividade que ocorre concomitantemente com outras atividades de desenvolvimento de software incluindo requisitos design e planejamento ou sobrepor lhes Estes tende abordar para misturar design codifica o e atividades de testes e eles muitas vezes tratam a combina o de atividades como constru o Consequentemente o que considerado constru o depende em certa medida do ciclo de vida utilizado b Planejamento de constru o A escolha de m todos de constru o s o aspectos chaves da atividade planejamento de constru o A escolha de m todos de constru o afeta o grau a qual pr requisitos de constru o s o realizados a ordem em qual eles s o realizados e o grau para qual eles s o esperados para ser conclu dos antes de 64 come ar os trabalhos de constru o A abordagem de constru o do projeto afeta capacidade para reduzir complexidades antecipar mudan as e verifica o para constru o Cada um desses objetivos pode tamb m ser abordado no processo requisitos e n veis de design mas eles tamb m ser o influenciados pela escolha dos m todos de constru o Planejamento da constru o tamb m define a ordem em qual os componentes s o criados e entregados a gerencia de processo de qualidade de software a distribui o de tarefas espec ficas atribu das aos engen
46. Apesar de existir toda esta variedade n o foi encontrado divis es para este t pico c Ferramentas de Constru o de Software Este t pico refere se s ferramentas de constru o de software Estas ferramentas s o usadas para produ o e tradu o da representa o de um programa por exemplo c digo fonte que suficientemente detalhado e desenvolvido para permitir a execu o na m quina e Editores de programas Estas ferramentas s o usadas para a cria o e modifica o de programas e possivelmente os documentos associados a eles Eles podem ser editores de textos ou documentos de uso geral ou podem ser editores espec ficos para uma determinada linguagem Compiladores e Geradores de C digo Tradicionalmente os compiladores n o eram tradutores interativos de c digo fonte mas houve uma tend ncia em integrar compiladores e programas de edi o para se ter ambientes de programa o integrados Este t pico tamb m referencia processadores linker loaders e geradores de c digo e Interpretadores estas ferramentas fornecem execu o de software atrav s de emula o Elas podem apoiar as atividades de constru o de softwares 166 fornecendo um ambiente mais control vel e observ vel para a execu o de programas Depuradores Estas ferramentas s o consideradas uma categoria separada desde que elas deem apoio aos processos de constru o de software mas elas s o diferentes dos programas de e
47. Counting Practices Manual ISO and IEC 2002 15090003 04 ISO IEC 90003 2004 Software and Systems Engineering Guidelines for the Application of ISO9001 2000 to Computer Software ISO and IEC 2004 IS09001 00 ISO 9001 2000 Quality Management Systems Requirements ISO 1994 1509126 01 ISO IEC 9126 1 2001 Software Engineering Product Quality Part 1 Quality Model ISO and IEC 2001 Jac98 M Jackman Homeopathic Remedies for Team Toxicity IEEE Software July August 1998 pp 43 45 Kan02 S H Kan Metrics and Models in Software Quality Engineering second ed Addison Wesley 2002 Kan97 K Kansala Integrating Risk Assessment with Cost Estimation IEEE Software May June 1997 pp 61 67 Kar96 D W Karolak Software Engineering Risk Management IEEE Computer Society Press 1996 Kar97 J Karlsson and K Ryan A Cost Value Aproach for Prioritizing Requirements IEEE Software September October 1997 pp 87 74 Kau99 K Kautz Making Sense of Measurement for Small Organizations IEEE Software March April 1999 pp 14 20 Kei98 M Keil et al A Framework for Identifying Software Project Risks Communications of the ACM vol 41 iss 11 1998 pp 76 83 Kel98 M Kellner et al Process Guides Effective Guidance for Process Participants presented at the 5th International Conference on the Software Process 1998 Ker99 B Kernighan and R Pike Finding Performance Improvements
48. Diffusing Software Engineering Methods IEEE Software July 1989 pp 81 90 Rog83 E Rogers Diffusion of Innovations Free Press 1983 240 Rob99 P N Robillard The Role of Knowledge in Software Development Communications of the ACM vol 42 iss 1 1999 pp 87 92 Rod97 A G Rodrigues and T M Williams System Dynamics in Software Project Management Towards the Development of a Formal Integrated Framework European Journal of Information Systems vol 6 1997 pp 51 66 Rop97 J Ropponen and K Lyytinen Can Software Risk Management Improve System Development An Exploratory Study European Journal of Information Systems vol 6 1997 pp 41 50 Sch99 E Schein Process Consultation Revisited Building the Helping Relationship Addison Wesley 1999 Sco92 R L v Scoy Software Development Risk Opportunity Not Problem Software Engineering Institute Carnegie Mellon University CMU SEI 92 TR 30 1992 SEI95 Software Engineering Institute The Capability Maturity Model Guidelines for Improving the Software Process Addison Wesley 1995 SEL96 Software Engineering Laboratory Software Process Improvement Guidebook Software Engineering Laboratory NASA GSFC Technical Report SEL 95 102 April 1996 em http sel gsfc nasa gov website Sla98 S A Slaughter D E Harter and M S Krishnan Evaluating the Cost of Software Quality Communications of the ACM vol 41 iss 8 1998 pp 67 73
49. Medi o de Software para medi o de software O processo adequado ao S P S 2 uso com IEEE EIA 12207 ISO IEC Engenharia de Software Este padr o descreve o COSMIC FFP M todo de 19761 200 COSMIC FFP Um M todo de Medi o de Tamanho Funcional um m todo de E 3 Medi o de Tamanho Funcional medi o de tamanho funcional de acordo com os requisitos do padr o ISO IEC 14143 1 ISO IEC Engenharia de Software IFPUG Este padr o descreve o IFPUG 4 1 contagem de 20926 200 4 1 M todo de Medi o de ponto de fun o desajustado um m todo de medi o 3 Tamanho Funcional Desajustado de tamanho funcional de acordo com os requisitos do P S S S Manual de padr o ISO IEC 14143 1 Pr ticas de Contagem ISO IEC Engenharia de Software Mk II Este padr o descreve o Mk II Analisador de Pontos de 20968 200 An lise de Ponto de Fun o Fun o um m todo de medi o de tamanho E s 2 Manual de Pr ticas de Contagem funcional de acordo com os requisitos do padr o ISO IEC 14143 1 224 O Q z n o o D So To Do Deo 2 nao nD asl ag ws nHo neo ves ne rain N mero ocli og 0n 08 os 22 oLa oLa 98 Fx 0 amp z a fa 328 29134 20 259 239 230 F283 3a E Nome padr o Descri o z 292 5 8 3 szal Dao 2 52 25002 29 padr o So Sal aala FB Sos SZS DIS Dina so o DO 6 DO 0 DDAa DD SDa a o 2 o a oS oo of an o D o o e o gt o ISO IEC Software e Engenharia de Este padr o forn
50. P Fowler and S Rifkin Software EngineeringProcess Group Guide Software Engineering Institute Technical Report CMU SEI 90 TR 24 1990 Gol99 D Goldenson et al Empirical Studies of Software Process Assessment Methods IEEE1074 97 IEEE Std 1074 1997 IEEE Standard forDeveloping Software Life Cycle Processes IEEE 1997 e IEEE12207 0 96 IEEE EIA 12207 0 1996 ISO IEC12207 1995 Industry Implementation of Int Std ISO IEC 12207 95 IEEE830 98 IEEE Std 830 1998 IEEE Recommended Practice for Software Requirements Specifications IEEE 1998 IS015504 98 ISO IEC TR 15504 1998 Information Technology Software Process Assessment parts 1 9 ISO and IEC 1998 IS015939 02 ISO IEC 15939 2002 Software Engineering Software Measurement Process ISO and IEC 2002 IS09126 01 ISO IEC 9126 1 2001 Software Engineering Product Quality Part 1 Quality Model ISO and IEC 2001 Joh99 D Johnson and J Brodman Tailoring the CMM for Small Businesses Small Organizations and Small Projects Jor02 P C Jorgensen Software Testing A Craftsman s Approach second edition CRC Press 2004 Chap 2 5 10 12 15 17 20 Kan01 C Kaner J Bach and B Pettichord Lessons Learned in Software Testing Wiley Computer Publishing 237 2001 Kan99 C Kaner J Falk and H Q Nguyen Testing Computer Software second ed John Wiley amp Sons 1999 Chaps 1 2 5 8 11 13 15 Kot00 G Kotonya a
51. Software Processo de Medi o de Produto Processo de Avalia o Processo de Defini o Processo de Implementa o e Mudan a Modelos de Modelos de Medi o de Processo de Modelos para Processo de Implementa o e Mudan a Considera es Praticas Nota es para Defini es de Processos Adapta o de Processo Automatiza o Infraestrutura Ciclo de Vida do Avalia o de Processo Software Processos Ciclo de Processos do M todos para Medi o de Gerenciamento Ciclo de Vida do Avalia o de Produtos de do Processo Software Processos software Software Medi o da Qualidade dos Resultados Modelos de Informa o do Software T cnicas de Medi o do Processo Figural Distribui o dos temas do Processo KA para Engenharia de Software Figura 23 T picos para a KA Processo de Engenharia de Software a Processo de Infraestrutura Este t pico inclui o conhecimento relacionado para o processo de engenharia de infraestrutura de software Para estabelecer o ciclo de vida do processo de software necess rio ter um 150 local com infraestrutura apropriada o que significa que os recursos devem estar dispon veis pessoal competente ferramentas e recursos financeiros e responsabilidades definidas Quando as tarefas forem completadas ser a indica o de desempenho do gerenciamento para a apropria o e desempenho
52. Software de Auditoria de Configura o Funcional O objetivo do software FCA garantir que o item de software auditado est em conformidade com as especifica es aplic veis A sa da das catividades de verifica o e valida o um contributo essencial para esta auditoria b Software de Auditoria de Configura o Fisica O objetivo da auditoria de configura o de software f sica PCA garantir que a documenta o do projeto e de refer ncia consistente com o produto de software como constru do c Auditorias de processo de uma Baseline Software Como mencionado acima as auditorias podem ser realizadas durante o processo de desenvolvimento para investigar o estado atual de elementos espec ficos da configura o Neste caso a auditoria pode ser aplicada a itens de linha de base da amostra para assegurar que o desempenho consistente com as 128 especifica es ou para assegurar a evolu o documenta o continua a ser consistente com o ponto inicial de desenvolvimento 2 1 3 6 6 Software de Gerenciamento de Libera o e Entrega A liberta o utilizado neste contexto para se referir distribui o de um item de configura o de software fora da atividade de desenvolvimento Isto inclui a liberta o interna bem como a distribui o aos clientes Quando as vers es diferentes de um item de software est o dispon veis para entrega como vers es para diferentes plataformas ou em vers es com
53. Software e Gerenciamento de Engenharia de Software Informa es mais espec ficas sobre m tricas de teste s o apresentadas na KA Teste de Software Refer ncias Fen97 Jon96 Kan02 Pfl01 apresentam discuss es sobre an lise de defeito que consiste em medir a ocorr ncias de defeitos e em seguida aplicar m todos estat sticos para entender os tipos de defeitos que acontecem mais frequentemente ou seja respondendo a perguntas a fim de avaliar suas densidades Eles tamb m ajudam a entender as tend ncias bem como t cnicas de detec o que est o trabalhando e bem como os processos de desenvolvimento e manuten o est o progredindo Medidas de cobertura de teste ajudam estimar quanto esfor o de teste ainda precisa ser feito e a prever poss veis defeitos restantes A partir destes m todos de medida podem ser desenvolvidos perfis de 190 defeito para um dom nio espec fico de aplica o Ent o para o pr ximo sistema de software dentro daquela organiza o os perfis podem ser usados para guiar os processos de SQM ou seja para gastar o esfor o onde os problemas s o prov veis de acontecer Semelhantemente benchmarks pontos de refer ncia ou t pica contagem de defeitos desse dom nio podem servir como um aux lio para determinar quando o produto estar pronto para entrega A discuss o sobre o uso dados de SQM para melhorar o processo de desenvolvimento e de manuten o aparece nas KAs Gest o de Engenharia de S
54. Zweben que atuaram como copresidentes A miss o da comiss o mista era Estabelecer os conjuntos de crit rios e normas adequadas para a pr tica profissional da engenharia de software sobre a qual decis es industriais certifica es profissionais e curr culos educacionais pudessem se basear A dire o do comit organizou grupos de trabalho nas seguintes reas 1 Defini o do corpo de conhecimentos e pr ticas recomendadas 2 Defini o de tica e padr es profissionais 3 Defini o de curr culos educacionais para gradua o p s gradua o e educa o continuada Este guia fornece o primeiro componente Corpo de conhecimentos e pr ticas recomendadas O c digo de tica e padr es profissionais de engenharia de software foi conclu do em 1998 e aprovado tanto pelo conselho da ACM quanto pelo conselho da IEEE e tem sido adotado por in meras empresas e outras organiza es O curr culo educacional para alunos de gradua o foi conclu do com esfor o da IEEE e ACM em 2004 15 2 1 2 Defini es iniciais O Guia n o deve ser confundido com o Corpo de Conhecimento propriamente dito que j existe publicado na literatura O prop sito do guia descrever qual por o do Corpo de Conhecimento geralmente aceito para organizar esta por o e para fornecer um acesso atual a esta Informa es adicionais ao significado dado geralmente aceito podem ser encontradas adiante no Ap ndice A O Guia para o C
55. alguns tipos espec ficos de problemas precisam ser agrupados juntos em ordem para determinar o que ser feito a respeito sobre eles O ponto estabelecer uma taxonomia de defeito que seja significante organiza o e para os engenheiros de software SQM encontra informa es em todas as fases de desenvolvimento e manuten o de software Na vers o original em ingl s deste guia as palavras defect e fault s o utilizadas como refer ncia ao termo defeito Culturas ou padr es diferentes podem utilizar significados diferentes para estes termos o que levou a tentativas de defini los Defini es parciais tomadas a partir da norma IEEE610 12 90 s o e Erro error A diferen a entre um resultado computado e o resultado correto e Defeito fault Um passo processo ou defini o de dados incorreto 185 Falha failure O resultado incorreto de um defeito Engano mistake Uma a o humana que produz um resultado incorreto Modelos de confian a s o constru dos a partir de dados obtidos em falhas durante o teste ou funcionamento do software e assim podem ser utilizados para predizer futuros fracassos e auxiliar em decis es sobre quando os testes devem terminar Mus89 Uma prov vel a o resultante do SQM encontrar e remover os defeitos do produto sujeitos a an lise Outras a es permitem a obten o do resultado perfeito a partir das atividades do SQM Estas a es incluem analisar e resumir os
56. ap ndice um conjuntos dos padr es mais relevantes sendo a maior parte formada por padr es do IEEE e da ISO alocada para as KAs do Guia SWEBOK 2 1 2 19 Ap ndice D Como uma ajuda notavelmente dos curr culos dos desenvolvedores e outros usu rios em suporte ao quinto objetivo do projeto o quarto ap ndice aponta um 28 conjunto de categorias pedag gicas comumente atribu das a Benjamin Bloom O conceito que os objetivos educativos podem ser classificados em seis categorias representando crescimento de profundidade conhecimento compreens o aplica o an lise s ntese e avalia o Os resultados deste exerc cio para todas as KAs podem ser encontrados no ap ndice D Este ap ndice n o deve contudo ser examinado como uma classifica o definitiva mas muito mais como um ponto de partida Guia do Conjunto de Conhecimentos em Engenharia de Software Vers o 2004 Requisitos de Software Design de Software Constru o de Software Teste de Manuten o de Software Software Fundamentos de Fundamentos de Fundamentos de Fundamentos de Fundamentos de Requisitos Design Constru o Teste de Manuten o de de Software de Software de Software de Software de Software Assuntos chave Processo de hari Assuntos chave Requisitos ese Ap N veis H Em Manuten o de Teste de Software Elicita o de mare Estrutura e T cni Processo de quisitos Arquitet N a ectu
57. at Proceedings of the Third International Conference on the Software Process 1994 Mad97 R J Madachy Heuristic Risk Assessment Using Cost Factors IEEE Software May June 1997 pp 51 59 Mas95 S Masters and C Bothwell CMM Appraisal Framework Version 1 0 Software Engineering Institute McC96 S C McConnell Rapid Development Taming Wild Software Schedules Microsoft Press 1996 McC97 S C McConnell Software Project Survival Guide Microsoft Press 1997 McC99 S C McConnell Software Engineering Principles IEEE Software March April 1999 pp 6 8 Moy97 T Moynihan How Experienced Project Managers Assess Risk IEEE Software May June 1997 pp 35 41 McG01 J McGarry et al Practical Software Measurement Objective Information for Decision Makers Addison Wesley 2001 Mcg93 C McGowan and S Bohner Model Based Process Assessments presented at International Conference on Software Engineering 1993 McG94 F McGarry et al Software Process Improvement in the NASA Software Engineering Laboratory Software Engineering Institute CMU SEI 94 TR 22 1994 em http www sei cmu edu pub documents 94 reports pdf tr22 94 pdf Nak91 T Nakajo and H Kume A Case History Analysis of Software Error Cause Effect Relationship IEEE Transactions on Software Engineering vol 17 iss 8 1991 Ncs98 P Ncsi Managing OO Projects Better IEEE Software July August 1998 pp 50 60
58. atividade formalmente organizada com participantes que t m pap is espec ficos como auditor l der outro auditor um relator ou um iniciador e inclui um representante da organiza o examinada A auditoria identificar exemplos de n o conformidade e produzir um relat rio exigindo que a equipe entre com a o corretiva Embora possam existir muitos nomes formais para revis es e auditorias como identificados na Norma IEEE1028 97 o ponto importante a se considerar que eles podem acontecer em praticamente qualquer produto e qualquer fase do desenvolvimento ou processo de manuten o 2 1 3 10 3 Considera es pr ticas a Requisitos de Qualidade de Software V rios fatores influenciam no planejando gerenciamento e sele o de 183 atividades de SQM e t cnicas incluindo e O dom nio do sistema em que o software ir residir seguran a cr tica miss o cr tica neg cio cr tico e Os requisitos de sistema e do software Os componentes que ser o utilizados no sistema comercial externos ou padr es internos As normas especificas de engenharia de software aplicadas e Os m todos e ferramentas a serem utilizados no desenvolvimento manuten o e na avalia o e melhoramento da qualidade O or amento a equipe a organiza o do projeto planos e cronogramas de todos os processos e Os usu rios destinados ao uso do sistema e O n vel de integridade do sistema Informa o sobre estes fatores exe
59. b Ger ncia de Mudan as A ger ncia de mudan as central no gerenciamento de requisitos Gerencia de mudan as descreve o seu papel os procedimentos que precisam ser efetuados e a an lise que deve ser aplicada s propostas de mudan as Ger ncia de mudan as de requisitos est intimamente ligada Ger ncia de Configura o de software c Atributos de Requisitos Requisitos n o s o constitu dos apenas pela especifica o do que requerido mas tamb m por um conjunto de informa es adicionais que auxiliam a interpretar e gerenciar os requisitos Isso pode incluir v rias classifica es m todos de verifica o e aceita o e planos de teste Pode incluir Resumo do requisito Fonte do requisito Hist rico das mudan as Identificador a mais importante pois permite que requisitos tenham identifica o nica e n o amb gua d Rastreamento de Requisitos Rastreamento tem a ver com as fontes dos requisitos e com os efeitos sobre 45 os seus descendentes Fundamental para fazer an lise de impacto quando o requisito modificado Requisitos precisam ser rastreados e Backward Nas suas origens requisito e stakeholders que o motivaram Forward Nas entidades de projeto geradas a a partir deles requisitos m dulos de c digo testes Rastreamento de requisitos num projeto t pico ir formar um grafo ac clico dirigido DAG e Medi o de Requisitos Por quest es pr tic
60. curso ao longo do processo e verifica o e valida o de produto realiza es s o tamb m especificadas neste est gio por exemplo revis es e inspe es t cnicas veja tamb m Qualidade de Software KA g Gest o de Plano Como o projeto e o plano ser o geridos tamb m deve ser planejado Reportando monitorando e controlando o projeto deve estar de acordo com o processo de engenharia de software selecionado e s realidades do projeto e devem ser refletidos nos variados artefatos que ser o usados para geri lo Mas num ambiente onde a mudan a esperada ao inv s de um choque vital que os planos sejam geridos por si s s Isso exige que a ader ncia aos planos seja sistematicamente dirigida monitorada revista reportada e onde apropriado revisada Planos associados a outros processos de suporte orientados para gest o por exemplo documenta o gest o de configura o de software e solu o de problema tamb m precisam ser geridos da mesma maneira 2 1 3 7 3 Formaliza o do Projeto de Software Os planos s o ent o implementados e os processos consubstanciados nos planos s o formalizados Em tudo h o foco na ader ncia aos planos com uma expectativa priorit ria de que tal ader ncia ir levar bem sucedida satisfa o dos requisitos do stakeholder e ao alcance dos objetivos do projeto Fundamental para a formaliza o s o as atuais atividades de mensura o monitora o controle e relat
61. da arquitetura do projeto de software an lise t cnica da integra o do software Varia es das expectativas s o identificadas e as a es adequadas s o tomadas Como acima na atividade de controle do processo veja t pico 3 5 Controle do Processo em todos os casos procedimentos de controle de mudan as e ger ncia de configura o de software s o cumpridos veja tamb m a KA de Ger ncia de Configura o de Software para que as decis es sejam documentadas e comunicadas a todos os interessados planos s o revistos e revisados quando preciso e dados importantes s o gravados na base de dados central veja tamb m 6 3 Execu o do Processo de Medi o Mensura o Mais informa es podem ser encontradas na KA de Teste de Software t pico 2 2 Objetivos de Testes e na KA de Qualidade de Software t pico 2 3 Revis es e Auditorias b Analisando e Avaliando o Desempenho Performance Revis es peri dicas de desempenho para o pessoal do projeto fornecem esclarecimentos quanto a probabilidade de cumprimento dos planos tanto quanto a poss veis reas de dificuldade por exemplo conflitos entre membros da equipe Os v rios m todos ferramentas e t cnicas empregados s o avaliados por sua efetividade e adequa o e o processo por si s sistem tica e periodicamente avaliado por sua relev ncia utilidade e efic cia no contexto do projeto Onde apropriado mudan as s o feitas e gerenciadas 2 1 3 7 5 Fechamento O p
62. da repeti o de ensaios em uma grande pe a de software pode ser significativo em termos de tempo e dinheiro Regress o de testes a sele o de uma rean lise de software ou componente para verificar se as modifica es n o tenham causado efeitos n o intencionais que importante para a manuten o Encontrar tempo para testar muitas vezes dif cil H tamb m a desafio de coordenar diferentes testes quando os membros da equipe da manuten o est o trabalhando em diversos problemas ao mesmo tempo PIfO1 Quando se executa um software com as fun es cr ticas pode ser imposs vel traz lo para testar offline O Teste de Software KA fornece informa es adicionais e as refer ncias sobre o assunto em seu sub t pico 2 2 6 Regress o de testes Estudos de impacto Dor02 v1c9s1 10 Pfl01 c11s11 5 Estudo de impacto descreve como a conduta de forma eficaz pode analisar completamente o impacto de uma mudan a no software atual Os mantenedores devem possuir um conhecimento aprofundado da estrutura do software e de seu conte do Pfl01 Eles usam esse conhecimento para realizar an lises de impacto o que identifica todos os sistemas e produtos de software afetado por uma solicitada mudan a de software e desenvolve uma estimativa dos recursos necess rios para realizar a mudan a Art88 Al m disso o risco de fazer a mudan a determinado A mudan a pedida s vezes chamada de Pedido de Modifica o MR e muitas vezes
63. de GCS limites e orienta o para o GCS planejamento para o GCS o pr prio plano de GCS e a monitora o da GCS A segunda sub rea a Identifica o de Configura o de Software que identifica itens a serem controlados estabelece esquemas de identifica o dos itens e as suas vers es tamb m estabelece os instrumentos e t cnicas a serem utilizadas na aquisi o e no gerenciamento dos itens controlados Os primeiros t picos nesta sub rea s o a identifica o dos itens a serem controlados e a biblioteca de software A terceira sub rea o Controle de Configura o de Software que a 24 ger ncia de mudan as durante o ciclo de vida de software Os t picos s o primeiro solicitando avaliando e aprovando altera es no software em segundo lugar implementa o de modifica es no software e terceiro desvios e n o aprova es ren ncia de altera es A quarta sub rea a Registros de Estado de Configura o de Software Os seus t picos s o a informa o sobre posi o de configura o doe software e a reportagem do estado de configura o do software A quinta sub rea a Auditoria de Configura o de Software Ele comp e se da auditoria de configura o funcional do software auditoria de configura o f sica do software e auditorias no processo a partir de uma base de refer ncia do software A ltima sub rea a Ger ncia de Libera o e Entrega de Software cobrindo elabora o
64. de software Apr03 Nie02 Kaj01 a Processos de Manuten o O processo de manuten o fornece atividades necess rias detalhando as entradas sa das para essas atividades e s o descritas na Manuten o em software IEEE 1219 e nas normas ISO IEC 14764 O modelo de processo de manuten o descrito no Standard Manuten o de Software IEEE1219 inicia se com o esfor o de manuten o de software durante a fase p s entrega e aborda itens como planejamento para manuten o Aquele processo ilustrado na Figura 20 Co Pa Ca Identific Requisi o de a a a Modifica o me a coa aa da ee Aceita o P ia j em Figura 20 Atividades do Processo de Manuten o A ISO IEC 14764 IS014764 99 um aprofundamento do processo de manuten o IEEE EIA 12207 0 96 As atividades de manuten o da ISO IEC um processo semelhante dos do IEEE com a diferen a de serem agregadas um pouco diferente As atividades desenvolvidas no processo de manuten o pela ISO IEC s o mostradas na Figura 21 107 Implementa o do processo An lise do Revis o Problema e Aceita o da Modifica o Manuten o Implementa o da Modifica o Aposentadoria Figura 21 Processo de Manuten o de Software Cada uma das atividades prim rias de manuten o de software das ISO IEC 14764 subdividida em tarefas como se segue e Processo de Execu o Problema e An lise da Modifica o Ex
65. de software pode ser originada por qualquer pessoa em qualquer ponto do ciclo de vida do software e pode incluir uma proposta de solu o e a prioridade solicitada Uma fonte de solicita es de mudan a o in cio de a o corretiva em resposta a relat rios de problemas Isso fornece uma oportunidade para acompanhar os defeitos e coletar medidas de atividade se alteram por tipo de altera o Depois de um SCR recebida uma avalia o t cnica tamb m conhecida como an lise de impacto realizada para determinar a extens o das modifica es que seriam necess rias caso o pedido de mudan a ser aceitas Uma boa compreens o das rela es entre software e possivelmente 124 hardware itens importante para esta tarefa Finalmente uma autoridade estabelecida compat vel com a linha de base afetado o SCI envolvidos bem como a natureza da mudan a ir avaliar os aspectos t cnicos e gerenciais da solicita o de mudan a e quer aceitar modificar recusar ou adiar a mudan a proposta A autoridade para aceitar ou rejeitar as altera es propostas recai sobre uma entidade tipicamente conhecido como um controle de configura o CCB Em projetos menores esta autoridade pode realmente residir com o l der ou um indiv duo atribu do ao inv s de uma placa multi pessoa Pode haver v rios n veis de autoridade mudar dependendo de uma variedade de crit rios tais como a criticidade do item em causa a natureza da mudan a por
66. de vers es de software e gerenciamento de libera o de software 2 1 2 11 KA de Gerenciamento da Engenharia de Software O KA Gerenciamento da Engenharia de Software aponta o gerenciamento e mensura o da engenharia de software Enquanto a mensura o um aspecto importante em todas as KAs est aqui que o t pico de programas de mensura o apresentado H seis sub reas na KA de gerenciamento de engenharia de software As cinco primeiras cobrem assuntos relacionados com gerenciamento de projetos de software e a sexta o sexto descrevem programas de mensura o de software A primeira sub rea a Inicia o e Defini o de Escopo que compreende a determina o e a negocia o de requisitos an lise de praticabilidade e processo da reavalia o e a revis o de requisitos A segunda sub rea o Planejamento de Projeto de Software e inclui o planejamento de processo determinando pacotes de trabalhos deliverables o esfor o agendamento e a estimativa de custos a aloca o de recursos a ger ncia dos riscos a ger ncia de qualidade e o plano de gerenciamento A terceira sub rea a Aprova o do Projeto de Software Os t picos tratados nesta KA s o a implementa o de planos ger ncia de contrato de fornecedores a implementa o do processo de mensura o monitora o de processo controle de processo e a divulga o de informa es do projeto A quarta sub rea Revis o e Avalia o que inclui os
67. design mapeando o software dentro dos peda os de componente Entretanto por conta dessa import ncia no campo de crescimento da arquitetura de software n s abordaremos o PF Design fam lia de padr o de projeto cujo o objetivo estabelecer explora es comuns na fam lia de software Em contraste a KA Design de Software n o aborda Design design da inven o usualmente executada durante o processo de requisitos de software como o objetivo de conceitualizar e especificar o software para satisfazer descobertas necess rias e requisitos desde este t pico deve ser considerado parte da especifica o e an lise de requisitos A descri o do Design de Software KA relatada especificamente para os Requisitos do software Constru o do Software Gerenciamento e Engenharia de Software Qualidade do Software e Disciplinas Relatadas com a Engenharia de Software 47 2 1 3 2 1 Fundamentos do Design de Software Os conceitos no es e terminologia introduzidas aqui formam uma linha base para entender o papel e o escopo do design de software a Conceitos Gerais de Design O Software n o o nico campo onde o design est envolvido No senso geral n s podemos ver design como uma forma de resolver problemas Por exemplo o conceito de um mau problema um problema sem solu o definitiva interessante em termos de entendimento dos limites do design Uma s rie de outras no es e conceitos s o tamb m de interesse par
68. devem pagar honor rios para custear o despesa de vota o titulares do CSDP devem ser particularmente bem vindos como membros do grupo de vota o ou como volunt rios em outros pap is Uma resolu o do comit de vota o deve ser selecionada por um comit de gerenciamento para servir como intermedi rio entre os redatores e os votantes Seu trabalho determinar o consenso para mudan as requisitadas pelo grupo de vota o e para garantir que os redatores ir o implementar as mudan as necess rias Em alguns casos o comit de resolu o de votos precisa formular quest es para guiar a revis o da reda o Cada objetivo anual alcan ar consenso entre o grupo de vota o nas novas e revisadas reas de conhecimento e ganhar o voto de aprova o dos votantes Apesar do guia SWEBOK n o mudar at o fim do time box o material aprovado de cada ciclo anual estar dispon vel gratuitamente na conclus o do time box o produto completo guia SWEBOK 2008 ser revisado e aprovado por um board da Sociedade de Computa o e governadores para publica o Se o suporte financeiro cont nuo puder ser obtido o produto estar dispon vel gratuitamente em um Web Site 2 1 4 2 4 Mudan as Antecipadas importante notar que o guia SWEBOK inerentemente um documento conservador por v rias raz es Primeiro limita se ao conhecimento das caracter sticas de engenharia de software ent o informa es de disciplinas relacionadas mes
69. do objetivo procurado que a efetividade do conjunto de teste pode ser avaliada Per95 c21 Fra98 c Teste para identifica o de defeito Nos testes para identifica o de defeito um teste de sucesso um que causa a falha do sistema Isso bastante diferente dos testes para demostrar que o software satisfaz suas especifica es ou outras propriedades desejadas nesse caso o teste de sucesso se nenhuma falha significante observada Kan99 c1 73 d O problema do or culo Um or culo qualquer agente humano ou mec nico que decide se um programa se comportou corretamente dentro de um determinado teste e consequentemente produz um veredito de passe ou falhe Existem muitos tipos de or culos e a automa o de or culos pode ser muito dif cil e cara Bei90 c1 Ber96 Wey83 e Limita es te ricas e pr ticas de teste A teoria de teste adverte contra atribuir n vel injustificado de confian a para uma s rie de testes passados Infelizmente a maioria dos resultados estabelecidos de teoria de teste s o negativos na condi o de que um teste pode nunca alcan ar ao inv s de que eles atualmente alcan am A cita o mais famosa nessa considera o o prov rbio de Dijkstra que teste de programa pode ser usado para provar a presen a de bugs mas nunca para mostrar sua aus ncia A raz o bvia que o teste completo de software n o poss vel em software real Por causa disto o tes
70. emprega uma importante regra no desenvolvimento de software isso permite engenheiros de software produzirem v rios de modelos que formam um tipo de plano de solu o para ser implementado N s podemos analisar e avaliar estes modelos para determinar se eles nos permitir o atender as diversas necessidades N s podemos tamb m examinar e avaliar v rias solu es alternativas e confront las Finalmente n s podemos usar os modelos resultantes para planejar as atividades do desenvolvimento subsequente em adi o ao uso deles como entrada e ponto de come o da constru o e teste Em uma listagem padr o do processo de ciclo de vida de software tal como IEEE EIA 12207 Processos de Ciclo de Vida do Software IEEE 12207 0 96 design de software consiste em duas atividades que situa se entre an lises e requerimentos de software e constru o de software e Design de arquitetura de software algumas vezes chamada design de alto n vel Top Level design Descreve altos n veis de estrutura e organiza o de software s e identifica o de componentes e Design de software detalhado Descreve cada componente suficientemente para permitir esta constru o A respeito do escopo da rea de Conhecimento do Design de Software KA a atual descri o KA n o discute cada t pico do nome que cont m a palavra design Na terminologia de Tom DeMarco s DeM99 a KA discutida neste cap tulo trata principalmente do D Design decomposi o do
71. engenheiro de software deve saber muito mais do que isso Al m do conhecimento geralmente aceito uma gradua o de engenharia de software com quatro anos deve possuir alguns elementos de disciplinas relacionadas bem como alguns elementos de conhecimento especializado conhecimento avan ado e possivelmente at mesmo conhecimento de pesquisa As seguintes suposi es foram feitas quando os n veis da taxonomia proposta e As avalia es s o propostas para um engenheiro de software generalista e n o um engenheiro de software que trabalham em um grupo especializado como uma equipe de gerenciamento de configura o de software por exemplo Obviamente como engenheiro de software seria necess rio atingir n veis taxonomia muito maiores na rea de especialidade do seu grupo Um engenheiro de software com quatro anos de experi ncia ainda est no in cio de sua carreira e lhe seria atribu das relativamente poucas fun es de gest o ou pelo menos n o para grandes empreendimentos T picos relacionados ao gerenciamento n o s o portanto uma prioridade nas avalia es propostas Pela mesma raz o os n veis de taxonomia tendem a ser menores para temas iniciais do ciclo de vida tais como os relacionados 226 com os requisitos de software do que para os t picos mais tecnicamente orientados tais como aqueles dentro do projeto de software software de constru o ou testes de software Assim as avalia es podem se
72. exemplo o impacto sobre o or amento e cronograma ou o ponto atual do ciclo de vida A composi o das CCBs utilizado para um determinado sistema varie em fun o desses crit rios um representante da SCM estaria sempre presente Todos os interessados adequadas ao n vel da CCB est o representados Quando o escopo da autoridade da CCB estritamente software que conhecido como comit de controle configura o de software SCCB As atividades do CCB s o normalmente sujeitas auditoria da qualidade de software ou de revis o Uma solicita o de mudan a efetiva de software SCR processo requer o uso de ferramentas de apoio e os procedimentos que v o de formul rios de papel e um procedimento documentado para uma ferramenta eletr nica para efetuar pedidos de mudan a refor ando o fluxo do processo de mudan a captando as decis es do CCB e relatar processo de mudan a da informa o A liga o entre essa capacidade da ferramenta e do sistema de notifica o de problemas pode facilitar o acompanhamento das solu es para os problemas relatados descri es de processo de mudan a e as formas de apoio informa o s o dados em uma variedade de refer ncias por exemplo Ber92 c9 b Implementa o de mudan as de software Aprovado SCRs s o implementados usando os procedimentos definidos por software em conformidade com os requisitos calend rio aplic vel Desde que um n mero de SCRs aprovados poder o ser imp
73. gerados da intui o e da experi ncia do engenheiro de software as especifica es a estrutura do c digo real ou artificial falhas a serem descobertas o uso de campos ou finalmente a natureza da aplica o s vezes estas t cnicas s o classificadas como caixa branca igualmente chamada caixa transparente se os testes confiam na informa o sobre como o software foi projetado ou codificado ou como caixa preta se os casos de teste confiam somente no comportamento de entrada sa da Uma ultima categoria trata o uso combinado de duas ou mais t cnicas Obviamente estas t cnicas n o s o usadas muitas vezes igualmente por todos os engenheiros S o inclu das na lista aquelas que um engenheiro de software deve saber a baseadas na intui o e na experi ncia da engenheiro de software e teste ad hoc Kan99 c1 Talvez a t cnica mais extensamente praticada 19 permane a sendo o teste ad hoc os testes s o derivados confiando na habilidade do engenheiro de software intui o e experi ncia com programas similares O teste ad hoc pode ser til para identificar testes especiais aqueles n o facilmente capturados por t cnicas formalizadas e Teste explorat rio O teste explorat rio definido simultaneamente como aprendizagem o projeto do teste e a execu o do teste isto os testes n o s o definidos antecipadamente em um plano de teste estabelecido mas s o dinamicamente projetados executados e modificad
74. identifica o de quais t cnicas ser o mais teis na identifica o de falhas e na avalia o de qualidade N veis de integridade por exemplo grada o de integridade s o propostos em IEEE1012 98 b Caracteriza o de Defeitos Os processos de SQM encontram defeitos A caracteriza o destes defeitos conduz compreens o do produto facilita corre es do processo ou do produto e informa ger ncia do projeto ou ao cliente o status do processo ou produto Existem muitas taxonomias de falhas e embora tentativas tenham sido feitas para se obter uma taxonomia padronizada de erros e falhas a literatura indica que ainda existem algumas vers es diferentes em uso Bei90 Chi96 Gra92 IEEE1044 93 Caracteriza o de defeitos tamb m usada em auditorias e revis es o l der de revis o frequentemente apresenta uma lista de falhas fornecidas por membros da equipe para aprecia o em uma reuni o de revis o Enquanto novos m todos de design e linguagens evoluem juntamente com os avan os em tecnologias de software globais novas classes de defeitos aparecem e uma grande dose de esfor o exigida para interpretar as classes definidas anteriormente Ao localizar defeitos o engenheiro de software est interessado n o s no n mero de defeitos mas tamb m nos tipos A informa o isolada sem nenhuma classifica o n o realmente de muita utilidade na identifica o das causas subjacentes dos defeitos uma vez que
75. impratic vel implementar requisitos como um processo linear e determin stico um mito pensar que nos grandes projetos de software os requisitos s o perfeitamente entendidos e especificados Na maioria das vezes o requisito sofre aperfei oamento continuado s ficando pronto quando o produto estiver terminado Requisitos podem ir para uma baseline sem que suas propriedades estejam completamente entendidas Isso arrisca retrabalho de problemas que podem surgir depois no processo de Engenharia de software Engenheiros de software por necessidades decorrentes do gerenciamento do projeto precisam tomar algumas atitudes que assegurem a qualidade dos requisitos t o alta quanto poss vel com os recursos dispon veis Devem ser explicitados quaisquer pressupostos bem como os problemas conhecidos 44 Entendimento dos requisitos envolve tanto os procedimentos do projeto como os de desenvolvimento Ponto crucial no entendimento de requisitos uma propor o significativa dos requisitos ir mudar devido a erros de an lise mudan as no ambiente de opera o ou de neg cio mudan as no mercado onde ser inserido o produto Mudan as s o inevit veis e medidas devem ser tomadas para mitigar o seu impacto Mudan as devem ser gerenciadas por um processo definido rastreamento an lise de impacto e Gerencia de Configura o Processo de requisitos n o tarefa front end mas expande se por todo o ciclo de vida do software
76. leitor seja melhor exposto fonte e ao alcance do padr o O texto que acompanha figuras e tabelas deve ser evidente ou conter texto relacionado suficiente Isto poder assegurar que o leitor saiba o que as figuras e as tabelas significam Assegure se que voc usa a informa o atual de refer ncias vers es t tulos etc Para assegurar se que alguma informa o contida no Guia do SWEBOK n o 208 fique rapidamente obsoleta por favor evite denominar diretamente ferramentas e produtos Em vez disso tente denominar suas fun es A lista de ferramentas e produtos pode sempre ser adicionada a um ap ndice Espera se que voc explique todos os acr nimos usados nos m nimos detalhes e use todos os direitos autorais apropriados marcas de servi o etc As Descri es de reas do Conhecimento devem sempre ser escritas na terceira pessoa 2 1 4 1 13 Edi o A Equipe Editorial e os editores profissionais editarao as Descri es das reas do Conhecimento A Edi o inclui a edi o de c pia gram tica pontua o e capitaliza o edi o do estilo conformidade ao estilo das revistas da casa Sociedade de Computa o e edi o do conte do fluxo significado clareza corre o e organiza o A edi o final ser um processo colaborativo no qual a Equipe Editorial e os autores colaboraram para realizar uma Descri o das reas do Conhecimento concisa bem expressa e til 2 1 4 1 14 Libera o de Di
77. linha de base funcional corresponde aos requisitos do sistema s o revisados A linha de base atribu do corresponde revista especifica o de requisitos de software e interface de software especifica o de requisitos A base de desenvolvimento representa a configura o de software em desenvolvimento por vezes selecionados durante o ciclo de vida do software Alterar autoridade para 122 essa linha de base geralmente cabe principalmente organiza o de desenvolvimento mas pode ser compartilhada com outras organiza es por exemplo SCM ou de teste A base do produto corresponde ao produto de software entregue preenchido para integra o de sistemas As linhas de base a ser usada para um determinado projeto juntamente com seus associados n veis de autoridade necess rio para a aprova o da mudan a s o geralmente identificadas no SCMP Itens de configura o de software s o colocados sob controle SCM em momentos diferentes ou seja eles s o incorporados a uma base particular em um determinado ponto do ciclo de vida do software O fato gerador a realiza o de algum tipo de tarefa a aceita o formal como uma revis o formal A Figura 2 caracteriza o crescimento de itens de linha de base como o produto do ciclo de vida Este valor baseado no modelo em cascata para fins de ilustra o os ndices usados na figura indicam as vers es dos itens de evolu o Ap s a aquisi o de um SCI altera es para o item
78. mensura o medi o Avalie o processo de medi o contra os crit rios de avalia o especificados e determine os pontos fortes e fracos do processo Isto pode ser realizado por um processo interno ou por uma auditoria externa e deve incluir o feedback retorno dos usu rios das medi es Registre as li es aprendidas numa base adequada ISO 15939 02 5 4 1 e Ap ndice D Identifique melhorias potenciais Tais melhorias podem ser mudan as nas formas dos indicadores mudan as nas unidades de medida ou reclassifica o das categorias Determine os custos e benef cios das melhorias potenciais e selecione as a es de melhoria adequadas Comunique as proposi es de melhoria aos propriet rios do processo de medi o e aos stakeholders para revis o e aprova o Tamb m comunique a falta de melhorias potenciais caso a an lise falhe ao identificar as melhorias ISO 15939 02 5 4 2 2 1 3 8 Processo de Engenharia de Software O processo de engenharia de software KA pode ser estudado em 2 n veis O primeiro n vel engloba as atividades t cnicas e gerenciais dentro do processo do ciclo de vida do software que s o realizados durante aquisi o desenvolvimento manuten o e retirada O segundo o meta n vel que se concentra na defini o implementa o avalia o mensura o ger ncia mudan a melhoria do processo de ciclo de vida software em si O primeiro n vel coberto por outra guia KA Este KA est concentrad
79. nad 2 1 3 reas de conhecimento 2 1 3 1Requisios de Solivare bl ik sat os dea OO ay tie aes A A DU a A e AS 31 2 1 3 1 1 Fundamentos de Requisitos de Software ccccccecceceeeeeeeneeeeeeeeeeeeeeeaeeceaeeeeeaeeseaeeesneeeseeeeesseeeeeeeeeees 32 2 1 9 1 2 Processo de Requisitos ena aana aea aaa ISO ete eaten alae cated eee ea 34 2 13 1 3 Elicita osde REQUISITOS m ea aii pus lise eA LAL ead ed AA ele aed 35 2 1 3 1 4Analise de REQUISILOS c5 aseeesceenreeben en tye ea o nodes TER E ee eee oe Hea ae ete eae 36 2 1 3 1 5 Especifica o de REqQuisitos ccccceccceceseeeeeeeeceseeeceeeeseeeeesaeeseaeesssaeeseaaeseaeessaaeessaeeeseneesseaaeeaeeeeeeeeess 39 2 1 3 1 6 Valida o de Requisito S fnt av ates avin andes GEE a E sd a ad fg capa En nb O 41 2 1 3 1 7 Considera es Praticas sic sister tanta a a E o valo a anda Na TEA E TEE eared Dead seas 43 2 11 32 Design de SOTWare adorar ea tees k tgs DRA OO nea S NOS eat Ia tay et beseech vs aon La GOO ces kel cdot DO O a GE Gaeta 46 2 1 3 2 1 Fundamentos do Design de Software ccccccesccecesceeeeeeeeeeeeeeneeceneeecaaeeseaeeesaeeseaeesseaeeesaeesseeeseaeeeees 48 2 1 3 2 2 Os Pontos Chave no Design de Software rear eaee nana aane nantan aaa aaaanana 50 2 1 3 2 3 Estrutura e Arquitetura de Software 2 1 3 2 4 An lise e Evolu o da Qualidade de Design de Software ereta 53 2 1 3 2 5 Nota es de Design de software
80. no inicio da fase de planejamento sendo preventivos em termos de processos e procedimentos necess rios para atingir as caracter sticas de qualidade e grau de qualidade necess rios pelas partes interessadas stakeholders no software A Ger ncia de Risco tamb m pode desempenhar um papel importante no cumprimento da qualidade de software Incorporar an lise disciplinada de riscos e t cnicas de gest o nos processos do ciclo de vida do software pode aumentar o potencial para se desenvolver um produto de qualidade Cha89 Recorra KA Gest o de Engenharia de Software para material relacionado sobre ger ncia de risco a Garantia da Qualidade de Software Os Processos SQA garantem que os produtos de software e os processos no ciclo de vida do projeto estejam em conformidade com seus requisitos de especifica o pelo planejamento ordenamento e execu o de uma s rie de atividades para fornecer a confian a adequada de que a qualidade est sendo incorporada ao software Isto significa assegurar que o problema est clara e adequadamente declarado e que os requisitos da solu o est o corretamente definidos e expressados SQA procura manter a qualidade ao longo do desenvolvimento e manuten o do produto pela execu o de uma variedade de 178 atividades em cada fase que pode resultar na identifica o precoce de problemas uma caracter stica quase inevit vel de qualquer atividade complexa O papel da SQA com respeito ao proces
81. o Pode conter modelos conceituais para ilustrar o contexto do sistema cen rios principais entidades do dom nio dados ou informa es e fluxogramas IEEE Std 1362 Documento de conceito de opera o modelo b Especifica o de Requisitos do Sistema Aplica se a sistemas que possuem n mero consider vel de componentes software e n o software frequentemente separa se a descri o dos requisitos do sistema da descri o dos requisitos de software Assim os requisitos de sistema s o especificados e os requisitos de software s o derivados deles e ent o os requisitos de componentes do software s o especificados Especifica o de Requisitos do Sistema uma atividade de Engenharia de Sistemas fora do nosso objetivo IEEE Std 1233 um guia para desenvolver requisitos de sistema c Especifica o de Requisitos de Software Estabelece base para acordo entre clientes contratadores ou fornecedores Define o que o produto de software deve ser e o que ele n o deve ser Para leitores n o t cnicos o documento de especifica o de requisitos de 40 software frequentemente acompanhado por um documento de defini o dos requisitos de software ERS Permite avalia o rigorosa dos requisitos antes do in cio do seu projeto e reduz re projeto Prov de base real stica para estimar custos prazos e riscos Base para confec o de planos de verifica o e valida o Normalmente escrito em lingua
82. o depende do uso de normas externas para constru o de linguagens constru o de ferramentas t cnicas de interfaces e intera es entre constru o de software e outras KAs Normas v m de numerosas 63 fontes incluindo hardware e interface de especifica o de software tais como o Grupo Gest o Objeto OMG e organiza es internacionais tais como a IEEE ou ISO Uso de normas interna Normas tamb m podem ser criadas sobre uma base organizacional no n vel corporativo ou para utiliza o em projetos espec ficos Estas normas apoiam a coordena o de grupos atividades minimizar complexidade antecipa o de mudan a e constru o para verifica o 2 1 3 3 2 Gest o de Constru o a Modelos de constru o In meros modelos t m sido criados para desenvolver software algumas dos quais enfatizam constru o mais do que outros Alguns modelos s o mais lineares e parti do ponto de constru o e visualiza o tal como o modelo de ciclo de vida cascata Estes modelos trata constru o como uma atividade na qual ocorre apenas depois de significativo trabalho de detalhamento de requisitos foi conclu do extenso trabalho de design e detalhe de planejamento O mais linear tende abordar para enfatizar a atividade esse precede constru o requisitos e design e tende para criar mais clara separa o entre as atividades Nestes modelos a nfase principal pode ser a codifica o Outros modelos s o mais interativos
83. o e integridade de um produto pela identifica o de seus elementos gerenciando e controlando mudan as e verificando registrando e apresenta o informa es sobre configura o A partir da perspectiva do engenheiro de software SCM facilita o desenvolvimento e a implementa o de atividades de mudan a Uma implementa o bem sucedida de SCM requer um cuidadoso planejamento e gerenciamento Este por sua vez requer um entendimento do contexto organizacional para e as restri es colocadas sobre o design e implementa o dos processos de SCM a Contexto Organizacional para SCM Para planear um processo de SCM para um Projeto necess rio compreender o contexto organizacional e os relacionamentos entre os elementos organizacionais SCM interage com v rias outras atividades ou elementos organizacionais Os elementos organizacionais respons veis pelo apoio aos 114 processos de engenharia de software podem ser estruturados de v rias maneiras Embora a responsabilidade de realizar certas tarefas SCM pode ser designada para outras partes da organiza o como a organiza o de desenvolvimento a responsabilidade global pelo SCM muitas vezes recai em um distinto elemento organizacional ou individuo designado Software frequentemente desenvolvido como parte de um sistema maior que contenham elementos de hardware e firmware Neste caso atividades SCM t m lugar em paralelo com atividades GC de hardware e firmware e devem se
84. principais fun es de software e refina o elaborando as de cima para baixo O design estruturado geralmente usado depois da an lise estruturada assim produ o entre outras coisas diagrama de fluxos de dados e descri es de processo associadas Os pesquisadores propuseram v rias estrat gias por exemplo a an lise de transforma o an lise de transa o e heur stica por exemplo fan in fan out o alcance do efeito contra o alcance do controle para transformar um DFD em uma arquitetura de software geralmente representada como um diagrama de estrutura Dor02 v1c6s4 Fre83 V Jal97 c5 Pre04 c9 c10 c Design orientado a objeto Numerosos m todos de design de software baseados em objetos foram propostos O campo evoluiu com o primeiro design baseado em objeto em meados dos anos 80 substantivo objeto verbo m todo o adjetivo atributo pelo design de OO onde a heran a e o polimorfismo desempenham um papel chave ao campo do design base de componente onde a informa o de Meta pode ser definida e acessada pela reflex o por exemplo Embora as ra zes de design OO venham do conceito de abstra o de dados o design levado por responsabilidade tamb m tenha sido proposto como uma aproxima o alternativa ao design de OO Dor02 v1 c6s2 s3 Fre83 VI Jal97 c6 Mar02 D Pre04 c9 d Design centrado por estruturas de dados O desenho centrado por estruturas de dados por exemplo Jackson Warnier Orr partidas
85. processo algumas atividades de manuten o s o comuns as do desenvolvimento de software por exemplo ger ncia de configura o de software uma atividade crucial para ambos Ben00 A Manuten o exige tamb m v rias 103 atividades que n o s o encontrados no desenvolvimento de software Essas atividades apresentam desafios para a gest o Dor02 Aspectos organizacionais da manuten o Pfl01 c12s12 1 c12s12 3 Par86 c4s7 Pig97 c2s2 5 Tak97 C8 Os aspectos organizacionais descrevem a forma de identificar qual organiza o e ou fun o ser respons vel pela manuten o de software A equipe que desenvolve o software n o necessariamente atribu da a manter o software quando este estiver operacional Para decidir onde ir funcionar a manuten o de software as organiza es de engenharia de software podem por exemplo permanecer com o desenvolvedor original ou ir a uma equipe separada ou mantenedores Muitas vezes a op o mantenedor escolhida de modo a garantir que o software funcione adequadamente e evolua para satisfazer necessidades evolutivas dos utilizadores Uma vez que h muitos pr s e os contras de cada uma destas op es Par86 Pig97 a decis o deve ser feita com base em cada caso O importante a delega o ou cess o da responsabilidade pela manuten o a uma nica pessoa ou grupo Pig97 independentemente da estrutura da organiza o Terceiriza o Dor02 v1c9s1 7 Pig97 c9s9 1
86. produto T rmino Bei90 c2s2 4 Per95 c2 Uma decis o deve ser tomada se a quantidade de teste suficiente e quando um est gio de teste pode ser terminado Medidas de efic cia como a cobertura conseguida do c digo ou a integralidade funcional assim como estimativas da densidade das falhas ou da confiabilidade operacional fornecem sustenta o util mas n o s o suficientes em si mesmas A decis o igualmente envolve considera es sobre os custos e os riscos incorridos pelo potencial para falhas restantes ao contr rio dos custos implicados na continuidade do teste Ver tamb m sub t pico 1 2 1 crit rios de sele o de testes sufici ncia de testes Reuso de teste e padr es de teste Bei90 c13s5 Para realizar o teste ou a manuten o de uma maneira organizada e custo efetiva os meios usados para testar cada parte do software devem ser reusados sistematicamente Este reposit rio de materiais do teste deve estar sob o controle da ger ncia de configura o do software de modo que as mudan as nos requisitos do software ou o projeto possam ser refletidos nas mudan as no escopo dos testes conduzidos As solu es de teste adotadas no teste de alguns tipos de 89 aplica o sob determinadas circunst ncias com as motiva es atr s das decis es tomadas d o forma a um padr o de teste que pode ser documentado para reuso posterior em projetos similares b Atividades de teste Sob este t pico dada uma br
87. profissional o projeto conjunto ACMM IEEE CS para desenvolver um curr culo de engenharia de software para n o graduados altamente reconciliados com o escopo do guia SWEBOK O comit de padr es para Engenharia de software SESC tem organizado essa cole o pelas reas de conhecimento do guia SWEBOK e a associa o de padr es IEEE j publicou uma edi o em CD ROM dos padr es de engenharia de software que refletem sua organiza o ISO IEC JTC1 SC7 os padr es internacionais de organiza o para software e engenharia de software est adotando o guia SWEBOK como relat rio t cnico ISO IEC 19759 e harmonizando sua cole o com a do IEEE A editora da Sociedade de Computa o IEEE em coopera o com o SESC est desenvolvendo uma s rie de livros baseados nos padr es de engenharia de software e no guia SWEBOK O portal da sociedade de computa o de engenharia de software SE online atualmente em planejamento ser organizado por reas de conhecimento do guia SWEBOK O uso da vers o trial do SWEBOK foi traduzido para o Japon s Prev se que em 2004 a vers o ser tamb m traduzida em Japon s chin s e possivelmente outras l nguas O CSDP adicionou uma rea de conhecimento Pr ticas de neg cio e engenharia econ mica para as dez reas de conhecimento cobertas pelo guia SWEBOK 2 1 4 2 3 O Processo de Evolu o Obviamente um produto com tanta aceita o precisa evoluir de uma forma aberta cons
88. programa o PDLs as linguagens estruturadas como linguagens de programa o para descrever geralmente na etapa de detalhamento de design o comportamento de um procedimento ou m todo Fre83 VII Jal97 c7 Pre04 c8 c11 2 1 3 2 6 Estrat gias e M todos de Design de Software Existem v rias estrat gias gerais para ajudar a orientar o processo de planejamento Mar02 D Em contraste com as estrat gias gerais os m todos s o mais espec ficos nisto eles geralmente sugerem e fornecem um conjunto de nota es a ser utilizadas com o m todo uma descri o do processo a ser utilizado quando o seguinte m todo e um conjunto de orienta es na utiliza o do m todo Tais m todos s o teis como um meio de transferir conhecimento e como um framework comum de equipes de engenheiros de software Veja tamb m os Instrumentos de Engenharia de Software e M todos KA a Estrat gias Gerais 57 Algumas vezes exemplos de estrat gias gerais s o citados como teis em design de processo dividir e conquistar em um refinamento gradual Fre83 V top down vs estrat gias bottom up abstra o de dados e informa es ocultas de Fre83 V o uso da heur stica uso de modelos e linguagens de modelo Bus96 c5 uso de uma aproxima o iterativa e incremental Pfl01 c2 b Design orientado por fun o Estruturado Este um dos m todos cl ssicos do design de software onde a decomposi o centra na identifica o das
89. rastreio de requisitos Dor02 v1c4s2 Pfl01 C11 e An lise est tica formal ou semi formal est tico n o execut vel an lises que possam ser utilizadas para avaliar um projeto por exemplo an lise fault tree ou verifica o cruzada automatizada Jal97 c5 Pfl01 c5 Simula o e prototipagem t cnicas din micas para avaliar um projeto por exemplo desempenho ou simula o viabilidade de prot tipo Bas98 c10 Bos00 c5 Pfl01 c5 c Medidas As medidas podem ser utilizadas para avaliar quantitativamente estimativos ou v rios aspectos do tamanho do design de software estrutura ou qualidade A maior parte das medidas que foram propostas dependem geralmente da abordagem 54 utilizada para produzir o design Estas medidas s o classificadas em duas grandes categorias e Medidas de Design Orientados a Fun o estruturados a concep o da estrutura obtido principalmente atrav s da decomposi o funcional geralmente representada como uma estrutura gr fica s vezes chamado de diagrama hier rquico em que v rias medidas podem ser computadas Jal97 C5 C7 Pre04 c15 e Medidas de Design Orientados a Objeto a concep o global da estrutura muitas vezes representada como um diagrama de classes em que v rias medidas podem ser computadas Medidas sobre as propriedades de cada classe interna do conte do tamb m podem ser computadas Jal97 C6 C7 Pre04 c15 2 1 3 2 5 Nota es de Design de software
90. requisito para suportar uma esp cie particular de conta livre de taxas O molde reflete uma caracter stica fundamental no dom nio banc rio essa conta pode ganhar vantagens enquanto que a anterior pode tornar se obsoleta por mudan a na legisla o governamental Destacando potenciais requisitos vol teis pode ajudar o engenheiro de software estabelecer um design que seja mais tolerante mudan as b Modelagem Conceitual Desenvolvimento de modelos de um problema no mundo real chave para an lise de requisitos de software Seu prop sito auxiliar no entendimento do problema antes de iniciar o projeto da solu o Consequentemente modelos conceituais compreendem modelos de entidades do dom nio do problema configurado para refletir relacionamentos e depend ncias do mundo real Diversos tipos de modelo podem ser desenvolvidos Esses incluem dados e fluxos de controle modelos de estado rastreamento de eventos intera o com usu rios modelos de objetos modelos de dados e outros Fatores que influenciam na escolha do modelo 37 e Natureza do problema software de tempo real gt modelo de fluxo de controle e estado e Per cia do engenheiro de software ou quem ir utilizar o modelo e Requisitos de Processo do Cliente podem impor sua nota o ou m todo e Disponibilidade de ferramentas e m todos SADT UML Na maioria dos casos util come ar pela constru o de um modelo do contexto do software que forn
91. resultados e utilizar t cnicas de medi o para melhorar o produto e o processo bem como localizar e remover os defeitos Melhoria de processos discutida principalmente na KA Processo de Engenharia de Software sendo o processo SQM uma fonte de informa o Os dados sobre falhas e defeitos encontrados durante a implementa o de t cnicas de SQM podem ser perdidos a menos que sejam registrados Para algumas t cnicas por exemplo revis es t cnicas auditorias inspe es relatores est o presentes para estabelecer informa es junto com quest es e decis es Quando ferramentas automatizadas forem usadas a sa da da ferramenta pode fornecer a informa o de defeito Os dados sobre os defeitos podem ser coletados e registrados em um SCR pedido de mudan a de software e pode ser entrado subsequentemente em algum tipo de banco de dados manualmente ou automaticamente de uma ferramenta de an lise Relat rios sobre defeitos s o fornecidos administra o da organiza o c T cnicas de Gerenciamento de Qualidade de Software T cnicas de SQM podem ser categorizadas em muitas formas est tico pessoas intensivas anal tico din mico T cnicas est ticas envolvem an lise da documenta o de projeto e software e outras informa es sobre os produtos de software sem os executar Estas t cnicas podem incluir atividades pessoas intensivas como definido em 3 3 2 ou atividades anal ticas como definido em 3 3 3 conduzid
92. rios divulga o de informa es 140 a Implementa o dos Planos O projeto iniciado e as atividades do projeto s o realizadas de acordo com o cronograma No processo recursos s o utilizados por exemplo esfor o pessoal financiamento e entregas s o produzidas por exemplo documentos de projeto da arquitetura casos de teste b Ger ncia de Contrato de Fornecedores Prepare e execute contratos com fornecedores monitore o desempenho dos fornecedores e aceite o fornecedor de produtos incorporando os como for apropriado c Implementa o da Mensura o de Processos O processo de mensura o formalizado junto com o projeto de software assegurando que os dados relevantes e teis s o coletados d Acompanhamento do Processo A ader ncia aos variados planos continuamente avaliada em intervalos pr determinados Resultados e condi es de conclus o de cada tarefa s o analisados Entregas s o avaliadas em termos de suas caracter sticas requeridas por exemplo atrav s de revis es e auditorias Esfor o despendido ades o ao cronograma e custos para entrega em dia s o investigados e o recurso utilizado examinado O perfil de risco do projeto revisto e a ader ncia aos requisitos de qualidade avaliada Medi es de dados s o modeladas e analisadas An lise de varia es baseada nos desvios dos resultados e valores atuais e esperados efetuada Isto pode ser feito na forma de cust
93. sistem ticas com a finalidade de se ter uma maior probabilidade de sucesso Os m todos normalmente fornecem nota es e vocabul rios para o procedimento de tarefas identific veis e orienta es para verificar o processo e o produto Eles variam amplamente no escopo para uma simples e completa fase do ciclo de vida A nfase nesta KA Knowledge Area rea de Conhecimento esta nos m todos da engenharia de software englobando v rias fases do ciclo de vida desde a fase de especifica o at os m todos cobertos por outras KAs Embora existam manuais detalhados ferramentas espec ficas e numerosos trabalhos de investiga es em rela o a ferramentas inovadoras t cnicas gen ricas de escrita de ferramentas de software s o relativamente escassas Uma das dificuldades a elevada taxa de mudan a nas ferramentas de software em geral Detalhes espec ficos s o alterados regularmente A engenharia de software ferramentas e m todos KA cobre todos os processos de 164 um ciclo de vida e portanto relacionada para toda KA neste guia Egon dd Gorn Correia a Biches Enger carte da Soha E amrai Fep Do o Faas Bhesa cu ma mi He ai m ir s arrea aa Lee Figura 25 T picos da KA Ferramentas e M todos da Engenharia de Software 2 1 3 9 1 Ferramentas da Engenharia de Software Os cinco primeiros t picos nas sub reas das Ferramentas de Engenharia de Software correspondem aos cinco primeiros KAs deste Guia Requisit
94. stakeholders trocam dados 42 Se for utilizada especifica o formal poss vel utilizar racioc nio l gico para provar propriedades das especifica es d Testes de Aceita o Propriedade importante dos requisitos O produto deve ser validado nos seus requisitos Requisitos que n o possam ser validados s o meros desejos preciso planejar como verificar cada requisito Teste de Aceita o Para serem validados eles precisam primeiro ser analisados at o ponto de serem expressos quantitativamente Pode ser dif cil projetar Testes de Aceita o para os Requisitos N o Funcionais Informa es adicionais no t pico 2 2 4 Testes de Conformidade KA Teste de Software 2 1 3 1 7 Considera es Pr ticas Vis o Simplista A decomposi o de subareas apresentada uma simplifica o do processo na verdade ele se expande por todo o ciclo de vida do software NICO ics Ciclo de Vida do Produto i lt final EA Se Engenharia de Requisitos Vigura 8 Vis o simplista 43 a Ciclo de Vida do Produto arco m ie o modifica o EEE PES ES Engenharia de Requisitos Figura 9 Vis o realista a Natureza Iterativa do Processo de Requisito Mercado atual pressiona ind stria para ciclos curtos de desenvolvimento Alguns projetos s o desenvolvidos adaptando projetos anteriores ou aproveitando partes deles quase sempre
95. t picos aqui contidos representa um aumento substancial da bagagem necess ria para que o profissional seja mai completo Isto contribui ainda para que este profissional tenha uma vis o mais ampla de todos estes processos e possa ser inserido em outros projetos da empresa Al m disso este trabalho torna se extremamente til como base para informar qualquer profissional interessado em conhecer a defini o de cada componente do corpo de conhecimento da engenharia de software 3 3 Aspectos positivos e Negativos Um importante aspecto a ser expresso que contribuir para o maior conhecimento deste guia e seus componentes foi uma atividade conclu da com xito Destaca se tamb m o aprofundamento de temas de engenharia de software o conhecimento de novos conceitos a interliga o destes conceitos com reas de outras ci ncias Isto sem d vida foi um ponto positivo deste trabalho A dificuldade em se traduzir alguns termos para a nossa l ngua culta talvez tenha sido um ponto a ser considerado como dificultoso Na l ngua inglesa usam se recursos como a uni o de palavras cujo sentido se torna totalmente divergente das 235 palavras originais N o raras s o as vezes onde o melhor termo a ser empregado para tradu o normalmente n o tem nada haver com as palavras usadas na l ngua inglesa 3 4 Futuro do Guia Analisando o por qu de sua cria o e observando os rumos que as tecnologias t m tomado no sentido da padroniza
96. t picos de determinar a 25 satisfa o dos requisitos e revis o e avalia o da performance A quinta sub rea descreve o Fechamento determina o de fechamento e atividades de fechamento Finalmente a sexta sub rea descreve a Mensura o da Engenharia de Software mais especificamente programas de mensura o As mensura es de produto e processos s o descritos na KA Processo de Engenharia de Software Muitas outras KA tamb m descrevem medidas espec ficas para a sua respectiva KA Os t picos desta sub rea incluem o estabelecimento e comprometimento da mensura o planejamento do processo de mensura o execu o do processo de mensura o e avalia o da mensura o 2 1 2 12 KA Processo de Engenharia de Software A KA Processo de Engenharia de Software trata da defini o implementa o avalia o mensura o gerenciamento altera es e melhora do pr prio processo de engenharia de software dividida em quatro sub reas A primeira subarea apresenta o Processo de Implementa o e Mudan as Os t picos nesta KA s o a infraestrutura de processo o ciclo do processo de gerenciamento do software modelos de implementa o do processo e mudan as e considera es pr ticas A segunda sub rea trata da Defini o do Processo Ela inclui os t picos de modelos de ciclo de vida do software processos de ciclo de vida de software nota es das defini es do processo adapta o do processo e automa
97. todos da Engenharia de Software fornece a descri o das ferramentas utilizadas por cada rea de conhecimento assim como ferramentas para problemas variados A rea de conhecimento Qualidade de Software se torna uma das mais importantes reas dentro do corpo de conhecimento da engenharia de software Nela encontramos as defini es para qualidade e em particular as t cnicas est ticas ou seja os valores conceitos e metodologias que envolvem a concep o do software As disciplinas relacionadas com engenharia de software cederam para esta 234 um acervo de conhecimento que foi fundamental para a sua exist ncia Atrav s delas foram tra adas as diretrizes e o conte do b sico e distinto para esta nova disciplina que tamb m contribu ram atrav s de seus autores com o seu rico reposit rio bibliogr fico Neste reposit rio encontramos material de refer ncia que de suma import ncia para pesquisas cient ficas e est o organizadas por rea de conhecimento facilitando assim seu manuseio 3 2 Principais contribui es Entre as contribui es advindas deste trabalho ressalta se em primeiro lugar a tradu o do SWEBOK para o portugu s Tamb m servir de fundamenta o para outros trabalhos acad micos e p s gradua o Para profissionais da rea de desenvolvimento de design de manuten o de constru o e outras reas afins n o s em se tratando de software mas de um modo geral o conhecimento dos
98. 07 95 Standard for Information Technology Software Life Cycle Processes Implementation Considerations IEEE 1997 IEEE14143 1 00 IEEE Std 14143 1 2000 ISO IEC14143 1 1998 Information Technology Software Measurement Functional Size Measurement Part 1 Definitions of Concepts IEEE 2000 IEEE1517 99 IEEE Std 1517 1999 IEEE Standard for Information Technology Software Life Cycle Processes Reuse Processes IEEE 1999 IEEE1540 01 IEEE Std 1540 2001 ISO IEC 16085 2003 IEEE Standard for Software Life Cycle Processes Risk Management IEEE 2001 IEEE610 12 90 IEEE Std 610 12 1990 R2002 IEEE Standard Glossary of Software Engineering Terminology IEEE 1990 15014674 99 ISO IEC 14674 1999 Information Technology Software Maintenance ISO and IEC 1999 15015288 02 ISO IEC 15288 2002 Systems Engineering System Life Cycle Process ISO and IEC 2002 15015504 98 ISO IEC TR 15504 1998 Information Technology Software Process Assessment parts 1 9 ISO and IEC 1998 15015939 02 ISO IEC 15939 2002 Software Engineering Software Measurement Process ISO and IEC 2002 15019761 03 ISO IEC 19761 2003 Software Engineering Cosmic FPP A Functional Size Measurement Method ISO and IEC 2003 15020926 03 ISO IEC 20926 2003 Software Engineering IFPUG 4 1 Unadjusted Functional Size Measurement Method Counting Practices Manual ISO and IEC 2003 15020968 02 ISO IEC 20968 2002 Software Engineering MK II Function Point Analysis
99. 1 c3 Pfl01 c5 Pre04 c9 Abstra o o processo de esquecer informa es tais como coisas diferentes que podem ser tratadas como se elas fossem a mesma Lis01 No contesto de design de software dois mecanismos chave de abstra o s o a parametriza o e a especifica o Abstra o por especifica o guia nos aos tr s maiores tipos de abstra o abstra o procedural abstra o de dados e controle itera o de abstra o Jal97 c5 c6 Lis01 c1 c2 c5 c6 Pre04 c1 Acoplamento e Coes o Acoplamento definido como uma for a de relacionamento entre m dulos enquanto coes o definido por como os elementos que formam um m dulo s o relacionados Jal97 c5 Pfl01 c5 Pre04 c9 Decomposi o e modulariza o Decompor e Modularizar um grande software dentro de um pequeno n mero de partes nicas e independentes usualmente com o objetivo de colocar diferentes funcionalidades ou responsabilidades em diferentes componentes Bas98 c6 Bus96 c6 Jal97 c5 Pfl01 c5 Pre04 c9 Encapsulamento Ocultamento de Informagao significa agrupar e separar em pacotes elementos e detalhes internos de uma abstra o e fazendo esses detalhes inacess veis Bus96 c6 Jal97 c5 Pfl01 c5 Pre04 c9 Separa o da interface e implementa o envolve definir um componente para especificar uma interface conhecer clientes separando os detalhes de como os componente ralizado Bos00 c10 Lis01 c1 c9 Sufici ncia completude e simplicid
100. 1 conhecimento geralmente aceito para gerenciamento de projetos da seguinte maneira Meios geralmente aceitos que o conhecimento e as pr ticas descritas s o aplic veis maior parte dos projetos na maior parte do tempo tendo consenso comum sobre o seu valor e utilidade Geralmente aceito n o significa que o conhecimento e as pr ticas descritas s o ou devem ser aplicados uniformemente em todos os projetos a equipe de gerenciamento de projetos sempre respons vel por determinar o que apropriado para qualquer projeto dado O Guia do Corpo de Conhecimento de Gerenciamento de Projetos agora um Padr o IEEE No encontro inicial Mont Tremblant em 1998 o Conselho Consultivo Industrial melhor definiu geralmente aceito como conhecimento a ser inclu do no material de estudo de um exame de engenharia de software que um graduado passaria depois de concluir quatro anos de experi ncia de trabalho Essas duas defini es devem ser vistas como complementares Tamb m se espera que Editores Associados das reas do Conhecimento estejam pensando a frente nas suas interpreta es levando em considera o n o s o que geralmente aceito hoje mas o que eles esperam que seja geralmente aceito em um per odo de 3 a 5 anos 204 Geralmente Aceito Estabelece pr ticas tradicionais recomendadas por v rias organiza es Avan ado e Pesquisa Pr ticas inovadoras testadas e usadas somente por algumas org
101. 19 98 A 11 IEEE12207 0 96 s6 2 Pfl01 c11s11 5 Tak97 c7 O padr o IEEE para Manuten o de Software IEEE 1219 IEEE1219 98 descreve a gest o da configura o de software como um elemento cr tico do processo de manuten o Os procedimentos de gerenciamento de configura o do Software dever o prever a verifica o valida o e auditoria de cada passo necess rio para identificar autorizar executar e liberar os produtos de software Ele n o suficiente simplesmente para monitorar a Modifica o ou os Pedidos de relat rios dos problemas O produto de software e quaisquer mudan as feitas a ele t m de ser controladas Este controle estabelecido pela implementa o e aplica o um programa aprovado de gerenciamento de processo de configura o SCM O Software Configuration Management KA fornece detalhes de SCM e discute o processo pelo qual os pedidos de mudan a de software sejam apresentados avaliados e aprovados O processo de SCM para manuten o de software diferente do processo SCM para desenvolvimento de software quanto ao n mero de pequenas mudan as que devem ser controladas no software operacional O processo SCM implementado atrav s do desenvolvimento de um plano de gest o e procedimentos operacionais Os mantenedores devem participar da configura o das c maras de controle e determinar o conte do dos pr ximos release vers es Qualidade de software IEEE12207 0 96 s6 3 IEEE1219 98 A 7 IS014764
102. 21 disciplinas com que a engenharia de software compartilha limites Este cap tulo identifica em ordem alfab tica essas disciplinas relacionadas Para cada disciplina relacionada e utiliza o de uma fonte reconhecida base de consenso s o identificados uma defini o informativa quando fact vel uma lista de KAs As seguintes disciplinas sao relacionadas com a engenharia de software Administragao Ergonomia de Software Ci ncias da Computa o Gerenciamento da Qualidade Engenharia de Computa o Gerenciamento de Projetos Engenharia de Sistemas Figura 4 Disciplinas relacionadas com engenharia de software 2 1 2 16 Ap ndice A O ap ndice descreve as especifica es fornecidas pela equipe editorial aos editores associados para o conte do refer ncias recomendadas formato e estilo das descri es das KAs 2 1 2 17 Ap ndice B O segundo ap ndice descreve a proposta do projeto da evolu o da Guia O Guia 2004 simplesmente a edi o atual de um guia que continuar evoluindo para conhecer as necessidades da comunidade de engenharia de software O planejamento quanto evolu o ainda n o esta completo mas uma tentativa feita com este ap ndice Como est sendo escrito este processo foi endossado pelo Industrial Advisory Board e resumido para o Board of Governors da Computer Society do IEEE por m ainda n o consolidado ou implementado 2 1 2 18 Ap ndice C O terceiro
103. 3 10 3 Considera es praticas uses pads etc eal ened eee ais activa ee 183 2 1 3 11 Disciplinas Relacionadas Com Engenharia de Software cccccccccecceceeeeeeeeeeeeeeneeeeeaeeseceeeenneeeeeeeeeeeeeees 192 2 1 3 11 1 Engenharia da Computagao csccccccceseseeeeeeeceseeeeeneeceaeeeeneeseaeeceaeeseseeeseaeeseaaeeseaeesseaeeseaeeseeneeeseaees 192 2 1 3 11 2 Ci ncia da Computa o 2 1 3 11 3 GEreNClaMeMtO ss ccicieices duce scecescesvacaccusnta shes estsdescaveneuesvocasnesgstcssiesuavescvsntacberesa deedeugassesubisvbssVinsscusedsuassees DASA IGA Matem tica as tido aa Rea de de li SS Ea 2 1 3 11 5 Gest o de Projeto Sninu ai aliens cea dO sam CA yaks opener ieee a ee 21 3 11 6 Ger ncia deiQualidade aa ccecdcoteccde coesade eu danc siete a ag eden a CDC IA SATA Era ad ein dar Dead 196 2 1 3 11 7 Ergonomia de SOWAS sseni ea a Mere eetials Seas dinda ala ads eua ala 196 2 1 3 11 8 Engenharia de sistemasS sas ecisarsissprirasioadic aaa e span ala ee alee ete 198 2 14 APONAICOS aininn o sis sie lead hasnt dt do GL ala LE dal LUAS a RS eee ad a ad etal a dA eit 199 21 44 Ap ndice sas E aata avtaneieed cn cays T PERSA OL RUE EURO Dad MUS Ol ap aaa gua a 199 2 1 4 1 1 Especifica es da Descri o de Area Para o SWEBOK c ccscssssssssesssssesesscssstsesscstsesestasstsenseacenees 199 2 1 4 1 2 Crit rios e Exig ncias para Propor as Divis es de T picos renas 199 2 1 4 1 3 Crit rios e
104. 5 2 Problemas chave na manuten o de software eee areearennanenacaeananananaaana 99 2 1 3 5 3 Processo de manuten o eita ceraeaaaena aerea aaaaana ne ananaa nana ana EEEE EESE EnEn EEEE 106 2 1 3 5 4 T cnicas de ManutenGa0 ccessseeic cei lasek Dl dono apa anna Da paia de da gd ra pai da gd Linda e OMe 112 2 1 3 6 Ger ncia de Configura o de Software cccccccsceeeeeeecenceeeeeeeeeeeeceaeeeeeaeeeesaeeceaeeeeaeeseaeesceaeeseneesseeesenaeeseaees 113 2 1 3 6 1 Gerenciamento dos Processos SGM iicssescecsscessceusensievscsacenscaccesteatcevccescsacenedaecoscentenacensnadeteavoodetenens 2 1 3 6 2 Identifica o da Configura o de Software re ereeaaeeaanarenanaeaanacarerennaaaaana 2 1 3 6 3 Software de controle de configura o erre eeetcareeanaraaaaaeanaaaaaaarareaaaaaaaaa 2 1 3 6 4 Software de contabilidade do Status da Configura o 2 1 3 6 5 Auditoria de Configura o de Software eira cera arena nananasanaaaanarenaanaaaaaa 2 1 3 6 6 Software de Gerenciamento de Libera o e Entrega 2 1 3 7 Ger ncia de Engenharia de Software rente cera aaeeea aerea aaaenananeanarna nana naaaaana 21 3 74 Inicia o e Defini o dei eSCOPO ive aater anaidai aeiaai ia adadi essas vdap nad 2 1 3 7 2 Planejamento de Projeto de Software ie erreeeeaereaaaeeaaaanaaaanenraaaaaanaaa 2 1 3 7 3 Formaliza o do Projeto de Software reter areea n
105. 5 o 5 9 5 9 E o oo Se Soja so Soo Da gia das Fa D o Q D D D o IEEE Std Padr o IEEE Vocabul rio de Este padr o o vocabul rio de terminologias de 610 12 terminologias de Engenharia de engenharia de software 1990 Software x x x A 3 5 E e E R2002 IEEE Std Padr o IEEE para qualidade e Este padr o especifica o formato e conte do dos 730 2002 garantia de planejamento de planos de garantia e qualidade de software S S P software IEEE Std Padr o IEEE para planejamento da Este padr o especifica o conte do do plano de 828 1998 ger ncia de configura o de Ger ncia de configura o de software juntamente P S software com requisitos para atividades espec ficas IEEE Std Padr o IEEE para documenta o Este padr o descreve a forma e conte do de um 829 1998 de teste de software conjunto b sico de documenta o para planejamento S P S execu o e relat rio de teste de software IEEE Std IEEE Pr tica recomendada para Este documento recomenda o conte do e 830 1998 especifica o de requisitos de caracter sticas da especifica o de requisitos de P software software S o fornecidos esbo os de exemplo IEEE Std Padr o IEEE Dicion rio de Este padr o fornece um conjunto de medidas para 982 1 medidas para produ o de avaliar a confiabilidade de um produto de software e E B 1988 software confi vel para a obten o de previs es iniciais da confiabilidade de um produto em desenvolvimento IEEE S
106. A lista resultante frequentemente classifica as anomalias consulte a IEEE 1044 93 para detalhes e a sua completude e corre o s o garantidas por uma revis o da equipe A decis o de sa da da inspe o tem que corresponder a um dos tr s crit rios seguintes 182 Aceitar com nenhuma ou no m ximo com pequenas modifica es e Aceitar com verifica o de refactoring Inspecionar Reuni es de inspe o duram tipicamente algumas horas enquanto que revis es t cnicas e auditorias em geral possuem um escopo mais abrangente e duram mais tempo O prop sito de um walk through avaliar um produto de software Um walk through pode ser realizado com a finalidade de educar uma audi ncia relacionada com o produto de software IEEE1028 97 Os principais objetivos s o IEEE 1028 97 e Encontrar anomalias Melhorar o produto de software e Considerar alternativas de implementa es e Avaliar conformidade a normas e especifica es O walk through semelhante a uma inspe o mas normalmente conduzida com menos formalidade O walk through principalmente organizado pelo engenheiro de software para dar aos companheiros de equipe oportunidade de revisar seu trabalho como uma t cnica de garantia O prop sito de uma auditoria de software fornecer uma avalia o independente da conformidade de produtos de software e processos para padr es diretrizes planos e procedimentos IEEE1028 97 A auditoria uma
107. Ger ncia de Engenharia de Software 2 1 3 7 1 Inicia o e Defini o de escopo O foco deste conjunto de atividades est na eficaz determina o de exig ncias de software via m todos de elicita o e avalia o do desenvolvimento da pr tica do projeto olhando de v rios pontos de vista Uma vez a pr tica sendo estabelecida as tarefas restantes dentro deste processo passam a ser a especifica o de requisitos e modifica o dos procedimentos ver tamb m as Exig ncias de Software KA a Determina o e Negocia o de Requisitos M todos de requerimentos de software para elicita o de requisitos por exemplo observa o an lise por exemplo modelagem de dados modelagem de casos de uso especifica o e valida o por exemplo prototipagem deve ser selecionado e aplicado considerando se as perspectivas de todas partes interessadas Isto leva determina o de alcance de projeto objetivos e constrangimentos Isto exige muitas vezes alguns campos de estima o esfor o e custo baseados em m todos adequados por exemplo t cnicas de analogia informadas por perito Dor02 v2c4 Pfl01 c4 Pre04 c7 Som05 c5 136 b An lise de Viabilidade t cnica operacional financeira Pol tica Social Engenheiros de software devem estar seguros sobre a capacidade adequada e se os recursos est o dispon veis pessoas especializa o instala es infraestrutura e apoio quer interna ou externamente para gara
108. ISTO3 utiliza uma frase semelhante Qualidade dirigida pelo cliente Mais recentemente qualidade foi definida na IS09001 00 como o grau com o qual um conjunto de caracter sticas intr nsecas cumpre requisitos Este cap tulo trata das considera es da qualidade de software que transcendem os processos do ciclo de vida Qualidade de software uma quest o onipresente na engenharia de software e por isso tamb m considerada em muitas das KAs Em resumo o Guia SWEBOK descreve v rios modos de alcan ar qualidade de software Em particular esta KA cobrir t cnicas est ticas aquelas que n o requerem a execu o do software sendo avaliado enquanto t cnicas din micas s o cobertas na KA Teste de Software n Engenharia de SW Qualidade Qualidade Qualidade Valida es Defeitos de Qualidade Auditorias Gerenciamento de Qualidade Melhoria Qualidade ca de Qualidade Figura 26 T picos para a KA Qualidade de Software 172 2 1 3 10 1 Fundamentos da Qualidade de Software O entendimento dos requisitos de qualidade bem como a clara comunica o com o engenheiro de software no que constitui qualidade requer que v rios aspectos sejam formalmente definidos e discutidos Um engenheiro de software deve entender os significados b sicos dos conceitos e caracter sticas da qualidade e seus valores para o produto em desenvolvimento ou manuten o O conceito fundamental o de que requisitos de sof
109. Impedir o desempenho degradante do software para um n vel inaceit vel d A Maioria dos Custos de Manuten o A manuten o consome uma parte significativa dos recursos financeiros do ciclo de vida de software A percep o comum de manuten o de software que ela apenas corrige falhas No entanto estudos e pesquisas ao longo dos anos t m indicado que a maioria mais de 80 do esfor o da manuten o de software usada para a es n o corretivas Abr93 Pig97 Pre01 Jones Jon91 descreve a maneira pela qual os grupos de gerentes de manuten o de software frequentemente apresentam melhorias e corre es na gest o de seus relat rios A inclus o de problemas acess rios aos relat rios contribui para algumas das ideias erradas sobre o elevado custo de corre es Compreender as categorias de manuten o de software ajuda a compreender a estrutura dos custos de manuten o do software Tamb m entender os fatores que influenciam a manuten o de um sistema pode ajudar na conten o de despesas Pfleeger Pfl01 apresenta alguns dos fatores t cnicos e n o t cnicos que afetam os custos de manuten o de software como segue Pfl01 c11s11 3 Pig97 c3 Pre01 c30s2 1 c30s2 2 97 e Tipo de aplica o e Novidade em Software Disponibilidade de pessoal para a manuten o de software e Dura o de vida do Software e Caracter sticas do Hardware e Qualidade de design de software constru o documenta o e te
110. M todos de avalia o de processos A fim de realizar uma avalia o um m todo avalia o espec fica deve ser seguido para produzir uma Pontua o quantitativa que caracteriza a potencialidade do processo ou maturidade da organiza o O m todo de avalia o CBA IPI por exemplo concentra se em processo de melhoria Dun96 o m todo SCE centra se em avaliar as capacidades dos fornecedores Bar95 Ambos foram desenvolvidos pelo SW CMM Ambos os tipos de m todos de requisitos refletem o que se acredita ser boas pr ticas de avalia o est o previstas em 15015504 98 Mas95 Os m todos scampi s o orientadas pela avalia es CMMI SEIO1 As atividades realizadas durante uma avalia o sao a distribui o do esfor o sobre estas atividades bem como a atmosfera durante um avalia o s o diferentes quando s o para a melhoria do que para uma jun o Tem havido cr ticas aos modelos de avalia o de processo e m todos por exemplo Fay97 Gra98 A maioria dessas cr ticas t m se preocupado com as evid ncias emp ricas que d o suporte utiliza o de modelos e m todos de avalia o No entanto desde a publica o desses artigos verificaram se de forma sistem tica alguns elementos que sustentavam a efic cia dos processos de avalia o Cla97 Ele00 Ele00a Kri99 2 1 3 8 4 Processo e Medi o de Produto Embora a aplica o de medi o da engenharia de software pode ser complexa particularmente em term
111. Provavelmente a inspe o e revis o dos documentos de requisitos constitui a maneira mais comum de valida o O grupo de revis o busca por erros contradi es falta de clareza e desvios de pr ticas padr es e A composi o do grupo muito importante e pelo menos um representante do cliente precisa estar inclu do Pode ser til o fornecimento de checklists para auxiliar Revis es devem ser constitu das quando for completado o Documento de Defini o do Sistema Documento de Especifica o do Sistema e Documento de Especifica o de Requisitos de Software ou em qualquer outro ponto do processo IEEE Std 1028 fornece guias para revis o b Prototipagem Meio de validar a interpreta o que o engenheiro de software faz do requisito Meio para elicitar novos requisitos Vantagens Facilita a interpreta o de como o engenheiro v o requisito Feedback til no caso de interpreta es estarem erradas Diminui o esfor o em desenvolvimento de requisitos errados Desvantagem e Desviar a aten o do usu rio para a parte cosm tica ao inv s de concentrar no que essencial Custo de desenvolvimento pode ser alto c Valida o do Modelo e necess rio validar a qualidade dos modelos desenvolvidos durante a an lise Por exemplo Na modelagem de objetos util executar uma an lise est tica para verificar os caminhos de comunica o existentes entre objetos que no dom nio dos
112. SCM g Ferramentas de gerenciamento de Engenharia de Software Ferramentas de gerenciamento de engenharia de software s o subdivididas em tr s categorias planejamento e acompanhamento de projeto gerenciamento de risco e medi o Ferramentas de planejamento e acompanhamento de projeto Estas ferramentas de software s o usadas para medir esfor os e estimar custos no projeto bem como a sincroniza o de projetos Ferramentas de gerenciamento de riscos Estas ferramentas s o usadas na identifica o estimativa e monitoramento de riscos Ferramentas de Medi o As ferramentas de medi o auxiliam na performance de atividades relacionadas na mensura o dos programas 168 h Ferramentas para M todos de Engenharia de Software Ferramentas para m todos de engenharia de software s o divididas em ferramentas de modelagem ferramentas de gerenciamento e ambiente de desenvolvimento de software Ferramentas para m todos de modelagem Pf101 Estas ferramentas s o usadas para modelar e verificar o processo de engenharia de software Ferramentas para m todos de gerenciamento Estas ferramentas fornecem suporte para o gerenciar a engenharia de software Ambiente CASE integrado Rei96 Som05 ECMA55 93 ECMA69 94 IEEE1209 92 IEEE1348 95 Mul96 Engenharia de software integrada com ferramentas auxiliadas por computador ou ambientes que abrangem multiplas fases do ciclo de vida da engenharia de software fazem parte de
113. SO IEC 14764 o padr o internacional para a manuten o de software define manuten o nos mesmos termos do IEEE EIA 12207 e enfatiza os aspectos pr entrega de manuten o como por exemplo o planejamento IEEE1219 98 s3 1 12 IEEE12207 0 96 53 1 55 5 IS014764 99 56 1 b Natureza da Manuten o A manuten o de Software sustenta o produto de software ao longo do seu ciclo de vida operacional Os requisitos de modifica o s o registrados e monitorados o impacto das propostas de mudan as determinado c digo de software e outros artefatos s o modificados o teste realizado e uma nova vers o lan ada Al m disso a forma o e o di rio de apoio s o oferecidos aos usu rios Pfleeger Pfl01 afirma que a manuten o tem um objetivo maior com maior monitoramento e controle do que o desenvolvimento Um mantenedor definido pelo IEEE EIA 12207 como uma organiza o que realiza atividades de manuten o IEEE12207 0 96 Este KA muitas vezes refere se aos indiv duos que desempenham essas atividades contrapondo os com os desenvolvedores IEEE EIA 12207 identifica as principais atividades de manuten o de software como processo de execu o problema com an lise e modifica o modifica o implementa o manuten o revis o aceita o migra o e reformas Estas atividades ser o discutidas no t pico 3 2 Manuten o de Atividades Os mantenedores podem aprender a partir do conhecimento do dese
114. Software Engenharia da Ci ncia da Gerenciamento Matem tica Computa o Computa o Figura 30 Disciplinas relacionadas Engenharia de Software Ger ncia de Qualidade Ger ncia de Projeto Engenharia de Ergonomia de Sistemas Software 2 1 3 11 1 Engenharia da Computa o O relat rio de desenho do volume para computador que cria o projeto Curr culos de Computa o 2001 CC2001 afirma que engenharia da computa o encarna a ci ncia e tecnologia de concep o constru o implementa o e 192 manuten o de software e hardware componentes dos modernos sistemas de computa o e equipamento controlado por computador Este relat rio identifica as seguintes reas de Conhecimento conhecidas como reas no relat rio para a engenharia da computa o Algoritmos e Complexidade Organiza o e Arquitetura de Computadores Engenharia de Sistemas de Computa o Circuitos e Sistemas L gica Digital Estruturas Discretas Processamento de Sinal Digital Sistemas Distribu dos Eletr nica Sistemas Integrados Intera o Humano Computador Gest o de Informa o Sistemas Inteligentes Redes de Computadores Sistemas Operacionais Programa o Fundamental Probabilidade e Estat stica Quest o Social e Profissional Engenharia de Software Teste e Verifica o VLSI ASIC Design 2 1 3 11 2 Ci ncia da Computa o O relat rio final do volume de Ci ncia da Computa
115. UNIVERSIDADE GAMA FILHO POSEAD MARCOS ROGERIO SANTIAGO Ensaio do SWEBOK Software Engineering Body Of Knowledge GOI NIA GO 2011 UNIVERSIDADE GAMA FILHO POSEAD MARCOS ROGERIO SANTIAGO Ensaio do SWEBOK Software Engineering Body Of Knowledge Trabalho de Conclus o de Curso apresentado em cumprimento s exig ncias para obten o do t tulo de especialista latu sensu em Gest o de Tecnologia da informa o da Universidade Gama Filho POSEAD Orientador Professor Rog rio Alvarenga GOI NIA GO 2011 Agradeciemtos Agrade o a minha esposa Tatiane por tanta paci ncia nesse momento de minha vida Quando eu mais precisei l estava ela sendo aquele suporte necess rio Ao professor Rog rio Alvarenga que com muita tranquilidade soube me ajudar nos momentos em que quase desisti Agrade o tamb m ao pessoal da Universidade Federal de Lavras pelo apoio e suporte recebidos Sobretudo ao meu bom Deus que o respons vel por tudo o que acontece em minha vida Minhas vit rias s o sem d vida por causa Dele Resumo Este trabalho tem por objetivo o estudo do SWEBOK ferramenta criada pelo IEEE Institute of Electrical and Electronics Engineers conhecida entidade de especifica o de padr es no mundo para ser a principal refer ncia para engenharia de software Tem o objetivo tamb m de fornecer uma tradu o de sua ltima vers o para a l ngua portuguesa e contribuir assim pa
116. a No Cap tulo 3 s o abordadas as conclus es deste trabalho 2 Referencial te rico 2 1 Aspectos do Conhecimento de Eng de Software 2 1 1 Hist ria Em 1958 John Tukey o estat stico de renome mundial cunhou o termo software O termo Engenharia de Software foi utilizado no t tulo de uma confer ncia da Otan realizada na Alemanha em 1968 Em 1972 a IEEE Computer Society publica pela primeira vez seu relat rio sobre Engenharia de Software Em 1976 foi fundada uma comiss o dentro da IEEE Computer Society com a incumb ncia de desenvolver padr es de engenharia de software A primeira vis o geral sobre Engenharia de Software a sair da IEEE Computer Society resultou de um esfor o liderado por Fletcher Buckley no padr o IEEE 730 que versava sobre garantia de qualidade de software e que foi conclu do em 1979 O prop sito do padr o IEEE 730 era fornecer requisitos m nimos de uniformidade para a prepara o e conte do do planejamento de software Esta norma influenciou o desenvolvimento e conclus o de outros temas gerenciamento de configura o teste de software requisitos de software design de software verifica o e valida o de software No per odo de 1981 1985 a IEEE Computer Society realizou uma s rie de oficinas sobre a aplica o de padr es de engenharia de software Nessas oficinas profissionais envolvidos compartilhavam suas experi ncias com as atuais normas Tamb m se realizavam nessas oficinas sess e
117. a Na KA manuten o de software definido como a investiga o e altera o do software ficando o sujeito a constru o de uma nova forma incluindo implementa es subsequentes desta nova 167 forma As ferramentas de reengenharia suportam essas atividades Ferramentas de engenharia reversa auxiliam o processo de trabalho a criar artefatos de um produto j existente como especifica o e descri es de desenhos que podem ent o ser transformados para gerar um novo produto a partir de um antigo f Ferramentas de Gerenciamento de Configura o de Software As ferramentas para gerenciar configura o de Software foram divididas em tr s categorias monitoramento gerenciamento de vers es e ferramentas de corre o Ferramentas para gerenciar defeito aprimoramento edi o e monitoramento Estas ferramentas s o usadas na conex o com o monitoramento de problemas associados a um determinado produto de software Ferramentas para gerenciar vers es Estas ferramentas est o envolvidas na gest o das v rias vers es de um produto Ferramentas de corre o Estas ferramentas s o usadas para obter uma tarefa de corre o e desenvolvimento de software A categoria inclui instala o de ferramentas que se tornaram amplamente utilizadas para configurar a instala o de produtos de software Informa es adicionais s o fornecidas em Configura o e Gerenciamento de Software KA t pico 1 3 planejamento para
118. a a compreens o de design no seu sentido geral objetivos restri es alternativas representa es e solu es b Contexto do Design de Software O Para entender o papel do design de software importante entender o contexto em que se enquadra o ciclo de vida da engenharia de software Assim importante entender as maiores caracter sticas das an lises de requerimento de software vs Design de software vs Constru o de software vs Teste de software IEEE12207 0 96 Lis01 c11 Mar02 Pfl01 c2 Pre04 c2 c Processo de Design de Software O Design de software geralmente considerado em dois passos e Design Arquitetural descreve como o software decomposto e organizado dentro de componentes a arquitetura de software IEEEP1471 00 e Design Detalhado descreve o comportamento espec fico desses componentes A sa da desse processo um conjunto de modelos e artefatos que guardam as maiores decis es que tenham sido tomadas IEE1016 98 Lis01 c13 Pre04 c9 d T cnicas Ativas De acordo com o Dicion rio Ingl s Oxford um princ pio uma verdade b sica ou lei geral que usada como a base racional ou guia de a o Os princ pios do design de software tamb m s o chamados de T cnicas Ativas Bus96 s o no es chave consideradas fundamentais para muitas diferentes abordagens e 48 conceitos de design de software As t cnicas ativas s o as seguintes Bus96 c6 IEEE 1016 98 Jal97 c5 c6 Lis01 c
119. a cobertura circunst ncia decis o O mais forte dos crit rios controle de fluxo baseados o teste do trajeto que tem por objetivo executar todos os trajetos do fluxo de controle de entrada a sa da no gr fico de fluxo Desde que o teste do trajeto n o seja geralmente pratic vel por causa dos la os outros crit rios menos estritos tendem a ser usados na pr tica como o teste de declara o o teste de ramifica o e o teste de condi o decis o A sufici ncia de tais testes medida nas porcentagens por exemplo quando todas as ramifica es foram executadas pelo menos uma vez pelos testes a cobertura da ramifica o de 100 dita ter sido conseguida Crit rios fluxo de dados baseados Bei90 c5 Jor02 Zhu97 No teste fluxo de dados baseado o gr fico de fluxo de controle anotado com informa o sobre como as vari veis do programa s o definidas usadas e destru das indefinidas O crit rio mais forte trajetos de uso definidos necessita que 81 para cada vari vel todo segmento do trajeto do fluxo de controle de uma defini o de qual vari vel para um uso de qual defini o seja executada A fim de reduzir o n mero de trajetos exigidos estrat gias mais fracas tais como todas as defini es e todos osusos s o empregadas Modelos de refer ncia para o teste c digo baseado gr fico de fluxo grafo chamado Bei90 c3 Jor02 c5 Embora n o seja uma t cnica em si a estrutura de controle de um pr
120. a definir as exig ncias em termos de fun es a serem desempenhadas por um determinado sistema EEE Std Padr o IEEE para Modelagem Este padr o define duas linguagens conceituais de 1320 2 Conceitual Sintaxe da Linguagem modelagem chamados coletivamente IDEF1X97 1998 e Sem ntica para IDEF1X 97 IDEFObject A linguagem suporta a implementa o E a IDEFobject de bancos de dados relacionais objeto de bancos de dados e modelos de objeto IEEE Std Guia IEEE de Tecnologia da Este documento fornece orienta o sobre o formato e 1362 1998 Informa o Sistema de Defini o o conte do de um Conceito de Opera es CONOPS Conceito de Opera es documento descrevendo as caracter sticas de um P CONOPS Documento sistema de propostas do ponto de vista dos usu rios IEEE Std Padr o IEEE para Tecnologia da Este padr o e seus suplementos descrevem 1420 1 Informa o Reutiliza o de informa es das bibliotecas de reutiliza o de 1995 Software Modelo de Dados para software que devem ser capazes de mudar a ordem 1420 1a Interoperabilidade da Biblioteca de de altern ncia das propriedades 5 1996 and Reutiliza o 1420 1b 1999 R2002 IEEE Std Padr o IEEE Ado o do padr o Este padr o fornece direcionamentos para a P 219 Q 92 oo Re ol nao oa oes og ES pE N mero E Ea SE 30 22 8 45 seS 389 389 3355 45 3 Nome padr o De
121. a do Corpo de 207 Conhecimento de Engenharia de Software seja totalmente 12207 compat vel este padr o permanece uma entrada chave vers o Stone Man e cuidados especiais ser o tomados em todas as partes do projeto quanto compatibilidade do Guia com o padr o 12207 g Merriam Webster s Collegiate Dictionary 10 ed Veja nota para o padr o IEEE 610 12 2 1 4 1 11 Estilo e Diretrizes T cnicas As Descri es de rea do Conhecimento devem enquadrar se com Confer ncia Internacional de Procedimentos de Engenharia de Software os padr es s o dispon veis em http sunset usc edu icse99 cfp technical papers html Espera se que as Descri es das reas do Conhecimento sigam o Guia de Estilo da Sociedade de Computa o IEEE Ver http www computer org author style cs style htm O formato preferencial de submiss o o Microsoft Word Por favor contate a Equipe Editorial se isto n o for fact vel para voc 2 1 4 1 12 Outras Diretrizes Detalhadas Referindo o guia recomendamos que voc use o t tulo inteiro Guia do SWEBOK em vez de s SWEBOK Por objetivo de simplicidade recomendamos que os Editores Associados das reas do Conhecimento evitem notas Em vez disso eles devem tentar incluir o seu conte do no texto principal Recomendamos usar no texto refer ncias expl citas para padr es ao contr rio de inserir simplesmente n meros que referem itens na bibliografia Acreditamos que isto permite que o
122. a estas atividades Em princ pio IEEE Std 1074 pode ser usada para construir processos em conformidade com qualquer dos modelos de ciclo de vida Normas que se concentram nos processos de manuten o s o IEEE Std 1219 1998 e ISO 14764 1998 IEEE 1219 98 Outros padr es importantes que fornecem a defini es de processo incluem IEEE Std 1540 Software Risk Management IEEE 1540 01 IEEE Std 1517 Software Reuse Processes IEEE 1517 99 e ISO IEC 15939 Software Measurement Process IS015939 02 Veja tamb m o gerenciamento de engenharia de software KA para a descri o detalhada deste processo Em algumas situa es processos de engenharia de software devem ser definidos tendo em conta os processos organizacionais de gest o da qualidade ISO 9001 ISO9001 00 provem requisitos para gerenciamento de processos da qualidade e ISO IEC 90003 que interpretam esses requisitos para as organiza es de desenvolvimento de software ISO90003 04 Alguns ciclos de vida de softwares enfatizam processos de entrega r pida e forte participa o dos usu rios chamados de m todos geis como Extreme 154 Programming Bec99 Uma forma do problema da sele o diz respeito escolha ao longo do plano de dire o do m todo base Uma abordagem de risco de como tomar essa decis o descrito em Boe03a c Nota es pra defini o de processos Este processo pode ser definido em diferentes n veis de abstra o por exemplo defini
123. a gerar um exig ncia de que os fatores que contribuam para esse objetivo sejam medidos de forma que os projetos possam ser gerenciados para ir de encontro a esse objetivo Defina o escopo da mensura o A unidade organizacional na qual cada exig ncia de medi o para ser aplicada deve ser definida Isso pode consistir de uma rea funcional um nico projeto um nico site ou mesmo a empresa inteira Todas as tarefas subsequentes relacionadas a esse requisito devem estar dentro do escopo definido Adicionalmente os stakeholders devem ser identificados Compromisso da ger ncia e equipe para medi es O compromisso deve ser formalmente estabelecido comunicado e apoiado por recursos veja o pr ximo item Comprometa confirme recursos para as medi es O compromisso da organiza o para as medi es um fator essencial de sucesso como evidenciado pela aloca o de recursos para implementar o processo de mensura o medi o A aloca o de recursos inclui a designa o de responsabilidade para as v rias tarefas do processo de mensura o tais como usu rio analista e documentador e o fornecimento de financiamento adequado treinamento ferramentas e apoio para conduzir o processo como uma moda duradoura b Planeje o Processo de Mensura o Medi o Caracterize a unidade organizacional A unidade organizacional fornece o contexto para a mensura o medi o ent o ela importante para tornar esse contexto expl c
124. acionados com ger ncia de qualidade s o a garantia da qualidade do processo e do produto b verifica o de processo e c valida o de processo O CMMI classifica revisa e audita como formas de verifica o e n o como processos espec ficos como a norma IEEE 12207 0 96 Inicialmente houve alguma discuss o sobre qual dos dois padr es 1509001 ou CMMI deveria ser usado por engenheiros de software para assegurar qualidade Esta discuss o esta amplamente publicada e como resultado foi tomada a posi o de que os dois s o complementares e que ter a certifica o S09001 pode contribuir consideravelmente para conseguir os n veis mais altos de maturidade do CMMI Dac01 O engenheiro de software primeiramente precisa determinar qual o real prop sito do software Nesta considera o de extrema import ncia ter em mente que os requisitos do cliente v m em primeiro lugar e que eles incluem requisitos de qualidade n o apenas requisitos funcionais Assim o engenheiro de software tem a responsabilidade de elicitar os requisitos de qualidade que geralmente n o est o expl citos e discutir sua import ncia bem como o n vel de dificuldade em obt los Todos os processos associados com a qualidade de software por exemplo constru o verifica o e melhoria da qualidade ser o projetados com estes requisitos em mente e isto leva a custos adicionais A norma 1509126 01 define para dois de seus tr s modelos de qualidade
125. ade Alcan ar sufici ncia completude e simplicidade significa garantir que um componente de software capturar todas as caracter sticas importantes de uma abstra o e nada mais Lis01 c5 49 Fundamendos do Desing de Software Conceitos gerais de design O contexto do design de software O processo do desing de software pe Ativando t cnicas Quest es Chave no Design de Software Concorr ncia Controlando carregando eventos Distribui o de Componentes Erro c exce o p M o guia e toler ncia a falha Intera o gt apresenta o Design de Software Estrutura e Arquitetura de Software Estruturas arquiteturais e pontos de vis o Estilos arquiteturais gt padr es de macroarquitetura Padr es de Design gt padr es de microarquitetura Familias de programas gt s 7 e frameworks An lise da Qualidade de Design de Software H gt Atributos de qualidade An lise de qualidade e T cnicas de avalia o p Medi es Nota es de Desing de Software Descri es Estruturais vis o est tica Deseri es de gt comportamento vis o din mica Estrat gias e M todos para o Design de Software gt Estrat gias Gerais Design orientado Pa fun o estruturada Design orientado a objetos Design centrado na estrutura de datos Design baseado em componentes p Persist ncia de dados gt Ou
126. aida lindas a ae asa 12 VO JUSUTICAIVA ARDE COP ROUPA RR RR CD RR RR RR RD DDR RR RD RRO APORTE SRA ROO REED OR PS 12 1 6 Delimita o do tema serra a aa a aa Ee eE a nana nara aaa a nana a aaa a acena nana aaa a oana ENAA 13 1 7 Metodologia de pesquisa lt nrn ssa sheeiwa healt a Diga ASS LOSE USOS ara ata Re aon dea La A 13 1 8 Estrutura do trabalho 2 Referencial aee aL o EE A ETT T E A T a Rana Rana aca aaa ana aa ara na nana aan acer ana sanar nanda 2 1 Aspectos do Conhecimento de Eng de Softwar e cccccccceccecececeeeeeeceeeeseeeeeeeeeeceeeesaeeseaeeseaeeesaeeeseeeseaeeseeeeeeeieeeeeeeeeaea 14 2 W Fico IES ce Sos cess ea E RAD IN RD OND boca cvs SD PR PERDA SRD E E RETRD E ORNE SERPRO Pr 14 211 2 Defini ES INICIAIS street als tes Ae AA oa SEADE CoD Se ded SS Bi We a pi ba ELI DESSES a 16 2 1 2 1 Organiza o Hier rquica 222 3u sass Seated eae vdag fees Satie eee ast lg Nese lala AS 17 2 12 2 Mat rial de refer ncia C2 atriZ sirr second ainak aada iK eaa Aaaa aa aK aa ae aaaea aea aai 18 2 1 2 3 Prof ndidade de tratamento ss iniinis 18 2 1 2 4 Estrutura de descri o das KAS cias sadeessceceveectesbae cgucactsececesseedescnev eat cavsesesacepgesbecmascet de sra O si iepa ae i a aii de 20 2 1 2 5 KA de Requisitos de Software ccccccccceeseecceneeeeeeeeseneeeceeeeecaeeeeeaeeseaaeeseaeesseaeeseaeeeseaeeseeeeeeaeeseeaeeseeeeeeeeeeeeeaaa 20 2 1 2 6 KAde Design de Softwate sarena wl ee
127. al s o fornecidos em IEEE Std 14143 1 Padr es internacionais para medir tamanho que incluem os m todos da funcional ISO IEC 19761 20926 20968 e IEEE 14143 1 00 1S019761 03 15020926 03 ISO20968 02 Medi o de estrutura Uma variada gama de medidas de estrutura de produtos de software pode ser aplicada para alto e baixo n vel de design e artefatos de c digo para refletir no fluxo de controle por exemplo o cyclomatic n mero n s de c digo fluxo de dados por exemplo medidas de corte otimiza o por exemplo a medida polinomial a medida BAND o controlo das estruturas por exemplo a medida vetorial a medida NPATH estrutura modular e intera o por exemplo informa es de fluxo com base em medidas de rvore acoplamento e coes o Fen98 C8 Pre04 C15 Medi o de qualidade Como um atributo multidimensional medi o da qualidade mais dificil de definir do que as anteriores Al m disso algumas das dimens es da qualidade exigem a medi o em termos qualitativos e n o de forma quantitativa Uma discuss o mais detalhada de mensura o do software fornecida em Qualidade do Software KA tema 3 4 ISO modelos de qualidade de software e medi es relacionadas est o descritas na norma ISO 9126 partes 1 de 4 ISO9126 01 Fen98 c9 c10 Pre04 c15 Som05 c24 b Qualidade dos resultados das medi es A qualidade dos resultados da medi o precis o reprodu o repeti o convers o err
128. alidade e t cnicas de avalia o e medidas A quinta sub rea Nota es de Design de Software que dividida em descri es estruturais e comportamentais A ltima sub rea descreve Estrat gias de Design de Software e M todos Primeiro as estrat gias gerais s o descritas seguidas por m todos de design orientados por fun o m todos de design orientados a objeto design centrando na estrutura de dados design baseado em componentes e outros 2 1 2 7 KA de Constru o de Software Constru o de software se refere cria o detalhada de trabalho significando software atrav s da combina o de codifica o verifica o testes de 22 unidades testes de integra o e depura o A KA possui tr s sub reas A primeira sub rea chamada de Fundamentos de Constru o de Software Os tr s primeiros t picos s o princ pios b sicos da constru o minimiza o da complexidade antecipa o de mudan as e constru o com foco na verifica o O t pico ltimo discute padr es da constru o A segunda sub rea descreve o Gerenciamento da Constru o Os t picos tratados s o modelos de constru o planejamento da constru o e mensura o da constru o A terceira sub rea cobre as Considera es Pr ticas Os t picos s o design de constru o linguagens de programa o codifica o teste de constru o reutiliza o qualidade de constru o e integra o 2 1 2 8 KA de Te
129. amento de SCM organiza o responsabilidades autoridades pol ticas aplicadas diretrizes e procedimentos e Atividades de SCM identifica o da configura o controle de configura o e assim por diante Cronograma de SCM coordena o com as outras atividades do projeto Recursos de SCM ferramentas recursos f sicos e humanos e Manuten o de SCMP e Monitoramento do Gerenciamento de configura o de software Depois que o processo de SCM implementado necess rio certo grau de monitoramento para garantir que as disposi es do SCMP sejam corretamente 119 executadas veja por exemplo Buc96 prov vel que existam requisitos espec ficos de SQA para garantir o cumprimento de processos e procedimentos especificados no SCM Isto poderia envolver uma autoridade de SCM garantindo que as pessoas com responsabilidades atribu das desempenhem corretamente as tarefas definidas no SCM A autoridade da garantia da qualidade de software como parte de uma atividade de auditoria e observ ncia poderia tamb m desempenhar esse monitoramento O uso de ferramentas SCM integrado com capacidade para processar o controle pode tornar a tarefa mais f cil controlar Algumas ferramentas para facilitar o cumprimento de transforma o ao mesmo tempo proporcionar flexibilidade para o engenheiro de software para adaptar os procedimentos Outras ferramentas para implementar o processo deixando o engenheiro de software com menos fl
130. aniza es e conceitos que ainda est o sendo desenvolvidos e testados em organiza es de pesquisa Especializado on a co ca oS o ELA _ ada o Da on os Toa os a Te wo os a ES E Figura 31 Categorias de Conhecimento 2 1 4 1 8 Comprimento de Descri o de reas do Conhecimento Espera se que as Descri es das reas do Conhecimento estejam atualmente em torno de 10 p ginas usando o formato da Confer ncia Internacional de Engenharia de Software definido abaixo Isto inclui texto refer ncias ap ndices tabelas etc Isto naturalmente n o inclui os pr prios materiais de refer ncia Este limite n o deve contudo ser visto como um constrangimento ou uma obriga o 2 1 4 1 9 Papel da Equipe Editorial Alain Abran e James W Moore s o os Editores Executivos e s o respons veis por manter boas rela es com a Sociedade de Computa o IEEE o Conselho Consultivo Industrial o Conselho de Controle de Modifica o Executivo e o Painel de Peritos bem como pela estrat gia geral aproxima o organiza o e consolida o do projeto Pierre Bourque e Robert Dupuis s o os Editores e s o respons veis pela coordena o opera o e log stica deste projeto Mais especificamente os Editores s o respons veis por desenvolver o plano de projeto e a especifica o da descri o das reas do Conhecimento coordenando Editores Associados das reas do Conh
131. anteriores afetar essa decis o Som01 A tarefa embalagens devem identificar quais os itens de produtos devem ser entregues em seguida selecione as variantes correta desses itens devido aplica o prevista para o produto As informa es documentar o conte do f sico de uma libera o conhecido como um documento de descri o de vers o As notas de lan amento normalmente descrevem novos recursos problemas conhecidos e os requisitos de plataforma necess ria para a opera o adequada do produto O pacote a ser lan ado tamb m cont m instru es de instala o ou atualiza o Este ltimo pode ser complicada pelo fato de que alguns usu rios atuais pode ter vers es que s o v rias vers es antigas Finalmente em alguns casos a atividade de gerenciamento de libera o pode ser necess ria para controlar a distribui o do produto para v rios clientes ou sistemas de destino Um exemplo seria um caso em que o fornecedor era obrigado a notificar o cliente de novos problemas relatados A capacidade de ferramenta necess ria para suportar essas fun es de gerenciamento de libera o til ter uma conex o com a capacidade ferramenta de 130 apoio ao processo de solicita o de altera o de conte do a fim de mapear a liberta o para o SCR que tenham sido recebidos Esta capacidade ferramenta pode tamb m manter informa es sobre as plataformas alvo diferentes e em ambientes de v rios clientes Som05 C29
132. antitativos da Ger ncia de Engenharia de Software GES A ger ncia efetiva requer a combina o de ambos n meros e experi ncia As seguintes defini es de trabalho s o adotadas aqui e Ger ncia de processo refere se s atividades que s o feitas com o fim de garantir que os processos de engenharia de software s o realizados de uma maneira consistente com as pol ticas objetivos e padr es da organiza o e Mensura o refere se atribui o de valores e r tulos aos aspectos de engenharia de software produtos processos e fontes s o definidos por Fen98 e os modelos que s o derivados a partir deles se esses modelos s o desenvolvidos usando estat stica conhecimento t cnico especializado ou outras t cnicas As sub reas da ger ncia de projetos da engenharia de software fazem uso extensivo da sub rea de medi o de engenharia de software N o inesperadamente esta KA est intimamente relacionada a outras no Guia SWEBOK e ler as descri es das seguintes KAs em conjunto com esta seria particularmente til e Requisitos de Software onde algumas das atividades a serem realizadas durante a defini o da fase de Inicia o e Escopo do projeto s o descritas e Ger ncia de Configura o de Software como esta trata a identifica o controle status de contabiliza o e auditoria da configura o do software junto com a ger ncia de lan amento e entrega e Processo de Engenharia de Software porque pro
133. ara aeee nareeaaaana nana naaaaana 2N 74 AnaliSee Avalia o aranana E a Ea o sae SENTADO Caia Seta dada Bett 2 103 7 D FECNAMENTO isasi i e ndo sanada ed eb ne abs dep ia dad beans tise es or ada bed pes ncia aeons 2 1 3 7 6 Mensura o Medi o de Engenharia de Software ie reeearaeaaeeaceraaananaa 2 1 3 8 Processo de Engenharia de Software ereta aerea carenanaraaaaaeeanaanaaaareraaaaaanaaa 2 1 3 8 1 Processo de implementa o e MUGANGA cccccececeeeeeeeeeeeeeeeeeeeeeeceeeeeaeeeseaeeeceeeeeaeeseeeeeeeieeeeeeaees 2 1 3 8 2 Defini o de Processo 2 163 8 3 Avaliacao de PrOC SSO nthini e bat delgada US ie Ad dal AD da ci 156 2 1 3 8 4 Processo e Medi o de Produto re rrareeaneeaaaaaaaaaeanacaaaaaa anna a aaaaaana 157 2 1 3 9 Ferramentas e M todos da Engenharia de Software ee eereaceneaaaaananaaaanraea 164 2 1 3 9 1 Ferramentas da Engenharia de Software ii ereereea aerea naraeaaeeaa care aanaaana 165 2 1 3 9 2 M todos de Engenharia de Software ii eereaaraacareanaraaaaeea nara anne nene nanaa 170 2 1 3 10 Qualidade de SOTWare i sssisssas mes anres a coast pa CASE Rega Dava anda q SN fo Scala cates e Hd lena a sao ada da a polia Da 172 2 1 3 10 1 Fundamentos da Qualidade de Software ecra ereta rena aaaaaaanna 173 2 1 3 10 2 Processos de Gest o da Qualidade de Software rear 176 2 1
134. are 2 1 Concorr ncia c5s4 1 CSD c30 c9 22 ce 3 2 2 Controle e e552 3284 583 transporte de eventos c32s5 edicao Zeus cl6s3 23 Dis 2 3 Distribui o de cosa c5s4 1 c2s3 DD c30 c30 Componentes 2 4 Erro e M o guia del exce o e Toler ncia c4s3 c4s5 cl2 c5s5 a falha 2 5 Intera o e z E x c6s2 c5s4 1 c2s4 cl3s3 c32s2 apresenta o 2 6 Persist ncia de dados c5s4 1 c3l Figura 11 T picos x refer ncias 1 59 Bas03 Bas98 Boo99 3 Estrutura e Arquitetura de Software Bos00 Bud03 Bus96 Dor02 Fre83 IEEE1016 98 IEEE1028 97 EEE1471 00 IEEE 12207 0 96 1SO9126 01 1S015026 98 Jal97 3 1 Arquiteturas estruturas e pontos de vis o Lis01 Mar02 Mar94 Mey97 PA01 Pre04 Smi93 3 2 Estilos arquiteturais 3 3 Padr es de design 3 4 Fam lias de programas e frameworks 4 An sile de qualidade de design de software e avalia o 4 1 Atributos de qualidade 4 2 An lise de qualidade e t cnicas de avalia o vlc4s2 4 3 Medi es Figura 12 T picos x refer ncias 2 se ses SES i eae fear eg aren a ERRAR 15 8 oa o ae a
135. are n o desenvolveu um bom exemplo Semelhantemente competir com desenvolvedores de software por recursos uma batalha constante Planejar uma vers o futura enquanto se desenvolve a pr xima vers o e se envia atualiza es de seguran a para a vers o atual tamb m fornece um desafio A se o seguinte apresenta alguns problemas t cnicos e gerenciais relacionados manuten o de software Eles t m sido agrupados como Problemas t cnicos Problemas gerenciais estimativa de custo e Medidas a Problemas t cnicos Compreens o limitada refere se a como o engenheiro de um software pode rapidamente perceber onde se deve fazer uma mudan a ou uma corre o no software que este indiv duo n o desenvolveu Pesquisas indicam que cerca de 40 a 60 dos esfor os de manuten o s o dedicados ao entendimento do software a ser modificado Assim o tema da compreens o do software de grande interesse para os engenheiros de software 99 A compreens o mais dificil na representa o do texto orientador no c digo fonte por exemplo onde muitas vezes dif cil rastrear a evolu o do software atrav s das suas releases vers es quando as altera es n o s o documentadas e quando os desenvolvedores n o est o dispon veis para explic las o que muitas vezes o caso Assim engenheiros de software podem inicialmente ter um compreens o limitada do software e muito tem de ser feito para remediar isto Testando O custo
136. are que passou previamente nos testes ainda passa Beizer Bei90 define como qualquer repeti o de teste que pretende mostrar que o comportamento do software inalterado exceto quando necess rio Obviamente um trade off deve ser feito entre a garantia dada pelo teste de regress o cada vez que uma mudan a feita e os recursos exigiram fazer isso O teste de regress o pode ser conduzido em cada um dos n veis do teste descritos no t pico 2 1 alvo do teste e pode aplicar se ao teste funcional e n o funcional teste de performance Pfl01 c9s8 3 Wak99 Este tem por objetivo espec fico verificar se o software cumpre as exig ncias espec ficas de desempenho por exemplo por inst ncia capacidade e tempo de resposta Um tipo espec fico do teste de desempenho o teste de volume Per95 p185 p487 Pfl01 p401 em que as limita es internas do programa ou do sistema s o experimentadas teste de stress Pfl01 c9s8 3 O teste de stress for a o software na carga m xima de projeto assim como al m dela teste back to back Um nico conjunto de teste executado em duas vers es implementadas de um produto de software e os resultados s o comparados teste de recupera o Pfl01 c9s8 3 O teste de recupera o tem o objetivo de verificar as capacidades de rein cio do software ap s um desastre teste de configura o Pfl01 c9s8 3 Nos casos onde o software constru do para servir usu rios diferentes o teste da co
137. ares a M todos Heur sticos Este t pico cont m quatro categorias Estruturado orientado a dados orientado a objetos e dom nio especifico A categoria dom nio espec fico inclui m todos especializados para desenvolvimento de sistemas o qual envolve tempo real seguran a ou aspectos seguros e M todos estruturados Dor02 Pfl01 Pre04 Som05 O sistema embutido 170 para um ponto de vista funcional iniciando com uma vis o de alto n vel e refinado progressivamente em um projeto mais detalhado M todos orientados a dados Dor02 Pre04 aqui o ponto inicial s o os dados estruturados que um programa manipula melhor do que a fun o que executa e M todos orientados a objeto Dor02 Pfl01 Pre04 Som05 O sistema visualizado como uma cole o de objetos em vez de fun es b M todos Formais Esta subse o dividida matematicamente com m todos de engenharia de software e esta subdividida com os v rios aspectos de m todos formais e Especifica o de linguagens e nota es Cla96 Pfl01 Pre01 Este t pico foca a especifica o de nota o ou de linguagem usada Linguagens de especifica es podem ser classificadas como orientado a modelo orientado por propriedade ou orientado por comportamento Refinamento Pre04 Este t pico d a forma de como o m todo refinado ou transformado numa especifica o de forma que seja mais pr xima da forma final desejada de um programa execut vel e Propri
138. aria de software necessariamente incorpora aspectos de criatividade e disciplina a manuten o de um apropriado equil brio entre as duas muitas vezes dif cil e O grau de novidade e complexidade do software muitas vezes extremamente elevado Existe um ritmo r pido de mudan as na tecnologia subjacente 131 Com respeito engenharia de software atividades de gerenciamento ocorrem em tr s n veis gerenciamento organizacional e de infraestrutura ger ncia de projetos e planejamento e controle do programa de mensura es As duas ltimas s o cobertas em detalhes na descri o desta KA Entretanto isto n o para diminuir a import ncia das quest es de gerenciamento organizacional Como o link s disciplinas relacionadas obviamente gerenciamento importante ele ser descrito em maior detalhe do que nas descri es das outras KA Aspectos de ger ncia organizacional s o importantes em termos de seu impacto na engenharia de software sobre a pol tica de gest o por exemplo padr es e pol ticas organizacionais fornecem a estrutura na qual a engenharia de software realizada Essas pol ticas podem precisar ser influenciadas pelos requisitos do efetivo desenvolvimento e manuten o do software e um n mero espec fico de pol ticas de engenharia de software podem ter que ser estabelecidas para o efetivo gerenciamento da engenharia de software no n vel organizacional Por exemplo pol ticas normalmente s o
139. as til possuir algum conceito de volume dos requisitos para um particular produto de software til para avaliar o tamanho de uma mudan a de requisitos na estimativa de custo de desenvolvimento tarefa de manuten o ou simplesmente para ter um denominador comum de compara o com outras medi es FSM Medida de Tamanho Funcional t cnica para avaliar o tamanho do corpo de requisitos funcionais IEEE Std 14143 1 define o conceito de FSM Informa es adicionais sobre medi es de tamanho e padr es s o encontradas na KA Processo de Engenharia de Software Matriz de T picos x Material de Refer ncia 2 1 3 2 Design de Software Design definido no IEEE610 12 90 de duas formas o processo de defini o da arquitetura componentes interfaces e outras caracter sticas de um sistema ou componente e o resultado do processo Visto como um processo o design de software o ciclo de vida da engenharia de software no qual os requisitos de software s o analisados para produzir uma descri o da estrutura interna dos software s que servir o como base de sua constru o Mais precisamente o design de software resultante pode descrever a arquitetura de software isto como o software decomposto e organizado dentro dos componentes e a interface entre estes componentes Isso tamb m descreve os componentes no n vel de detalhe que permitem sua constru o 46 O Design de Software
140. as t cnicas e metodologias seguran a para m dias f sicas treinamento informa o e documenta o de SQA Al m disso o planejamento SQA aborda as atividades de garantia da qualidade de software e qualquer outro tipo de atividade descritas no projeto de software como obten o de fornecedores para o projeto ou instala o do software de prateleira commercial off the shelf software COTS e servi o ap s a entrega do software Tamb m podem existir crit rios de aceita o bem como relat rios e gest o de atividades que s o essenciais qualidade do software b Verifica o amp valida o Por quest es de simplicidade Verifica o e Valida o V amp V s o tratadas como um nico t pico neste Guia ao inv s de em t picos separados como na norma 179 IEEE12207 0 96 Verifica o e Valida o de Software uma abordagem disciplinada para avalia o dos produtos de software ao longo do ciclo de vida do produto V amp V se esfor a para garantir que a qualidade seja incorporada ao software e que este satisfa a os requisitos do usu rio IEEE1059 93 V amp V aborda diretamente a qualidade do produto de software e utiliza t cnicas de teste para localizar defeitos que em seguida devem ser resolvidos Eles tamb m avaliam os produtos intermedi rios e neste caso as etapas intermedi rias dos processos do ciclo de vida O processo V amp V determina se os produtos de uma certa atividade de desenvolviment
141. as e ger ncia de configura o de software s o cumpridos veja tamb m a KA de Ger ncia de Configura o de Software para que as decis es sejam documentadas e comunicadas a todos os interessados planos s o revistos e revisados quando preciso e dados importantes s o gravados na base de dados central f Relat rio Nos per odos especificados e acordados o cumprimento dos planos relatado tanto internamente para a organiza o por exemplo para o comit diretor de portf lios de projeto quanto externamente para os stakeholders por exemplo clientes usu rios Relat rios desta natureza devem focar se no cumprimento geral em oposi o aos relat rios detalhados frequentemente exigidos pela equipe interna do projeto 2 1 3 7 4 An lise e Avalia o Em pontos cr ticos do projeto o progresso geral voltado para o alcance dos objetivos definidos e para a satisfa o dos requisitos do stakeholder avaliado Analogamente avalia es da efetividade do processo como um todo para prazos pessoal envolvido e ferramentas e m todos empregados tamb m s o realizados nos 142 marcos particulares a Determinando a Satisfa o dos Requisitos Desde que a obten o da satisfa o do stakeholder usu rio e cliente um dos nossos principais objetivos importante que o progresso deste objetivo seja formal e periodicamente avaliado Isto ocorre no atingimento dos principais marcos do projeto por exemplo confirma o
142. as extrapola es s o baseadas Alguns igualmente discutem que esta t cnica deve ser usada com grande cuidado desde que a 86 introdu o de falhas no software envolve o risco bvio de deix las l Contagem da muta o Zhu97 s3 2 s3 3 No teste da muta o ver o sub t pico 3 4 2 a rela o de mutantes destru dos com o n mero total de mutantes gerados pode ser uma medida da efic cia do conjunto de teste executado Compara o e efic cia relativa das diferentes t cnicas Jor02 c9 c12 Per95 c17 Zhu97 s5 Fra93 Fra98 Pos96 p64 72 Diversos estudos foram conduzidos para comparar a efic cia relativa de diferentes t cnicas de teste importante ser preciso a respeito da propriedade contra a qual as t cnicas est o sendo avaliadas que por exemplo dado o significado exato ao termo efic cia As interpreta es poss veis s o o n mero de testes necess rios para encontrar o primeiro fracasso a rela o do n mero de falhas encontradas por meio do teste para todas as falhas encontradas durante e ap s o teste ou quanto a confiabilidade foi melhorada As compara es anal ticas e emp ricas entre t cnicas diferentes foram conduzidas de acordo com cada um das no es da efic cia especificadas acima 2 1 3 4 5 Processo de Teste Os conceitos as estrat gias as t cnicas e as medidas do teste precisam de ser integrados em um processo definido e controlado que funcione atrav s de p
143. ate a equipe editorial para mais informa o 2 1 4 1 6 ndice dos Conte dos Comuns As descri es de reas do Conhecimento devem usar o seguinte ndice de conte do Introdu o e Divis o de t picos de Areas do Conhecimento para objetivos de esclarecimento acreditamos que esta se o deve ser colocada na frente e n o em um ap ndice no fim do documento Tamb m deve ser acompanhado por uma figura que descreve a divis o Matriz de t picos versus material de Refer ncia e Refer ncias recomendadas da reas do Conhecimento descrita por favor n o os misture com refer ncias usadas para escrever a descri o da reas do Conhecimento Lista de Leituras Complementares 203 2 1 4 1 7 O que Queremos Dizer com Conhecimento Geralmente Aceito O corpo de conhecimento de engenharia de software um termo tudo em um que descreve a soma do conhecimento dentro da profiss o de engenharia de software Contudo o Guia do Corpo de Conhecimento da Engenharia de Software procura identificar e descrever qual subconjunto do corpo do conhecimento geralmente aceito ou em outras palavras o corpo principal do conhecimento Para ilustrar melhor o que o conhecimento geralmente aceito quanto a outros tipos do conhecimento a Figura 31 prop e um esquema de tr s categorias preliminares para classificar o conhecimento O Instituto de Gerenciamento de Projetos no seu Guia do Corpo de Conhecimento de Gerenciamento de Projetos
144. atureza da aplica o As t cnicas acima aplicam se a todos os tipos de software Entretanto para alguns tipos das aplica es algum know how adicional exigido para a deriva o do teste Uma lista de alguns campos de teste especializados fornecida aqui baseada na natureza da aplica o sob o teste Teste orientado ao objeto Jor02 c17 Pfl01 c8s7 5 Bin00 Teste componente baseado Teste web baseado Teste de GUI Jor20 Teste dos programas simultaneos Car91 Teste de conformidade do protocolo Pos96 Boc94 Teste de sistemas de tempo real Sch94 Teste dos sistemas seguran a cr ticos IEEE1228 94 9 Selecionando e combinando t cnicas 83 Funcional e estrutural Bei90 c1s 2 2 Jor02 c2 c9 c12 Per95 c17 Pos96 As t cnicas de teste baseadas na especifica o e c digo baseadas s o contrastadas frequentemente como testes funcionais versus estruturais Estas duas aproxima es para sele o de teste n o devem ser vistas como alternativas mas como bastante complementares de fato usam fontes de informa o diferentes e tem demonstrado destacar tipos diferentes de problemas Poderiam ser usadas em combina o dependendo das considera es or amentais e Determin sticas versus aleat rias Ham92 Lyu96 p541 547 Os casos de teste podem ser selecionados de uma maneira deterministica de acordo com uma das v rias t cnicas listadas ou selecionados aleatoriamente de alguma distribui
145. b m A equipe do teste pode se compor de membros internos isto na equipe de projeto envolvido ou n o na constru o do software de membros externos na esperan a de trazer em uma perspetiva imparcial independente ou 88 finalmente de membros internos e externos As considera es de custos de agendamento de n veis da maturidade das organiza es envolvidas e de criticidade da aplica o podem determinar a decis o A estima o do custo esfor o e outras medidas do processo Per95 c4 c21 Per95 Ap ndice B Pos96 p139 145 IEEE982 1 88 Diversas medidas relativas aos recursos gastos no teste assim como efic cia relativa da busca de falhas das v rias fases de teste s o usadas por gerentes para controlar e melhorar o processo do teste Estas medidas do teste podem cobrir tais aspetos como n mero de casos de teste espec ficos n mero de casos de teste executados n mero de casos de teste passados e n mero de casos de teste que falharam entre outros A avalia o de relat rios da fase de teste pode ser combinada com a an lise origem causa para avaliar a efic cia do processo de teste em encontrar falhas o mais cedo poss vel Tal avalia o pode ser associada com a an lise dos riscos Al m disso os recursos que gastam valor no teste devem ser proporcionais com o uso criticidade da aplica o as t cnicas diferentes t m custos diferentes e rendem n veis diferentes de confian a na confiabilidade do
146. boas pr ticas Essas pr ticas podem dizer respeito somente a atividades de t cnicas de engenharia software ou podem tamb m referir se por exemplo gest o engenharia de sistemas e humanos bem como as atividade de gerenciamento dos recursos ISO IEC 15504 15015504 98 define um modelo de avalia o exemplo e sobre outras exig ncias conforme modelo de avalia o Modelos espec ficos de avalia o dispon vel e em uso sao SW CMM SEI95 CMMI SEIO1 e Bootstrap Sti99 Capacidade de maturidade e de muitos outros modelos t m sido definidas por exemplo para a concep o documenta o e m todos formais para citar apenas alguns ISO 9001 outro modelo de avalia o comum que tem sido aplicado por organiza es de software ISO9001 00 156 Um modelo de maturidade para a engenharia de sistemas tamb m tem sido desenvolvidos o que seria mais til quando um projeto ou organiza o est envolvida no desenvolvimento e manuten o de sistemas incluindo software EIA IS731 99 A aplicabilidade dos modelos para avalia o pequenas organiza es abordado em Joh99 San98 Existem duas arquiteturas para uma avalia o geral modelo que faz diferentes suposi es sobre a ordem em que processos devem ser avaliados cont nua e por fases Pau94 Eles s o muito diferentes e devem ser avaliadas pela organiza o considerando as para determinar qual seriam as mais apropriada para as suas necessidades e objetivos b
147. bstitu vel s do sistema que se conformam com e fornecem a realiza o de um jogo de interfaces Boo99 e suas rela es m tuas Boo99 c12 c31 Cart es de colabora o de classes respons veis CRC s usado para denotar os nomes de componentes classe suas responsabilidades e os nomes de seus componentes de colabora o Bus96 Diagramas de desenvolvimento usado para representar um jogo de n s f sicos e as suas rela es m tuas e assim modelar os aspectos f sicos de um sistema Boo99 c30 Diagramas de entidades e relacionamento ERDs usado para representar modelos conceituais de dados fornecidos em sistemas de informa o Dor02 v1c5 Mar02 DR Linguagens de descri o de interface IDLs parecido a com uma linguagem de programa o usada para definir as interfaces nomes e tipos de opera es exportadas de componentes de softwareBoo99 c11 Estrutura de diagrama Jackson usado para descrever os dados das estruturas quanto a sequ ncia sele o e itera o Mar02 DR Diagramas de estrutura usado para descrever a estrutura que chama programas que o m dulo chama e chamado por outro m dulo Jal97 c5 Mar02 DR Pre04 c10 b Descri es Comportamentais vis o din mica As seguintes nota es e linguagens alguns gr ficos e alguns textuais s o usados para descrever o comportamento din mico de componentes de software Muitas dessas nota es s o til pela maior parte mas n o exclusivamente
148. ca permitir a realiza o de sistemas bem sucedidos Centra se sobre a defini o de necessidades do cliente e da funcionalidade exigida cedo no ciclo de desenvolvimento documentando exig ncias ent o continua o com s ntese de projeto e valida o do sistema quando considera o problema completo opera es desempenho teste fabrica o custo e programa o treinamento e sustenta o e elimina o A engenharia de sistemas integra todas as disciplinas e grupos da especialidade em um esfor o de equipe que d forma a um processo de desenvolvimento estruturado e que prossiga do conceito de produ o opera o A engenharia de sistemas considera o neg cio e as necessidades t cnicas de todos os clientes com o objetivo de fornecer um produto de qualidade que encontre as necessidades do usu rio O Conselho internacional na engenharia de sistemas INCOSE www incose org est trabalhando em um guia ao corpo de engenharia de sistemas de conhecimento As vers es preliminares incluem as seguintes reas da compet ncia dos primeiros n veis e Processos de neg cio e avalia o operacional BPOA Sistema arquitetura da solu o teste SSTA e Ciclo da vida e do custo An lise de benef cio de custo LCC amp CBA e Servico habilidade logistica S L e Modelagem simula o e An lise MS amp A e Ger ncia Risco configura o linha de base Mgt 198 2 1 4 Ap ndices 2 1 4 1 Ap ndice A 2 1 4 1 1 Especif
149. capacidades diferentes frequentemente necess rio para recriar vers es espec ficas de pacotes e os materiais corretos para a entrega da vers o A biblioteca de software um elemento chave na realiza o de tarefas de lan amento e entrega a Construindo software Constru o de software a atividade de combinar as vers es corretas dos itens de configura o de software utilizando os dados de configura o adequada em um programa execut vel para a entrega a um cliente ou outro destinat rio como a atividade de teste Para sistemas com hardware ou firmware o programa execut vel entregue atividade de constru o do sistema Construir instru es garantir que o bom construir sejam tomadas medidas e na sequ ncia correta Al m da constru o de software para novos lan amentos geralmente necess rio tamb m para SCM ter a capacidade de reproduzir vers es anteriores para a recupera o testes manuten o ou para fins de libera o adicional Software constru do usando uma vers o particular de ferramentas de apoio tais como compiladores Pode ser necess rio para reconstruir uma c pia exata de um item previamente constru da configura o de software Neste caso as ferramentas de apoio e instru es de constru o associados precisam estar sob controle de SCM para garantir a disponibilidade das vers es corretas dos instrumentos A capacidade de ferramenta til para selecionar as vers es corretas
150. cas E E rquitetura Considera es de Teste Manuten o de Software Pr ticas An lise de rer Requisitos 3 T cnicas de Avalia o An lise Mensura es Manuten o rd ie da Qualidade do Relacionadas Especifica o de Design de Software aos Testes Requisitos Valida o de Nota o de Processo Requisitos Design de de Testes Software Considera es Pr ticas Estrat gias e M todos para Design de Software a b c Figura 5 Primeiras 5 areas do conhecimento a 29 Guia do Conjunto de Conhecimentos em Engenharia de Software Vers o 2004 erenciamento de Gerenciamento Processo de Ferramentas e Configura o de da Engeharia Engenharia de M todos de Software de Software Software Engenharia de Software Gites do Licita o e Processo de Ferramentas de Processo de Defini o de Implementa o e Software GCS Escopo Mundan a Defini o de A E oftware Jefini o Requisitos de Si a Identifica o de Planejamento de Processo Configura o de H Processo de Ferramentas de Software Software Design de Software Avalia o de Controle de Aprova o de Processo Configura o de Projeto de Matii a a Safan Mensura o de Constru o de Software Prodato s Ferramentas de Registros de Estado Revis o e Pr cess Teste de Software 4 de Configura o de Avalia o Software ma ofbarare Fechamento Marostengio d
151. cessos e projetos s o intimamente ligados esta KA tamb m descreve a medi o de processos e produtos e Qualidade de Software como qualidade uma meta constante da ger ncia e um objetivo de muitas atividades que devem ser gerenciadas 134 Como a KA de Ger ncia de Engenharia de Software vista aqui como um processo organizacional o qual incorpora a no o de ger ncia de processo e de projetos n s criamos uma estrutura que tanto baseada em t picos quanto baseada no ciclo de vida Entretanto a principal base para a estrutura de t pico de n vel mais superior o processo de ger ncia de um projeto de engenharia de software Existem seis grandes sub reas As cinco primeiras sub reas seguem largamente o Processo de Gerenciamento da IEEE EIA 12207 As seis subareas sao Inicia o e defini o de escopo a qual vai de encontro com a decis o de iniciar um projeto de engenharia de software Planejamento do projeto de software a qual orienta as atividades empreendidas para preparar para o sucesso a engenharia de software a partir de uma perspectiva de gerenciamento Formaliza o do projeto de software a qual aborda as atividades de ger ncia de engenharia de software geralmente aceitas que ocorrem durante a engenharia de software An lise e avalia o a qual trata da garantia de que o software seja satisfat rio Fechamento encerramento que trata das atividades de p s realiza
152. cionais e propriedades emergentes A sub rea tamb m descreve a import ncia de requisitos quantific veis e tamb m apresenta a diferen a entre requisitos de software e requisitos de sistemas A segunda sub rea de conhecimento o Processo de Requisitos que introduz o pr prio processo orientando o resto das cinco subareas e exposi o como a engenharia de requisitos se relaciona com os demais processos de engenharia de software Ela descreve modelos de processo atores de processo processos de suporte e gerenciamento e o processo de qualidade e melhoria A terceira sub rea a Elicita o de Requisitos que descreve de onde os 20 requisitos de software v m e como o engenheiro de software pode obt los Ele inclui as fontes de requisitos e t cnicas elicita o A quarta sub rea An lise de Requisitos se preocupa com o processo de analisar os requisitos para Detectar e resolver conflitos entre requisitos e Descobrir os limites do software e como ele deve interagir com o seu ambiente e Elaborar requisitos de sistema de forma a se transformarem requisitos de software A an lise de requisitos inclui a classifica o dos requisitos a modelagem conceitual o desenho da arquitetura e aloca o de requisitos e a negocia o de requisitos A quinta sub rea a Especifica o de Requisitos A especifica o de requisitos tipicamente refere se produ o de um documento ou o seu equivalente eletr nico que pode s
153. cisamente formas definidas de combinar os s mbolos que evitam a ambiguidade de muitas linguagens natural de constru o Nota es Visual baseiam se muito menos sobre as nota es de palavras chaves da constru o lingu stica e formal e em vez disso dependem a interpreta o visual direta e o posicionamento das entidades visual que representam o software subjacente Constru o Visual tende a ser um pouco limitado pela dificuldade de fazer complexas declara es usando apenas o movimento das entidades visuais numa exibi o No entanto tamb m pode ser uma ferramenta poderosa nos casos em que a tarefa de programa o principal simplesmente construir e ajustar uma interface visual a um programa comportamento detalhado do que foi definido anteriormente c Codificando As considera es seguintes se aplicam codifica o na atividade de constru o software Ben00 IEEE12207 95 McC04 e T cnicas para criar c digo fonte compreens vel incluindo a nomea o e layout de c digo de origem e Utiliza o de classes tipos enumerados vari veis constantes nomeados e outras entidades similares Uso do controle estruturas e Manuten o das condi es de erro tanto planejadas erros e excep es entrada de dados incorreto por exemplo e Preven o das viola es de seguran a de n vel de c digo satura es de buffer ou matriz ndice estouros por exemplo 67 e Uso de recursos atrav s da utiliza
154. co Claramente a melhor abordagem para a estimativa da manuten o combinar dados emp ricos e experi ncia Estes dados dever o ser fornecidos como resultado de um programa de medi o d Medi o da Manuten o de Software Grady e Caswell Gra87 discutem a institui o de um programa para as grandes empresas para a medi o da manuten o de software onde formul rios e dados coletados s o descritos O Sistema de Medi o PSM um software pr tico que descreve um projeto issuedriven processo de medi o que utilizado por muitas organiza es e bastante pr tico McG01 Os softwares possuem medidas que s o 105 comuns a todos os empreendimentos sendo que o Engineering Institute SEI tem identificadas as seguintes categorias de Software tamanho esfor o cronograma e qualidade Pig97 m Estas medidas constituem um bom ponto de partida para o mantenedor A discuss o sobre o processo e o produto da medi o apresentada no Software Engineering Process KA O programa descrito na medi o do Software Engenharia de Gest o KA Medidas Espec ficas IEEE1219 98 Table3 Sta94 p239 249 Abran Abr93 apresenta t cnicas de benchmarking para comparar as diferentes organiza es da manuten o interna O mantenedor deve determinar quais s o as medidas adequadas para a organiza o em quest o IEEE1219 98 1S09126 01 Sta94 sugere medidas que sejam mais espec ficas para os programas de medi o da man
155. como os componentes se comunicam como um middleware pode ser usado para entregar software heterog neo Bos00 c5 Bus96 c2 Mar94 DD Pre04 c30 d Transporte de Exce o Erro e Toler ncia a falha Como prevenir e tolerar falhas e entregar condi es excepcionais Pfl01 c5 e Intera o e Apresenta o Como estruturar e organizar intera es com usu rios e a apresenta o da informa o por exemplo separa o da apresenta o e l gica de neg cios usando a abordagem Model View Controller Bos00 c5 Bus96 c2 Lis01 c13 Mey97 c32 Isto pode ser notado que este t pico n o sobre detalhes de especifica o da interface de usu rios deseja se que a tarefa do design de interface de usu rio uma parte do Software Ergon mico veja as Disciplinas Relatadas da Engenharia de Software f Persist ncia dos dados Como dados de longa vida podem ser transportados 2 1 3 2 3 Estrutura e Arquitetura de Software No seu sentido estrito uma arquitetura de software uma descri o dos subsistemas e de componentes de um sistema de software e as rela es entre eles Bus96 c6 Arquitetura assim as tentativas de definir a estrutura interna Segundo o Dicion rio Ingl s Oxford a forma como algo constru do ou organizado do resultando software Durante meados da d cada de 1990 no entanto arquitetura de software come ou a emergi como uma mais ampla disciplina que envolve o estudo de estruturas e de arquiteturas de soft
156. como um constrangimento ou uma obriga o f Uma matriz do material de refer ncia versus t picos deve ser fornecida 202 2 1 4 1 5 Crit rios e exig ncias para Identificar KAs das Disciplinas relacionadas Espera se que os Editores Associados das reas do Conhecimento identifiquem em uma se o em separado que reas do Conhecimento das Disciplinas Relacionadas s o suficientemente relevantes para as reas do Conhecimento de Engenharia de Software que foram atribu das a terem o conhecimento esperado por um graduado com quatro anos da experi ncia Esta informa o ser especialmente til e empenhar muito di logo entre a inciativa do Guia do Corpo de Conhecimento de Engenharia de Software e nossas iniciativas irm s respons veis por definir um curr culo comum de engenharia de software e normas de realiza o padr o para engenheiros de software A lista de reas do Conhecimento de Disciplinas Relacionadas pode ser encontrada na Lista Base Proposta de Disciplinas Relacionadas Se considerado necess rio e se acompanhado de uma justificativa os Especialistas das reas do Conhecimento tamb m podem propor Disciplinas Relacionadas adicionais n o inclu das ou identificadas na Lista Base Proposta de Disciplinas Relacionadas Por favor observe que uma classifica o dos t picos das Disciplinas Relacionadas foi produzida mas ser publicada no Web site em uma data posterior em um documento de trabalho separado Por favor cont
157. d Lp ancd na gabi Joga ana degree eae ie ae ia maga tela SE da A 22 2 1 2 7 KA de Constru o de SoftWare assis sos ssocoescenvontseasecd pois enoiada sence ieeace tens ani eld unas a Deo rima goi ada adaga ao pen pandas 22 2 1 2 8 KA de Testes de Software 2 1 2 9 KA de Manuten o de Softwar e ccccccecescecsenceeesceeeeeeeeesaeeeeaeeseeneeeeaeeeseneeseaeeeseaeeseaeeceaeeeeaeeseieenseneeeeeeeteeeees 24 2 1 2 10 KA de Gerenciamento de Configura o do Softwar e cccccccccsecceeeeeeeeeneeeeeeeeseaeeseeaeeseeeeeeneeeeeeeeeeeeeeeeeeas 24 2 1 2 11 KA de Gerenciamento da Engenharia de Software ccccccccccceceeceeceeeeeeeeeeeeaeeeeneeeseeeeesaeeeseaeeeseeeseseeesenaaeee 25 2 1 2 12 KA Processo de Engenharia de Software cccccccssceeeeeeeeeeeeeeeeeeeeaeeceaeeeceeeeseeeeseeeeeeeeeeseeeseiaeeeeeeeeeeeeenaeea 26 2 1 2 13 KA Ferramentas e M todos de Engenharia de Software eee cerenaeraaaeeraann 26 21 22 14 KA Qualidade de Softwares nsciis iraro SENA aan eiin aaa ad a Ga ca E asa ied 27 2 1 2 15 KA Disciplinas Relacionadas com Engenharia de Software ie reeeereraraeaaanania 27 2 1 2 16 Ap ndice An iss ttt eae tah Sad eae ee ee ied ees ae ee 28 2 12 17 Ap ndice Brinta niiae aati ean dea cide 28 21 218 Ap ndice C e u2ar seara datada a RSA NS patentee coat a Ges S LUA RS dA es Manteca a ea eta 28 2 1 2 19 ADENGICE Dis etn hah ata octet Ae tl bh Attra OS ma UAM Lda E SE a LA ROO ga LE SU Sd
158. das estruturas de dados que um programa manipula e n o da fun o que ele executa O engenheiro de software primeiro descreve os dados de produ o 58 e a entrada das estruturas usando os diagramas de estrutura de Jackson por exemplo e logo desenvolvem a estrutura de controle do programa baseada nesses diagramas de estrutura de dados V rias heur sticas foram propostas para tratar com casos por exemplo especiais quando h uma m combina o entre as estruturas de produ o e entrada Fre83 III VIl Mar02 D e Design baseado em componente Um componente de software uma unidade independente tendo interfaces bem definidas e depend ncias que podem ser compostas e desdobradas independentemente O design baseado em componente dirige quest es relacionadas a fornecimento desenvolvimento e integra o de tais componentes ara melhorar reutiliza o f Outros m todos Outros interessantes mas com enfoque menor tamb m existem m todos formais e rigorosos Dor02 c5 Fre83 Mey97 c11 Pre04 c29 e m todos transformacionais Pfl98 c2 IEEE1016 98 IEEE1028 97 IEEE 1471 00 LEEE12207 0 96 S09126 01 ISO15026 98 Mar02 Mar94 Mey97 Smi93 1 Fundamentos do Design de Software 1 1 Conceitos Gerais de Design de Software 1 2 O Contexto do Design de Software 1 3 O Processo do Design de Software 1 4 Ativando T cnicas c9s1 c9s3 2 Quest es chave no Design de Softw
159. de g Taxonomia Processos de Engenharia de software 1 Ferramentas de software Reparti o dos T picos Nivel ee Ferramentas de requisitos de software AP Texenomia Ferramentas de design de software AP db Pieces cie fp EU e MEENE Ferramentas de constru o de software AP Processos d infraestrutura Ferramentas de testes de software AP Grupo de processo de engenharia de C Ferramentas de manuten o de AP software software Fabia de SXpPEnencIa c Ferramentas de processos de AP Atividades A engenharia de software Modelos para implementa o de io Ferramentas de qualidade de software AP processos e mudan a Ferramentas de gerenciamento de AP Considera es pr ticas C configura o de software 2 DEED CE POCS Ferramentas de gerenciamento de AP Modelos de ciclo de vida AP engenharia de software Processos de ciclo de vida do software C Ferramenta para assuntos diversos AP Nota es para defini es de processos c 2 M todos de Engenharia de software Adapta o de processos c M todos heur sticos AP Automa o c M todos formais e nota es C 3 Avalia o de Processo M todos de prototipa o AP Modelos de avalia o de processo Cc M todos para assuntos diversos c M todos de avalia o de processo C 4 Medi o de produto e processo Qualidade de Software Medi o de processo de software AP i Reparti o dos T picos N vel de Medi o de produto de software AP Taxonomia Medi o de tamanho AP DE 1 Fundamentos de qualidade de sof
160. de AP Processos para requisitos de C an lise revis o 2 Planejamento de projeto de software Planejamento de processos C Determinar resultados AP Estimativa de esfor o programa o e AP custo Aloca o de recursos AP Gerenciamento de risco AP Gerenciamento da qualidade AP Gerenciamento de projeto C 3 Lei do projeto de software Implementa o de projeto AP Gerenciamento de contratos com C fornecedores Implementa o de processos de AP medi o Processo de monitoramento AN Controle de processos AP Relat rio AP 4 An lise e avalia o Determinando a satisfa o dos AP requisitos 231 Reparti o dos T picos N vel de Reparti o dos T picos N vel de Taxonomia Taxonomia An lise e avalia o de performance AP Modelos de informa o de software 5 Fechamento Modelo de constru o AP Determinando fechamento AP Modelo de implementa o AP Atividades de fechamento AP T cnicas de medi o 6 Medi es de engenharia de software T cnicas anal ticas AP Estabelecer e manter compromisso de Cc T cnicas de benchmarking Cc medi o Planejar o processo de medi o C Ferramentas e m todos de Engenharia Executar o processo de medi o C de software Avaliar medi es c C Reparti o dos T picos N vel
161. de administra o da qualidade do software Per95 c17 IEEE 1008 87 Teste versus provas de exatid o e verifica o formal Pfl01 c8 Teste versus depura o Veja tamb m a rea de Conhecimento Constru o de Software t pico 3 4 Teste de constru o Bei90 c1s2 1 IEEE1008 87 Teste versus programa o Veja tamb m a rea de Conhecimento Constru o de Software t pico 3 4 Teste de constru o Bei90 c1s2 3 Teste e certifica o Wak99 2 1 3 4 2 N veis de Teste a alvo do teste O teste de software executado geralmente a n veis diferentes ao longo dos processos do desenvolvimento e da manuten o Isso para dizer o alvo do teste pode variar um nico m dulo um grupo de tais m dulos relacionados pela finalidade uso comportamento ou estrutura ou um sistema inteiro Bei90 c1 Jor02 c13 Pfl01 c8 Tr s est gios grandes de teste podem ser conceitualmente distinguidos s o eles unidade integra o e sistema O modelo do processo n o significativo nem suposto que algum daqueles tr s est gios tenha maior import ncia do que os outros dois e teste de unidade Bei90 c1 Per95 c17 Pfl01 c8s7 3 IEEE1008 87 O teste de unidade verifica o funcionamento isoladamente das partes do software que sao testaveis separadamente Dependendo do contexto estas podiam ser os subprogramas ou os grandes componentes feitos de unidades firmemente relacionadas Um teste de unidade definido mais precisament
162. de manuten o como uma caracter stica de qualidade 1509126 01 As subcaracter sticas da capacidade de manuten o devem ser especificadas revista e controladas durante o desenvolvimento das atividades de software a fim de reduzir os custos de manuten o Se for feito com xito a manuten o do software ir melhorar Isso muitas vezes dif cil de ser concretizado porque as caracter sticas da capacidade de manuten o n o s o um importante foco durante o processo de desenvolvimento de software Os desenvolvedores est o preocupados com muitas outras coisas e frequentemente ignoram as exig ncias do mantenedor Este fato por sua vez pode e muitas vezes o faz resultar em uma falta de documenta o do sistema o que uma das principais causas das dificuldades no programa de compreens o e avalia o do impacto Tamb m tem foi observado que a presen a de sistemas de processos maduros t cnicas e ferramentas ajudam a refor ar a manuten o de um sistema Estudos de impacto Dor02 v1c9s1 10 Pfl01 c11s11 5 Estudo de impacto descreve como a conduta de forma eficaz pode analisar completamente o impacto de uma mudan a no software atual Os mantenedores devem possuir um conhecimento aprofundado da estrutura do software e de seu conte do Pfl01 Eles usam esse conhecimento para realizar an lises de impacto o que identifica todos os sistemas e produtos de software afetado por uma solicitada mudan a de software e desenvol
163. des sequenciadas o que permitindo um ciclo iterativo para um cont nuo feedback e melhoria do processo de software e Atividade de Estabelecer o Processo Infraestrutura consiste em estabelecer compromisso para o processo de implementa o e mudan a incluindo obten o management buy in e na cria o de uma infraestrutura adequada recursos e responsabilidades para as atividades 151 e A meta da atividade Planejamento entender os objetivos do neg cio corrente e necessidades do indiv duo projeto ou organiza o para identificar seus pontos fortes e fracos e fazer um plano para processo de implementa o e mudan a A meta da atividade de Processo de Implementa o e Mudan a executar o plano implantar os novos processos os quais podem envolver por exemplo implanta o de ferramentas e treinamento do grupo e ou mudar os processos existentes e Processo Avalia o se preocupa em descobrir o qu o bem a implementa o das mudan as atenderam ou n o as expectativas e se os benef cios esperados foram alcan ados Os resultados s o ent o usados como entrada para ciclos sequentes c Modelos Para Processos de Implementa o e Mudan a Dois modelos gerais que tem emergido para orientar processos de implementa o e mudan a s o o Paradigma de Melhoria de Qualidade QIP SEL96 e o Modelo IDEAL McF96 Os dois paradigmas s o comparados em SEL96 Os Resultados da avalia o do processo de implementa
164. deve ser formalmente aprovado como adequado para a SCl e a linha de base em causa tal como definido na SCMP Ap s a aprova o o item ser incorporado no software de base de acordo com o procedimento adequado b Biblioteca de Software Uma biblioteca de software um conjunto controlado de software e documenta o relacionada com a inten o de auxiliar no desenvolvimento de software uso e manuten o IEEE610 12 90 tamb m fundamental no gerenciamento de software de lan amento e entrega de atividades V rios tipos de bibliotecas podem ser utilizadas cada uma correspondendo a um determinado n vel de maturidade do item de software Por exemplo uma biblioteca de trabalho poder apoiar codifica o e uma biblioteca de apoio ao projeto poderia apoiar testes enquanto uma biblioteca de mestre pode ser utilizado para produtos acabados Um n vel adequado de controle de SCM associadas de base e n vel de autoridade para a mudan a associado a cada biblioteca Seguran a em termos de controle de acesso e as instala es de backup um aspecto fundamental da gest o da biblioteca Um modelo de uma biblioteca de software descrito em Ber92 C14 A ferramenta usada s para cada biblioteca deve apoiar o controle SCM precisa dessa biblioteca tanto em termos de SIC controlar e controlar o acesso 123 biblioteca Ao n vel da biblioteca de trabalho esta uma capacidade de gerenciamento de c digo que serve os desenvolv
165. di o e dos compiladores d Ferramentas de Teste de Software Geradores de teste Estas ferramentas auxiliam no desenvolvimento de casos de testes Execu o de testes por etapas Estas ferramentas permitem a execu o de casos de teste em um ambiente controlado onde o comportamento do objeto que est sendo testado observado Ferramentas de avalia o de teste Estas ferramentas suportam a avalia o dos resultados dos testes de desempenho ajudando a determinar se o comportamento observado est de acordo com o comportamento previsto Ferramentas de Gerenciamento de Teste Estas ferramentas fornecem suporte para todos os aspectos do processo de testes de software Ferramentas de An lise e desempenho Rei96 Estas ferramentas s o usadas para medir e analisar o desempenho do software que uma forma especializada de ensaios onde o objetivo avaliar o comportamento da opera o e n o o comportamento funcional corre o e Ferramentas de Manuten o de Softwares Este t pico refere se s ferramentas que s o particularmente importantes na manuten o de software existentes e que necessitem de modifica es S o identificadas duas categorias ferramentas de compreens o e ferramentas de reengenharia Ferramentas de compreens o Re196 Estas ferramentas ajudam na compreens o humana de programas Os exemplos incluem ferramentas de visualiza o e partes animadas de programas Ferramentas de reengenhari
166. dida da confiabilidade a avalia o da usabilidade e a aceita o para que as aproxima es diferentes sejam tomadas Note que o objetivo do teste varia com o alvo de teste geralmente finalidades diferentes que est o sendo endere adas a diferentes n veis de teste As refer ncias recomendadas acima para este t pico descrevem o conjunto de potenciais objetivos de teste As sub t picos listados abaixo s o aqueles mencionados mais frequentemente na literatura Note que alguns tipos de teste s o mais apropriados para pacotes de software feitos sob medida teste de instala o por exemplo e outros para produtos gen ricos como teste beta Teste de aceita o e qualifica o Pfl01 c9s8 5 IEEE12207 0 96 s5 3 9 O teste de aceita o verifica o comportamento do sistema de encontro aos requisitos do cliente por m estes devem ter sido expressados os clientes empreendem ou especificam tarefas t picas para verificar se seus requisitos est o sendo cumpridos ou que a organiza o tenha identificado estes requisitos para o objetivo mercadol gico do software Esta atividade de teste pode ou n o pode envolver os desenvolvedores do sistema teste de instala o Pfl01 c9s8 6 Geralmente ap s a conclus o do teste do software e de aceita o o software pode ser verificado em cima da instala o no ambiente alvo O teste de instala o pode ser visto como teste do sistema conduzido mais uma vez de acordo com requisi
167. do processo de engenharia de software Varias diretorias poder ter que vir a ser criadas tais como diretoria de supervis o do desempenho do processo de engenharia de software Uma descri o geral de uma infraestrutura para o processo de melhoria mostrada no MCF96 Dois principais tipos de infraestrutura s o usados na pr tica o Grupo de Engenharia de Processo de Software e a F brica de Experi ncia e Grupo de Engenharia de Processo de Software SEPG O SEPG destinado a ser o foco central da engenharia de melhoria de software e ela tem uma s rie de responsabilidades em para iniciar e manter essa posi o os quais s o descritas em Fow90 e Experi ncia F brica EF O conceito de EF separa o projeto organizacional por exemplo a organiza o de desenvolvimento de software da rea de melhoria A rea de projeto organizacional se preocupa com o desenvolvimento e manuten o de software enquanto EF se preocupa com a melhoria da engenharia do processo de software A EF destinada a institucionalizar o aprendizado coletivo de uma rea pelo desenvolvimento atualizando e entregando rea de projetos pacotes experientes por exemplo guias modelos e cursos de treinamento tamb m referidos como processos ativos A organiza o do projeto Exemplos de pacotes experientes s o apresentados in Bas92 b Gerenciamento do ciclo do Processo de software O gerenciamento de processo de software consiste de quatro ativida
168. dos itens de software em um ambiente determinado objectivo e para automatizar o processo de constru o do software a partir das vers es selecionada e os dados de configura o apropriada Para grandes projetos com desenvolvimento paralelo ou 129 em ambientes de desenvolvimento distribu do esta capacidade ferramenta necess ria A maioria dos ambientes de engenharia de software fornecem esse recurso Essas ferramentas variam em complexidade de exigir o engenheiro de software para aprender uma linguagem de script especializada para abordagens de gr ficos orientado que escondem muito da complexidade de um inteligente construir instala es O processo de constru o e produtos est o frequentemente sujeitos a verifica o da qualidade de software As sa das do processo de compila o pode ser necess rio para refer ncia futura e pode tornar se registros de garantia da qualidade Bab86 C6 Som05 C29 b Software de Gerenciamento de Libera o Software de gerenciamento de libera o compreende a identifica o embalagem e entrega dos elementos de um produto por exemplo o programa execut vel documenta o notas de lan amento e os dados de configura o Dado que as altera es do produto pode ocorrer em uma base cont nua uma preocupa o para a gest o de libera o determinar quando a emitir um comunicado A gravidade dos problemas abordados pela libera o e medi es das densidades de falha de vers es
169. duplicar o conte do do Guia do PMBOK aqui seria tanto imposs vel quanto inapropriado Ao contr rio sugerimos que o leitor interessado na ger ncia de projeto al m do que espec fico para os projetos de engenharia de software consulte o PMBOK Ger ncia de projetos tamb m encontrada no cap tulo das Disciplinas Relacionadas Engenharia de Software A KA Ger ncia de Engenharia de Software consiste tanto do processo de ger ncia de projeto de software nas suas primeiras cinco sub reas quanto da mensura o da engenharia de software na sua ltima sub rea Embora essas duas disciplinas sejam muitas vezes consideradas como sendo separadas e sem d vida elas possuem muitos aspectos nicos suas estreitas rela es levaram a um tratamento combinado nesta KA Infelizmente uma percep o comum na ind stria de software que ela entrega produtos com atraso al m do custo de baixa qualidade e de funcionalidade incerta Ger ncia de mensura o informada um 133 princ pio assumido de qualquer verdadeira disciplina de engenharia pode ajudar a mudar essa percep o Na ess ncia gerenciamento sem mensura o qualitativa e quantitativamente sugere uma falta de rigor e mensura o sem gerenciamento sugere uma falta de finalidade ou contexto Da mesma forma entretanto gerenciamento e mensura o sem conhecimento t cnico especializado in til por isso devemos ter cuidado para evitar o excesso de nfase nos aspectos qu
170. durante o detalhamento do design Diagramas de atividade usado para mostrar o controle de fluxo de atividade execu o n o at mica cont nua dentro de uma maquina de estado atividade Boo99 c19 Diagramas de colabora o usado para mostrar as intera es isto ocorre 56 entre um grupo de objetos onde a nfase est nos objetos as seus links e as mensagens trocadas entre eles por esses links Boo99 c18 Diagramas de fluxo de dados DFDs usado para mostrar fluxo de dados entre um jogo de processos Mar02 DR Pre04 c8 Diagramas e tabelas de decis o usado para representar combina es complexas de condi es e a es Pre04 c11 Fluxogramas e fluxogramas estruturados usado para representar o controle de fluxo e as a es associadas a ser executadas Mar02 DR Pre04 c11 Diagramas de sequ ncia usado para mostrar as intera es entre um grupo de objetos com nfase no timeordering de mensagens Boo99 c18 Transi o de estado e diagramas de statechart usado para mostrar o fluxo de controle de estado para estado em uma m quina de estado ar02 DR Jal97 c7 Linguagens formais de especifica o linguagens textuais utiliza no es b sicas da matem tica por exemplo a l gica o jogo sequ ncia para definir com rigor e de maneira abstrata as interfaces de componente de software e comportamento muitas vezes em termos de pr e p s condi es Dor02 v1c6s5 Mey97 c11 Pseudoc digo e as linguagens de design de
171. e identifica o das suas rela es com os cronogramas do projeto e das metas estabelecidas na fase de gerenciamento de planejamento do projeto Qualquer requerimento de treinamento necess rio para a implementa o dos planos e programas de forma o para novos funcion rios tamb m s o especificados Diferentes tipos de ferramenta de capacidades e os procedimentos para a sua utiliza o s o apoiados pelas atividades de SCM Dependendo da situa o a capacidade destas ferramentas podem ser disponibilizadas com alguma combina o de ferramentas manuais ferramentas automatizadas proporcionando uma capacidade nica de SCM ferramentas automatizadas integrando uma s rie de SCM e talvez outras capacidades ou ferramenta integrada para os ambientes que servem as necessidades dos v rios participantes no processo de engenharia de software por exemplo SCM o desenvolvimento V amp V Ferramenta automatizada torna se o apoio cada vez mais importante e cada vez mais dif cil de estabelecer como projetos que crescem em tamanho e como ambientes projetos se tornam mais complexos Estas capacidades das ferramentas fornecer apoio para e A Biblioteca do SCM O pedido de mudan a no software SCR e procedimentos de aprova o e C digo e produtos relacionados com o trabalho e mudan a das tarefas de gerenciamento Relato de Status Configura o de Software e cole o de m tricas de SCM Auditoria e Configura o de Software G
172. e o do modelo de ciclo de vida de software apropriado por exemplo espiral prototipa o evolutiva e a adapta o e implanta o de software de ciclo de vida por processos apropriados s o realizadas em fun o das especialidades dos requisitos do projeto M todos relevantes e os instrumentos tamb m s o selecionados Dor02 v1c6 v2c8 Pfl01 c2 Pre04 c2 Rei02 c1 c3 c5 Som05 c3 Tha97 c3 Ao nivel do projeto ferramentas e m todos apropriados sao utilizados para decompor o projeto em fun es com os insumos resultados conclus o e condi es de realiza o por exemplo estrutura de emerg ncia de trabalho Dor02 v2c7 Pfl01 c3 Pre04 c21 Rei02 c4 c5 Som05 c4 Tha97 c4 c6 Este por sua vez influencia as decis es na programa o e organiza o estrutural do projeto b Determinar os Resultados Finais O s produto s de cada tarefa por exemplo desenho arquitet nico relat rio de inspe o s o especificados e caracterizados Pfl01 c3 Pre04 c24 Tha97 c4 Oportunidades de reutilizar componentes de software previamente desenvolvidos ou a utiliza o de produtos de software s o avaliados Uso de terceiros bem como adquirir software planejado e fornecedores s o selecionados c Esfor o Programa o e Estimativa de Pre o Com base na reparti o de tarefas entradas sa das e a variedade necess ria de esfor o esperada para cada tarefa determinada usando uma 138 estimativa ba
173. e no padrao IEEE para Teste de unidade de software IEEE1008 87 que tamb m descreve uma aproxima o integrada para testes de unidade sistem ticos e documentados Tipicamente o teste de unidade ocorre com acesso ao c digo que est sendo testado e com o suporte de ferramentas de depura o de erros e for a o envolvimento dos programadores que 19 escreveram o c digo teste de integra o Jor02 c13 14 Pfl01 c8s7 4 O teste da integra o o processo de verificar a intera o entre os componentes de software Estrat gias cl ssicas de teste de integra o tais como de cima pra baixo ou de baixo para cima s o usadas com software tradicional hierarquicamente estruturado As estrat gias modernas de integra o sistem ticas s o um pouco guiadas pela arquitetura implica que a integra o dos componentes de software ou subsistemas baseiam se em linhas de identifica o funcional O teste da integra o uma atividade cont nua em cada est gio no qual os engenheiros de software devem abstrair perspectivas de baixo n vel distantes e concentrar nas perspetivas do n vel que est o integrando exce o de software pequeno simples sistem tico as estrat gias de teste de integra o incremental s o geralmente prefer veis para colocar todos os componentes juntos imediatamente que chamado pictorialmente de teste do big bang teste de sistema Pfl01 c9 O teste do sistema estado relacionado com o com
174. e portanto qualidade de software tamb m intimamente ligada a constru o de software A rela o entre disciplina de engenharia de software a KA constru o de software semelhante a ci ncia da computa o no uso de seu conhecimento de algoritmo e de detalhamento de pr ticas de codifica o ambos geralmente s o considerados pertencentes ao dom nio da ci ncia da computa o Ela tamb m est relacionada a gerencia de projeto na medida em que a gerencia da constru o pode apresentar desafios consider veis A reparti o da KA constru o de software apresenta abaixo junto com breve descri o dos principais t picos associados com ela Refer ncias adequadas tamb m s o fornecidas para cada um dos t picos A figura 14 apresenta um gr fico da decomposi o de n vel superior da reparti o para est KA 61 2 1 3 3 1 Fundamentos da constru o de software Os fundamentos da constru o de software inclui minimizar complexidade antecipa o da mudan a e constru o para verifica o normas de constru o Constru o de Software Fundamentos Gest o de Considera es de Constru o constru o Pr ticas de Software Minimizar complexidade Modelos de constru o Design de Constru o gt Linguagens de Constru o Antecipa o de mudan a Planejamento de constru o TOT PEPA Constru o para verifica o Testando a Constru o Medi o de constru o Reutiliza o N
175. e Si 4 Auditoria de Ferramentas de Gerenciamento Configura o de Mensura o da Senne a 8 Software Engenharia de Ferramentas de Gerenciamento Software de Engenharia de Software L Ger ncia de Libera o Ferramentas de Gerenciamento e Entrega de Software if 9 h Figura 6 ltimas 6 reas do conhecimento de Processos de Sotware Ferramentas de Qualidade de Software a Qualidade de Software Processos de Gerenciamento da Qualidade do Software Ferramentas de Assuntos Diversos M todos de Engenharia de a Software M todos Heur sticos M todos Formais 4 M todos de Prototipasio J i Considera es Pr ticas Disciplinas Relacionadas co Engenharia de Software Engenharia de Computa o Ci ncia da Computa o Administra o Matem tica Gerenciamento de Projetos Gerenciamento da Qualidade Ergonomia de Software Engenharia de Sistemas k 30 2 1 3 reas de conhecimento 2 1 3 1 Requisitos de Software A rea de conhecimento Requisitos de Software trata da elicita o an lise especifica o e valida o dos requisitos de software A m condu o dessas atividades tornam projetos de engenharia de software criticamente vulner veis Requisitos de Software expressam as necessidades e restri es colocadas sobre um produto de software que contribui para a solu o de um problema do mundo r
176. e manuten o e ele parte importante da constru o atual do produto Realmente o planejamento para teste deveria come ar nos est gios iniciais dos processos de requisitos e planos de teste e procedimentos precisam ser sistematicamente e continuamente desenvolvidos e possivelmente refinados como desenvolvimento cont nuo Estes planos de teste e atividades de planejamento constituem contribui o til para desenvolvedores real ando potenciais debilidades como descuidos ou contradi es e omiss es ou ambiguidades na documenta o considerado atualmente que a atitude certa em dire o qualidade uma de preven o obviamente muito melhor evitar problemas que corrigi los Testes devem ser vistos ent o principalmente como meios para conferir n o s se a preven o foi efetiva mas tamb m para identificar faltas nesses casos onde por alguma raz o n o foi efetivo talvez bvio mas com reconhecido valor que at mesmo depois da conclus o de uma extensiva campanha de testes que o software 11 ainda possa conter falhas O rem dio para falhas experimentadas de software depois da entrega feito por a es de manuten o corretiva T picos de Manuten o de Software est o cobertos na rea de Conhecimento Manuten o de Software Na rea de Conhecimento Qualidade de Software t cnicas de administra o de qualidade de software s o categorizadas notavelmente em t cnicas est ticas nenhuma execu
177. e regulamentos normas diretrizes planos e procedimentos IEEE1028 97 As auditorias s o realizadas de acordo com um processo bem definido composto de v rios pap is e 127 responsabilidades do auditor Consequentemente cada auditoria deve ser planejada com cuidado Uma auditoria pode exigir um n mero de indiv duos para executar uma variedade de tarefas ao longo de um per odo relativamente curto de tempo Ferramentas para apoiar o planeamento e a condu o de uma auditoria pode contribuir para facilitar o processo Orienta o para a realiza o de auditorias de software est dispon vel em diversas refer ncias como Ber92 C11 Buc96 C15 e IEEE1028 97 O software da catividade de auditoria de configura o determina o grau em que um item satisfa a as caracter sticas exigidas f sica e funcional Informal auditorias deste tipo podem ser realizados em pontos chave do ciclo de vida Dois tipos de auditorias formais pode ser exigido pelo contrato que rege por exemplo em contratos de cobertura de software cr tico a Auditoria de Configura o Funcional FCA e da Auditoria de Configura o F sica PCA A conclus o bem sucedida destas auditorias pode ser um pr requisito para o estabelecimento da linha de base do produto Buckley Buc96 c15 contrasta os efeitos da FCA e PCA em contextos de hardware versus software e recomenda uma avalia o cuidadosa da necessidade de um software FCA e PCA antes de execut las a
178. e ser impl cito no conjunto de interfaces de um kit de ferramentas Linguagens de programa o s o o tipo mais flex vel das linguagem de constru o Elas tamb m cont m o m nimo de informa es sobre reas de aplica o espec ficas e processos de desenvolvimento e assim o exigem mais forma o e habilidade para utiliz las de forma eficaz Existem tr s tipos gerais de nota o usada para linguagens de programa o que s o e Lingu stica e Formal e Visual Nota es lingu sticas distinguem se em especial atrav s da utiliza o de cadeias de palavras chave de texto para representar constru es de software complexo e a combina o de tais strings de palavra chave em padr es que possuem 66 uma sintaxe de frase semelhante Corretamente utilizados cada cadeia de caracteres deve ter uma forte conota o sem ntica fornecendo uma compreens o intuitiva imediata do que acontecer quando a constru o de software subjacente executada Nota es formais contam com menos significados intuitivos palavras comuns e cadeias de texto e mais em defini es de suporte preciso sem ambiguidades e defini es formais ou matem tica Nota es de constru o formal e os m todos formais s o o centro da maioria das formas de sistema de programa o onde a precis o comportamento de tempo e testabilidade s o mais importantes do que a facilidade de mapear para linguagem natural Constru es formais tamb m usam pre
179. e software uma atividade executada para avaliar a qualidade do produto e para melhor lo pela identifica o de defeitos e problemas Teste de software consiste da verifica o din mica do comportamento de um programa em um conjunto finito de casos de teste adequadamente selecionados de um dom nio de execu o usualmente infinito contra o comportamento esperado Na defini o anterior as palavras em it lico correspondem a assuntos chave na identifica o de rea do Conhecimento de Teste de Software Em particular e Din mico Esse termo significa que testar sempre implica executar o programa com entradas valorizadas Para ser preciso s os valores de entrada n o s o sempre suficientes para determinar um teste desde que um sistema complexo n o determin stico pode reagir mesma entrada com diferentes comportamentos dependendo do estado do sistema Nessa rea do conhecimento embora o termo entrada ser mantido com a conven o inclu da que seu significado tamb m inclua um estado espec fico de entrada nesses casos para os quais isso necess rio Diferente de testar e complementar a isso s o as t cnicas est ticas descritas na rea de Conhecimento Qualidade de Software e Finito At mesmo em programas simples tantos casos de testes s o teoricamente poss veis que testes exaustivos possam exigir meses ou anos para executar Isso por que na pr tica o conjunto inteiro de testes pode geralmente se
180. ea de Engenharia de Software Professor da cadeira de Sistemas de Informa o no Departamento de Inform tica da UERJ Consultor nas reas de Engenharia de Software e Sistemas de Informa o dele a cita o A d cada de 60 e princ pio da d cada de 70 mostraram a inviabilidade da ideia do sistema de informa o global para toda uma organiza o A despeito dos grandes avan os tecnol gicos v rias organiza es passaram pela desagrad vel experi ncia de terem alt ssimos gastos em processamento de dados e contrariamente ao esperado terem acumulados grandes insucessos na implanta o de ambiciosos Sistemas de Informa o os quais englobariam toda a organiza o Um Sistema de Informa o n o como muitos acreditavam e infelizmente alguns ainda acreditam um sistema puramente t cnico Cabe a ger ncia de Engenharia de Software todo o suporte no desenvolvimento e manuten o do software constante do sistema computacional de apoio aos Sistemas de Informa o da organiza o O Instituto de Engenheiros Eletricistas e Eletr nicos IEEE uma organiza o profissional sem fins lucrativos fundada nos Estados Unidos a maior em n mero de s cios organiza o profissional do mundo O IEEE foi formado em 10 1963 pela fus o do Instituto de Engenheiros de Radio IRE com o Instituto Americano de Engenheiros Eletricistas AIEE O IEEE tem filiais em muitas partes do mundo sendo seus s cios engenh
181. eal O termo Engenharia de Requisitos muito utilizado para denotar um tratamento sistem tico dos requisitos Por consist ncia ser evitado o uso do termo neste guia A rea Requisitos de Software fortemente relacionada a e Design do Software Teste de Software Manuten o do Software Ger ncia de Configura o do Software e Ger ncia da Engenharia de Software e Processo de Engenharia de Software Qualidade de Software A divis o aqui adotada inteiramente compat vel com as se es da IEEE 12207 que referem se s atividades de requisitos Um risco inerente divis o proposta que um modelo do tipo cascata pode ser inferido Para se precaver disso a sub rea 2 Processos de Requisitos projetada para prover uma vis o geral em alto n vel do processo de requisitos estabelecendo os recursos e restri es sobre os quais o processo opera e que servem para configur lo Uma decomposi o alternativa poderia ser uma estrutura baseada em produto requisitos do sistema requisitos de software prot tipos casos de uso 31 Fusdamentos de Requintos de Software Processos de Requintos Defica o de Le we Requato de Zaftware Requatos de o Prodstor Processo oe Fuscas e His Fuscicnass Modelos de gt Process Atceres s e Procenso Suporte e o Oertexie do Processo Requisitos de Software Elicsta o de Requsates p Fortes de Requmos gt Mmemfica o
182. ece orienta es para organiza es 90003 Sistemas Orienta es para a na aplica o do ISO 9001 2000 para a aquisi o E Aplica o da ISO 9001 2000 para suprimento desenvolvimento opera o e Software de computador manuten o de software de computador 225 2 1 4 4 Ap ndice D 2 1 4 4 1 Classifica o dos Temas Segundo a Taxonomia de Bloom Taxonomia de Bloom uma classifica o bem conhecida e amplamente utilizada para objetivos educacionais cognitivos Foi adotado com o objetivo de ajudar o p blico que deseja utilizar o guia como uma ferramenta na defini o de material de curso curr culos universit rios crit rios universit rios para credenciamento de programas descri es de trabalho descri es de pap is dentro de uma defini o do processo de engenharia de software caminhos de desenvolvimento profissional e programas de forma o profissional entre outras necessidades Os n veis da taxonomia de Bloom para os t picos do guia SWEBOK s o sugeridos neste ap ndice para uma gradua o de engenharia de software com quatro anos de experi ncia A gradua o de engenharia de software com quatro anos de experi ncia em ess ncia o alvo do Guia SWEBOK conforme definido pelo que se entende por conhecimento geral aceito Uma vez que este ap ndice apenas se refere ao que pode ser considerado como conhecimento geralmente aceito muito importante lembrar que um
183. ece uma conex o entre o software pretendido e o ambiente externo Isso fundamental para entender o contexto do software no seu ambiente operacional e identificar interfaces Modelamento fortemente acoplado com m todos Para prop sitos pr ticos um m todo uma nota o ou um conjunto de nota es suportado por um processo que guia a aplica o das nota es Geralmente um m todo n o muito superior a outros A larga aceita o de um m todo ou nota o podem resultar em uma extensa e ben fica comunh o de habilidades e conhecimentos Modelos formais usando nota es baseada na matem tica discreta baseados no racioc nio l gico podem ter impacto em alguns dom nios especializados Podem ser impostos por clientes ou padr es e oferecer vantagens na an lise de fun es ou componentes cr ticos Dois padr es prov m nota es que podem ser teis IEEE Std 1320 1 IDEFO para modelamento funcional IEEE Std 1320 2 IDEFIX97 IDEFObject para modelar informa es c Projeto de Arquitetura e Aloca o de Requisitos Em algum ponto a arquitetura da solu o precisa ser derivada Projeto da arquitetura o ponto onde o processo de requisitos sobrep e se com o projeto do software ou do sistema e ilustra como imposs vel desacoplar com clareza essas duas tarefas Este t pico fortemente relacionado com a sub rea Estrutura do software e Arquitetura da rea de conhecimento Design do Software Em muitos caos o eng
184. ecimento e suas contribui es recrutando revisores e chefes de revis o bem como coordenando v rios ciclos de revis o Por isso os Editores s o respons veis pela coer ncia do Guia inteiro e por identificar e estabelecer conex es entre as reas do Conhecimento Os Editores e os Editores Associados das reas do Conhecimento negociar o a resolu o de 205 lacunas e sobreposi es entre reas do Conhecimento 2 1 4 1 10 Documentos Relacionados Importantes a P Bourque R Dupuis A Abran J W Moore L Tripp e D Frailey Uma Lista B sica de reas do Conhecimento da Vers o Stone Man do Guia do Corpo de Conhecimento de Engenharia de Software Universit du Qu bec Montr al Montr al Fevereiro de 1999 Baseado na vers o Straw Man nas discuss es mantidas e expectativas afirmadas na reuni o de in cio do Conselho Consultivo Industrial em outras propostas de corpo de conhecimento e em crit rios definidos neste documento este documento prop e uma lista b sica de dez reas do Conhecimento da Vers o Teste do Guia do Corpo de Conhecimento de Engenharia de Software Esta base pode desenvolver se naturalmente com o progresso de trabalhos e identifica o de problemas durante o curso do projeto b P Bourque R Dupuis A Abran J W Moore e L Tripp Uma Lista B sica Proposta de Disciplinas Relacionadas da Vers o Stone Man do Guia do Corpo de Conhecimento de Engenharia de Software Universit d
185. ecu o da Modifica o Revis o da Manuten o Aceita o e Migra es Aposentadoria do Software Grubb amp Takang Tak97 fornecem um hist rico de modelos de processos de manuten o conducentes aos modelos de processos de desenvolvimento do IEEE e ISO IEC Parikh Par86 tamb m d uma boa vis o geral de um processo gen rico de manuten o Recentemente metodologias geis foram criadas e promoveram a efici ncia dos processos Essa exig ncia decorre do da procura por fast turn around de manuten o de servi os Alguns experimentos com manuten o s o apresentados em Extreme Poo01 108 b Atividades de Manuten o Como j foi dito muitas atividades de manuten o s o semelhantes com as de desenvolvimento de software Os mantenedores executam an lise projeto codifica o testes e documenta o Estes requisitos devem monitorar suas atividades como feito no desenvolvimento atualiza o a documenta o como base na altera o ISO IEC14764 recomenda que quando um mantenedor refere se a um processo de desenvolvimento semelhante ele tem que adapt lo para satisfazer suas necessidades espec ficas 5014764 99 s8 3 2 1 2 No entanto para a manuten o de software algumas atividades envolvem processos de software exclusivos para a manuten o Atividades nicas Dor02 v1c9s1 9 1 IEEE1219 98 s4 1 s4 2 1SO14764 99 58 2 2 1 58 3 2 1 Pfl01 c11s11 2 H uma s rie de processos atividades e pr
186. edades de verifica o confirma o Cla96 Pfl01 S0om05 Este t pico trata as propriedades de verifica o que s o especificas as abordagens formais incluindo tanto o modelo de teoria como o modelo de verifica o c M todos de Prototipagem Esta subse o abrange m todos que envolvem a prototipagem de software e subdividida em estilos de prototipagem metas e avalia es t cnicas e Estilo de prototipagem Dor02 Pfl01 Pre04 Pom96 O t pico estilo de prototipagem identifica as v rias abordagens rejeitada evolutiva e especifica o execut vel e Os objetivos de um m todo de prototipagem podem ser os requisitos de desenho de arquitetura ou interface do usu rio e Avalia es t cnicas de prototipagem Este t pico abrange as maneiras pelas quais os resultados de um treinamento de prototipagem s o usados 171 2 1 3 10 Qualidade de Software O que qualidade de software e por que t o importante que este assunto fa a parte do Guia SWEBOK Durante anos autores e organiza es t m definido qualidade de formas diferentes Para Phil Crosby Cro79 a melhor defini o era conformidade com os requisitos do usu rio Watts Humphrey Hum89 refere se ao termo como alcan ar excelentes n veis de adequa o para uso enquanto a IBM cunhou a frase Qualidade dirigida pelo mercado que est baseada em alcan ar a satisfa o total do cliente O crit rio Baldrige para qualidade organizacional N
187. edores mantenedores e SCM focado na gest o de vers es de itens de software apoiando as atividades de v rios desenvolvedores Em n veis mais altos de controle o acesso mais restrito e SCM o principal usu rio Essas bibliotecas s o tamb m uma importante fonte de informa o para a medi o do trabalho e do progresso Bab86 c2 c5 Buc96 c4 IEEE828 98 c4s3 1 Pau93 L2 82 Som01 C29 2 1 3 6 3 Software de controle de configura o Software de controle de configura o esta preocupado com o gerenciamento de mudan as durante o ciclo de vida do software Abrange o processo para determinar quais as mudan as a fazer a autoridade para aprovar as mudan as o apoio para a implementa o dessas mudan as e o conceito de desvios formais de requisitos do projeto bem como a ren ncia a eles Informa es resultantes dessas atividades til para medir o tr fego de mudan a e ruptura e aspectos de retrabalho a Requerente Avalia o e aprova o de altera es de software O primeiro passo para gerir as mudan as de produtos controlados determinar quais as mudan as a fazer O processo de solicita o de altera o de software ver Figura 5 prev procedimentos formais para a apresenta o e grava o de solicita es de mudan a avaliando o custo potencial e o impacto de uma mudan a proposta e aceitando modificar ou rejeitar as altera es propostas Os pedidos de altera o de itens de configura o
188. eiros eletricistas engenheiros da computa o cientistas da computa o profissionais de telecomunica es etc Sua meta promover conhecimento no campo da engenharia el trica eletr nica e computa o Um de seus pap is mais importantes o estabelecimento de padr es para formatos de computadores e dispositivos A leitura destes autores foi de fundamental import ncia para que se observasse a necessidade de uma ferramenta que agrupasse as melhores pr ticas as melhores ideias em n vel mundial na rea de Engenharia de Software em um local e a partir de onde as dire es para o futuro dessa nova ci ncia fossem apontadas 11 1 3 Objetivos gerais Promover o maior conhecimento do SWEBOK pelos profissionais que atuam na engenharia de software e fornecer um primeiro contato ao corpo de conhecimento de Engenharia de Software 1 4 Objetivos espec ficos Contextualiza o da utiliza o do guia SWEBOK Defini o dos principais conceitos de Engenharia de Software Exposi o das reas de conhecimento Exposi o das disciplinas relacionadas Engenharia de Software Expans o do uso do guia SWEBOK 1 5 Justificativa Roger Pressman no livro Engenharia de Software 6a edi o 2006 cap tulo 1 p gina 13 diz O software tornou se o elemento chave na evolu o de sistemas e produtos baseados em computador e uma das tecnologias mais importantes em todo o mundo Ao longo dos ltimos 50 anos o so
189. encontradas em McC04 e IEEE1012 98 Enquanto as m tricas para caracter sticas de qualidade e funcionalidades do produto puderem ser teis em si por exemplo o n mero de requisitos defeituosos ou a propor o de requisitos defeituosos t cnicas matem ticas e gr ficas poder o ser aplicadas para ajudar na sua interpreta o Estas se encaixam nas categorias seguintes e s o discutidos em Fen97 Jon96 Kan02 Lyu96 Mus99 e Baseado em estat stica por exemplo an lise de Pareto gr ficos de execu o scatter plots distribui o normal e Testes estat sticos por exemplo teste binomial teste do qui quadrado chi squared test e An lise de tend ncias e Predi o por exemplo modelos de confian a As t cnicas e testes baseados em estat stica frequentemente fornecem um snapshot das reas mais problem ticas do produto de software sob an lise As tabelas e gr ficos resultantes s o visualiza es que os tomadores de decis es podem usar para concentrar os recursos onde eles parecem mais necess rios Resultados de an lise de tend ncia podem indicar que um cronograma n o tem sido respeitado tais como nos testes ou que certas classes de falhas tornam se mais intensas a menos que seja tomada alguma a o corretiva em desenvolvimento As t cnicas de predi o ajudam no planejamento de testes e na previs o de tempo de falhas Mais discuss es sobre m tricas em geral aparecem nas KAs Processo de Engenharia de
190. engenharia o mais radical e caro formul rio de altera o Outros entendem que a reengenharia pode ser usada para pequenas altera es Ela muitas vezes n o compromete se a melhorar a durabilidade mas a substituir o envelhecido legado de software Arnold Arn92 prev um comp ndio abrangente de temas como por exemplo conceitos ferramentas e t cnicas estudos de caso e os riscos e benef cios associados reengenharia Arn92 C1 C3 C6 Dor02 v1c9s1 11 4 IEEE1219 98 B 2 Fow99 c Engenharia reversa Engenharia reversa o processo de an lise de software que identifica os 112 componentes do software e suas inter rela es para criar representa es do software sob outra forma ou em n veis mais elevados de abstra o A Engenharia Reversa passiva ela n o muda o software ou resultar em novos softwares Ela produzir esfor os chamados grafos e gr ficos de controle de fluxo para achar o c digo Um tipo de engenharia reversa a redocumenta o Outro tipo a recupera o de design Dor02 Refactoring um programa de transforma o que reorganiza um programa sem modificar o seu comportamento e uma forma de engenharia reversa que visa melhorar a estrutura do programa Fow99 Finalmente os dados de engenharia reversa t m ganhado import ncia ao longo dos ltimos anos onde schemas l gicos foram recuperados f sicos a partir de bases de dados Hen01 Arn92 c12 Dor02 v1c9s1 11 3 IEEE1219 98 B 3
191. enheiro de software age como arquiteto do software pois o processo de analisar e elaborar os requisitos demanda que os componentes que ser o respons veis por satisfazer os requisitos sejam identificados Isso aloca o 38 de requisitos a atribui o a componentes da responsabilidade por satisfazer os requisitos Aloca o importante pois permite a an lise detalhada dos requisitos Projeto da arquitetura fortemente identificado com modelamento conceitual O mapeamento de entidades do mundo real para componentes de software nem sempre obvio Assim projeto da arquitetura identificado como um t pico separado Os requisitos de nota es e m todos s o os mesmos no modelamento conceitual e no projeto da arquitetura IEEE 1471 2000 sugere uma abordagem de m ltiplos pontos de vista para descrever a arquitetura do sistema e seus itens de software d Negocia o de Requisitos e Negociar requisitos X Resolu o de conflitos Resolver problemas decorrentes de conflitos entre requisitos Dois stakeholders podem requerer features mutuamente incompat veis e Conduzida por especialistas de requisitos e Evita se decis o unilateral stakeholders envolvidos s o consultados em busca de consenso Por raz es contratuais s vezes clientes s o envolvidos Foi classificado como an lise de requisitos de software porque problemas emergem como resultado da an lise Entretanto um caso grande pode tamb m ser co
192. enibilidade Requisitos de Confiabilidade e outros tipos Exemplos O custo n o pode ultrapassar R 50 000 00 ou Uma fun o deve estar dispon vel ao usu rio 99 99 do tempo d Propriedades Emergentes Alguns requisitos representam propriedades emergentes do software isto propriedades que n o s o endere adas por um componente mas cuja satisfa o depende da inter opera o de diversos componentes do sistema Por exemplo a efici ncia throughput de um call center depende do sistema telef nico sistema de informa o e de todos os operadores interagindo sob condi es operacionais A rapidez de atendimento de um cliente numa loja depende de fatores tais como facilidades de consulta ao cadastro de clientes facilidades para libera o de mercadoria no estoque agilidade na libera o pelo caixa etc Propriedades emergentes s o crucialmente dependentes da arquitetura do sistema e Requisitos Quantific veis Requisitos precisam ser definidos com clareza e sem ambiguidade o quanto 33 for poss vel e quando for o caso quantitativamente Evitar defini es vagas ou que n o possam ser verificadas tais como O atendimento ao cliente deve ser r pido Fica melhor O cliente deve ser atendido num intervalo de tempo de 2 minutos f Requisitos de Sistema e Requisitos de software Sistema Uma combina o de elementos interagindo para obter um determinado objetivo Inclui software hardware pessoa
193. er sistematicamente revisto avaliado e aprovado Para sistemas complexos em particular os que implicam o uso de componentes que n o necessariamente s o software No m nimo tr s tipos diferentes de documentos s o produzidos defini o de sistema especifica o de requisitos do sistema e especifica o de requisitos de software A sub rea descreve os tr s documentos e as atividades subjacentes A sexta sub rea a Valida o de Requisitos cujo objetivo buscar qualquer problema antes que os recursos sejam implantados no envio dos requisitos A valida o de requisitos preocupa se com o processo de examinar os documentos de requisitos para assegurar que eles est o definindo o sistema correto isto o sistema que o usu rio espera subdividido em descri es de procedimento de revis o de requisitos prototipa o valida o de modelo e testes de aceita o A s tima sub rea que a ltima sub rea chamada de Considera es Pr ticas Ela descreve os t picos que t m de ser compreendidos na pr tica O primeiro t pico a natureza iterativa do processo de requisitos Os pr ximos tr s t picos s o fundamentalmente sobre a ger ncia de mudan as e a manuten o de requisitos em um estado que exatamente reflete o software a ser constru do ou que j tenha sido constru do Ele inclui ger ncia de mudan as atributos de requisitos e investiga o de requisitos O t pico final a medi o de requisitos
194. era o de software software GCS medidas e dimens es AP Constru o de software AP Entrada de processos de auditorias para C Gerenciamento de libera o de software C GCS 2 Identifica o de configura o de software Identificando itens a serem controlados Ger ncia de Engenharia de software Configura o de software AP Itens de configura o de software AP Itens de relacionamento de configura o AP de software Vers es de software AP Ponto de partida AP Itens de aquisi o de configura o de AP software Biblioteca de software C 3 Controle de Configura o de software Requisi o avalia o e aprova o de mudan a de software Tabela de controle de configura o de AP software Processo de requisi o de mudan a de AP software Implementa o de mudan as de AP softwares Desvios e concess es C 4 Status da contabilidade de configura o de software Status de informa es de configura o de software C Status de relat rios de configura o de software AP 5 Auditoria de configura o de software Auditoria de configura o de software funcional Reparti o dos T picos N vel de Taxonomia 1 Inicia o e defini o de escopo Determina o de negocia o de AP requisitos An lise de possibilida
195. erenciamento e monitoramento da documenta o de software Performance da constru o do software Gerenciamento monitoramento da vers es de software e da sua entrega As ferramentas utilizadas nessas reas tamb m podem fornecer m tricas para o processo de melhoria Royce Roy98 descreve sete medidas fundamentais de valor no gerenciamento dos processos de engenharia de software Informa es dispon veis a partir das diversas ferramentas de SCM refere se Royce ao trabalho e progresso de indicadores de gerenciamento e sua qualidade de indicadores de 117 mudan a de Tr fico e estabilidade a Quebra e Modularidade Retrabalho e Adaptabilidade e MTBF tempo m dio entre falhas e maturidade Elabora o de relat rios sobre estes indicadores podem ser organizados de v rias maneiras por exemplo item configura o de software ou pelo tipo de altera o solicitada Outras ferramentas podem fornecer dados e relat rios de gerenciamento de capacidades para o gerenciamento do desenvolvimento e atividades de garantia de qualidade Como foi acima referido a capacidade dos diversos tipos de ferramenta pode ser integrada com sistemas de SCM o qual por sua vez est intimamente ligado s v rias atividades de outros softwares No planejamento engenharia de software SCM seleciona ferramentas adequadas para o trabalho Planejamento considera quest es que possam surgir na implementa o destas ferramentas especialmente se algum tipo de c
196. es da constru o que constroem uma estrutura f sica 65 devem fazer modifica es contabilizar pequenas falhas no plano do construtor construtores de software devem fazer modifica es em escala menor ou maior para enriquecer detalhes do design de software durante sua constru o Os detalhes da atividade de design a n vel de constru o s o essencialmente os mesmos como descrito na rea de conhecimento de design de software mas foram aplicadas numa escala menor b Linguagem de Constru o Linguagens de constru o incluem todas as formas de comunica o em que um homem pode especificar um solu o de um problema execut vel para o computador O tipo mais simples de linguagem de constru o uma linguagem de configura o na qual engenheiros de software escolhem um conjunto limitado de op es predefinidas para criar instala es de software novas ou personalizadas Os arquivos de configura o baseado em texto usados nos sistemas operacionais Windows e UNIX s o exemplos e as listas de sele o de estilo de menu de alguns geradores de programa constituem outro Kit de ferramentas de linguagem s o usadas para criar aplicativos em kits conjuntos integrados de partes reutiliz veis espec ficas do aplicativo e s o linguagens de configura o mais complexas Kit de ferramentas de linguagem podem ser explicitamente definidas como linguagens de programa o de aplicativo por exemplo scripts ou podem simplesment
197. essoas O processo de teste suporta atividades de teste e fornece a orienta o s equipes do teste do plano de teste para o teste de avalia o da sa da de modo a oferecer a garantia justificada de que os objetivos do teste sejam encontrados de maneira rent vel a Considera es pr ticas Atitudes programa o sem ego Bei90 c13s3 2 Pfl01 c8 Um componente muito importante do teste bem sucedido uma atitude colaborativa para o teste e as atividades de garantia da qualidade Os gerentes t m um papel chave em promover uma recep o geralmente favor vel para a descoberta da falha durante o desenvolvimento e a manuten o por exemplo impedindo uma atitude mental da posse de c digo entre programadores de modo que n o sintam respons veis pelas falhas reveladas por seu c digo 87 Guias de teste Kan01 As fases de teste podiam ser guiadas por v rios alvos por exemplo no teste risco baseado que usa os riscos do produto para dar a prioridade e focalizar a estrat gia do teste ou no teste cen rio baseado em que os casos de teste s o definidos baseados em cen rios espec ficos do software Teste da gest o de processo Bec02 Ill Per95 c1 c4 Pfl01 c9 IEEE1074 97 IEEE12207 0 96 s5 3 9 s5 4 2 s6 4 s6 5 O teste das atividades conduzidas a n veis diferentes ver sub t pico 2 n veis de teste deve ser organizado junto com as pessoas ferramentas pol ticas e medidas em um processo bem definid
198. est tica IEEE1028 ver igualmente na rea de conhecimento de qualidade de software tema 2 3 revis es e auditorias A t cnica espec fica ou t cnicas selecionadas dependem da natureza do software a ser constru do bem como dos engenheiros de software no conjunto habilidades executando a constru o Atividades de qualidade de constru o s o diferenciadas das outras atividades de qualidade pelo seu foco Atividades de qualidade de constru o concentram se no c digo e n o nos artefatos que est o intimamente relacionados ao c digo desenhos pequenos em vez de outros artefatos que est o menos diretamente conectados com o c digo como requisitos design de alto n vel e planos g Integra o 69 Uma atividade fundamental durante a constru o a integra o das rotinas constru das separadamente classes componentes e subsistemas Al m disso um sistema de software espec fico talvez precise ser integrado com outros sistemas de software ou hardware Preocupa es relacionadas com a integra o da constru o incluem planejamento a sequ ncia em que os componentes ser o integrados criando suporte para apoiar a vers es provis rias do software determinar o grau de testes e trabalho de qualidade realizado nos componentes antes de serem integrados e em que determinantes pontos no projeto vers es provis rias do software s o testadas Bec99 IEEE12207 95 McC04 2 1 3 4 Teste de Software Teste d
199. eve vista geral de atividades de teste como implicado frequentemente pela seguinte descri o a ger ncia bem sucedida de atividades do teste depende fortemente do processo da ger ncia de configura o do software Planejamento Kan99 c12 Per95 c19 Pfl01 c8s7 6 IEEE829 98 s4 IEEE1008 87 s1 s3 Como todos os outros aspetos do gerenciamento do projeto as atividades de teste devem ser planejadas Os aspectos chave do planeamento de teste incluem a coordena o dos pessoal a ger ncia das facilidades de teste e dos equipamentos dispon veis que podem incluir meios magn ticos planos de teste e procedimentos e o planejamento para poss veis resultados indesej veis Se mais de uma linha de base do software est sendo mantida ent o uma considera o principal do planeamento o momento e o esfor o necess rios para assegurar se de que o ambiente de teste esteja ajustado configura o apropriada Gera o de casos de teste Kan99 c7 Pos96 c2 IEEE1008 87 s4 s5 A gera o de casos de teste baseada no n vel de teste a ser executado e das t cnicas de teste particulares As situa es de teste devem estar sob o controle da ger ncia de configura o do software e incluir os resultados previstos para cada teste Desenvolvimento do ambiente de testes Kan99 c11 O ambiente usado para o teste deve ser compat vel com as ferramentas da tecnologia de programa o Deve facilitar o desenvolvimento e o contr
200. evel de software das organiza es as suas macro arquiteturas outros padr es de projeto pode ser usado para descrever em detalhes uma menor mais n vel local a sua micro arquitetura Boo99 c28 Bus96 c1 Mar02 DP e Padr es Creational por exemplo construtor f brica prot tipo e Singleton e Padr es estruturais por exemplo adaptador ponte comp sito decorador fachada flyweight e proxy e Padr es comportamentais por exemplo comando o int rprete intera o mediador memento observador estatal estrat gia modelo visitante c Fam lias de programas e frameworks Uma poss vel abordagem para permitir a reutiliza o de design de softwares e de componentes a concep o das fam lias de software tamb m conhecidos como linhas de produtos de software Isto pode ser feito atrav s da identifica o dos membros comuns dessas fam lias e usando componentes reutiliz veis e personaliz veis para levar em conta a variabilidade entre os membros da fam lia Bos00 c7 c10 Bas98 c15 Pre04 c30 Na programa o OO uma chave relaciona no es do que um framework um subsistema parcialmente completo de software que pode ser estendido pelas instala es de plug ins mais espec ficos tamb m conhecidos como hot spots 2 1 3 2 4 An lise e Evolu o da Qualidade de Design de Software Esta sec o inclui uma s rie de t picos de qualidade e avalia o que est o especificamente relacionadas com a concep
201. exibilidade Acompanhamento e exig ncias ao n vel da flexibilidade de ser fornecido a um engenheiro de software s o considera es importantes na ferramenta de sele o SCM medidas podem ser projetadas para fornecer informa es espec ficas sobre a evolu o do produto ou fornecer informa es sobre o funcionamento dos processos de SCM Um dos objetivos de acompanhar os processos de SCM descobrir as oportunidades para melhoria dos processos Medi es dos processos de SCM fornecem um bom meio para monitorar a efic cia das atividades de SCM de forma continua Essas medi es s o teis para caracterizar o estado atual do processo bem como fornecer uma base para compara es ao longo do tempo An lises das medi es podem produzir conhecimento importante para mudan as e atualiza es correspondentes ao SCMP Bibliotecas de software e as diversas ferramentas de capacidades do SCM fornecem as fontes para extrair informa es sobre as caracter sticas do processo de SCM bem como dispor de projetos e gerenciamento da informa o Por exemplo informa es sobre o tempo necess rio para executar diversos tipos de mudan as seriam teis numa avalia o dos crit rios para determinar quais s o os n veis de autoridade s o timas para autorizar certos tipos de mudan as Cuidados devem ser tomados para manter o foco no monitoramento sobre os conhecimentos que podem ser derivados a partir das medi es n o sobre as medi e
202. exig ncias para descrever T picos ren areeearacaaaeanananaaaaaaana 201 2 1 4 1 4 Crit rios e exig ncias para Selecionar Material de Refer ncia ia 201 2 1 4 1 5 Crit rios e exig ncias para Identificar KAs das Disciplinas relacionadas neeese 203 2 1 4 1 6 ndice dos Conte dos Comuns 2 1 4 1 7 O que Queremos Dizer com Conhecimento Geralmente Aceito 2 cece eee eeneeeneeeeenaees 204 2 1 4 1 8 Comprimento de Descri o de Areas do Conhecimento 205 2 1 4 1 9 Papel da Equipe Editorial zse a sess dass LisssreseoL SALE RSA aaa aa A esas NES nao agli Se ae eats 205 2 1 4 1 10 Documentos Relacionados Importantes ii ireeeereareraceraeaeeaa care aananana 206 2 1 4 1 11 Estilo Diretrizes F cnicasS csssmenesssenesintesgrnssiuisgeresertama din Mesa Ria tava Rise Fenda neon EES ca Renas eU gaia siei aie 208 2 1 4 1 12 Outras Diretrizes Detalhadas eee nanna aan sees eaeeeaeeseesaeeseeeseeesaeeseeeseeeseeseeeseeetaeeeseneaaas 208 2A ANS EGiGAOsetescci ica iad Aire iets ii RO diga anon den Micha earn lente 209 2 1 4 1 14 Libera o de Direitos AUtorais cccccceececeeeeeececeeeeeeeeeaeeeeaeeeecaeeeeaaeeseaeeseaeeseaeeeseaeeseneeeeeeeeeeeeeeaaee 209 22 42 Ap ndice Bansi Rats leita ieee a IAGO GEO ile iv hee ce OE ld Oh A eh oa Aen 210 2 1 4 2 1 Evolu o do SWEBOK sc causa avccnceeieeneesenanveets ce
203. ftware Isto porque processo constru o de software se aplica significativo design de software e atividade de teste Ele utiliza tamb m a produ o de design e fornece uma contribui o de teste ambos design e teste pode ser atividades n o KAs neste caso Detalhado limite entre design constru o e testes ir variar dependendo do ciclo de vida do processo de software que usado no projeto Embora alguns detalhes de design podem ser realizados anteriores a constru o muito trabalho de design realizado na atividade constru o Portanto KA rea de conhecimento constru o de software est intimamente ligado KA design de software Durante toda constru o engenheiros de software trabalham os dois testes de unidade e de integra o Assim a KA constru o de software est intimamente ligada a teste de software como KA A constru o de software tipicamente produz alto volume de itens de configura o esses necessitam de gerenciamento de projeto de software fonte arquivo conte do caso de teste e etc Portanto a KA constru o de software tamb m intimamente ligada a KA ger ncia de configura o de software A constru o de software invoca desde ferramentas e m todos e s o provavelmente ferramentas intensivas das KAs Elas s o ligadas a KA engenharia de software ferramentas e m todos Enquanto qualidade de software importante em todas as KAs o c digo a ultima realiza o do projeto de software
204. ftware Os processos Vida do Software Reutiliza o de s o adequados para uso com IEEE EIA 12207 2 of oJ goles oe oa oe 8 wad oe ES oe N mero SE 92 92 95 SE 4095 9485 988 4855 55 p di o Nome padr o Descri o 5 z 5 e E 5 q 3 5 F E E 5 E E z a z 9 E z a oo Se Soja ee Soo voa pra dos Sa D o Q D D D o Processos IEEE Std Padr o IEEE para Processos de Este padr o fornece um processo de ciclo de vida 1540 2001 Ciclo de Vida do Software Gest o para gest o de risco O processo adequado para INSONEC de Risco uso com IEEE EIA 12207 S P 16085 200 3 IEEE Std IEEE Pr ticas Recomendadas para Este documento recomenda pr ticas para engenharia 2001 2002 a Internet Engenharia de S tios de p ginas www para uso em ambientes de Intranet e p Web Gest o de S tios Web e Extranet Ciclo de Vida de S tios Web ISO Sistemas de Gest o da Qualidade Este padr o especifica os requisitos para um sistema 9001 2000 Requisitos de gest o de qualidade organizacional objetivando E 5 fornecer requisitos conhecidos de produtos e aumentar a satisfa o do cliente ISO IEC Engenharia de Software Este padrao fornece um modelo para a qualidade do 9126 Qualidade de Produto Parte 1 produto de software 1 2001 Modelo de Qualidade em rela o qualidade interna qualidade externa e qualidade em uso O modelo P S S S sob a forma de uma tax
205. ftware evoluiu de um ferramental especializado em solu o de problemas e an lise de informa es para um produto de ind stria Mas ainda temos problemas na constru o de software de alta qualidade no prazo e dentro do or amento O software programas dados e documentos dirigido a uma ampla variedade de tecnologias e aplica es continua a obedecer a uma s rie de leis que permanecem as mesmas h cerca de 30 anos O intuito da engenharia de software fornecer uma estrutura para a constru o de software com alta qualidade A partir do posicionamento de Pressman inferimos a necessidade de se manter uma documenta o padronizada e din mica que incorpore as melhores pr ticas e metodologias norteando em n vel global os rumos desta relativamente 12 nova ci ncia que desponta 1 6 Delimita o do tema Este trabalho tem como objetivo o estudo e divulga o do guia SWEBOK buscando a amplia o do seu uso entre os profissionais da rea de engenharia de software corroborando ainda para sua sedimenta o como principal ferramenta para padroniza o de conceitos no mundo 1 7 Metodologia de pesquisa Este trabalho foi realizado com base em pesquisas bibliogr ficas que serviram de fundamenta o a sua ideia principal a centraliza o de padroniza es Para isso o uso da internet para localiza o de informa es relevantes foi de crucial valor A pesquisa bibliogr fica justif
206. gem natural Pode conter suplementos em descri o formal ou semi formal Normalmente escrito em linguagem natural Pode conter suplementos em descri o formal ou semi formal A regra geral escolher nota es apropriadas que permitam uma descri o mais precisa e concisa Indicadores de qualidade vem sendo desenvolvidos e podem ser usados para relatar a qualidade da especifica o dos requisitos de software para outras vari veis de projeto custo aceita o desempenho cronograma reprodutibilidade Indicadores de qualidade da especifica o de um requisito imperativos diretivas frases fracas op es Indicadores de qualidade da ERS como um todo tamanho legibilidade estrutura do texto profundidade IEEE Std 830 padr o para ERS 2 1 3 1 6 Valida o de Requisitos Documentos devem ser revisados por stakeholders diferentes inclusive por representantes do cliente e do desenvolvedor Documentos de requisitos est o sujeitos mesma Ger ncia de Configura o que os demais documentos normal explicitar um ou mais pontos no processo de requisitos onde a valida o realizada Isso ajuda prevenir alguns problemas antes que recursos sejam alocados Valida o de requisitos diz respeito ao processo de examinar os documentos de requisitos para ter certeza que eles definem o software correto ou seja O software que faz o que o usuario espera que ele fa a 41 a Revis es de Requisitos
207. genharia de software Aqui o foco est no processo de medi o e o objetivo na implementa o e modifica o de processo O contexto afeta o relacionamento entre os processos e os resultados de processos Isto significa que esta rela o processo a processo depende do contexto do relacionamento Nem todo processo ter um impacto positivo em todos os resultados Por exemplo a introdu o de software pode reduzir os ensaios de esfor o e custo mas pode aumentar o tempo decorrido se em cada inspe o introduzir atrasos devido programa o de inspe o de grandes reuni es Vot93 Portanto prefer vel utilizar m ltiplos resultados de processos que s o importantes para o neg cio da organiza o Embora algum esfor o pode ser feito para avaliar o aproveitamento das ferramentas o principal recurso que deve ser geridos em engenharia de software o 158 pessoal Contudo as principais medidas de interesse s o aquelas relacionadas produtividade de equipes ou de processos por exemplo usando a medida de pontos de fun o produzidos por unidade de personeffort e seus respectivos n veis de experi ncia em engenharia de software em geral e tamb m nas tecnologias Os resultados de processo por exemplo podem ser qualidade do produto faltas por KLOC Kilo Lines of Code ou por PF Function Point manutenibilidade o esfor o para fazer um certo tipo de modifica o produtividade LOC Lines of Code ou Pontos de Fun
208. ger ncia de qualidade s o Sistemas de gest o da qualidade do 9000 2000 do ISO Fundamentos e Vocabul rio e Sistemas de gest o da qualidade do 9001 2000 do ISO Exig ncias Sistemas de gest o da qualidade do 9004 2000 do ISO Diretrizes para melhorias do Desempenho A sociedade americana para a qualidade identifica as seguintes reas do conhecimento t picos da avaria do primeiro n vel em seu esbo o em seu corpo para a certifica o de um coordenador da qualidade Desenvolvimento execu o e verifica o de sistemas da qualidade Planejando controlando e assegurando a qualidade do produto e do processo e Confiabilidade e gest o de riscos e Resolu o de problema e melhoria de qualidade M todos quantitativos 2 1 3 11 7 Ergonomia de software O campo de ergonomia definido pelo Comit T cnico da Ergonomia no ISO 159 como segue A ergonomia ou fatores humanos a disciplina cient fica relacionada com a compreens o das intera es entre o ser humano e os outros elementos de um sistema e a profiss o que aplica a teoria os princ pios os dados e os m todos ao projeto a fim de aperfei oar o desempenho do bem estar humano e do sistema total Uma lista de reas do conhecimento para a ergonomia como se aplica ao software proposto abaixo a Cogni o e Cognitivo Al raciocinando Aprendizagem de maquina e indu o da gram tica e M todos formais na ci ncia cognitiva Linguagem 196
209. gineering Component Based Design Configuration Control Board Configuration Management Capability Maturity Model Integration Commercial Off the Shelf Software Class Responsibility Collaborator card Directed Acyclic Graph Data Flow Diagram Experience Factory Engenharia de Sfotware Entity Relationship Diagram Functional Configuration Audit Function Point Functional Size Measurement Ger ncia de Configura o de Software Human Resources Management International Conference on Software Maintenance Initiating Diagnostic Establishing Acting Learning Interface Description Language International Council on Systems Engineering Knowledge Area Mean Time Between Failures Object Management Group Physical Configuration Audit Plan Do Check Act Pseudo Code and Program Design Language Guide to the Project Management Body of Knowledge Quality Improvement Paradigm Paradigma de Melhoria de Qualidade Structured Analysis and Design Tecnique Standard CMMI Appraisal Method for Process Improvement Software Configuration Control Board Software Engineering Evaluation Software Configuration Item Software Configuration Management SCMP SCR SCSA SEI SEPG SQA SQM SRET SRS TQM UML USNRC V amp V Y2K Software Configuration Management Plan Software Change Request Software Configuration Status Accounting Software Engineering Institute Software Engineering Process Group Software Quality Assurance Software Quality Ma
210. heiros de software e a outras tarefas segundo o m todo escolhido c Medi o de constru o In meras atividades de constru o e artefatos podem ser medidas incluindo desenvolvimento de c digo modifica o de c digo reutiliza o de c digo destrui o de c digo complexidade de c digo inspe o estat sticas de c digo a falhas e corrigir falhas esfor o e agendamento Estas medi es podem ser teis para prop sito de gerencia da constru o assegurar qualidade durante a constru o melhorar o processo de constru o bem como por outros motivos Ver a KA processo de engenharia de software para mais sobre medi es 2 1 3 3 3 Considera es pr ticas Constru o uma atividade na qual o software tem que se condicionar as restri es arbitrarias e ca ticas do mundo real e faz la precisamente Devido sua proximidade a restri es do mundo real constru o est mais orientada por considera es pr ticas do que algumas reas de conhecimento e a engenharia de software assemelhasse a esta rea de constru o a Design de Constru o Alguns projetos reservam mais aten o para o design de constru o outros em uma fase expl cita focam o plano Independente do momento alguns detalhes do design ocorrer o em n vel de constru o e este design de trabalho ser ditado pelas restri es im veis impostas pelo mundo real problemas que s o abordados pelo software Tal como trabalhador
211. ible IEEE Software March 1996 pp 23 26 Hum95 W Humphrey A Discipline for Software Engineering Addison Wesley 1995 Hum97 W S Humphrey Managing Technical People Innovation Teamwork and the Software Process Addison Wesley 1997 Hum99 W Humphrey An Introduction to the Team Software Process Addison Wesley 1999 Hut94 D Hutton The Change Agent s Handbook A Survival Guide for Quality Improvement Champions Irwin 1994 IEEE1044 93 IEEE Std 1044 1993 R2002 IEEE Standard for the Classification of Software Anomalies IEEE 1993 IEEE1061 98 IEEE Std 1061 1998 IEEE Standard for a Software Quality Metrics Methodology IEEE 1998 IEEE1074 97 IEEE Std 1074 1997 IEEE Standard for Developing Software Life Cycle Processes IEEE 1997 238 IEEE1219 98 IEEE Std 1219 1998 IEEE Standard for Software Maintenance IEEE 1998 IEEE1220 98 IEEE Std 1220 1998 IEEE Standard for the Application and Management of the Systems Engineering Process IEEE 1998 IEEE12207 0 96 IEEE EIA 12207 0 1996 ISO IEC12207 1995 Industry Implementation of Int Std ISO IEC 12207 95 Standard for Information Technology Software Life Cycle Processes IEEE 1996 IEEE12207 1 96 IEEE EIA 12207 1 1996 Industry Implementation of Int Std ISO IEC 12207 95 Standard for Information Technology Software Life Cycle Processes Life Cycle Data IEEE 1996 IEEE12207 2 97 IEEE EIA 12207 2 1997 Industry Implementation of Int Std ISO IEC 122
212. ica es da Descri o de Area Para o SWEBOK Este documento apresenta a vers o 1 9 das especifica es fornecidas pela Equipe Editorial ao Especialista de reas do Conhecimento quanto s Descri es de reas do Conhecimento do Guia do Corpo de Conhecimento de Engenharia de Software Vers o de Ironman Este documento come a apresentando especifica es dos conte dos da Descri o da reas do Conhecimento Os crit rios e as exig ncias s o propostos para divis es de t picos para a base l gica dessas divis es para a descri o sucinta dos t picos para selecionar materiais de refer ncia e para identificar reas do Conhecimento relevantes de Disciplinas Relacionadas Os documentos de entrada importantes tamb m s o identificados bem como explicado seus papeis dentro do projeto Quest es n o relacionados ao conte do como formato de submiss o e diretrizes de estilos tamb m s o discutidas 2 1 4 1 2 Crit rios e Exig ncias para Propor as Divis es de T picos As seguintes exig ncias e crit rios devem ser usados quando se propuser uma separa o de t picos dentro de uma dada rea do Conhecimento a Espera se que editores associados proponham uma ou possivelmente duas divis es complementares que sejam espec ficas sua rea do Conhecimento Os t picos encontrados em todos as divis es dentro de uma dada rea do Conhecimento devem ser id nticos b Espera se que essas divis es de t picos sejam raz
213. ica se por se tratar de tema que n o fora abordado no curso de especializa o e por se entender que algo de suma import ncia para a disciplina de engenharia de software Tal ferramenta SWEBOK deveria ser um dos temas principais a serem abordados pela sua riqueza de informa es que tem como uma de suas premissas manter se sempre atualizado 1 8 Estrutura do trabalho Este trabalho foi elaborado de acordo com os par grafos a seguir O Cap tulo 1 trata as raz es que motivaram a pesquisa a formula o do problema as exposi es do objetivo geral e dos objetivos espec ficos a justifica o do tema do trabalho e sua delimita o O Cap tulo 2 trata dos fundamentos te ricos para o trabalho seus aspectos e como formada sua estrutura No t pico Hist ria faz uma descri o de toda a origem da engenharia de software desde suas primeiras men es nos meios sociais at a data presente No t pico Estrutura de Descri o das KAs informado como o documento foi pensado de forma a resolver algum problema do mundo real Nos 13 t picos subsequentes s o detalhadas todas as reas do conhecimento na forma como elas ser o abordadas Tamb m informa a maneira como deve ser compreendida cada KA e uma breve descri o dos seus objetivos Os t picos dos ap ndices A B C e D referem se aos suplementos e informa es necess rias para a manuten o do pr prio guia tais como crit rios conselhos padr es e taxonomi
214. icabilidade Nesse ponto os processos de ciclo de vida de software s o avaliados e a parte mais apropriada dado a natureza do projeto o seu grau de novidade a sua complexidade funcional e t cnica as suas exig ncias de qualidade e assim por diante selecionada Onde relevante o pr prio projeto ent o planejado na forma da decomposi o hier rquica de tarefas os resultados finais de cada tarefa s o especificados e caracterizados em termos de qualidade e outros atributos de acordo com determinadas exig ncias e esfor o detalhado hor rio e pre o a estimativa empreendida Os recursos ent o s o alocados s 137 tarefas para otimizar produtividade de pessoal no individual equipe e n veis organizacionais equipamento e utiliza o de materiais e ader ncia para planejar A ger ncia de riscos detalhada empreendida e o perfil de riscos do projeto discutido e aceito por todas as partes relevantes interessadas Na ger ncia de qualidade de software abrangente os processos s o determinados como parte do processo de planejamento na forma de procedimentos e responsabilidades por software asseguramento da qualidade verifica o e valida o revistas e auditorias ver a Qualidade de Software KA Como um processo iterativo vital que os processos e responsabilidades pela ger ncia de plano cont nuo a an lise e a revis o sejam tamb m claramente afirmadas e aceitas a Planejamento de Processo Sel
215. ion 1998 SEIO1 Software Engineering Institute Capability Maturity Model Integration v1 1 2001 em SEL96 Software Engineering Laboratory Software Process Improvement Guidebook NASA GSFC Som05 Sommerville Software Engineering Seventh ed Addison Wesley 2005 Som97 Sommerville and P Sawyer Requirements engineering A Good Practice Guide John Wiley and Sons 1997 Chap 1 2 Sti99 H Stienen Software Process Assessment and Improvement 5 Years of Experiences with Bootstrap Tha97 R H Thayer ed Software Engineering Project Management IEEE Computer Society Press 1997 VIM93 ISO VIM International Vocabulary of Basic and General Terms in Metrology ISO 1993 You01 R R You Effective Requirements Practices Addison Wesley 2001 Zhu97 H Zhu P A V Hall and J H R May Software Unit Test Coverage and Adequacy Har98 D Harel and M Politi Modeling Reactive Systems with Statecharts The Statemate Approach McGraw Hill 1998 Hen99 S M Henry and K T Stevens Using Belbin s Leadership Role to Improve Team Effectiveness An Empirical Investigation Journal of Systems and Software vol 44 1999 pp 241 250 Her98 J Herbsleb Hard Problems and Hard Science On the Practical Limits of Experimentation IEEE TCSE Hoh99 L Hohmann Coaching the Rookie Manager IEEE Software January February 1999 pp 16 19 Hsi96 P Hsia Making Software Development Vis
216. istro do teste para identificar quando um teste foi conduzido quem executou o teste que configura o de software foi a base para o teste e outras informa es de identifica o relevantes Os resultados da an lise inesperados ou incorretos podem ser gravados em um sistema de relat rio de problemas os dados que formam a base para uma posterior depura o e repara o de problemas que foram observados como falhas durante o teste Tamb m as anomalias n o classificadas como falhas poderiam ser documentadas no caso de se mostrarem posteriormente mais s rias do que pensado inicialmente Os relat rios de teste tamb m s o uma entrada ao processo de pedido de ger ncia da mudan a ver rea de conhecimento gerenciamento de configura o de software sub t pico 3 de controle de configura o do software Procurando por defeito Kan99 c6 Os fracassos observadas durante o teste s o mais frequentemente devido a falhas ou defeitos no software Tais defeitos podem ser analisados para determinar quando foram introduzidos no software que tipo de erro fez com que eles fossem criados requisitos mal definidos declara o incorreta de vari veis estouro de mem ria erro na 91 sintaxe de programa o por exemplo e quando poderiam primeiramente ter sido observados no software A informa o da procura por defeito usada para determinar que aspetos da engenharia de software precisam melhorar e como foram eficazes as an
217. ito e para articular as proposi es que ela incorpora e as restri es que a ela s o impostas A caracteriza o pode ser em termos de processos organizacionais dom nios de aplica es tecnologia e fronteiras organizacionais Um modelo de processo organizacional tamb m tipicamente um elemento de caracteriza o da unidade organizacional ISO 15939 02 5 2 1 145 Identifique as informa es necess rias Informa es necess rias s o baseadas nas metas restri es riscos e problemas da unidade organizacional Elas podem ser derivadas a partir do neg cio da organiza o regulamenta o e ou objetivos do produto Elas devem ser identificadas e priorizadas ent o um subconjunto a ser tratado deve ser selecionado e seus resultados documentados comunicados e revisados pelos stakeholders ISO 15939 02 5 2 2 Selecione as medidas Medidas candidatas devem ser selecionadas com v nculos claros s informa es necess rias Medidas devem ent o ser selecionadas baseado nas prioridades das informa es necess rias e outros crit rios tais como custo da coleta grau de ruptura do processo durante a coleta facilidade de an lise facilidade de obten o de acur cia consist ncia dos dados e outros mais ISO 15939 02 5 2 3 e Ap ndice C Defina os procedimentos de coleta de dados an lise e relat rios Isso engloba os procedimentos de coleta e cronograma armazenamento verifica o an lise divulga o de relat
218. ito ser usado aqui e um indesej vel efeito observado no servi o entregue do sistema o qual ser chamado um fracasso Testes podem revelar fracassos mas s o as falhas que podem e devem ser removidas Por m deveria ser reconhecido que a causa de um fracasso n o pode ser sempre inequivocamente identificado N o existe um crit rio te rico para determinar definitivamente que falta causou o fracasso observado Poderia ser dito que era a falta que tinha de ser modificada para remover o problema mas outras modifica es poderiam ter trabalhado bem da mesma maneira Para evitar ambiguidades alguns autores preferem falar de entradas causando fracassos Fra98 em vez de falhas quer dizer esses conjuntos de entradas que causam um fracasso a Crit rios de sele o de testes crit rios de sufici ncia de Teste ou regras de parada Um crit rio de sele o de testes um meio de decidir qual conjunto satisfat rio de casos de testes deve ser Um crit rio de sele o de testes pode ser usado para selecionar os casos de testes ou checar qual suite de testes adequada quer dizer decidir se o teste pode ser parado Veja tamb m as termina es do sub t pico no t pico 5 1 Considera es pr ticas Zhu97 s1 1 Wey83 Wey91 Zhu97 b Efetividade do teste Objetivos de teste Testar a observa o de uma amostra de execu es do programa Sele es de amostras podem ser guiadas por diferentes objetivos isso somente na luz
219. l de Estimativa de custos de manuten o AN TESTE Medi o de manuten o de software AN 1 Fundamentos de Teste de software papos cs soc menarie Terminologia relacionada a testes C Processos de manuten o c Assuntos chave AP Atividades de manuten o AP Rela es de testes com outras C 4 T cnicas para manuten o atividades Compreens o d programa AN 2 N veis de teste Engenharia reversa C Alvo de teste AP Obistivos ie tE AP Ger ncia de Configura o de Software 3 T cnicas de teste GCS Baseada na intui o e na experi ncia do AP Reparti o dos T picos N vel de engenheiro Taxonomia Baseada na Especifica o s 1 Gerenciamento dos processos de GCS C digo de barras AP Contexto organizacional para GCS C Falhas baseadas ai Restri es e orienta es para GCS C U50 baseadas AP Planejamento para GCS Baseadas na natureza da aplica o Ar GCS organiza o e responsabilidades AP Selecionando e combinando t cnicas AP GCS fontes e programa o AP 230 Reparti o dos T picos N vel de Reparti o dos T picos N vel de Taxonomia Taxonomia Ferramenta de sele o e implementa o AP Auditoria de configura o de software C Controle de Vendas contratos C f sico Controle de interface C Auditorias em processo de uma base de C Plano de gerenciamento de C software configura o de software Inspe o de gerenciamento de configura o de 6 Entrega e gerenciamento de lib
220. lementadas simultaneamente necess rio fornecer um meio para controlar quais SCRs s o incorporadas em vers es de software espec fico e linhas de base Como parte do encerramento do 125 processo de mudan a completou mudan as podem sofrer auditorias de configura o e verifica o da qualidade de software Isto inclui assegurar que apenas as altera es aprovadas foram feitas O processo de solicita o de altera o descrita acima normalmente o documento SCM e outras informa es de aprova o para a mudan a A implementa o efetiva de uma mudan a suportada pela capacidade biblioteca de ferramentas que fornecem o gerenciamento de vers es e suporte reposit rio de c digo No m nimo essas ferramentas fornecem recursos de controle de vers o Check In Check Out e associados Ferramentas mais poderosas podem apoiar o desenvolvimento paralelo e ambientes geograficamente distribu dos Essas ferramentas podem se manifestar como separar aplica es especializadas sob o controle de um grupo de SCM independente Eles tamb m podem aparecer como uma parte integrada do ambiente de engenharia de software Finalmente podem ser t o elementar como um sistema rudimentar de mudan a de controle equipado com um sistema operacional c Desvios e Dispensas As restri es impostas a um esfor o de engenharia de software ou com as especifica es produzidas durante as atividades de desenvolvimento podem conter disposi es que n
221. lises e testes precedentes P M 4 i EFEN a pi a RY i 0 Teste alfa e beta o da confiabilidade L UT Ped Bes Ber Frat P o o ema a EN RE Teste versus provas de exatid o e verifica o formal Ts Teste versusdepura o gt OOo Teste versus programa o 0 OS 2 1 alvo do teste ds Teste de un dade a Teste de sistema l 2 2 Objetivos de teste S o Teste de aceita o e qualifca o S OoOo Teste de instala o S Oo ES Teste de dad ste de exatid o PA z baa Es a nes Es EH mM Ni Teste amp do de desenvolvimento Figura 16 T picos x refer ncias 4 PEL RUT ee FRE BREE BL ABSIT ETRE EL eT Eee eth RRR UT UTA TTT e LETTE LETTE TTC Ta 92 Odd RIR L ee eee TET Te Andlese do valor limite Tabeis ce decis o Se estado fino Crit rios comtrote de tiuxo baseados Baseada em Teste aleat rio m 3 2 T cnicas baseadas na RO picos x refer ncias 5 Figura 17 T EF i fle URL CEEE CRECHE PAUL ALLTEL AUT EE ee RER T 1 ae AB Oo Hi E LHE PUI BLL Ge teste da confiabilidade Modelos de crescimento da confiabilidade e efic cia relativa das diferentes t cnicas Teste de Medidas de cobertura efic cia Contagem da muta o Equipe de teste intema versus independente A estima o do custo esfor o e outras medidas do processo Reuso de teste e
222. liza d exemplos infere interpreta par frases prev reescreve resume traduz Aplica o Usa um conceito em uma situa o nova ou usa espontaneamente de uma abstra o Aplica se o que foi aprendido em sala de aula em situa es Aplica se muda calcula constr i demonstra descobre manipula modifica opera prev prepara produz se relaciona shows resolve usa 221 N vel da Taxonomia de Bloom Palavras chave Associadas novas no trabalho An lise Separa o material ou conceitos em componentes de forma que sua estrutura organizacional pode ser entendida Distingue entre fatos e infer ncias Analisa divide compara contrasta diagramas desconstr i diferencia discrimina diferencia identifica ilustra infere define relaciona seleciona separa S ntese Cria uma estrutura ou padr o a partir de elementos diversos Coloca as pe as para formar um todo com nfase na cria o de um novo significado ou estrutura Categoriza combina compila comp e cria inventa projeta explica gera modifica organiza planeja se recicla reconstr i se refere se reorganiza revisa reescreve resume diz escreve Avalia o Faz julgamentos sobre o valor das ideias ou materiais Avalia compara conclui os contrastes critica critica defende descreve discrimina avalia explica interpreta justifica diz resume su
223. m do Instituto de Gerenciamento de Projetos Project Management Institute PMI O conhecimento geralmente aceito aplica se maior parte de projetos na maior parte do tempo e o consenso comum valida o seu valor e a efic cia Geralmente Aceito 5 Estabelecido tradicionais praticas D recomendadas por v rias Oerganizacoes A p o s c Roe q E A a eee D a u Avan ado Pesquisa Bay wee Praticas inovadoras testadas e utilizadas aa por algumas organiza es e conceitos sendo desenvolvidos e testados em IC b organiza es de pesquisa Figura 3 Categorias de Conhecimento Contudo o termo geralmente aceito n o implica que o conhecimento indicado deva ser uniformemente aplicado a todas as tentativas de engenharia de software as necessidades de cada projeto determinam isto mas implica que engenheiros de software competentes e capazes devam ser equipados com este conhecimento para potencial aplica o Mais precisamente o conhecimento geralmente aceito deve estar inclu do no material de estudo do exame de licen a de engenharia de software que graduados deveriam prestar depois de quatro anos da experi ncia de trabalho Embora este crit rio seja espec fico ao estilo de educa o dos Estados Unidos e n o necessariamente se aplique a outros pa ses foi considerado til No entanto as duas defini es de conhecimento geralmente aceito 19 devem ser vistas como complementares 2 1 2 4 Es
224. ma o profissional As reas de conhecimento de modo geral est o fortemente concisas A KA de Requisitos de software no seu item de elicita o de requisitos apresenta um conjunto de regras para se obter os dados necess rios ao desenvolvimento de software A KA Design de Software mostra as v rias terminologias encontradas para o design como D Design PF Design e I Design todas com diferentes conceitos e atua es para diferentes objetivos Na KA Constru o de Software o princ pio de reutiliza o de software mostra que o conceito bem mais que criar bibliotecas de recursos busca se tamb m a integra o dos processos de reutiliza o com atividades no ciclo de vida do software A rea de conhecimento Teste de Software trouxe uma nova abordagem de testes onde n o se pensa em testes ap s a conclus o do produto mas sim em todo o processo de desenvolvimento e manuten o A KA Manuten o de Software oferece a possibilidade de se gerir um sistema e todas as realidades inerentes a ele como aspectos de hardware software e firmware entre outros Temos na Ka Ger ncia de Engenharia de Software os mecanismos necess rios para a administra o de todos os pontos relativos engenharia de software e suas especificidades Na KA Processo de Engenharia de Software o foco est onde mudan as de processos ou de tecnologia s o inicialmente introduzidas atrav s da melhoria de processos ou produtos A rea de conhecimento Ferramentas e M
225. medida pode igualmente ser usada para aperfei oar o planejamento e execu o dos testes A ger ncia de teste pode usar diversas medidas de processos 84 para monitorar o progresso As medidas relativo ao processo do teste para finalidades de ger ncia s o consideradas no t pico 5 1 considera es pr ticas a Avalia o do programa sob o teste e Medidas do programa para auxiliar no planejamento e no teste do projeto Bei90 c7s4 2 Jor02 c9 Ber96 IEEE982 1 88 As medidas baseadas no tamanho do programa por exemplo linhas de c digo fonte ou pontos de fun o ou na estrutura do programa como a complexidade s o usadas para guiar o teste As medidas estruturais podem igualmente incluir medidas entre os m dulos de programa nos termos da frequ ncia com que os m dulos chamam um ao outro IEEE982 1 98 e Tipos classifica o e estat sticas de falha Bei90 c2 Jor02 c2 Pfl01 c8 Bei90 IEEE 1044 93 Kan99 Lyu96 A literatura do teste rica nas classifica es e nas taxonomias das falhas Para fazer o teste mais efetivo importante saber que tipos de falhas poderiam ser encontrados no software sob o teste e a frequ ncia relativa com que estas falhas ocorreram no passado Esta informa o pode ser muito til em fazer predi es de qualidade assim como para a melhoria do processo Mais informa o pode ser encontrada na rea de conhecimento qualidade de software no t pico 3 2 carateriza o do defeito
226. mento de projetos engenharia de sistemas confian a e seguran a A an lise e o reagrupamento das cole es de padr es exp em as rela es chave entre padr es Mesmo embora o Guia do Corpo de Conhecimento de Engenharia de Software n o seja um projeto de desenvolvimento de padr es de engenharia de software por si s um cuidado especial ser tomado em todas as partes do projeto quanto compatibilidade do Guia com o atual IEEE e com a Cole o de Padr es de Engenharia de Software ISO e Gloss rio Padr o IEEE de Terminologia de Engenharia de Software std 610 12 1990 IEEE 1990 A hierarquia de refer ncias de terminologia o Dicion rio Acad mico de Merriam Webster 10 ed IEEE std 610 12 e novas defini es propostas se necess rio f Tecnologia da Informa o Processos de Ciclo de Vida de Software Internacional std ISO IEC 12207 1995 E 1995 Este padr o considerado o padr o chave quanto defini o do processo de ciclo de vida e foi adotado por dois corpos de padroniza o principais da engenharia de software ISO IEC JTC1 SC7 e o Comit de Padr es de Engenharia de Software da Sociedade de Computa o IEEE Tamb m foi indicado como o padr o fundamental em torno o qual o Comit de Padr es de Engenharia de Software SESC est harmonizando atualmente a sua cole o inteira de padr es Este padr o foi uma entrada chave vers o Straw Man Mesmo embora n o tenhamos inten o que o Gui
227. mento dos projetos dos desenvolvedores O planejamento da manuten o de Software deve come ar com a decis o de desenvolver um novo sistema e dever considerar objetivos de qualidade IEEE1061 98 Um conceito de documento dever ser desenvolvido seguido de um plano de manuten o O conceito de documento de manuten o 15014764 99 s7 2 deve abordar e O mbito da manuten o de software e Adapta o do processo de manuten o de software e Identifica o da organiza o de manuten o do software Uma estimativa dos custos de manuten o de software 110 O pr ximo passo desenvolver um software correspondente ao plano de manuten o Este plano dever ser elaborado durante o desenvolvimento de software e deve especificar como os usu rios ir o solicitar as modifica es ou relatar os problemas de software O planejamento da manuten o de Software de Pig97 abordado no IEEE 1219 IEEE 1219 98 e ISO IEC 14764 IS014764 99 ISO IEC14764 fornece diretrizes para um plano de manuten o Por fim ao mais alto n vel a organiza o da manuten o ter de realizar atividades de planejamento empresarial or amental financeira e recursos humanos tal como todas as outras divis es da organiza o A gest o de conhecimentos necess rios para o fazer pode ser encontrada nas Disciplinas de Engenharia de Software Relacionadas ao final do cap tulo Gerenciamento de configura o de Software Art88 c2 c10 IEEE12
228. mo disciplinas aplicadas por engenheiros de software omitida Segundo desenvolvida e aprovada por um processo consensual para que possa apenas gravar informa o para que a concord ncia em grande escala possa ser obtida 213 2 1 4 3 Ap ndice C 2 1 4 3 1 Distribui o dos Padr es de EG da IEEE ISO para as KAs do SWEBOK O ap ndice C do SWEBOK fornece uma lista com os padr es de engenharia de software produzidos pelo IEEE e ISO IEC JTC1 SC7 bem como alguns padr es selecionados a partir de outras fontes Para cada padr o o seu n mero e o t tulo fornecido Al m disso a coluna Descri o fornece o material extra do do resumo ou outro material da norma introdut ria Cada uma das normas mapeado para as reas de conhecimento do Guia SWEBOK Em alguns casos como o vocabul rio de normas padr o do mesmo se aplica a todos os KAS em tais casos aparece um X em cada coluna Na maioria dos casos cada norma tem uma aloca o for ada a uma nica e principal rea de conhecimento esta atribui o est marcada com um P Em muitos casos existem distribui es secund rias de KAs estas s o marcadas com um S A lista ordenada por n mero de norma independentemente da sua categoria IEEE ISO etc 214 Q a v9 Re ol wae na 9 nao og ES pE N mero E sd SE 29 44 42 28 29 959 4508 4505 25 gadis Nome padr o Descri o F 5 e 5 4 3 3 a
229. mo segue Lie78 Dor02 v1c9s1 5 IEEE1219 98 s3 1 1 3 1 2 83 1 7 A 1 7 ISO14764 99 s4 1 84 3 s4 10 s4 11 s6 2 Pig97 c2s2 3 e Manuten o corretiva modifica o reativa realizada ap s a entrega de produtos de software para corrigir problemas detectados 98 e Manuten o Adaptativa Altera o de um produto de software realizada ap s a entrega e visa manter o software utiliz vel em um produto modificado ou que fora alterando seu ambiente e Manuten o Perfectiva Altera o de um produto de software ap s a entrega para melhorar o desempenho ou capacidade de manuten o Manuten o Preventiva Altera o de um produto de software ap s a entrega para detectar e corrigir latente falhas no software A ISO IEC 14764 classifica a manuten o adaptativa e perfectiva como acess rias Tamb m re ne as categorias de manuten o preventiva e corretiva na categoria de corre o conforme mostrado na Tabela 1 A manuten o preventiva a mais nova categoria a maior parte das vezes realizada sobre produtos de software onde a seguran a cr tica 2 1 3 5 2 Problemas chave na manuten o de software Um n mero de problemas chave deve ser tratado para garantir a manuten o efetiva do software importante entender que manuten o de software fornece desafios t cnicos e gerenciais nicos para engenheiros de software Tentar achar uma falha em software contendo 500 mil linhas de c digo que o engenheiro de softw
230. na SNA ERTEKE cera esa KEELEKE danada engana endeared 210 21 42 2 taken Ide a A a E A A a a dada A en 210 2 1 4 2 3 O Processo de Evolu o 2 1 4 2 4 Mudan as AntecipadasS css isto sprnrcese a a aaa aa ego Soa adia ne aos ga e E sabes ada Loves al aaa eases 213 ZVA Ap ndice E mas its oar ate eet nea ee nee aah T a an EA SR SD E Ea SUAVE ao aan na we 214 2 1 4 3 1 Distribui o dos Padr es de EG da IEEE ISO para as KAs do SWEBOK cececceeeeeeeeeeeeeeeeeee 214 2 1 4 4 Apendice D 2 seg sa atten DADE A tiveness abate panei da sa 226 2 1 4 4 1 Classifica o dos Temas Segundo a Taxonomia de Bloom rita 226 BD odela eiU Co aa EE E E T E E EE EE AE EEA AAEE A A E TEE AE E 234 31Apresentacaodosiresultados ceinen ea a a N A AE Anata N AE a Aga AE AEA Rana 234 3 2 Principais ContriDUI ES iis a ah ADL ASA a a aa aose Via oli a oak 235 33 Aspectos positivos e NegaliVOS s cus tardsasrasonsesas orador derea aaie pastes Adeeb as sd ott NEA SE eo ai iaaa aaa iE 235 ER A UE IKORO LO ETO Ee MESA AAEE EE E E T E do cuucersurtectsdecdeuttcddenee 236 Bibliografia Lista de abreviaturas ADL BABOK CASE CBD CCB CM CMMI COTS CRC DAG DFD EF EG ERD FCA FP FSM GCS HRM ICSM IDEAL IDL INCOSE KA MTBF OMG PCA PDCA PDL PMBOK QIP SADT SCAMPI SCCB SCE SCI SCM Architecture Description Languages Guide to the Business Analysis Body of Knowledge Computer Aided Software En
231. nagement Software Reliability Engineered Testing Software Requirement Specification Total Quality Management Unified Modeling Language U S Nuclear Regulatory Commission Verification and Validation Year 2000 Lista de figuras Figura 1 Figura 2 Figura 3 Figura 4 Figura 5 Figura 6 Figura 7 Figura 8 Figura 9 Figura 10 Figura 11 Figura 12 Figura 13 Figura 14 Figura 15 Figura 16 Figura 17 Figura 18 Figura 19 Figura 20 Figura 21 Figura 22 Figura 23 Figura 24 Figura 25 Figura 26 Figura 27 Figura 28 Figura 29 Figura 30 Figura 31 reas de Conhecimento KA do SWEBOK Disciplinas relacionadas Categorias de Conhecimento Disciplinas relacionadas com engenharia de software Primeiras 5 reas do conhecimento ltimas 6 reas do conhecimento T picos dos Requisitos de software Vis o simplista Vis o realista T picos para Design de Software T picos x refer ncias 1 T picos x refer ncias 2 T picos x refer ncias 3 Reparti o dos t picos para o rea de conhecimento de constru o de software T picos para rea de Conhecimento Teste de Software T picos x refer ncias 4 T picos x refer ncias 5 T picos x refer ncias 6 T picos da Manuten o de software Atividades do Processo de Manuten o Processo de Manuten o de Software T picos da KA Ger ncia de Engenharia de Software T picos para a KA Processo de Engenharia de Software Rela o ent
232. nd Sommerville Requirements Engineering Processes and Techniques John Wiley and Sons 2000 Lou95 P Loucopulos and V Karakostas Systems Requirements Engineering McGraw Hill 1995 Pfl01 S L Pfleeger Lyu96 M R Lyu Handbook of Software Reliability Engineering Mc Graw Hill IEEE 1996 Chap 2s2 2 5 7 McF96 B McFeeley IDEAL A User s Guide for Software Process Improvement Software Engineering Moi98 D Moitra Managing Change for Software Process Improvement Initiatives A Practical Experience Based Approach Mus99 J Musa Software Reliability Engineering More Reliable Software Faster Development and Testing McGraw Hill 1999 OMG02 Object Management Group Software Process Engineering Metamodel Specification 2002 em http www omg org docs formal 02 11 14 pdf Per95 W Perry Effective Methods for Software Testing John Wiley amp Sons 1995 Chap 1 4 9 10 12 17 19 21 Pfl01 S L Pfleeger Software Engineering Theory and Practice second ed Prentice Hall 2001 Pre04 R S Pressman Software Engineering A Practitioner s Approach sixth ed McGraw Hill 2004 Rei02 D J Reifer ed Software Management IEEE Computer Society Press 2002 Chap 1 6 7 12 13 Rob99 S Robertson and J Robertson Mastering the Requirements Process Addison Wesley 1999 San98 M Sanders The SPIRE Handbook Better Faster Cheaper Software Development in Small Organisations European Commiss
233. necess rias para estabelecer processos espec ficos em escala organizacional ou procedimentos para tais tarefas de engenharia de software como projeto implementa o estimativas monitoramento e informes relatorios Tais pol ticas s o essenciais para a ger ncia efetiva e de longo termo da engenharia de software pela defini o de uma base consistente sobre a qual analisar a performance passada e implementar as melhorias por exemplo Outro aspecto importante do gerenciamento a gest o de pessoal pol ticas e procedimentos para contratar treinar e motivar pessoal e mentalizar o desenvolvimento da carreira s o importantes n o somente no n vel do projeto mas tamb m no sucesso de longo prazo de uma organiza o Pessoal de engenharia de software pode ter treinamento nico ou gerenciamento das mudan as de pessoal por exemplo mantendo a atualiza o num contexto onde a tecnologia subjacente sofre mudan as r pidas e cont nuas Ger ncia de comunica o tamb m muitas vezes mencionada como um aspecto despercebido por m importante de performance dos indiv duos num campo onde o entendimento preciso das necessidades do usu rio e dos requisitos e projetos complexos necess rio Finalmente a ger ncia de portf lio que a capacidade de ter uma vis o geral n o somente do conjunto de software em desenvolvimento mas tamb m do software j em uso em uma organiza o necess ria Al m do mais reuso de software o
234. nfigura o analisa o software sob as v rias configura es espec ficas teste de usabilidade Pfl01 c9s8 3 Este processo avalia o quanto f cil para 78 que os utilizadores finais usem e aprendam o software incluindo a documenta o de usu rio como efetivamente o software funciona no apoio de tarefas do usu rio e finalmente sua habilidade de se recuperar de erros do usu rio e teste dirigido de desenvolvimento Bec02 O teste dirigido de desenvolvimento n o uma t cnica de teste por si s promovendo o uso de testes como um substituto para um documento de especifica o de requisitos como uma verifica o independente se o software implementou corretamente os requisitos 2 1 3 4 3 T cnicas de Teste Um dos objetivos do teste revelar tanto potencial para a falha como poss vel e muitas t cnicas foram desenvolvidas para fazer isso que tentam parar o programa rodando um ou v rios testes esbo ados das classes identificadas de execu es julgadas equivalentes O princ pio fundamental que a base de tais t cnicas ser t o sistem tico como poss vel em identificar um conjunto representativo de comportamentos do programa por exemplo considerando subclasses do dom nio de entrada cen rio estados e fluxo de dados dif cil encontrar uma base homog nea para classificar todas as t cnicas e essa usada aqui deve ser vista como um compromisso A classifica o baseada em como os testes s o
235. nsiderado como um t pico de valida o 2 1 3 1 5 Especifica o de Requisitos Na maioria das engenharias o termo especifica o refere se a atribui o de valores num ricos ou limites para o produto de metas do projeto Sistemas f sicos t picos possuem um n mero relativamente pequeno desses valores Software t pico possui um grande n mero de requisitos e a nfase repartida entre executar a quantifica o num rica e gerenciar a complexidade da intera o entre um grande n mero de requisitos Assim no jarg o de engenharia de software uma Especifica o de Requisitos de Software tipicamente refere se a produ o de um 39 documento ou seu equivalente eletr nico que possa ser sistematicamente revisado avaliado e aprovado Para sistemas complexos envolvendo substanciais componentes n o software pelo menos tr s documentos s o produzidos Defini o do Sistema Requisitos do Sistema e Requisitos do Software Nos sistemas simples apenas o terceiro requerido a Documento de Defini o do Sistema Tamb m denominado Documento de Requisitos do Usu rio ou Conceitos de Opera es Registra num alto n vel os requisitos do sistema Destina se aos clientes e usu rios do sistema ou seus representantes Define requisitos funcionais e n o funcionais do sistema em alto n vel seus objetivos gerais o ambiente alvo suas restri es e pressupostos Ponto de vista Dom nio da aplica
236. ntir que o projeto tenha xito em tempo oportuno e eficaz em termos de custos usando por exemplo um requisito capacidade matriz Isto muitas vezes necessita alguma estimativa aproximada de esfor o e pre o baseado em m todos apropriados por exemplo informa o de perito e analogia t cnica Pre04 c6 Som05 c6 c Processo para An lise e Revis o de Requisitos Dada a inevitabilidade da mudan a fundamental que o acordo entre as partes interessadas seja realizado no in cio Para isso as exig ncias e o acordo devem ser revisados por exemplo atrav s de mudan as na gest o dos procedimentos Isto implica claramente que os requisitos n o ser o gravados na pedra mas podem e devem ser revistos em pontos como o processo se desdobra por exemplo na revis o de desenhos revis o de gerenciamentos Se mudan as s o aceitas ent o alguma forma de rastreabilidade an lise de risco ver t pico 2 5 Gest o de Riscos deveria ser utilizada para aferir o impacto dessas mudan as A gest o de abordagem das mudan as deveria ser igualmente til se na hora de analisar o resultado do projeto o escopo e requisitos formam uma base para a avalia o do sucesso Som05 c6 Ver tamb m as subareas de configura o de controle de software em Software Configuration Management KA 2 1 3 7 2 Planejamento de Projeto de Software O processo de planejamento iterativo informado pelo alcance e exig ncias e pelo estabelecimento de prat
237. nvolvedor de software O contato precoce com os desenvolvedores ajuda a reduzir os esfor os de manuten o do mantenedor Em alguns casos o engenheiro de software pode n o ser encontrado ou se mudou para outras tarefas o que cria um desafio adicional para os mantenedores Os mantenedores devem ter os produtos do desenvolvimento como os c digos ou documenta o por exemplo e mant los ou evolu los progressivamente ao longo do ciclo de vida do software Pfl01 c11s11 2 c Necessidade da manuten o A manuten o necess ria para assegurar que o software continue a satisfazer os requisitos dos usu rios A manuten o aplic vel a qualquer software desenvolvido utilizando o ciclo de vida modelo por exemplo em espiral O sistema 96 modificado devido s a es de mudan as corretivas e n o corretivas A sua manuten o deve ser realizada a fim de Pig97 c2s2 3 Tak97 c1 e Corrigir falhas Melhorar o design Implementar melhorias e Interface com outros sistemas e Adaptar programas para que diferentes hardware software sistema de recursos e de telecomunica es possam ser utilizados e Migrar software legado Aposentar software As atividades de manuten o compreender o quatro caracter sticas principais de acordo com Pfleeger Pfl01 Manter o controle sobre o software no dia a dia das fun es Manter o controle sobre as modifica es de software e Aperfei oar fun es existentes
238. o veis n o perfeitas O Guia do Corpo de Conhecimento de Engenharia de Software visto definitivamente como um esfor o multif sico e muitas itera es dentro de cada fase bem como m ltiplas fases ser o necess rias para melhorar continuamente essas divis es c A divis o proposta de t picos dentro de uma rea do Conhecimento deve 199 decompor o subconjunto do Corpo de Conhecimento de Engenharia de Software que geralmente aceito Veja abaixo uma discuss o mais detalhada disto d A divis o proposta de t picos dentro de uma rea do Conhecimento n o deve presumir dom nios de aplica o espec ficos necessidades negociais tamanhos das organiza es estruturas organizacionais filosofias de ger ncia modelos de ciclo de vida de software tecnologias de software ou m todos de desenvolvimento de software e A divis o proposta de t picos tanto quanto poss vel deve ser compat vel com v rias escolas do pensamento dentro da engenharia de software f A divis o proposta de t picos dentro das reas do Conhecimento deve ser compat vel com a divis o da engenharia de software geralmente encontrado na ind stria e na literatura sobre engenharia de software e padr es g Espera se que a divis o proposta de t picos seja t o inclusiva quanto poss vel Julga se que melhor sugerir t picos demasiadamente e descart los do que fazer ao contr rio h Espera se que os Editores Associados das
239. o a totalidade das atividades necess rias para fornecer o melhor custo benef cio ao suporte de software As atividades s o realizadas durante a fase pr entrega bem como durante o per odo ap s a entrega As atividades pr entrega incluem o planejamento para as opera es p s entrega opera es estas de manuten o log stica e de determina o de transi o de atividades As atividades pr entrega incluem modifica o de software forma o e opera o da interface de suporte A rea de conhecimento de Manuten o de Software est relacionada a todos os outros aspectos da engenharia de software Portanto essa descri o de rea de conhecimento est ligada a todos os outros cap tulos do Guia Reparti o dos t picos de Manuten o de software A reparti o dos t picos da rea de conhecimento de Manuten o de Software apresentada na Figura 19 94 Manuten o de Sofiware I Fundamentos da Manuten o de Software Quest es chave na Manuten o de Software i 3 j L Processo de Manuten o T cnicas para Manuten o Defini es e Tecnologia Natureza da Manuten o Necessidade de Manuten o Maioria dos Custos de Manuten o Quest es T cmcas Quest es gerenciais Estima o de Custos de Manuten o Medi o de Manuten o de Software Processos de Manuten o Atividades de Manuten o gt Compreens o do Prog
240. o aprendizado organizacional e melhoram os empreendimentos veja tamb m a KA Processo de Engenharia de Software 2 1 3 7 6 Mensura o Medi o de Engenharia de Software A import ncia da mensura o e sua fun o nas melhores pr ticas de gerenciamento vastamente reconhecida e assim sua import ncia tende a crescer nos anos vindouros Mensura o efetiva tem se tornado uma das pedras fundamentais da maturidade organizacional Termos chave na medi o de software e nos m todos de medi o tem sidos definidos na ISO 15939 02 com base no vocabul rio ISO internacional de mensura o ISO93 Contudo leitores ir o encontrar diferen as de terminologia na literatura por exemplo o termo m trica algumas vezes usado no lugar de medidas Este t pico segue o padr o internacional ISO IEC 15939 o qual descreve um processo que define as atividades e tarefas necess rias para implementar um processo de mensura o de software bem como inclui um modelo de informa es 144 de mensura o a Estabele a e Sustente o Compromisso de Medi es Aceite as exig ncias por mensura es medi es Cada empreendimento de medi o deve ser guiado por objetivos organizacionais e orientado por um conjunto de requisitos de medi es estabelecidos pela organiza o e pelo projeto Por exemplo um objetivo organizacional deve ser ser o primeiro no mercado com novos produtos Fen98 c3 c13 Pre04 c22 Isto por sua vez poderi
241. o de um projeto de engenharia de software Mensura o da engenharia de software a qual aborda o desenvolvimento e implementa o efetiva de programas de mensura o nas organiza es de engenharia de software IEEE 12207 0 96 A estrutura de t picos para a KA de Ger ncia de Engenharia de Software mostrada na Figura 22 135 Ger ncia de Engenharia de Software I I l l i Inicia o e Planejamento Formaliza o rE AO Mensura o Defini o do Projeto do Projeto Hea Fechamento da Engenharia de Escopo de Software de Software S de Software e ar x x Estabele a ee Planejamento Implementa o a a o Determinando eap ie o SS pr do Processo dos Planos RE E PSA o T rmino Compromisso Requisitos Requisitos ss de Medi o iiia x Gerenciamento An lise e Planejamento An lise de Determina o E ARE Atividades de Viabilidade de Entregas de Contrata o Avalia o RE q E do Processo de Fomecedores do Desempenho de Medi o quam re penas Estima o Implementa o Execu o do Evisio do mess do Processo Processo de Requisitos e Custo de Medi o Medi o Aloca o de Processo de Avalia o das Recursos Monitora o Medidas Gerenciamento Controle do de Riscos Processo Gerenciamento de Qualidade Relat rios Gerenciamento do Planejamento Figura 1 Estrutura de t picos para a rea de conhecimento de Ger ncia de Engenharia de Software Figura 22 T picos da KA
242. o de entradas como feito geralmente no teste de confiabilidade Diversas compara es anal ticas e emp ricas foram conduzidas para analisar as condi es que fazem uma aproxima o mais eficaz do que a outra 2 1 3 4 4 Medidas Relacionadas ao Teste s vezes as t cnicas de teste s o confundidas com os objetivos do teste As t cnicas de teste devem ser vistas como aux lio que ajudam a assegurar a realiza o de objetivos do teste Por exemplo a cobertura da ramifica o uma t cnica de teste popular Conseguir uma medida espec fica da cobertura da ramifica o n o deve ser considerada o objetivo do teste por si s um meio para melhorar as possibilidades de encontrar falhas sistematicamente exercitando cada ramifica o do programa fora de um ponto de decis o Para evitar tais enganos uma distin o clara deve ser feita entre as medidas teste relacionadas que fornecem uma avalia o do programa sob o teste baseado nas sa das observadas do teste e as aquelas que avaliam a efic cia do conjunto do teste A informa es adicionais em medida de programas fornecida na rea de conhecimento da ger ncia da engenharia de software sub rea 6 medi o da engenharia de software A informa es adicionais em medidas pode ser encontrada na rea de conhecimento do processos de engenharia de software na sub rea 4 processos e medida do produto A medida considerada geralmente instrumental an lise da qualidade A
243. o diferencial e integral e Equa es diferenciais Probabilidade e Estat sticas An lise num rica e Matem tica discreta Uma lista mais focalizada de t picos matem ticos chamados unidades e t picos no relat rio que sustente a tecnologia de programa o pode ser encontrada no relat rio de esbo o do volume na tecnologia de programa o do projeto de computa o dos curr culos 2001 CC2001 2 1 3 11 5 Gest o de Projetos A gest o de projeto definida na edi o 2000 como um de guia ao corpo da gest o do projeto de conhecimento PMBOK Guide 6 publicado pelo instituto da gest o do projeto e adotado como IEEE STD 1490 2003 como a aplica o do conhecimento das habilidades das ferramentas e das t cnicas para projetar atividades cumprir exig ncias do projeto As reas do conhecimento identificadas no guia PMBOK para a gest o do projeto s o Ger ncia da integra o do projeto e Ger ncia do espa o do projeto Ger ncia de tempo do projeto Ger ncia do custo do projeto e Ger ncia de qualidade do projeto Ger ncia de recursos humanos do projeto e Ger ncia de comunica o do projeto e Gest o de riscos do projeto e Ger ncia da obten o do projeto 195 2 1 3 11 6 Ger ncia de Qualidade A ger ncia de qualidade definida na ISO 9000 2000 como Coordenando Atividades para Dirigir e Controlar uma Organiza o no que diz Respeito Qualidade As tr s refer ncias selecionadas na
244. o do software A maior parte abrangida de uma forma geral no Quality Software KA 53 a Atributos de Qualidade Diversos atributos s o geralmente considerados importantes para a obten o de um design de software de boa qualidade e diversas ilities manutenibilidade portabilidade testabilidade rastreabilidade v rias des corre o robustez incluindo fitness de prop sito Bos00 c5 Bus96 c6 1509126 1 01 15015026 98 Mar94 D Mey97 c3 Pfl01 c5 Um dado interessante a distin o entre atributos de qualidade discern vel em tempo de execu o desempenho seguran a disponibilidade funcionalidade usabilidade para aqueles que n o s o discern veis em tempo de execu o modificabilidade portabilidade reusabilidade integrabilidade e testabilidade e os relacionados com as qualidades intr nsecas da arquitetura conceitual integridade a exatid o e a exaustividade buildability b An lise de qualidade e T cnicas de Avalia o V rias ferramentas e t cnicas podem ajudar a garantir uma concep o da qualidade de software e Revis o do design de Software semi formal ou informal muitas vezes baseadas em grupo t cnicas para verificar e assegurar a qualidade da concep o de componente por exemplo a revis o da arquitetura Bas0S C11 opini es de design e inspe es Fre83 VIII IEEE1028 97 Jal97 C5 C7 Lis01 C14 Pfl01 c5 t cnicas de cen rio de base Bas98 c9 Bos0O0 c5
245. o e criticidade As principais atividades abrangidas s o Identifica o e Configura o de Software Controle de Configura o de Software Contagem de Status de Configura o de Software Audi o da Configura o de Software e Gerenciamento de Release e Entrega do Al m disso quest es como a organiza o e as responsabilidades recursos e cronogramas sele o e utiliza o de ferramenta controle de fornecedores e subcontratados e controle de interface s o normalmente considerados Os resultados do planejamento das atividades s o gravados em um Plano de SCM SCMP que normalmente est sujeitos a revis o e auditoria da SQA Para evitar confus o sobre quem ir realizar determinada atividade ou tarefas de SCM as organiza es envolvidas no processo de SCM precisam ser claramente identificadas Responsabilidades espec ficas para determinadas atividades ou tarefas de SCM tamb m precisam ser atribu das a entidades organizacionais quer pelo t tulo ou pelo elemento organizacional A autoridade global e relat rios de crit rios para SCM tamb m devem ser identificados embora isto possa ser realizado no gerenciamento de projetos ou na fase de Planejamento da Garantia da 116 Qualidade O planejamento para SCM identifica os funcion rios e as ferramentas envolvidas na realiza o de atividades e tarefas de SCM Aborda quest es da programa o estabelecendo as sequ ncias necess rias para a cria o de tarefas de SCM
246. o e descoberta antecipada de erros melhoria continua e foco no cliente s o pertinentes engenharia de software Estes conceitos est o baseados nos trabalhos de especialistas em qualidade que t m declarado que a qualidade de um produto est diretamente ligada qualidade do processo utilizado para desenvolv lo Cro79 Dem86 Jur89 Abordagens como a Gest o da Qualidade Total TQM e a metodologia Planejar Executar Verificar Atuar PDCA s o ferramentas para se atingir os objetivos de qualidade O apoio gerencial prov avalia es de processos e produtos e os resultados encontrados Em seguida um programa de melhoria desenvolvido identificando a es detalhadas e melhoria nos projetos para serem abordadas em um prazo razo vel A ger ncia se certifica de que cada projeto de melhoria tenha o suficiente em recursos para alcan ar a meta definida para o mesmo O apoio gerencial frequentemente deve ser solicitado implementando atividades de comunica o preventivas O envolvimento de grupos de trabalho como tamb m apoio de ger ncias intermedi rias e aloca o de recursos para n veis de projeto s o discutidos na KA Processo de Engenharia de Software 2 1 3 10 2 Processos de Gest o da Qualidade de Software A Gest o da Qualidade de Software SQM aplica se a todas as perspectivas dos processos de software produtos e recursos Definem processos donos e requisitos para os mesmos medi es do processo e de seus resultado
247. o e mudan a podem ser qualitativos ou quantitativos d Considera es Pr ticas Processo de implementa o e mudan a constitui um exemplo de mudan a organizacional A mudan a organizacional mais bem sucedia trata a mudan a como um projeto pr prio com planos apropriados monitoramento e revis es A Orienta es sobre o processo de implementa o e mudan a da engenharia de software dentro de organiza es inclui a es de planejamento forma o gest o de patroc nio desempenho e a sele o de projetos piloto que abrangem tanto processos como ferramentas s o apresentados em Moi98 San98 Sti99 Estudos emp ricos sobre fatores de sucesso para processos de mudan a s o relatados em ElE99a O papel dos agentes de mudan a nesta atividade discutido em Hut94 O processo de implementa o e mudan a tamb m pode ser visto como uma inst ncia de consulta seja interna ou externa 152 Uma mudan a organizacional tamb m pode ser vista a partir da perspectiva da transfer ncia de tecnologia Rog83 Artigos de engenharia de software que discutem a transfer ncia de tecnologia e as caracter sticas dos destinat rios da nova tecnologia que pode incluir tecnologias relacionadas com o processo est o em PfI99 Rag89 Existem duas formas de abordar a avalia o do processo de implementa o e mudan a quer em termos de altera es do pr prio processo ou em termos de altera es do processo de resultados p
248. o entre fracassos b Avalia o dos testes executados Medidas de cobertura efic cia Jor02 c9 Pfl01 c8 IEEE982 1 88 Diversos crit rios de sufici ncia de teste exigem que os casos de teste exercitem sistematicamente um conjunto de elementos identificados no programa ou nas especifica es ver a sub t pico 3 Para avaliar a efic cia dos testes executados os verificadores podem monitorar os elementos cobertos de modo que possam dinamicamente medir a rela o entre os elementos cobertos e seu n mero total Por exemplo poss vel medir a porcentagem de ramifica es cobertas no gr fico de fluxo do programa ou dos requisitos funcionais exercidos entre aquelas listadas no documento das especifica es Os crit rios c digo baseados de sufici ncia exigem a instrumenta o apropriada do programa sob o teste Semeando falhas Pfl01 c8 Zhu97 s3 1 Algumas falhas s o introduzidas artificialmente no programa antes do teste Quando os testes s o executados alguma destas falhas semeadas ser o reveladas e possivelmente algumas falhas que j haviam l tamb m ser o Na teoria dependendo de qual das falhas artificiais s o descobertas e de quantas o teste de efic cia pode ser avaliado e o n mero restante de falhas genu nas pode ser estimado Na pr tica os estat sticos questionam a distribui o e a representatividade das falhas semeadas relativas s falhas genu nas e do pequeno tamanho de amostra em que todas
249. o no segundo 148 O termo processo de engenharia de software pode ser interpretado de diferentes maneiras e isto pode causar confus o A primeira maneira onde a palavra o usada como o processo de engenharia de software poderia implicar que existe somente uma maneira correta de se executar tarefas de desempenho de engenharia de software Este significado evitado neste Guia porque n o existe tal processo Padr es como IEEE12207 falam sobre o processo de engenharia de software de maneira que existem muitos processos envolvidos tais como processo de desenvolvimento ou gerencia de processo de configura o Uma segunda maneira refere se discuss o geral do processo para engenharia de software relatado Esta a maneira entendida nesta KA e sua maior inten o Finalmente a terceira maneira poderia significar a atual forma das atividades realizadas dentro das organiza es a qual pode ser visualizado como um processo especialmente dentro de uma organiza o Esta interpreta o usada no KA em poucos exemplos A KA se aplica a qualquer parte do gerenciamento do processo de ciclo de vida do software onde mudan as de processos ou de tecnologia s o inicialmente introduzidas atrav s da melhoria de processos ou produtos Processo de engenharia de software relevante n o somente para grandes organiza es Pelo contr rio as atividades relacionadas com o processo podem e tem sido executadas com suces
250. o ou de manuten o est o em conformidade com os requisitos da atividade e se o produto final de software atende sua finalidade e satisfaz requisitos do usu rio Verifica o uma tentativa de garantir que o produto seja constru do corretamente no sentido que a atividade de desenvolvimento dos produtos re ne as especifica es impostas em atividades anteriores Valida o uma tentativa de se certificar que o produto certo foi constru do ou seja que o produto espec fico cumpre sua fun o espec fica Os processos de verifica o e valida o come am cedo no desenvolvimento ou fase de manuten o Eles fornecem uma an lise das principais funcionalidades do produto tanto em rela o ao produto imediatamente antecessor quanto em rela o a especifica es s quais ele deve se ater O prop sito do planejamento de V amp V garantir que cada recurso papel e responsabilidade sejam claramente assegurados Os planos de V amp V resultantes documentam e descrevem os v rios recursos seus pap is e atividades al m das t cnicas e ferramentas a serem utilizadas Uma compreens o dos prop sitos diferentes de cada atividade de V amp V ajudar no planejamento cuidadoso das t cnicas e recursos necess rios para cumprir seus prop sitos As normas IEEE 1012 98 s7 e IEEE1059 93 Ap ndice A especificam o que normalmente acontece em um plano de V amp V O plano tamb m contempla a gest o comunica o pol ticas e procediment
251. o que seja uma parte integrante do ciclo de vida No IEEE EIA Standard 12207 0 o teste n o descrito como um processo aut nomo mas os princ pios para atividades do teste s o inclu dos junto com Os cinco processos preliminares do ciclo de vida e o processo de suporte No IEEE STD 1074 o teste agrupado com outras atividades da avalia o como integrante ao ciclo de vida inteiro Teste de documenta o e produtos do trabalho de Bei90 c13s5 Kan99 c12 Per95 c19 Pfl01 c9s8 8 IEEE829 98 A documenta o uma parte integrante da formaliza o do processo de teste O padr o IEEE para teste de documenta o de Software IEEE829 98 fornece uma boa descri o de documentos de teste e de seus relacionamentos uns com os outros e com o processo do teste Os documentos de teste podem incluir entre outros o plano de teste a especifica o do projeto do teste a especifica o do procedimento de teste a especifica o dos casos de teste o registro de teste e o relat rio do incidente ou problema do teste O software sob o teste documentado como item do teste A documenta o de teste deve ser produzida e continuamente atualizada ao mesmo n vel de qualidade que outros tipos de documenta o na engenharia de software Equipe de teste interna versus independente Bei90 c13s2 2 c13s2 3 Kan99 c15 Per95 c4 Pfl01 c9 a Formaliza o do processo de teste pode envolver formalizar a organiza o da equipe de teste tam
252. o tempo e a antecipa o das mudan as controla muitos aspectos da constru o de software A muta o de ambientes externos de software parte inevit vel e as mudan as nesses ambientes externos afetam o software em diversas maneiras As antecipa o da mudan a apoiada por muitas t cnicas espec ficas resumidas no t pico 3 3 codifica o c Constru o para verifica o Constru o para verifica o meio de construir software de forma que as falhas podem ser prontamente encontradas pelo engenheiro de software que escreveu o software bem como durante os testes independentes e atividades operacionais T cnicas especificas de suporte a constru o para verifica o inclui seguinte normas de codifica o de suporte a revis o de c digo teste de unidades organiza o de c digo de suporte automa o de testes e restri o de uso complexo ou linguagem de dif cil compreens o das estruturas entre outras d Normas de constru o Normas que afetam diretamente quest es de constru o incluem e M todos de comunica o por exemplo padr o de formatos de documenta o e contexto Linguagem de programa o por exemplo padr es de linguagem com linguagens Java e C e Plataforma por exemplo programador padr o para a interface do sistema operacional chamado Ferramenta por exemplo diagramas padr o para nota es ligadas a UML Linguagem de Modelagem Unificada Uso de normas externas Constru
253. oftware e Processo de Engenharia de Software a g o tO z 1 Fundamentos da qualidade de software 1 1 Cultura e tica da Engenharia de Software 1 2 Valor e Custo da Qualidade 1 3 Modelos e Caracter sticas de Qualidade 1 4 Melhoria da Qualidade de Software 2 Processos de gerencia de Qualidade de Software e DONA OA ANAADERA Qualidade de Software 2 2 ae e CI 46 1 lida o 2 3 Revis es e Auditorias SELLE LL Figura 28 T picos x refer ncias 8 191 Mus99 3 Considera es Praticas Qualidade de Software 3 1 Requisitos de Qualidade de Software 3 2 Caracteriza o de Defeitos 3 3 T cnicas de SQM 3 4 M tricas de Qualidade de Software Figura 29 T picos x refer ncias 9 2 1 3 11 Disciplinas Relacionadas Com Engenharia de Software A fim de circunscrever a engenharia de software necess rio identificar as disciplinas de engenharia de software com o qual partilha uma fronteira comum Este cap tulo identifica em ordem alfab tica estas disciplinas relacionadas Evidentemente as Disciplinas Relacionadas tamb m partilham muitas coisas em comum entre si Usando um consenso baseado em fonte reconhecida este cap tulo identifica para cada disciplina relacionada Uma defini o informativa quando poss vel Uma lista de areas do conhecimento Disciplmas Relacionadas Engenharia de
254. ogias como comportamental vs funcional vs estruturais vs modelagem de dados view Em resumo um projeto de software um multifacetada artefato produzido pelo processo de design e geralmente composto de relativa independ ncia e ortogonais vista Bas03 c2 Boo99 c31 Bus96 c6 IEEE1016 98 IEEE1471 00 estilos arquitet nicos padr es de macroestruturas Um estilo arquitet nico um conjunto de restri es sobre um arquitetura que define um conjunto ou fam lia de arquiteturas que os satisfazem Bas03 c2 Um estilo arquitet nico pode ser visto como uma metamodelo que possa fornecer software de alto n vel high level para as organiza es a macro arquitetura Diversos autores identificaram uma s rie de grandes estilos arquitet nicos Boo99 c28 Bos00 c6 Bus96 c1 c6 Pfl01 c5 e Estrutura geral por exemplo camadas tubos e filtros Blackboard Sistemas Distribu dos por exemplo cliente servidor threetiers broker 52 Sistemas Interativos por exemplo Model View Controller Apresenta o Abstra o Controle Adapta o de sistemas por exemplo micro kernel reflex o Outros por exemplo lote int rpretes controle de processos regras base b Padr es de Design padr es de micro arquitetura Sucintamente descritos um padr o uma solu o comum para um problema comum em um determinado contexto Jac99 Embora estilos arquitet nicos possam ser vistos como padr es que descrevem o high l
255. ograma representada graficamente usando um gr fico de fluxo nas t cnicas de teste c digo baseadas Um gr fico de fluxo um grafo dirigido de n s e arcos que correspondem aos elementos do programa Por exemplo os n s podem representar declara es ou sequ ncias ininterruptas de declara es e arcos a transfer ncia de controle entre os n s d T cnicas falha baseadas Com graus diferentes de formaliza o as t cnicas de teste falha baseadas planejam as situa es de teste visadas especificamente revelando categorias de falhas predefinidas ou prov veis Mor90 Suposi o do erro Kan99 c7 No suposi o do erro as situa es de teste s o projetadas especificamente pelas engenheiros de software que tentam externar as falhas mais plaus veis em um programa dado Uma boa fonte de informa o a hist ria das falhas descobertas em projetos prematuros assim como a per cia do engenheiro de software Teste de muta o Per95 c17 Zhu97 s3 2 s3 3 Um mutante uma vers o ligeiramente modificada do programa sob o teste diferindo dele por uma mudan a pequena sint tica Cada caso de teste exercita ambos o original e todos os mutantes gerados se um caso de teste bem sucedido em identificar a diferen a entre o programa e um mutante o ltimo seria destru do Concebido originalmente como uma t cnica para avaliar um caso do teste ver 4 2 teste de muta o igualmente um crit rio de teste p
256. ole dos casos de teste assim como o registro e a recupera o de resultados previstos de manuscritos e de outros materiais do teste Execu o Bei90 c13 Kan99 c11 IEEE1008 87 s6 s7 A execu o dos testes deve personificar um princ pio b sico de experimenta o cient fica tudo feito durante o teste deve ser executado e documentado bem claramente 90 para que uma outra pessoa possa reproduzir os resultados Consequentemente o teste deve ser executado de acordo com procedimentos documentados usando uma vers o claramente definida do software sob o teste Avalia o dos resultados da an lise Per95 c20 c21 Pos96 p18 20 p131 138 Os resultados do teste devem ser avaliados para determinar se o teste foi mesmo bem sucedido ou n o Na maioria dos casos bem sucedido significa que o software executou como esperado e n o teve nenhum resultado principal inesperado N o todos os resultados inesperados s o necessariamente falhas entretanto mas poderia ser julg para ser simplesmente o ru do Antes que uma falha possa ser removida uma an lise e um esfor o na elimina o de erros necess rio para isol la identific la e descrev la Quando os resultados do teste s o particularmente importantes um conselho de revis o formal pode ser reunido para avali los Relat rio do problema registro do teste Kan99 c5 Per95 c20 IEEE829 98 s9 s10 As atividades do teste podem ser incorporadas a um reg
257. onomia de caracter sticas definidas que o software pode apresentar IEEE EIA Implementa o Industrial do Este padr o fornece uma estrutura de processos X X x X X X X P X X 12207 0 Padr o Internacional ISO IEC usados pelo ciclo de vida completo de software 1996 12207 1995 Padr o para 221 2 5 Q z o m Mo pu o os a9 of og PE nae v 8 p g vag a Numero SE 40 32 34 8 29 958959 3 95 25 Nome padr o Descri o z4 so 2 28 5 Sja zal Ega 323 ES padr o so 82 5418 50 Dor SZS szo Szaz Sa 82 do a2 ao Sra dalo Do 6a a8 a 8 8 g GP B EE 8 INSO NEC Tecnologia de Informa o 12207 199 Processos de Ciclo de Vida de 5 Software IEEE EIA Implementa o Industrial do Este documento fornece orienta es sobre grava o 12207 1 Padr o Internacional ISO IEC de dados resultantes do ciclo de vida dos processos 1996 12207 1995 Padr o para IEEE EIA 12207 0 X X x X xX X x P X X Tecnologia da Informa o Processos de Ciclo de Vida de Software Ciclo de Vida de Dados IEEE EIA Implementa o Industrial do Este documento fornece orienta es adicionais para a 12207 2 Padr o Internacional ISO IEC implementa o do ciclo de vida dos processos 1997 12207 1995 Padr o de Tecnologia IEEE EIA 12207 0 X X xX X x X X P X X de Informa o Processos de Ciclo de Vida de Software Considera
258. or exemplo medir o retorno sobre o investimento para realizar a altera o Um olhar pragm tico para o que pode ser alcan ado a partir desses estudos de avalia o dado em Her98 Um panorama das formas de avaliar processo de implementa o e mudan a e os exemplos de estudos pode ser encontrado em Gol99 9kit98 Kra99 McG94 2 1 3 8 2 Defini o de Processo A defini o de processo pode ser um procedimento uma pol tica ou uma norma Processos de ciclo de vida de software s o definidos por uma s rie de raz es incluindo o incremento da qualidade do produto melhorias da compreens o humana e comunica o apoio ao processo de melhoria apoio aos processos de gest o orienta o aos processos automatizados e providenciando a execu o de suporte automatizado Os tipos de defini es exigidas no processo depender o pelo menos parcialmente do motivo da defini o Tamb m importa notar que o contexto do projeto e da organiza o ir o determinar a defini o do tipo de processo que mais til Vari veis importantes a considerar incluem a natureza do trabalho por exemplo a manuten o ou desenvolvimento o dom nio da aplica o o modelo do ciclo de vida e da maturidade da organiza o a Modelos de Ciclo de Vida de Software Os modelos de Ciclo de vida de software servem como um alto n vel de defini o das fases que ocorrem durante o desenvolvimento Eles n o s o destinados a fornecer defini
259. or si s outros testes s o gerados aleatoriamente at que mutantes suficientes estejam destru dos ou testes s o projetados especificamente para destruir mutantes sobreviventes No ltimo caso o teste da muta o pode igualmente ser categorizado como uma t cnica c digo baseada A 82 suposi o subjacente do teste de muta o o efeito do acoplamento que procurando as falhas sint ticas simples mais falhas complexas por m reais ser o encontradas Para que a t cnica seja eficaz um grande n mero de mutantes deve ser automaticamente derivado de uma maneira sistem tica e T cnicas uso baseadas Perfil operacional Jor02 c15 Lyu96 c5 Pfl01 c9 No teste para a avalia o da confiabilidade o ambiente de teste deve reproduzir o ambiente operacional dos software t o pr ximo como poss vel A ideia para inferir dos resultados da an lise observados a confiabilidade futura do software quando no uso real Para fazer isto entradas s o atribu das numa distribui o de probabilidade ou num perfil de acordo com sua ocorr ncia na opera o real Teste projetado da confiabilidade de software Lyu96 c6 O teste projetado da confiabilidade de software SRET um m todo de teste que abrange o processo de desenvolvimento inteiro por meio de que o teste projetado e guiado por objetivos de confiabilidade e uso relativo e criticidade previstos de fun es diferentes no campo f T cnicas baseadas na n
260. ormas de constru o Qualidade da Constru o Integra o Figura 14 Reparti o dos t picos para o rea de conhecimento de constru o de software Os tr s primeiros conceitos se aplicam ao design bem como a constru o As seguintes se es definem estes conceitos e descreve como eles se aplicam na constru o a Minimizar complexidade Um fator principal em como as pessoas transmitirem as inten es dos computadores limita es serias das capacidades das pessoas em realizar complexas estruturas e informa es em suas mem rias de trabalho especialmente durante longos per odos de tempo Isto conduz a um forte controle em constru o de software Minimizar complexidade O necess rio de reduzir aplica es complexas basicamente de todos os aspectos da constru o de software e particularmente critico dos processos de verifica o e testes de constru o de software Em constru o de software reduzir complexidade obter por enfatiza a cria o de c digo que simples e leg vel e bastante engenhoso Minimizar complexidade realizada por meio da utiliza o de padr es que discutido no t pico 1 4 Padr o em 62 constru o e por numerosas t cnicas especificas resumidas no t pico 3 3 codifica o Ele tamb m apoiado pela constru o com foco na t cnica de qualidade resumida no t pico 3 5 qualidade de constru o b Antecipa o de mudan a A maior parte dos software ira mudar com
261. orpo de Conhecimento de Engenharia de Software SWEBOK foi estabelecido com os cinco seguintes objetivos 1 Promover uma vis o consciente da engenharia do software no mundo inteiro 2 Esclarecer o lugar e estabelecer o limite da engenharia de software com respeito a outras disciplinas como ci ncia da computa o gerenciamento de projetos engenharia da computa o e matem tica 3 Caracterizar os conte dos da disciplina de engenharia de software 4 Fornecer um acesso ao Corpo de Conhecimento de Engenharia de Software 5 Fornecer uma base para desenvolvimento de curr culo certifica o individual e licenciamento de material O primeiro desses objetivos uma vis o mundial consistente da engenharia de software foi apoiada por um processo de desenvolvimento que empregou aproximadamente 500 revisores de 42 pa ses na fase de Stoneman 1998 2001 levando vers o de Prova e mais de 120 revisores de 21 pa ses na fase de Ironman 2003 levando vers o 2004 Mais informa o quanto ao processo de desenvolvimento pode ser encontrada no Pref cio e no site www swebok org As sociedades profissionais e eruditas e as ag ncias p blicas implicadas na engenharia de software foram oficialmente contatadas feitas conscientes deste projeto e convidadas para participar do processo de revis o Editores associados foram recrutados de Am rica Norte Costa Pacifica e Europa Apresenta es do projeto foram feitas em v rios eventos inte
262. os A efic cia do teste explorat rio confia no conhecimento do engenheiro de software que pode ser derivado de v rias fontes comportamento observado do produto durante o teste familiaridade com a aplica o a plataforma o processo da falha o tipo de falhas e fracassos poss veis o risco associado com um produto em particular e assim por diante Kan01 c3 b t cnicas baseadas na Especifica o e 3 2 1 Divis o equivalente Jor02 c7 Kan99 c7 O dominio de entrada subdividido em uma cole o de subconjuntos ou classes equivalentes que s o julgadas equivalente de acordo com uma rela o espec fica e um conjunto representativo dos testes s vezes somente um s o tomados de cada classe e An lise do valor limite Jor02 c6 Kan99 c7 Os casos de teste s o escolhidos pr ximo e nos limites do dom nio da entrada das vari veis com a raz o subjacente que muitas falhas tendem a se concentrar perto dos valores extremos de entradas Uma extens o desta t cnica teste de vigor onde as situa es de teste s o escolhidas igualmente fora do dom nio da entrada das vari veis para testar o vigor do programa para entradas inesperadas ou err neas e Tabela de decis o Bei90 c10s3 Jor02 As tabelas de decis o representam relacionamentos l gicos entre condi es aproximadamente entradas e a es aproximadamente sa das Os casos de teste s o derivados sistematicamente considerando cada combina o pos
263. os de V amp V e suas atividades de intera o bem como a elabora o de relat rios de defeitos e documenta o de requisitos c Revis es e Auditorias 180 Por quest es de simplicidade revis es e auditorias s o tratadas como um nico t pico neste Guia ao inv s de em dois t picos separados como em IEEE12207 0 96 Os processos de revis o e auditoria est o amplamente definidos em IEEE12207 0 96 e em mais detalhe em IEEE1028 97 S o apresentados cinco tipos de revis es ou auditorias na Norma IEEE 1028 97 e Revis es Gerenciais e Revis es T cnicas Inspe o Verifica o e Walk throughs e Auditorias O prop sito de uma revis o gerencial monitorar o progresso determinar o status de planos e cronogramas confirmar requisitos e aloca o de seus sistemas ou avaliar a efic cia das abordagens de ger ncia utilizadas para atingir a adequa o ao objetivo IEEE 1028 97 Tais abordagens apoiam decis es sobre mudan as e a es corretivas que s o requeridas durante um projeto de software Revis es gerenciais determinam a adequa o dos planos cronogramas e requisitos e monitoram seu progresso ou inconsist ncias Estas revis es podem ser executadas em produtos tais como relat rios de auditoria relat rios de progresso relat rios de V amp V e muitos tipos de planos inclusive gest o de risco gest o de projeto gest o de configura o de software seguran a de software e avalia o de risco ent
264. os de Software Design de Software Constru o de Software Teste de Software e Manuten o de Software Os pr ximos quatro t picos restantes correspondem as KAs Gest o de Configura o de Software Gest o de Engenharia de Software Processos de Engenharia de Software e Qualidade do Software Um outro t pico adicional dirige se a diversas reas contanto que sejam semelhantes e abordadas como ferramenta de integra o t cnicas que s o potencialmente aplic veis a todas as classes de ferramentas 165 a Ferramentas de Requisitos de Software As ferramentas para tratar os requisitos de softwares foram classificadas em duas categorias ferramentas de modelagem e ferramentas de rastreabilidade Ferramentas de requisitos de modelagem Estas ferramentas s o usadas para obten o an lise especifica o e valida o de requisitos de software e Ferramentas de requisitos de rastreabilidade Dor02 Estas ferramentas est o crescendo e se tornando cada vez mais importantes na medida que cresce a complexabilidade do software Desde que sejam tamb m relevantes em outros processos de ciclo de vida eles s o apresentados separadamente dos requisitos de ferramentas de modelagem b Ferramentas de Design de Software Este t pico refere se s ferramentas para cria o e verifica o de projetos de softwares Existe uma variedade destas ferramentas consequentemente uma diversidade de nota es e m todos de projeto de softwares
265. os de medi o essencial para a medi o de programas para proporcionar resultados eficazes e delimitados As caracter sticas chaves dos instrumentos de medi o para garantir resultados de medi o e qualidade foram definidas na norma ISO Vocabul rio internacional sobre metrologia VIM93 A teoria de medi o estabelece a base sobre a forma que as medi es podem ser feitas Esta teoria e tipos de escala s o discutidas em Kan02 A medi o definida 160 na teoria como a atribui o de n meros para os objetos de uma forma sistem tica de representar propriedades do objeto Uma avalia o da medi o de software e as implica es de cada tipo de escala em rela o sua sele o posterior de m todos de an lise de dados especialmente importante Abr96 Fen98 c2 Pfl01 C11 Escalas significativas s o relacionada em uma classifica o de escalas A teoria da medi o fornece cada vez mais formas de como realizar as medidas Se os n meros atribu dos s o apenas para fornecer etiquetas para classificar os objetos eles s o denominados como nominal Se eles forem atribu dos de uma forma que classifica os objetos por exemplo bom melhor eles s o chamados como ordinais Se eles lidam com as magnitudes de propriedade em rela o a uma unidade de medi o definida eles s o chamados como intervalo e os intervalos s o uniformes entre os n meros a menos que de outra maneira n o est o especificado e s o
266. os de modelagem e an lise de m todos existem 157 v rios aspectos de engenharia de medi o de software que s o fundamentais e que s o a base de muitos dos mais avan ados processos de medi o e an lise Al m disso a realiza o do processo e os esfor os para a melhoria dos produtos s pode ser avaliado se um conjunto de medidas de base tiver sido estabelecido A medi o pode ser executada para apoiar a inicia o ou para avaliar as consequ ncias da implementa o de processo E tamb m esta medi o pode ser executa no pr prio produto Conceitos fundamentais sobre medidas de software e m todos de medi o foram definidos na norma ISO IEC 15939 com base nas ISO vocabul rio internacional de metrologia ISO IEC 15359 tamb m fornece um processo padr o de medir tanto os processos quanto as caracter sticas de produto VIM93 No entanto os leitores v o encontrar termos divergentes na literatura por exemplo o termo m trica s vezes usado no lugar de medir a Processo de Medi o O termo processo de medi o conforme usado aqui significa que informa es quantitativas sobre o processo s o recolhidas analisadas e interpretadas A medi o utilizada para identificar os pontos fortes e fracos dos processos e para avali los depois que eles foram implementados e ou modificados O processo de medi o pode servir a outros objetivos tamb m Por exemplo til para gerenciar um projeto de en
267. os de software Defini o de requisitos de software C Requisitos de produto e processo C Requisitos funcionais e n o funcionais C Propriedades emergentes C Requisitos quantific veis C Requisitos de sistema e requisitos de C software 2 Processo de requisitos Modelo de processo C Atores do processo C Suporte do processo e gerenciamento C Qualidade do processo e C aproveitamento 3 Requisitos de elicita o Origens dos requisitos C T cnicas de elicita o AP 4 An lise de requisitos Classifica o de requisitos AP Modelagem conceitual AN Design arquitetural e aloca o de AN requisitos Negocia o de requisitos AP 5 Especifica o de requisitos Documento de defini o do sistema C Especifica o dos requisitos do sistema C Especifica o dos requisitos de software AP 6 Valida o de requisitos An lise de requisitos AP Prototipa o AP Valida o de modelo C Testes de aceita o AP 7 Considera es pr ticas Processo de requisitos de natureza C iterativa Gerenciamento de mudan a AP Atributos de requisitos C Rastreamento de requisitos AP avalia o Atributos de qualidade C An lises que qualidade e t cnicas de AN avalia o Medi es C 5 Nota es de design de software Descri es Estruturais AP Descri es de comportamento AP 6 Estrat gias e m todos para o design de software Estrat gias gerais AN Design orientado a fun o AP Design orientado a objetos AN Design centrado na est
268. os de software Interessados em facilitar o desenvolvimento do software 2 1 3 1 3 Elicita o de Requisitos Preocupa se com o de onde podem ser obtidos os requisitos de software e como os engenheiros de software podem colet los Constitui o primeiro est gio para definir e entender o problema que o software pretende solucionar E uma atividade fundamentalmente humana onde os stakeholders s o identificados e s o estabelecidas rela es entre equipe de desenvolvimento e o cliente Pode ser conhecida por outros nomes captura de requisitos descoberta de requisitos ou aquisi o de requisitos Um princ pio fundamental da boa Engenharia de software boa comunica o entre usu rios do software e os engenheiros de software Deve se esfor ar para isso Analistas devem mediar entre o dom nio do usu rio e o dom nio t cnico a Fontes de Requisitos Principais fontes a serem utilizadas Metas ou objetivos Objetivos do Neg cio objetivos de alto n vel do software Conhecimento do dom nio Conhecimentos sobre o dom nio da aplica o Stakeholders Pontos de vista dos diferentes tipos de stakeholders Ambiente operacional Ambiente onde o software ser executado Ambiente organizacional Estrutura cultura e pol ticas da organiza o b T cnicas de Elicita o Identificadas as fontes de requisitos o engenheiro de software deve elicitar os requisitos 35 e uma rea dif cil
269. os engenheiros de software a avaliar a qualidade do seu trabalho para prop sitos SQA e para a melhoria de qualidade de processo a longo prazo Com a sofistica o crescente de softwares as quest es de qualidade v o al m de simples quest es como se o software funciona ou n o para algo como qu o bem ele atinge metas de qualidade mensur veis H alguns t picos onde m trica apoia diretamente SQM Estes incluem ajuda para decidir quando interromper os testes Para isto modelos de confian a e benchmarks ambos usando dados de falhas e fracasso s o teis O custo dos processos SQM um assunto que quase sempre levantado durante a decis o de como um projeto deve ser organizado frequentemente s o utilizados modelos gen ricos de custo que s o baseados em quando um defeito encontrado e quanto esfor o necess rio para corrigir o defeito em rela o ao custo de se encontrar o defeito mais cedo no processo de desenvolvimento Dados de projeto podem dar uma melhor estimativa de custo Uma discuss o sobre este t pico pode ser encontrada em Rak97 pp 39 50 Informa es relacionadas podem ser encontradas nas KAs Processo de Engenharia de Software e Gest o de Engenharia de Software Finalmente os pr prios relat rios de SQM fornecem informa es valiosas n o s sobre estes processos mas tamb m sobre como todos os processos de ciclo vida do software podem ser melhorados Discuss es sobre estes t picos s o 189
270. os estimados a Classifica o de Requisitos Classifica o feita segundo diversos crit rios Funcional ou N o Funcional T pico 1 3 e Derivado de requisito de alto n vel propriedade emergente ou imposta diretamente sobre o software por um stakeholder ou qualquer outra fonte 36 Produto ou Processo se o requisito sobre o produto ou sobre o processo Requisitos sobre o processo podem restringir a escolha de um contratante um processo a ser adotado a ader ncia a um padrao e Prioridade em geral s o de alta prioridade os requisitos considerados essenciais para preencher os objetivos gerais do software frequentemente s o classificados numa escala de pontos fixos como obrigat rio muito desej vel desej vel ou opcional A prioridade tem que ser balanceada com o custo de desenvolvimento e implementa o Escopo refere se extens o com que o requisito afeta o software e os componentes de software Alguns requisitos e particularmente certos requisitos n o funcionais possuem um escopo global e n o pode ser alocado a nenhum componente em particular Podem afetar muito na arquitetura e Volatilidade Estabilidade Alguns requisitos ir o mudar durante o ciclo de vida do software e mesmo durante o processo de desenvolvimento Pode ser til a informa o de quanto um requisito muda Exemplo Numa aplica o banc ria requisitos para calcular e creditar juros para clientes s o provavelmente mais est veis que um
271. os extrapolados cronograma ultrapassado e coisas parecidas Identifica es at picas an lise da qualidade e outras mensura es de dados s o realizadas por exemplo an lise da densidade dos defeitos A influ ncia de e a exposi o a riscos s o recalculadas e rvores de decis o simula es e outros mais s o refeitos luz dos novos dados Essas atividades habilitam a detec o de problemas e a identifica o de exce es com base nos limites excedidos Os resultados s o relatados medida do preciso e com certeza onde 141 os limites aceit veis s o superados e Controle do Processo Os resultados das atividades de acompanhamento do processo fornecem as bases nas quais as a es de decis o s o tomadas Onde for apropriado e onde o impacto e os riscos associados forem modelados e gerenciados as mudan as podem ser feitas no projeto Isto pode ter a forma de a es corretivas por exemplo retestar certos componentes ela pode envolver a incorpora o das conting ncias de forma que ocorr ncias similares sejam evitadas por exemplo a decis o de usar prototipa o para ajudar na valida o dos requisitos do software e ou ela pode acarretar a revis o de v rios planos e documentos do projeto por exemplo especifica o de requisitos para acomodar os resultados inesperados e suas implica es Em alguns casos ela pode levar ao abandono do projeto Em todos os casos procedimentos de controle de mudan
272. os por indiv duos com ou sem a ajuda de ferramentas automatizadas A coloca o para t cnicas de pessoas intensivas incluindo revis es e 186 auditorias pode variar de uma reuni o formal a um ajuntamento informal ou uma situa o de desk check mas normalmente pelo menos duas ou mais pessoas est o envolvidas Uma prepara o antes do tempo pode ser necess ria Outros itens de recursos de an lise podem incluir checklists e resultados de t cnicas anal ticas e testes Estas atividades s o discutidas em IEEE 1028 97 nas revis es e auditorias Fre98 Hor03 e Jon96 Rak97 Um engenheiro de software geralmente aplica t cnicas anal ticas s vezes v rios engenheiros de software utilizam a mesma t cnica mas cada um a aplica em partes diferentes do produto Algumas t cnicas s o dirigidas por ferramentas outras s o manuais Algumas podem encontrar defeitos diretamente mas elas tipicamente s o usadas para apoiar outras t cnicas Algumas tamb m incluem v rias avalia es como parte da an lise de qualidade global Exemplos de tais t cnicas incluem an lise de complexidade an lise de controle de fluxo e an lise algor tmica Cada tipo de an lise tem um prop sito espec fico e nem todos os tipos s o aplicados em todos os projetos Um exemplo de uma t cnica de apoio a an lise de complexidade que til para determinar se o projeto ou implementa o ou n o muito complexo para desenvolver corretamente
273. os s o expostos A fase de manuten o do ciclo de vida come a a partir da entrega porem as atividades de manuten o ocorrem muito antes A KA de Manuten o de Software dividida em quatro sub reas Primeiramente apresentado os Fundamentos de Manuten o de Software defini es e terminologia a natureza de manuten o a necessidade de manuten o os principais custos de manuten o evolu o de software e as categorias de manuten o A segunda sub rea agrupa as Quest es chave em Manuten o de Software S o as quest es t cnicas de ger ncia estimativas de custos de manuten o e a mensura o da manuten o de software A terceira sub rea descreve o Processo de Manuten o Os t picos aqui s o os processos de manuten o e atividades de manuten o T cnicas para Manuten o constituem a quarta sub rea Essa sub rea inclui a compreens o de programa a reengenharia e a engenharia reversa 2 1 2 10 KA de Gerenciamento de Configura o do Software A Ger ncia de Configura o de Software GCS a disciplina de identificar a configura o do software em pontos distintos no tempo com o prop sito de sistematicamente controlar modifica es configura o e de manter a integridade e a auditoria da configura o em todas as partes do ciclo de vida de sistema Este KA inclui seis sub reas A primeira subarea a Ger ncia do Processo de GCS Ela cobre os t picos do contexto organizacional
274. porta A reparti o dos assuntos nos quadros n o corresponde perfeitamente reparti o contida nas reas do conhecimento A avalia o para esse anexo foi preparado enquanto alguns coment rios ainda estavam pr ximos do t rmino Finalmente lembre se que as avalia es do presente ap ndice definitivamente devem ser vistos apenas como uma proposta para ser desenvolvida e validada 226 Requisitos de Software Requisitos de medi o AP Design de Software Reparti o dos T picos N vel de Taxonomia 1 Fundamentos de Design de software Conceitos gerais de design C Contexto de design de software C Processo de design de software C T cnicas de ativa o AN 2 Quest es chave no design de software Concorr ncia AP Controlando e carregando eventos AP Distribui o de componentes AP Erro e manejo de exce o e toler ncia a AP falhas Apresenta o e intera o AP Persist ncia de dados AP 3 Estrutura e arquitetura de software Estruturas arquiteturais e pontos de vista AP Estilos arquiteturais AN Padr es de design AN Fam lias de programas e frameworks C 4 An lise da qualidade do design de software e Reparti o dos T picos N vel de Taxonomia 1 Fundamentos de requisit
275. portamento de um sistema inteiro A maioria das falhas funcionais deve j ter sido identificada durante os testes de unidade e de integra o O teste do sistema considerado geralmente apropriado para comparar o sistema aos requisitos de sistema n o funcionais tais como a seguran a a velocidade a exatid o e a confiabilidade As interfaces externas a outras aplica es as utilidades os dispositivos de hardware ou o ambiente operacional s o avaliadas neste n vel tamb m Ver a rea de Conhecimento requisitos de software para mais informa o sobre requisitos funcionais e n o funcionais b objetivos de teste Pfl01 c9s8 3 O teste conduzido na perspectiva de um objetivo espec fico que fixado mais ou menos explicitamente e com v rios graus de precis o Fixando o objetivo em termos precisos e quantitativos permite que o controle seja estabelecido sobre o processo do teste O teste pode ser apontado na verifica o de propriedades diferentes Os casos de teste podem ser projetados para a verifica o da correta execu o das especifica es funcionais que referido variadamente na literatura como teste de conformidade teste de exatid o ou teste funcional Entretanto diversas outras propriedades n o funcionais podem ser testadas tamb m incluindo 76 o desempenho a confiabilidade e a usabilidade entre muitas outras Outros objetivos importantes para o teste incluem mas n o se limitam a me
276. portanto aditivo As medi es est o em n vel de propor o se tiverem um n vel absoluto ponto zero portanto n veis de dist ncias para o ponto zero s o significativos c Modelos de Informa o sobre Software Como os dados s o reunidos e o reposit rio de medi o preenchido nos ajudam a construir modelos de dados utilizando o conhecimento e os dados no reposit rio Estes modelos existentes para fins de an lise classifica o e previs o Tais modelos t m de ser avaliados para assegurar que os seus n veis de precis o s o suficientes e que as suas limita es s o conhecidas e entendidas O refinamento de modelos que se realiza durante e ap s os projetos s o conclu dos esta outra atividade importante Modelo de constru o Modelo de constru o inclui ajustes e avalia o do modelo A meta abordagem orientada para a medi o do modelo de processo de constru o na medida em que modelos s o constru dos para responder a perguntas pertinentes e atingir objetivos na melhoria de software Este processo tamb m influenciado pelas limita es impl citas de medi o em escalas com rela o escolha de m todos de an lise Os modelos s o ajustados usando particularmente observa es pertinentes por exemplo os projetos recentes utilizam a mesma tecnologia e sua efic cia avaliada por exemplo pelo seu desempenho em testes e amostras Fen98 C4 C6 C13 Pfl01 c3 C11 C12 Som05 C25 161
277. posi es que afetam o processo de SCM Por exemplo a configura o de algumas auditorias poderia ser necess ria ou poderia especificar que certos itens sejam colocados sob CM Quando os produtos de software a ser desenvolvidos t m o potencial de afetar a seguran a p blica entidades reguladoras podem impor restri es externas ver por exemplo USNRC1 169 97 Finalmente o ciclo de vida de software escolhido 115 para um processo de software e as ferramentas de projeto selecionadas para executar o software afetam a concep o e implementa o do processo de SCM Ber92 Orienta o para o desenvolvimento e a implementa o de um processo de SCM pode tamb m ser obtido a partir de melhores pr ticas o que se refletiu em normas da engenharia de software emitidas por diferentes organiza es de padroniza o Moore Moo98 fornece um roteiro para estas organiza es e as suas normas As melhores pr ticas tamb m se reflete na melhoria dos processos e modelos de processo de avalia o tas como o Software Engineering Institute s Capability Maturity Model Integration SEI CMMI SEIO1 e ISO IEC15504 Software Engineering Process Avaliagao ISO IEC 15504 98 IEEE828 98 c4s1 c4s2 3 Moo98 c Planejamento para SCM O planejamento de um processo de SCM para um determinado projeto deve ser coerente com o contexto organizacional respeitar as restri es e seguir as orienta es e a natureza do projeto por exemplo o tamanh
278. r adaptadas para mais engenheiros de software s nior ou engenheiros de software especializados em determinadas areas do conhecimento nenhum t pico dado um nivel superior de An lise de taxonomia Isto consistente com a abordagem da Software Engineering Education Body of Knowledge SEEK onde a nenhum assunto atribu do um n vel superior a taxonomia Aplica o O objetivo do SEEK definir um programa de educa o do corpo de conhecimento de engenharia de software adequado para orientar o desenvolvimento dos curr culos de gradua o em engenharia de software Embora distintos nomeadamente em termos de alcance SEEK e SWEBOK est o intimamente relacionados A taxonomia de Bloom de dom nio cognitivo proposto em 1956 cont m seis n veis A tabela 14 do ap ndice D do SWEBOK apresenta esses n veis e palavras chave muitas vezes associadas a cada n vel Maiores informa es sobre a Classifica o de Bloom est o inseridas no Ap ndice D do SWEBOK N vel da Taxonomia de Bloom Palavras chave Associadas Conhecimento Retorno de dados Define descreve identifica conhece r tulos listas jogos nomes contornos retorna reconhece reproduz seleciona afirma Compreens o Entender o significado a tradu o a interpola o e interpreta o de instru es e problemas Estado um problema em suas pr prias palavras Compreende converte defende distingue estima explica se estende genera
279. r compat veis com o n vel de GC do sistema Buckley Buc96 c2 descreve SCM dentro deste contexto Note que o firmware cont m hardware e software portanto os conceitos de GC s o aplicados a ambos hardware e software SCM pode interagir com uma organiza o atividade garantia de qualidade em quest es tais como gerenciamento de registros e itens em n o conformidade Em rela o ao anterior alguns itens sob controle SCM podem tamb m ser registros de projeto sujeito ao fornecimento garantia de qualidade do programa da organiza o Gerenciamento itens sem conformidade geralmente da responsabilidade da atividade de garantia de qualidade entretanto SCM pode ajudar com monitoramento e relat rios sobre configura o de software itens que se inserem nesta categoria Talvez a mais estreita rela o com desenvolvimento e manuten o de software nas organiza es neste contexto que muitas tarefas de controle e configura o do software s o executadas Muitas vezes as mesmas ferramentas apoiam o desenvolvimento manuten o prop sitos de SCM Ber92 c4 Dar90 c2 IEEE828 98 c4s2 1 b Limita es e orienta es para o processo de SCM As restri es e orienta es para o processo de SCM prov m de v rias de fontes Pol ticas e procedimentos organizacionais podem influenciar a concep o e implementa o dos processo de SCM para um determinado projeto Al m disso contratos entre o compradores e o fornecedores podem conter dis
280. r considerado infinito Testes sempre implicam em uma troca 70 entre recursos limitados e programados de um lado e exig ncias inerentemente ilimitadas de testes de outro Selecionado As muitas t cnicas propostas de teste diferem essencialmente em como elas selecionam o conjunto de teste e engenheiros de software precisam estar atentos que crit rios de sele o diferentes podem render diferentes graus de efetividade Como identificar o crit rio de sele o mais satisfat rio em determinadas condi es um problema muito complexo na pr tica t cnicas de an lise de risco e per cias de engenharia de testes s o aplicadas e Esperado Deve ser poss vel embora nem sempre f cil decidir se os resultados observados da execu o do programa s o aceit veis ou n o caso contr rio o esfor o de teste seria in til O comportamento observado pode ser conferido contra expectativas de usu rio comumente chamado teste para valida o contra uma especifica o teste para verifica o ou finalmente contra o comportamento antecipado de exig ncias impl citas ou expectativas razo veis A vis o de testes de software tem evolu do para uma mais construtiva Teste j n o mais visto como uma atividade que come a somente depois que a fase de codifica o est completa com a finalidade limitada de detec o de falhas Teste de software agora visto como uma atividade que deve abranger todo o processo de desenvolvimento
281. ra Este padr o fornece uma abordagem uniforme para a 1044 1993 anomalias de software classifica o das anomalias detectadas nos softwares R2002 e sua documenta o Inclui listas teis de E gt E j classifica es de anomalias de dados relacionados IEEE Std Padr o IEEE para m tricas de Este padr o fornece uma terminologia consistente 1045 1992 produtividade de software para medi o da produtividade de software e define R 2002 uma forma coerente para medir os elementos que P S est o inseridos nos mecanismos de produtividade de software IEEE Std Padr o IEEE para planejamento e Este padr o descreve o formato e conte do do P 216 7 3 E Sol Dol Po Pesl 9 padr o di pera PERGE RE 228 258 822 FERE S go 68 60 58 S o EFIE d D o Doida D o o 2 o o o o 1058 1998 gerenciamento de projeto de planejamento e gerenciamento de projeto de software software IEEE Std Padr o IEEE para Metodologia e Este padrao descreve uma metodologia abrangendo 1061 1998 m trica da qualidade de software todo o ciclo de vida para o estabelecimento dos requisitos de qualidade e identifica o S S S S P implementa o e valida o de medidas correspondentes IEEE Std IEEE Pr tica recomendada para Este documento recomenda um conjunto pr ticas 1062 aquisi o de software teis que podem ser selecionadas e aplicadas 1998 durante a aquisi o de software p
282. ra das organiza es Alguns padr es como o IEEE EIA 12207 cont m mecanismos e recomenda es para a realiza o das adapta es 155 e Automa o Cada ferramenta automatizadas da suporte a execu o da defini es do processo ou fornecem orienta es para os indiv duos exercerem processos definidos Nos casos onde processo de an lise realizado algumas ferramentas permitem diferentes tipos de simula es por exemplo a simula o eventos discretos Al m disso h ferramentas que suportam cada um dos referidos processo de defini o nota es Essas ferramentas podem executar o processo automatizado de fornecer suporte as defini es dos processos reais ou automatizar totalmente em alguns casos Uma vis o geral das ferramentas de modelagem de processos pode ser encontrada em Fin94 e do centro de processo de ambienta o em Gar96 Trabalho sobre a aplica o da Internet para a provis o de orienta o do processo em tempo real est descrito em Kel98 2 1 3 8 3 Avalia o de Processo Processo de avalia o realizada utilizando tanto uma modelo de avalia o ou um m todo de avalia o Em alguns casos o termo avalia o usado no lugar de avalia o bem como o prazo Capacidade de avalia o utilizada quando a avalia o para os efeitos da adjudica o de um contrato a Modelos de Avalia o de Processos O modelo de avalia o de processos utiliza o que reconhecido como
283. ra o seu terceiro objetivo que sua divulga o O SWEBOK comparado a outros modelos de qualidade de software tem sua divulga o e utiliza o t mida mas em expans o Possui seus crit rios e conte dos objetivos claros e bem definidos tornando se uma ferramenta de excel ncia em aplicabilidade na pr tica al m de fornecer formaliza es direcionadas para certifica es a profissionais e acad micas Sum rio RESUMO sessilis eee ETE sae aaea te donaaa anula od dada EEE EAA EE unica EA EEE EE ubendantuaadsdunubasuesdlssnvansdabcscueusseudcasetndasrdandsduiavsnaveneadcceited 2 Lista de ablbreviaturasisccciicccissiecniacsiiesstecinesraesccsuetecncessasacuscvascscasnased obaciiivessassdocuedeciaelssusivecsieansattadeadeiasiacusseseiveatiacaschisaieasuscuscaseensed 6 EIS tea he Th Ua ooo sec cs cee cote oe aces eect E canta A set cev ase cup sunk extcebbaues ices hades snes tuseesecnctoscteannaseshausvacestacuceuseteceaasbaseeaestven 8 RO oligo o 8 GAO ce RE RAR TEARS ONE REPARAR Ee DE EO RIR ARE wend sueany sabes A cccuuestesagateescacky acu E EE E A T 9 11 Formula o do problema a rear A eh ADD te he eit a a Dn Do aa ca AC bas 9 1 2 Revisdo de Literatura ste tre ea eoir EA E N passando Sad sda nad saga Tape duas pas dedicados 10 1 3 Objetivos geraiS entao asilos DEI TRI Edi pa SONDAS E A Elastin stew dae a et A a ee eed 12 1 4 Objetivos especificos 2 c ciesiad Aidedcal au bal AS ado ide et aid Io SS a do SR DADA
284. racter sticas de qualidade de software ou atributos que podem ser teis para discuss o planejamento e avalia o da qualidade dos produtos de software Boe78 McC77 A ISO IEC definiu tr s modelos relacionados de qualidade de produtos de software qualidade interna qualidade externa e qualidade em uso 1509126 01 e um conjunto de partes relacionadas 15014598 98 O gerenciamento de qualidade de software e a qualidade dos processos de engenharia de software t m um grande impacto na qualidade final do produto Modelos e crit rios que avaliam as capacidades das organiza es de software s o principalmente organiza o de projeto e considera es de gerenciamento e como tais est o cobertos nas KAs Ger ncia de Engenharia de Software e Processo de Engenharia de Software Evidentemente n o poss vel distinguir completamente a qualidade do processo da qualidade do produto Qualidade de Processo discutida na KA Processo de Engenharia de Software deste Guia influencia as caracter sticas dos produtos de software percebidas pelo consumidor 174 Dois importantes padr es de qualidade s o o TicklT e o padr o 1S09001 00 junto com suas diretrizes para aplica o em software ISO90003 04 Outro padr o da industria de qualidade de software o CMMI SEIO2 tamb m discutido na KA Processo de Engenharia de Software O CMMI tem o objetivo de fornecer orienta es para melhorar processos reas de processos espec ficos rel
285. rama Reengenharia Engenharia Reversa Evolu o de Software Categorias de Manuten o Figura 19 T picos da Manuten o de software 2 1 3 5 1 Fundamentos da Manuten o de Software Essa primeira se o introduz os conceitos e terminologia subjacente que formam uma base para a compreens o do papel e o alcance da manuten o de software Os t picos fornecem defini es e enfatizam o porqu da necessidade de manuten o As categorias de manuten o de software s o cr ticas para a compreens o do seu significado subjacente a Defini o e Terminologia Manuten o de Software definida na Norma IEEE para Manuten o de Software IEEE 1219 como a modifica o de um produto de software ap s a entrega para corrigir falhas para melhorar o desempenho ou outros atributos ou adaptar o produto para um ambiente modificado A norma tamb m arrola as atividades de manuten o antes da entrega do de produtos de software mas apenas em um ap ndice da informa o da norma O IEEE EIA 12207 uma norma para o processo do ciclo de vida de software que retrata essencialmente a manuten o como um dos processos prim rios do ciclo de vida e descreve a manuten o como o processo que sofre um produto de software de modifica o de c digo e documenta o associada devido a um problema ou necessidade de melhoria O objetivo modificar o software atual 95 enquanto o produto preserve a sua integridade I
286. rcem influ ncia em como os processos de SQM s o organizados e documentados como atividades espec ficas de SQM s o selecionadas que recursos s o necess rios e quais devem impor limites sobre os esfor os Em casos onde falhas de sistema podem ter consequ ncias extremamente severas depend ncia geral de hardware software e humana o principal requisito de qualidade se posicionando acima das funcionalidades b sicas Depend ncia de software inclui caracter sticas como toler ncia a falha seguran a usabilidade Confiabilidade tamb m um crit rio que pode ser definido em termos de depend ncia 1509126 Uma base liter ria para sistemas deve ser indispens vel sistemas de alta confian a ou alta integridade A terminologia para sistemas el tricos e mec nicos tradicionais que podem n o incluir software tem sido importada para discutir amea as ou perigos riscos integridade de sistema e conceitos relacionados e pode ser encontrada nas refer ncias citadas para esta se o O nivel de integridade determinado baseado nas poss veis consequ ncias de falhas no software e na probabilidade das falhas Para softwares no qual a seguran a ou garantia importante podem ser utilizadas t cnicas como an lise de perigo ou amea a para seguran a a fim de se desenvolver uma atividade de planejamento que identificaria potenciais pontos de problemas O hist rico de falha 184 semelhantes no software tamb m pode ajudar na
287. re outros Consulte as KAs Gerenciamento de Engenharia de Software e Gerenciamento de Configura o de Software para material relacionado O prop sito de uma revis o t cnica avaliar um produto de software para determinar se ele adequado para o uso planejado O objetivo identificar inconsist ncias a partir de normas e especifica es aprovadas Os resultados dever o fornecer evid ncias confirmando ou n o que o produto cumpre as especifica es e adere aos padr es necess rios e que mudan as s o controladas IEEE1028 97 Devem ser estabelecidos pap is especificos em uma revisao t cnica um tomador de decis es um lider de revis es um relator e uma equipe t cnica para dar assist ncia s atividades de revis o Uma revis o t cnica requer que entradas obrigat rias estejam no lugar e em ordem para proceder e Declara o de objetivos 181 Um espec fico produto de software e O espec fico plano de gerenciamento de projeto e Alista de assuntos associados com este produto O procedimento de revis o t cnica A equipe acompanha os procedimentos de revis o Uma pessoa qualificada tecnicamente apresenta uma vis o geral do produto e a an lise realizada durante uma ou mais reuni es A revis o t cnica estar completa uma vez que forem finalizadas todas as atividades listadas na an lise O prop sito de uma inspe o descobrir e identificar anomalias nos produto de software IEEE1028 97 Dua
288. re processos e resultados T picos da KA Ferramentas e M todos da Engenharia de Software T picos para a KA Qualidade de Software T picos x refer ncias 7 T picos x refer ncias 8 T picos x refer ncias 9 Disciplinas relacionadas Engenharia de Software Categorias de Conhecimento 1 Introdu o 1 1 Formula o do problema A Engenharia de Software uma rea do conhecimento da computa o voltada para a especifica o desenvolvimento e manuten o de sistemas de software aplicando tecnologias e pr ticas de ger ncia de projetos e outras disciplinas objetivando organiza o produtividade e qualidade Os fundamentos cient ficos para a Engenharia de Software envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro especificar projetar implementar e manter sistemas de software avaliando e garantindo suas qualidades Hoje em dia encontramos software em todas as partes Est o nos celulares nos aparelhos de cozinha equipamentos m dicos brinquedos etc Linhas de c digo est o presentes em todos estes produtos e a cada dia temos mais produtos surgindo Tudo isso sem entrarmos no campo das aplica es web dos sistemas empresariais cient ficos educacionais internet e por a vai Com toda essa demanda a Engenharia de Software ainda uma rea nova com poucas institui es que oferecem cursos de gradua o Em 1995 o padr o internacional ISO IEC 12207 serviu de subs dio para a elabora
289. reitos Autorais Todas as propriedades intelectuais associadas com o Guia do Corpo de Conhecimento de Engenharia de Software permanecer o com a Sociedade de Computa o IEEE Foi pedido aos Editores Associados das reas do Conhecimento que assinassem um formul rio de libera o de direitos autorias Tamb m entendido que o Guia do Corpo de Conhecimento de Engenharia de Software ser posto em dom nio p blico pela Sociedade de Computa o IEEE gratuita por meio de tecnologia web ou por outros meios 209 2 1 4 2 Ap ndice B 2 1 4 2 1 Evolu o do SWEBOK Apesar de guia para o Corpo de conhecimento de engenharia de software ser uma refer ncia em atingir uma grande concord ncia no conte do da disciplina de engenharia de software n o o fim de um processo O guia de 2004 simplesmente a edi o corrente do guia que continuar evoluindo para corresponder as necessidades da comunidade de engenharia de software O planejamento da evolu o ainda n o est completo mas um esbo o da tentativa do processo oferecido nessa se o Como foi descrito este processo est sendo aprovado pelo Board do Conselho de projetos industriais e resumido pelo board de governadores da Sociedade de Computa o IEEE mas ainda n o est financiada ou implementada 2 1 4 2 2 Stakeholders A Ado o me larga escala do Guia SWEBOK tem produzido uma comunidade substancial de partes envolvidas em adi o pr pria Sociedade de Computa
290. requerem um relat rio problema PR que deve em primeiro lugar ser analisado e traduzido em termos de software Dor02 realizado ap s a entrada de um pedido de mudan a de software no gerenciamento de configura o processo Arthur Art88 afirma que e Determina o do mbito de uma mudan a no sentido de planejar e executar trabalhos e Desenvolvimento de estimativas precisas dos recursos necess rios para executar o trabalho 100 e An lise dos custos beneficios das altera es solicitadas e Comunica o a terceiro da complexidade de uma dada mudan a A gravidade de um problema frequentemente utilizada para decidir como e quando um problema ser corrigido O engenheiro de software ent o identifica os componentes afetados V rias solu es potenciais s o apresentadas e em seguida feita uma recomenda o quanto ao melhor curso de a o O Software projetado com a manuten o em mente facilita e muito a avalia o de impacto Mais informa es podem ser encontradas na Ger ncia de Configura o de Software KA Capacidade de Manuten o I5014764 99 s6 856 8 1 Pfl01 c9s9 4 Pig97 c16 Como que um acompanhamento pode promover as quest es da capacidade de manuten o durante o desenvolvimento O IEEE IEEE610 12 90 define capacidade de manuten o como a facilidade com que pode o software ser mantido refor ado adaptado corrigido ou satisfazer requisitos especificados ISO IEC define capacidade
291. riar um software que tenha valor e este valor pode ou n o pode ser quantificado como um custo O cliente ter algum custo m ximo em mente em troca do qual se espera que o prop sito b sico do software seja cumprido O cliente tamb m pode ter alguma 173 expectativa sobre a qualidade do software s vezes clientes podem n o ter pensado nas quest es de qualidade ou nos custos relacionados a ela A caracter stica meramente decorativa ou essencial ao software Se a resposta se encontra em algum ponto entre as duas op es como quase sempre o caso importante que o cliente fa a parte do processo de decis o e esteja completamente a par dos custos e benef cios O ideal que a maioria destas decis es seja feita no processo de defini o de requisitos do software veja a KA Requisitos de Software mas estas quest es tamb m podem surgir ao longo do ciclo de vida do software N o h nenhuma regra definida para como estas decis es devem ser tomadas mas o engenheiro de software deve apresentar as alternativas de qualidade e os seus custos Uma discuss o relativa ao custo e ao valor dos requisitos de qualidade pode ser encontrada em Wei96 c11 c Modelos e Caracter sticas da Qualidade A terminologia para caracter sticas de qualidade de software diferem entre os modelos podendo haver diferen as entre o n mero de n veis de hierarquia e a quantidade total de caracter sticas V rios autores produziram modelos de ca
292. rincipalmente p Edition indicado para aquisi es que incluem desenvolvimento ou modifica o em vez de compra de software de prateleira IEEE Std Padr o IEEE para documenta o Este padr o fornece os requisitos m nimos para a 1063 2001 de software de usu rio estrutura conte do e formato da documenta o de P S usu rio impressos e eletr nicos IEEE Std Padr o IEEE para Processos de Este padr o descreve uma aproxima o para a 1074 1997 Ciclo de Vida de Desenvolvimento defini o dos processos de ciclo de vida do software P de Software IEEE Std Guia IEEE para ferramentas CASE Este padr o o primeiro de uma s rie planejada de 1175 1 de Interconex o Classifica o e padr es sobre a integra o de ferramentas CASE 2002 Descri o dentro de um ambiente produtivo de engenharia de P software Esta parte descreve conceitos fundamentais e introduz as partes restantes planejadas 217 x o z 9 m m m_m p N mero s SE s 83 g EE g3 E TE TEE gs Nome padr o Descri o T2 50 Es so z3 253 253 239 525 Fe pages 33 se 8852 58 bl Gn5 50 850558 J 2 8 8 8 0 8 IEEE Std Padr o IEEE para Manuten o de Este padr o descreve um processo para manuten o 5 1219 1998 Software de software e seu gerenciamento IEEE Std Padr o IEEE para Aplica o e Este padr o descreve as atividades dos sistemas de 1220 1998 Gerenciamen
293. rnacionais e outras foram planejadas para o pr ximo ano O segundo dos objetivos o desejo de estabelecer um limite da engenharia de software motiva a organiza o fundamental do guia O material que reconhecido como sendo parte desta disciplina organizado nas dez primeiras reas de Conhecimento Knowledge Areas KA enumeradas na Figura 1 Cada uma dessas 16 KAs tratada como um cap tulo neste guia Requisitos de Software Design de Software Constru o de Software Teste de Software Manuten o de Software Ger ncia de Configura o de Software Ger ncia da Engenharia de Software Processo de Engenharia de Software Ferramentas e M todos da Engenharia de Software Qualidade de Software Figura 1 reas de Conhecimento KA do SWEBOK No estabelecimento de um limite tamb m importante identificar que disciplinas compartilham este limite e muitas vezes uma intersec o comum com a engenharia de software Para este fim o Guia tamb m reconhece oito disciplinas relacionadas enumeradas na figura 2 Engenheiros de software naturalmente devem ter conhecimento do material desses campos e as descri es das KAs podem fazer refer ncia a eles Contudo n o um objetivo do Guia caracterizar o conhecimento das disciplinas relacionadas mas ao inv s que conhecimento visto como espec fico engenharia de software Administra o Ergonomia de Software
294. rojeto alcan a o fim quando todos os planos e processos envolvidos tenham sido formalizados e completados Neste est gio o crit rio para o sucesso do projeto revisto Uma vez que o fechamento t rmino seja estabelecido atividades post mortem de melhoria do processo e de arquivamento s o realizadas 143 a Determinando o Fechamento As tarefas como especificada nos planos s o completadas e o alcance satisfat rio da completude dos crit rios confirmado Todos os produtos planejados s o entregues com caracter sticas aceit veis Requisitos s o verificados e confirmados como satisfeitos e os objetivos do projeto s o alcan ados Esses processos normalmente envolvem todos os stakeholders e resultam na documenta o da aceita o do cliente e quaisquer relatos de problemas remanescentes reconhecidos b Atividades de Fechamento Ap s o fechamento ser confirmado o arquivamento dos materiais do projeto toma lugar alinhado com a concord ncia do stakeholder quanto a m todos localiza o e dura o A base de dados de mensura es medi es da organiza o atualizada com os dados finais do projeto e an lises p s projeto s o realizadas O post mortem de um projeto feito de forma que quest es problemas e oportunidades encontradas durante o processo particularmente atrav s de revis es e avalia es veja sub rea 4 An lises e Avalia es s o analisadas e li es s o desenhadas a partir do processo e alimentam
295. rte ao ao processo de ciclo de vida do software IEEE23307 096 beneficiando o gerenciamento de projeto as atividades de desenvolvimento e manuten o 113 atividades de garantia e a cliente e usu rios do produto final O conceito de ger ncia de configura o aplica a todos os itens a serem controlados embora existam algumas diferen as na implementa o entre ger ncia de configura o de hardware e ger ncia de configura o de software SCM est intimamente relacionado com a atividade de garantia de qualidade de software SQA Como definido na Qualidade de Software KA processos SQA fornecem garantia que os produtos de software e processos de ciclo de vida projeto est o em conformidade com suas especifica es de requisitos pelo planejamento articula o e execu o de um conjunto de atividade para fornecer confian a adequada que a qualidade est sendo constru da no software Atividades de SCM ajudam na realiza o das metas de SQA Em alguns contextos projetos veja por exemplo IEEE 730 02 especificam requisitos de SQA descrevendo certas atividades de SCM As atividade de SCM s o ger ncia e planejamento dos processos de SCM identifica o e configura o de software controle configura o de software estimar o status da configura o de software auditoria da configura o de software e a gest o de lan amento e entrega do software 2 1 3 6 1 Gerenciamento dos Processos SCM SCM controla a evolu
296. rutura de dados C Design baseado em componentes C Outros m todos C 229 Reparti o dos T picos N vel de Constru o de Software Taxonomia Reparti o dos T picos Nivende 4 Medidas Relacionadas ao Teste TESE Avalia o do programa sob o teste AN 1 Fundamentos de Constru o de software Avalia o dos testes executados AN Minimizar complexidade AN 9 Processo de Teste Antecipa o de mudan a AN Considera es pr ticas C Constru o para verifica o AN Atividades de Teste AP Normas de constru o AP 2 Gest o de constru o Manuten o de Software Modelos de constru o C Reparti o dos T picos N vel de Planejamento de constru o AP Taxonomia Medi o de constru o AP 1 Fundamentos da Manuten o de software 3 Considera es pr ticas Defini es e tecnologia C Design de constru o AN Natureza da manuten o C Linguagens de constru o AP Necessidade de manuten o C Codificando AN Maioria dos custos de manuten o C Testando a constru o AP Evolu o de software C Qualidade da constru o AN Categorias de manuten o AP Integra o AP 2 Quest es chave na manuten o de software Quest es t cnicas C Testes de Software Quest es gerenciais AP Reparti o dos T picos N ve
297. s e canais de 176 avalia o Art93 Os processos de gest o de qualidade de software consistem de muitas atividades Algumas podem encontrar defeitos diretamente enquanto outras indicam onde an lises adicionais podem ser valiosas Estas tamb m s o referenciadas como atividades de busca direta de defeito Muitas atividades frequentemente se enquadram nos dois grupos Planejamento para qualidade de software envolve 1 Definir os requisitos do produto em termos de suas caracter sticas de qualidade descrito em mais detalhe na KA Gest o da Engenharia de Software 2 Planejar os processos para alcan ar o produto requerido descrito nas KAs Projeto de Software e Constru o de Software Estes aspectos diferem por exemplo dos processos de planejamento SQM que confrontam o planejamento de caracter sticas de qualidade com a atual implementa o desses planos Os processos de ger ncia de qualidade de software devem abordar a forma como os produtos de software precisam satisfazer os requisitos do cliente e das partes interessadas stakeholders prover valor para os clientes e outras partes stakeholders e prover qualidade de software necess ria para satisfazer os requisitos SQM pode ser usado para avaliar tanto os produtos intermedi rios quanto o produto final Alguns dos espec ficos processos SQM est o definidos no padr o IEEE12207 0 96 Processo de garantia da qualidade e Processo de verifica o Processo de
298. s informa es t cnicas servi os e outros elementos de suporte Requisitos de Sistema Requisitos para o sistema como um todo Requisitos de Software Num sistema que possui componentes de software requisitos de software s o derivados dos requisitos do sistema e alocados ao software Requisitos do Usu rio O guia define requisitos do usu rio como sendo requisitos dos usu rios do sistema ou usu rios finais 2 1 3 1 2 Processo de Requisitos a Modelos de Processo N o uma atividade discreta mas cobre desde o in cio at o final do projeto sendo refinado continuamente durante todo o ciclo de vida Identifica os Requisitos de software como itens de configura o e os gerencia usando as pr ticas de GC Customizado de acordo com o contexto da Organiza o e do Projeto Relaciona se com atividades de Elicita o An lise Especifica o e Valida o Inclui atividades de Pesquisa de Mercado e Factibilidade b Atores de Processo Define os papeis dos participantes do processo e Interdisciplinar Especialistas de requisitos fazem media o entre os especialistas de dom nio e demais interessados stakeholders Exemplos t picos de stakeholders Usu rios os que ir o operar o software 34 Clientes mercado alvo e os que lucram com o produto Analistas de Mercado especialistas em necessidades do mercado Agentes Reguladores depende do dom nio da aplica o bancos transporte com rcio Engenheir
299. s o de teste de conformidade de componentes e produtos COTS utilizados no produto existe agora um padr o para pacotes de software IEEE 1465 98 Em alguns casos uma organiza o de V amp V independente pode ser convidada para acompanhar o processo de teste e s vezes testemunhar a execu o para garantir que ele seja conduzido conforme procedimentos especificados Novamente V amp V pode ser chamada para avaliar o teste propriamente dito adequa o de planos e procedimento e adequa o e precis o de resultados Outro tipo de teste que pode cair sob a pauta da organiza o de V amp V o teste de terceiros O terceiro n o o desenvolvedor nem de qualquer forma 188 associado com o desenvolvimento do produto O terceiro um mecanismo independente normalmente credenciado por algum rg o da autoridade O seu objetivo testar um produto para conformidade de um conjunto espec fico de requisitos d M tricas da Qualidade de Software Os modelos de qualidade de produto de software frequentemente incluem m tricas para determinar o grau de cada caracter stica de qualidade atingida pelo produto Se selecionadas corretamente m tricas podem apoiar a qualidade de software entre outros aspectos de ciclo de vida dos processos em m ltiplas formas Elas podem ajudar no gerenciamento do processo e em tomadas de decis o Elas podem encontrar reas problem ticas e gargalos no processo de software e elas podem ajudar
300. s vel de condi es e de a es Uma t cnica relacionada a representa o gr fica de causa efeito Pfl01 c9 e Baseada em m quina de estado finito Jor02 c8 Modelando um programa 80 como uma m quina de estado finito os testes podem ser selecionados a fim cobrir estados e transi es nela Teste das especifica es formais Zhu97 s2 2 Ber91 Dic93 Hor95 Dar as especifica es em uma linguagem formal permite a deriva o autom tica de casos de teste funcionais e ao mesmo tempo fornece uma sa da de refer ncia um or culo para verificar os resultados do teste Os m todos existem derivando casos de teste de especifica es modelo baseadas Dic93 Hor95 ou alg bricas Ber91 Teste aleat rio Bei90 c13 Kan99 c7 Os testes s o gerados puramente em aleat rio para n o ser confundidos com o teste estat stico do perfil operacional como descritos no sub t pico 3 5 1 perfil operacional Esta forma de teste cai sob o t tulo da entrada de especifica o baseada desde que pelo menos o dom nio da entrada seja conhecido para poder escolher pontos aleat rios dentro dele c t cnicas c digo baseadas Crit rios ipecaconhas de flor branca Bei90 c3 Jor02 c10 Zhu97 Os crit rios de cobertura ipecaconhas de flor branca tem o objetivo de cobrir todas as indica es ou blocos de indica es em um programa ou combina es espec ficas deles Diversos crit rios de cobertura foram propostos como
301. s 95 reports pdf tr001 95 pdf http emec mec gov br em 7 de janeiro de 2011 Http pt wikipedia org wiki Friedrich_Ludwig_Bauer em 11 01 2011 Http Awapedia mobi pt engenharia de software em 11 01 11 colocar refer ncia Institute CMU SEI 96 HB 001 1996 em http www sei cmu edu pub documents 96 reports pdf hb001 96 pdf Method Description Software Engineering Institute CMU SEI 96 TR 007 1996 em http www sei org eoc G47 index html Software Process Newsletter vol 11 1998 pp 18 21 em http www seg iit nrc ca SPN Technical Report SEL 95 102 April 1996 em http sel gsfc nasa gov website documents online doc 95 1 02 pdf 241
302. s casos onde as mudan as est o para ser praticadas antes de um amplo emprego dessas mudan as Considera es devem ser feitas quanto aos recursos necess rios para o emprego com sucesso dos novos procedimentos ou medidas ISO 15939 02 5 2 6 2 Adquira e empregue tecnologias de apoio Isto inclui a avalia o de tecnologias de apoio dispon veis sele o das tecnologias mais apropriadas aquisi o e emprego dessas tecnologias ISO 15939 02 5 2 7 c Execute o Processo de Mensura o Medi o Integre os procedimentos de medi o com os processos relevantes Os procedimentos de medi o tais como coleta de dados devem ser integrados nos processos que eles est o medindo Isto pode envolver a mudan a dos processos atuais para acomodar a coleta de dados ou gera o de atividades Ela pode envolver tamb m a an lise dos processos atuais para minimizar os esfor os adicionais e a avalia o do efeito sobre os empregados para garantir que os procedimentos de medi o ser o aceitos Quest es morais e outros fatores humanos precisam ser considerados Adicionalmente os procedimentos de medidas devem ser comunicados aqueles que fornecem os dados pode ser preciso providenciar treinamento e apoio suporte deve tipicamente ser providenciado An lise de dados e procedimentos de divulga o de relat rios devem tipicamente ser integrados aos processos e ou projetos organizacionais de uma forma similar ISO 15939 02 5 3 1 Colete dados
303. s em si Discuss o de medi o do processo e do produto apresentado no 120 Processo de Engenharia de Software KA O Programa de medi o de software descrito no Gerenciamento da Engenharia de Software KA As auditorias podem ser realizadas durante o processo de engenharia de software para investigar o estado atual de elementos espec ficos da configura o ou para avaliar a implementa o dos processos de SCM Auditoria no processo de SCM fornece mais um mecanismo formal para o monitoramento de determinados aspectos do processo e pode ser coordenados com a fun o de SQA Veja tamb m sub rea 5 Auditoria configura o de Software Pau93 L2 87 2 1 3 6 2 Identifica o da Configura o de Software A atividade de identifica o de configura o de software identifica itens a serem controlados estabelece esquemas de identifica o para os itens e vers es deles e estabelece as t cnicas e ferramentas para serem usadas em aquisi o e gerenciamento de itens controlados Estas atividades fornecem o b sico para outras atividades SCM a Identificando itens a serem controlados Um primeiro passo no controle de mudan as identificar os itens de software a serem controlados Isto envolve a compreens o da configura o de software dentro do contexto do sistema de configura o selecionando itens de configura o de software desenvolvendo uma estrat gia para classifica o dos itens de software e descrever as suas rela
304. s importantes diferen as entre inspe es e revis es s o as seguintes Um indiv duo que ocupe uma posi o de gerenciamento sobre qualquer membro da equipe de inspe o n o deve participar da inspe o Uma inspe o deve ser conduzida por um facilitador imparcial treinado em t cnicas de inspe o Inspe es de software sempre envolvem o autor de um produto intermedi rio ou final enquanto outras revis es n o o fazem Inspe es tamb m incluem um l der de inspe o um relator um leitor e alguns 2 a 5 inspetores Os membros de uma equipe de inspe o podem possuir diferentes especializa es como especializa o no dom nio especializa o em m todos de design ou especializa o em linguagens As inspe es s o geralmente conduzidas em uma parte relativamente pequena do produto a cada momento Cada membro da equipe deve examinar o produto de software e outra revis o aplicada antes da reuni o de avalia o talvez aplicando uma t cnica anal tica consulte a se o 3 3 3 numa pequena se o do produto ou no produto inteiro com foco em apenas um aspecto por exemplo interface Qualquer anomalia encontrada documentada e enviada ao l der de inspe o Durante o processo o l der de inspe o conduz a sess o e verifica se todos os participantes est o preparados para a tarefa Um checklist com anomalias e quest es pertinentes aos assuntos de interesse uma ferramenta comum usada em inspe es
305. s onde eram discutidos os rumos para as normas incluindo as medidas e m tricas para a engenharia de software produtos e processos O planejamento resultou tamb m no padr o IEEE 1002 padr o de taxonomia de engenharia de software 1986 que proporcionou uma nova vis o de 14 engenharia de software O padr o descreve a forma e conte do da taxonomia dos padr es de engenharia de software Ele explica v rios tipos de padr es seus relacionamentos funcionais e externos bem como o papel das v rias fun es participantes no ciclo de vida do software Em 1990 o planejamento para um padr o internacional com uma vis o geral foi iniciado Este planejamento foi focado em conciliar os pontos de vista de processo de software da IEEE 1074 e revisado pelo padr o U S DoD 2167A Esta revis o foi finalmente publicada como DoD Std 498 O padr o internacional foi terminado em 1995 com a designa o ISO IEC 12207 e dado o t tulo de padr o para os processos de ciclo de vida do software O padr o ISO IEC 12207 forneceu um importante ponto de partida para o corpo de conhecimentos deste guia Foi o Conselho de tutores do IEEE Computer Society que aprovou a mo o apresentada em maio de 1993 por Fletcher Buckley que resultou na elebora o do guia O conselho da Association for Computing Machinery ACM aprovou a referida mo o em agosto de 1993 As duas propostas levaram a cria o de uma comiss o mista sob a lideran a de Mario Barbacci e Stuart
306. s pessoas em diferentes n veis de organiza o e de ambientes no qual o software opera Atributos de expressam Classifica o de prioridade para habilitar trade offs em face de recursos requisitos al m das propriedades comportamentais que finitos Status que permita acompanhar e monitorar o progresso do projeto Identifica o nica para que possa ser controlado pela Ger ncia de Configura o e gerenciado durante todo o ciclo de vida 32 b Requisitos de Produto e Processo Requisitos de Produto Requisitos sobre o software a ser desenvolvido Por exemplo O software deve verificar se um aluno cumpriu os pr requisitos antes de aceitar a sua matr cula numa disciplina Requisitos de Processo s o essencialmente restri es impostas ao desenvolvimento do software tais como linguagem de programa o processos e t cnicas de desenvolvimento Podem ser impl citos ou expl citos Podem ser impostos pela organiza o desenvolvedora pelo cliente ou por terceiros c Requisitos Funcionais e N o Funcionais Requisitos Funcionais capabilities Descreve fun es que o software deve executar como por exemplo controlar fluxo de caixa Requisitos N o Funcionais restri es ou requisitos de qualidade S o aqueles que agem para restringir uma solu o S o conhecidos como restri es ou requisitos de qualidade que podem ser classificados em Requisitos de Desempenho Requisitos de Seguran a Requisitos de Manut
307. s s o as consequ ncias prov veis avalia o cr tica de riscos quais s o os riscos mais significativos em termos de exposi o o que podemos fazer em termos de inicia o compensa o de risco e conting ncia de planejamento formula o de uma estrat gia para lidar com riscos e para gerenciar o perfil de risco s o todas realizadas M todos de avalia o de riscos por exemplo rvores de decis o e simula es de processo devem ser usados para destacar e avaliar os riscos A pol tica de abandono de projeto deve ser determinada neste ponto na discuss o com todas partes interessadas Dor02 v2c7 Pfl01 c3 Pre04 C25 Rei02 C11 Som05 c4 Tha97 c4 Aspectos de riscos de software como a tend ncia de engenheiros de software em acrescentarem recursos indesej veis ou os riscos ligados natureza intang vel do software devem influenciar a gest o de risco do projeto 139 f Gest o de Qualidade A qualidade definida em termos de atributos pertinentes ao projeto espec fico e qualquer produto s associado s possivelmente tanto em requisitos quantitativos quanto qualitativos Essas caracter sticas de qualidade ser o determinadas na especifica o dos requerimentos detalhados do software Veja tamb m os Requerimentos de Software KA Os limiares para ader ncia qualidade s o definidos para cada indicador de acordo com as expectativas dos intervenientes com rela o ao software Procedimentos relativos SQA em
308. s9 2 Car94 McC02 As ind strias terceirizadas est o a tornar se uma grande ind stria As grandes corpora es est o terceirizando portf lios inteiros de sistemas de software incluindo a manuten o de software Mas muitas vezes a terceiriza o uma op o selecionada de forma n o absoluta por empresas que n o est o dispostas a perder o controle do software usado no seu core business Carey Car94 relata que alguns ir o terceirizar apenas se poderem encontrar maneiras da manuten o de controle estrat gico No entanto as medidas de controle s o dif ceis de encontrar Um dos grandes desafios para os terceirizados determinar o alcance dos servi os de manuten o necess rios e os detalhes contratuais McCracken McC02 afirma que 50 dos terceirizados prestam servi os sem qualquer acordo claro de n vel de servi o As empresas de terceiriza o geralmente gastam muitos meses para avaliar o software que ir entrar em um rela o contratual antes de concretiz la Dor02 Outro desafio identificado a transi o do software para o contratante Pig97 c Estima o do Custo de manuten o Engenheiros de software deve compreender as diferentes categorias de 104 manuten o de software acima discutidas a fim de abordar a quest o da avalia o do custo da manuten o de software Para fins de planejamento calcular custos um aspecto importante de manuten o de software Estima o de Custo Art88
309. scri o z2 c 25 22 25 230 250 sal 2398 Es pedro so gp 852 59 aso gol gol seas aS J 2 o 8 8 8 0 8 1462 1998 internacional isso IEC 14102 1995 avalia o e sele o de ferramentas CASE INSO EC Tecnologia da Informa o 14102 199 Direcionamento para a Avalia o e 5 Sele o de Ferramentas CASE IEEE Std Padr o IEEE Ado o do Padr o Este padr o descreve requisitos de qualidade 1465 1998 Internacional ISO IEC especificamente adequados para pacotes de software INSO NEC 12119 1994 E Tecnologia da e orienta es sobre testes de pacotes contra tais 12119 Informa o Pacotes de Software requisitos Qualidades de Requisitos e Testes IEEE Std IEEE Pr ticas Recomendadas para Este documento recomenda uma estrutura conceitual 1471 2000 Descri o de Arquitetura de e conte do para a descri o arquitetural de sistemas Software em Sistemas de software concentrados Concentrados IEEE Std IEEE Guia Ado o do Padr o Este documento a ado o da IEEE do Projeto de 1490 1998 PMI Um Guia para o Projeto de Gest o do Corpo de Conhecimento definido pelo Gest o Corpo de Conhecimento Instituto de Gerenciamento de Projetos PMI Ele identifica e descreve os conhecimentos geralmente aceitos sobre gest o de projetos IEEE Std Padr o IEEE para Tecnologia da Este padr o fornece processos de ciclo de vida para 1517 1999 Informa o Processo do Ciclo de reutiliza o sistem tica do so
310. se baseiam em aproxima es de desenvolvimento de software em torno de m ltiplas formas de prototipa o 2 1 2 14 KA Qualidade de Software A KA Qualidade de Software aborda considera es relativas qualidade de software que v o al m dos processos de ciclo de vida de software Um vez que a qualidade de software um assunto presente em todas as partes na engenharia de software tamb m considerado em muitas outras KAs e o leitor notar pontos desta KA nas outras KAs do Guia Esta KA possui tr s sub reas A primeira sub rea descreve Fundamentos da Qualidade de Software como uma cultura e tica na engenharia de software os valores e custos da qualidade caracter sticas de modelos e qualidade e melhoria da qualidade A segunda sub rea trata dos Processos de Gerenciamento da Qualidade do Software Os t picos tratados aqui s o garantia da qualidade de software verifica o e valida o e por fim revis es e auditorias A terceira e ltima sub rea descreve Considera es Pr ticas relacionadas qualidade de software Os t picos s o requisitos de qualidade de software caracteriza o de defeito t cnicas de gerenciamento da qualidade do software e mensura o da qualidade do software 2 1 2 15 KA Disciplinas Relacionadas com Engenharia de Software O ltimo cap tulo trata das disciplinas relacionadas com a engenharia de software Para circunscrever a engenharia de software necess rio identificar as
311. seada no modelo hist rico do tamanho do esfor o quando os dados dispon veis e relevantes ou outros m todos como peritos s o avaliados As depend ncias de tarefa s o estabelecidas e os gargalos potenciais s o identificados usando m todos convenientes por exemplo an lise de caminho cr tico Os gargalos s o resolvidos onde poss vel e o tempo estimado de tarefas com tempos de partida projetados dura es e tempo limite para produ o s o produzidos por exemplo um gr fico PERT Requerimentos de recursos pessoas ferramentas s o traduzidos em estimativas de custos Dor02 v2c7 Fen98 c12 Pfl01 c3 Pre04 c23 c24 Rei02 c5 c6 Som05 c4 c23 Tha97 c5 Isto uma atividade altamente iterativa que deve ser negociada e revisada at que o consenso seja conseguido entre todas as partes afetadas principalmente engenharia e ger ncia d Aloca o de Recurso Equipamentos instala es e as pessoas est o associados tarefas agendadas incluindo a atribui o de responsabilidades para a conclus o utilizando por exemplo um gr fico Gantt Esta atividade informada e condicionada pela disponibilidade de recursos e a sua utiliza o otimizada nestas condi es bem como pelas quest es relativas ao pessoal por exemplo produtividade dos indiv duos equipes equipe din mica e estruturas organizacionais e Gest o de Riscos Identifica o e an lise de risco o que pode dar errado como e por qu e quai
312. so assegurar que os processos planejados sejam apropriados e depois implementados de acordo com o planejamento e que processos de medi es pertinentes sejam fornecidos organiza o apropriada O planejamento SQA define os meios que ser o usados para assegurar que o desenvolvimento de software para um certo produto satisfa a os requisitos dos usu rios e seja da melhor qualidade poss vel dentro das restri es do projeto Para faz lo em primeiro lugar preciso garantir que os objetivos da qualidade estejam claramente definidos e compreendidos preciso considerar gerenciamento desenvolvimento e planos de manuten o para o software Para detalhes consulte a norma IEEE 730 98 As atividades e tarefas espec ficas de qualidade s o definidas com os seus custos e requerimentos de recursos seus objetivos globais de gest o e o seu cronograma em rela o a esses objetivos na gest o da engenharia de software desenvolvimento ou planos de manuten o O planejamento SQA deve ser consistente com o plano de gest o de configura o do software consulte a KA Gest o de Configura o de Software O planejamento SQA identifica documentos normas pr ticas e conven es que regem o projeto e como eles ser o conferidos e monitorados para garantir conformidade e adequa o O planejamento SQA tamb m identifica m tricas t cnicas estat sticas procedimentos para reportar problemas e a es de corre o recursos como ferrament
313. so ISO IEC Tecnologia da Informa o N veis Este padr o internacional introduz o conceito de n vel 15026 199 de Integridade de Software e de integridade de software e requisitos de integridade 8 Sistemas de software Ele define o conceito associado com S S P n veis de integridade e requisitos de integridade de software e as exig ncias locais de cada processo ISO IEC Tecnologia da Informa o Guia Este documento um guia para uso da isso lEC TR para ISO IEC 12207 Processos de 12207 E 15271 199 Ciclo de Vida do Software 8 ISO IEC Engenharia de Sistemas Este padrao fornece uma estrutura de processos 15288 200 processos de Ciclo de Vida de usados em todo o ciclo de vida de sistemas feitos 2 Sistema pelo homem ISO IEC Engenharia de Software Este relat rio t cnico agora a ser revisto como um P 223 7 9 Fl Sol Po Bu Perl p g di o Nome padr o Descri o 5 z 5 e 5 5 2 3 5 F E E 5 E E z a E z S z z D su Se 3 0 do eo Boo Do pa dos Fa D o Q D D D o Software Avalia o de Processos padr o fornece os requisitos de m todos de TR 15504 avalia o de processo de execu o como base para 9 parts a melhoria do processo ou da determina o Process capacidade and Draft IS 15504 5 parts ISO IEC Engenharia de Software Este padr o fornece um processo de ciclo de vida 15939 200 Processo de
314. so por pequenas organiza es equipes e indiv duos O objetivo do gerenciamento do ciclo de vida do processo de software implementar um novo ou melhores processos nas atuais pr ticas sejam elas individuais de projeto ou organizacional Esta KA n o especifica o gerenciamento de recursos humanos HRM por exemplo como os baseados em pessoas CMM Cur02 e processo de engenharia de sistemas IS01528 028 IEEE 1220 981 Tamb m se deve reconhecer que muitos problemas de processo de engenharia de software estao intimamente relacionados com outras disciplinas tais como o gerenciamento embora tecnologias diferentes sejam usadas 149 2 1 3 8 1 Processo de implementa o e mudan a Este sub rea concentra se na mudan a organizacional Ela descreve a infraestrutura atividades modelos e considera es pr ticas para o processo de implementa o e mudan a descrita aqui a situa o em que os processos s o implantados pela primeira vez por exemplo introdu o de um processo de inspe o em um projeto ou um m todo que abrange todo o ciclo de vida e onde os processos atuais est o mudando por exemplo introdu o de uma ferramenta ou otimiza o de um procedimento Isto tamb m pode ser denominado processo de evolu o Em ambos os casos existe pr ticas que devem ser modificadas Se as modifica es s o grandes ent o mudan as na cultura da organiza o podem ser necess rias Processo de Engenharia de
315. ss ria assim o leitor pode selecionar o material de refer ncia apropriado segundo suas necessidades 2 1 4 1 4 Crit rios e exig ncias para Selecionar Material de Refer ncia a Materiais de refer ncia espec ficos devem ser identificados para cada t pico Cada material de refer ncia naturalmente pode cobrir m ltiplos t picos b Os materiais de refer ncia propostos podem ser cap tulos de livros artigos referenciados de jornais artigos referenciados de confer ncias relat rios t cnicos ou industriais ou qualquer outro tipo de artefato reconhecido como documentos web Eles devem ser dispon veis de maneira geral e n o devem ser de natureza confidencial A refer ncia deve ser t o exata quanto poss vel identificando quais cap tulos ou se es espec ficas s o relevantes c Os materiais de refer ncia propostos devem ser em ingl s d Um montante razo vel de materiais de refer ncia deve ser selecionados para cada rea do Conhecimento As seguintes diretrizes devem ser usadas na determina o do quanto razo vel e Se o material de refer ncia foi escrito de uma maneira coerente seguindo a divis o proposta de t picos e em um estilo uniforme por exemplo em um novo livro baseado na descri o da reas do 201 Conhecimento proposta uma m dia razo vel de n mero de p ginas seria 500 Contudo este meta pode n o ser ating vel selecionando o material de refer ncia existente devido a diferen as em es
316. ste sub t pico Tais ferramentas desempenham m ltiplas fun es e portanto interagem potencialmente com o ciclo de vida a ser executado pelo processo de software Ambiente centrado no processo de engenharia de software Rei96 Gar96 estes ambientes incorporam explicitamente informa es no processo do ciclo de vida do software e orientam o monitoramento do usu rio de acordo com os processo definidos i Ferramentas de Qualidade do Software Ferramentas de qualidade s o divididas em duas categorias verifica o e an lise de ferramentas Ferramentas de auditoria e an lise Estas ferramentas s o usadas para auxiliar na an lise e auditorias Ferramentas de an lise est tica Cla96 Pfl01 Rei96 estas ferramentas s o usadas para analisar artefatos de software tais como an lises sint tica e sem ntica bem como dados controle de fluxo e an lise de depend ncias Essas ferramentas s o destinadas para verificar artefatos de softwares de modo analisar conformidade ou para verifica o das propriedades desejadas j Ferramentas para Problemas Variados Este t pico abrange assuntos aplic veis para todas as classes de 169 ferramentas Existem tr s categorias bem identificadas ferramentas de integra o t cnica meta ferramentas e ferramentas de evolu o e Ferramentas de integra o t cnica Pfl01 Rei96 Som01 Bro94 Ferramentas de integra o s o importantes para estruturar pessoas a ferramentas Es
317. stema para especifica o de 118 interface e controle e podem incluir especifica es da interface planos de controle de interfaces documentos de controle de interfaces Nesse caso planejamento SCM para controle de interface tem lugar no contexto do n vel de sistema do processo A discuss o da performance das atividades do controle de interface dada em Ber92 C12 IEEE 12207 0 96 c6 52 1 Som01 c29 d Plano SCM Os resultados do planejamento SCM para um determinado projeto s o gravados em um plano de gerenciamento de configura o de software SCMP um documento vivo que serve de refer ncia para o processo de SCM Ele mantido isto atualizado e aprovado conforme necess rio durante o ciclo de vida do software Na implementa o do SCMP normalmente necess rio desenvolver uma s rie de defini o mais detalhada dos procedimentos para a subordina o de forma espec fica os requisitos que ser o realizados durante as atividades do dia a dia Orienta o sobre a cria o e a manuten o de um SCMP com base nas informa es produzidas pelas atividades de planejamento est dispon vel a partir de uma variedade de fontes tais como IEEE828 98 c4 Esta refer ncia estabelece requisitos de informa o a ser inclu da em uma SCMP Tamb m define e descreve seis categorias de SCM informa es a serem inclu das em um SCMP Buc96 c3 Pau93 L2 81 e Introdu o objetivos escopo termos usados e Gerenci
318. stes e Evolu o do Software Lehman foi o primeiro estudioso addressed da manuten o de software e evolu o dos sistemas em 1969 Ao longo de um per odo de vinte anos suas pesquisas levaram formula o de oito Leis de Evolu o Leh97 As principais conclus es incluem o fato de que a manuten o evolutiva e que as decis es sobre a manuten o s o auxiliadas pela compreens o do que acontece com os sistemas e software ao longo do tempo Outra conclus o que o estado de manuten o um desenvolvimento continuado exceto quando h uma entrada extra ou constrangimento ou seja quando o software nunca est conclu do e continua a evoluir Como ele evolui ele cresce mais complexo a menos que se tomem provid ncias para reduzir esta complexidade Desde que os softwares regulares demonstram comportamento e tend ncias estes podem ser medidos As tentativas de desenvolver modelos para estimar os esfor os com a manuten o t m sido feitos e como resultado instrumentos teis de gest o t m sido desenvolvidos Art88 Bel72 Art88 c1s1 0 s1 1 81 2 c11S1 1 s1 2 Leh97 108 124 Bel72 f Categorias de Manuten o Lientz amp Swanson inicialmente definidam tr s categorias de manuten o corretiva adapt vel e perfectiva Lie78 IEEE1219 98 Esta defini o foi posteriormente atualizada pela Norma para a Manuten o de Software Engenharia de Software ISO IEC 14764 para incluir quatro categorias co
319. stes de Software Teste de Software comp e se da verifica o din mica de uma sele o de dom nios de execu es normalmente infinito contra o comportamento esperado Ela inclui cinco sub reas A KA inicia com a descri o de Fundamentos de Testes de Software Primeiro a terminologia de testes de apresentada ent o s o descritos assuntos relacionados com testes de software e finalmente os relacionamentos entre testes e as outras atividades s o descritos A segunda sub rea chamada de N veis de Teste dividida entre os alvos dos testes e os objetivos dos testes A terceira sub rea chamada de T cnicas de Teste A primeira categoria inclui os testes baseados na intui o e experi ncia do testador Um segundo grupo compreende t cnicas baseadas na especifica o seguidas por baseadas no c digo em falhas no uso e baseadas na natureza da aplica o Uma discuss o de como selecionar e combinar as t cnicas apropriadas tamb m apresentada A quarta sub rea cobre Mensura es Relacionadas aos Testes As medidas s o agrupadas conforme o relacionamento de forma a avaliar o programa que esta sofrendo testes e avaliar o os testes executados A ltima sub rea descreve o Processo de Testes e inclui considera es pr ticas e as atividades de teste 23 2 1 2 9 KA de Manuten o de Software Uma vez na opera o as anomalias s o descobertas modifica o no ambientes operacional e novos requisitos dos usu ri
320. ta categoria potencialmente sobrep e com a integra o da categoria do ambiente CASE onde s o aplicadas integra es t cnicas no entanto elas s o suficientemente distintas para merecer sua pr pria categoria S o os modelos t picos de ferramentas de integra o plataformas apresenta o processo dados e controles e Metas ferramentas Metas ferramentas geram outras ferramentas um exemplo cl ssico compilar um c digo compiladores Ferramentas de evolu o Pfl01 IEEE1209 92 IEEE1348 95 Mos92 Val97 Por causa da continua evolu o da engenharia de software ferramentas de evolu o um t pico essencial 2 1 3 9 2 M todos de Engenharia de Software As sub reas dos M todos da Engenharia de Software s o divididas em tr s t picos relacionamento de m todos heuristicos com abordagens informais relacionamento de m todo formal com abordagens matematicamente baseadas e relacionamento de m todos de prototipagem com abordagens em engenharia de software baseada em diferentes formas de prot tipo Estes tr s t picos n o s o separados em partes particularmente eles representam interesses distintos Por exemplo um objeto orientado a m todos pode incorporar t cnicas formais e contar com um prot tipo de verifica o e valida o Tal como ferramentas de engenharia de software s o desenvolvidas tecnologias continuamente Consequentemente a KA evita descrever na medida que poss vel nomear metodologias particul
321. td Padr o IEEE para unidade de teste Este padr o descreve uma abordagem s lida de 1008 1987 de software unidade de teste de software e os conceitos e s p s 5 R 2003 premissas sobre as quais se baseia Ele tamb m fornece informa o orienta o e recursos 215 m o z 9 m m m_m p N mero s SE s 83 g EE g3 8 TF TEE os a Nome padr o Descri o Z2 50 zs o z3 253 253 FFG 525 Fe pene 33 se 8852 58 sea een 85 850588 J E o 8 8 B o 8 IEEE Std Padr o IEEE para verifica o e Este padr o descreve o processo de verifica o e 1012 1998 valida o de software valida o de software que s o usados para e 1012a determinar se os produtos de software satisfazem os 1998 reguisitos da atividade e tamb m se os software satisfazem as necessidades do usu rio para o fim pretendido O escopo inclui an lise avalia o revis o inspe o avalia o e testes de produtos e processos IEEE Std IEEE Pr tica recomendada para Este documento recomenda o conte do e 1016 1998 descri o de design de software organiza o das descri es de design de software P IEEE Std Padr o IEEE para an lise de Este padr o define cinco tipos de an lises de 1028 1997 software software e procedimentos para sua execu o Os S 5 6 R 2002 tipos incluem an lise de gerenciamento an lise t cnica inspe es simula es e auditorias IEEE Std Padr o IEEE Classifica o pa
322. te precisa ser dirigido baseado no risco e pode ser visto como uma estrat gia de administra o de risco Kan99 c2 How76 f O problema dos caminhos invi veis Caminhos invi veis os caminhos de controle de fluxo que n o podem ser exercitados por qualquer dados de entrada s o um significante problema no teste de caminho orientado e particularmente na deriva o automatizada de testes de entrada para t cnicas de teste c digo baseadas Bei90 c3 9 Testabilidade O termo testabilidade de software tem dois significados diferentes mas relacionados por um lado se refere ao grau a que se f cil para o software cumprir um crit rio de cobertura de teste como em Bac90 por outro lado est definida como a probabilidade possivelmente medida estatisticamente que o software ir expor uma falha sob o teste se est defeituoso como em Voa98 Ber96a Ambos os significados s o importantes Bei90 c3 c13 Bac90 Ber96a Voa95 h Rela es de teste com outras atividades 74 Teste de software relacionado a mas diferente de t cnicas est ticas de administra o de qualidade de software provas de exatid o depura o e programa o Por m informativo considerar os testes do ponto de vista de analistas de qualidade de software e de certificadores Teste versus t cnicas est ticas de administra o da qualidade de software Veja tamb m a rea de Conhecimento Qualidade de Software sub rea 2 Processos
323. testar ou manter O resultado de uma an lise de complexidade pode tamb m ser utilizado para desenvolver casos de testes T cnicas de encontrar defeito tais como an lise de controle de fluxo podem tamb m ser utilizadas para apoiar outras atividades Para softwares com muitos algoritmos an lise algor tmica importante especialmente quando um algoritmo incorreto poderia causar um resultado catastr fico H muitas t cnicas de an lise para listar todas aqui A lista e refer ncias fornecidas podem oferecer discernimento na sele o de uma t cnica como tamb m sugest es para uma futura leitura Outros tipos de t cnicas anal ticas mais formais s o conhecidos como m todos formais Eles s o usados para verificar requisitos de software e projeto Prova de corre o aplica a partes cr ticas de software Elas foram principalmente utilizadas na verifica o de partes cruciais de sistemas cr ticos como seguran a espec fica e requisitos de seguran a Nas97 Diferentes tipos de t cnicas din micas s o executados ao longo do desenvolvimento e manuten o do software Geralmente s o t cnicas de teste mas t cnicas como simula o modelo de verifica o e execu o simb lica tamb m 187 podem ser consideradas din micas Leitura de c digo considerada uma t cnica est tica mas engenheiros de software experientes s o capazes de executar o c digo em paralelo enquanto eles o leem Neste caso leitura de c digo tamb
324. ticas que s o exclusivas da manuten o de software como por exemplo e Transi o uma sequ ncia de atividades coordenadas e controladas onde o software transferido progressivamente a partir do desenvolvedor para o mantenedor Dek92 Pig97 e Aceita o Recusa do Pedido de Modifica o o pedido de modifica o por ter certo tamanho esfor o complexidade pode ser rejeitado pelo mantenedor e reencaminhado para um desenvolvedor Dor02 Apr01 e Requisi o de modifica o e sua solicita o ao Help Desk uma fun o de apoio aos usu rios finais o que desencadeia avalia o prioriza o e custeio do pedido de modifica o Ben00 e An lise do impacto ver ponto 2 1 3 para mais detalhes Suporte de Software ajuda e aconselhamento ao usu rio relativo a um pedido de informa o por exemplo regras empresariais a valida o de dados significado e pedidos ad hoc reports Apr03 e Acordos de n vel de servi o SLAs especificam que o dominio dos contratos de manuten o de responsabilidade dos mantenedores Apr01 As atividades de apoio IEEE1219 98 A 7 A 11 IEEE12207 0 96 c6 c7 ITI01 Pig97 c10s10 2 c18 Kaj01 Os mantenedores podem tamb m realizar atividades de apoio tas como planejamento da manuten o de software gest o da configura o de software verifica o e valida o garantia da qualidade de software revis es e auditorias treinamento ao usu rio Outra atividade de apoio do 109
325. tilo sobreposi o e redund ncia com outros materiais de refer ncia selecionados e O montante de material de refer ncia seria razo vel se ele se consistisse do material de estudo da rea do Conhecimento para o exame de licenciamento de engenharia de software que um graduado passaria depois de concluir quatro anos de experi ncia de trabalho e O Guia do Corpo de Conhecimento de Engenharia de Software destinado por defini o para ser seletivo na sua escolha de t picos e materiais de refer ncia associados A lista dos materiais de refer ncia de cada rea do Conhecimento deve ser examinada e ser apresentada como uma sele o informada e razo vel e n o como uma lista definitiva Materiais de refer ncia adicionais podem ser inclu dos na lista Leituras Complementares Essas leituras complementares devem ainda estar relacionadas a divis o de t picos Elas tamb m devem discutir o conhecimento geralmente aceito N o deve haver uma matriz entre o material de refer ncia enumerado em Leituras Complementares e os t picos individuais e Se considerado fact vel e rent vel pela Sociedade de Computa o IEEE o material de refer ncia selecionado ser publicado no Web site do Guia do Corpo de Conhecimento de Engenharia de Software Para facilitar esta tarefa deve ser dada prefer ncia ao referir materiais quais os direitos autorais j pertencem Sociedade de Computa o IEEE Contudo isto n o deve ser visto
326. tipo de teste de desempenho de um sistema depende da identifica o de uma organiza o excelente em um campo e documenta o das suas pr ticas e instrumentos Teste 163 de desempenho de um sistema assume isto se a organiza o proficiente adotar as pr ticas da organiza o excelente esta tamb m ira se tornar excelente Teste de desempenho de um sistema implica avaliar a maturidade de uma organiza o ou a capacidade de seus processos Ele exemplificado pelo processo de avalia o de software Uma vis o geral do processo de avalia o e sua aplica o est prevista no Zah98 2 1 3 9 Ferramentas e M todos da Engenharia de Software Ferramentas de desenvolvimento de software s o as que se destinam a ajudar nos processos de ciclo de vida do software As ferramentas permitem repetir e definir a es automatizadas reduzindo a carga cognitiva sobre a engenharia de software deixando o livre para concentrar se na criatividade e aspectos do processo As ferramentas s o muitas vezes concebidas para apoiar em particular os m todos da engenharia de software reduzindo qualquer carga administrativa associada a m todos aplicados manualmente Como os m todos de engenharia s o destinados a tornar a engenharia de software mais sistem tica eles variam o escopo para suportar tarefas individuais englobando um ciclo de vida completo Os m todos da engenharia de software imp em na sua estrutura metas de fabrica o e atividades
327. to dos Processos de engenharia e processos necess rios ao longo de um Engenharia de Sistemas ciclo de vida do sistema para desenvolver sistemas que unam as necessidades dos clientes e suas e P limita es IEEE Std Padr o IEEE para Planejamento Este padr o descreve o conte do m nimo de um 1228 1994 de Seguran a de Software plano para aspectos de software de desenvolvimento g s p aquisi o manuten o e retirada de um sistema de seguran a cr tica IEEE Std Guia IEEE Para Especifica o de Este documento fornece orienta es sobre o 1233 Requisi es de Desenvolvimento desenvolvimento de um Sistema de Especifica o de 1998 de Sistemas Requisitos abrangendo a identifica o Edition organiza o apresenta o e modifica o dos reguisitos Ele tamb m proporciona orienta o sobre as caracter sticas e qualidades dos requisitos EEE Std Padr o IEEE para Linguagem de Este padr o define a modelagem IDEFO como S S S P 1320 1 Modelagem Funcional Sintaxe e linguagem utilizada para representar as decis es 1998 Sem ntica para IDEFO a es e atividades de uma organiza o ou sistema 218 Q a 9 Re ol wae wae wee og ES me Numero 7 sd SE 49 44 42 Se 29 959 5458 4505 25 padis Nome padr o Descri o F 5 e 5 5 4 3 F 8 5 o 5 9 5 9 E D So o2 ola ao B oD odo Dog 3a 8 8 amp CG cmo go GSqIa IDEFO pode ser usada par
328. tos de configura o de hardware Os procedimentos de instala o tamb m podem ser verificados teste alfa e beta Kan99 c13 Antes que o software seja liberado s vezes ele fornecido a um grupo pequeno mas representativo de potenciais usu rios para o uso experimental interno teste alfa ou o externo teste beta Estes usu rios relatam problemas com o produto O uso alfa e beta frequentemente descontrolado e n o referido sempre dentro de um plano de teste teste de conformidade teste funcional teste de exatid o Per95 c8 Wak99 O teste de conformidade tem por objetivo validar se o comportamento do software testado conforma se a suas especifica es Realiza o e avalia o da confiabilidade Pfl01 c9s 8 4 Pos96 Ajudando na identifica o de falhas testar um meio de melhorar a confiabilidade Pelo TT contraste pela gera o aleat ria de casos de teste de acordo com o perfil operacional as medidas estat sticas de confiabilidade podem ser derivadas Usando modelos incrementais de confiabilidade ambos os objetivos podem ser levados a cabo juntos ver o sub t pico 4 1 4 teste de vida avalia o da confiabilidade teste de regress o Per95 c11 c12 Pfl01 c9s8 1 Rot96 De acordo com IEEE610 12 90 o teste de regress o reteste seletivo de um sistema ou de um componente para verificar que modifica es n o causaram efeitos n o intencionais Na pr tica a ideia mostrar que esse softw
329. trodu o de IEEE 1517 99 Executando reutiliza o de software implica mais do que criar e usar bibliotecas de recursos necess rio formalizar a pr tica de reutiliza o integrando os processos de reutiliza o e atividades no ciclo de vida do software No entanto a reutiliza o suficientemente importante na constru o de software e que inclu da aqui como um t pico 68 As tarefas relacionadas com a reutiliza o na constru o de software durante a codifica o e testes s o IEEE1517 99 Som05 A sele o das unidades reutiliz veis bancos de dados procedimentos de ensaio ou testar dados A avalia o da reutiliza o de c digo ou de teste A comunica o de informa es de reutiliza o sobre o novo c digo testar procedimentos ou testar dados f Qualidade da Constru o Numerosas t cnicas existem para garantir a qualidade de como o c digo constru do As principais t cnicas utilizadas para constru o incluem Bec99 Hun00 IEEE 12207 95 Mag93 McC04 Unidade ensaios e testes de integra o tal como mencionado no t pico 3 4 testes de constru o Primeiro teste de desenvolvimento ver igualmente o teste de software na rea de conhecimento t pico 2 2 objetivos de teste C digo de refor o Utiliza o de afirma es Depura o Revis es t cnicas ver igualmente o software qualidade na rea de conhecimento an lises t cnicas do sub t pico 2 3 2 An lise
330. tros m todos Figura 10 T picos para Design de Software 2 1 3 2 2 Os Pontos Chave no Design de Software Um certo n mero de pontos chave devem ser tratados na concep o de software Alguns s o preocupa es de qualidade Algumas preocupa es s o a qualidade que todos os softwares devem ter por exemplo performance Outra quest o importante a forma de decompor organizar e empacotar componentes de software Isso t o fundamental que todas as abordagens endere am isto em um caminho ou outro Em contraste a isto outros pontos entregam alguns aspectos do comportamento de software que n o est o no dom nio da aplica o mas desejam Bos00 frequentemente cortar funcionalidades do sistema endere ar algo no dom nio do suporte Tais pontos desejam referindo se a aspectos aspectos n o tendem a ser unidades de software funcionais decompostos mas antes propriedades que afetam a performance ou sem ntica dos componentes em caminhos sist micos a Concorr ncia Como decompor o software em processos tarefas e servi o e desejar efici ncia atomicidade sincroniza o e vers es agendadas Mesy97 c30 Pre04 c9 50 b Controle e transporte dos Eventos Como organizar dados e controlar fluxos como trasportar eventos reativos e temporais atrav s de v rios mecanismos tais como invoca o impl cita e call back Pfl01 c5 c Distribui o de Componentes Como distribuir o software baseado no hardware
331. tru o de software ou an lise do impacto das mudan as propostas Adequado controle dessas rela es tamb m importante para apoiar a rastreabilidade A concep o do sistema de identifica o de s tios de import ncia comunit ria devem considerar a necessidade de mapear os elementos identificados com a estrutura de software bem como a necessidade de apoiar a evolu o dos itens de software e seus relacionamentos Uma vers o de um item de software um item espec fico identificado e especificado Ele pode ser pensado como um estado de um item em evolu o Con98 C3 C5 Uma revis o uma nova vers o de um item que se destina a substituir a antiga vers o do item A variante uma nova vers o de um item que ser o adicionados configura o sem substituir a vers o antiga Uma linha de base de software um conjunto de itens de configura o de software formalmente designado e fixado em um tempo espec fico durante o ciclo de vida do software O termo tamb m usado para se referir a uma vers o espec fica de um item de configura o de software que foi acordado Em ambos os casos a base s pode ser alterada atrav s de procedimentos formais de controle de mudan a Uma linha de base juntamente com todas as altera es aprovadas para a linha de base representa a configura o atual aprovado Comumente bases utilizadas s o as bases funcionais atribu das de desenvolvimento e do produto ver por exemplo Ber92 A
332. trutura de descri o das KAs A descri o das KAs s o estruturadas como a seguir Na introdu o uma breve defini o da KA e um resumo do seu respectivo escopo e do relacionamento entre outras KA s o apresentados O desdobramento em t picos que comp e a estrutura central da descri o da KA feita descrevendo a decomposi o da KA em sub reas t picos e sub t picos Para cada t pico ou sub t pico uma descri o curta fornecida junto com uma ou mais refer ncias O material de refer ncia foi escolhido porque se considera que ele constitui a melhor apresenta o do conhecimento quanto ao t pico tratado considerando as limita es impostas escolha de refer ncias Uma matriz liga os t picos ao material de refer ncia A ltima parte da descri o da KA a lista de refer ncias recomendadas O Ap ndice A de cada KA inclui sugest es leituras complementar para aqueles usu rios que desejam aprender mais sobre os t picos da KA O Ap ndice B apresenta a lista de padr es mais relevantes para a KA 2 1 2 5 KA de Requisitos de Software Um requisito definido como uma propriedade que deve ser exposta para resolver algum problema do mundo real A primeira sub rea de conhecimento chamada de Fundamentos de Requisitos de Software Ela inclui defini es dos pr prios requisitos de software mas tamb m os principais tipos de requisitos como diferen a entre produto e processo propriedades funcionais e n o fun
333. tware Medi o da estrutura AP e Cultura e tica em engenharia de AN Medi o da qualidade AP software Resultados da medi o da qualidade AN Valor e custo da qualidade AN 232 Reparti o dos T picos N vel de Taxonomia Modelos de qualidade e caracter sticas Qualidade do processo de software AN Qualidade do produto de software AN Melhoria da qualidade AP 2 Processos de gerenciamento da qualidade de software Garantia da qualidade de software AP Verifica o e valida o AP An lise e auditoria Inspe es AP Revis es com parceria AP Revis o conjunta AP Testes AP Auditorias C 3 Considera es pr ticas Requisitos de qualidade da aplica o Criticidade dos sistemas C Fidelidade C N vel de integridade de software C Caracteriza o de defeitos AP T cnicas de gerenciamento de qualidade de software T cnicas est ticas AP T cnicas com pessoas de alto n vel de AP conhecimento T cnicas anal ticas AP T cnicas din micas AP Medi o de qualidade de software AP 233 3 Conclus o 3 1 Apresenta o dos resultados O presente trabalho procurou fazer uma exposi o da import ncia do Guia para o Corpo de Conhecimento de Engenharia de Software SWEBOK Teve como foco sua tradu o e o conhecimento de temas n o abordados por alguns cursos por m tidos como importantes para a for
334. tware definem as caracter sticas necess rias de qualidade e influenciam os m todos de medida e crit rios de aceita o na avalia o de tais caracter sticas a Cultura e tica da Engenharia de Software Espera se que os engenheiros de software compartilhem um compromisso com qualidade de software como parte de sua cultura Uma robusta cultura de engenharia de software descrita em Wie96 A tica pode desempenhar um papel significante na qualidade de software na cultura e nas atitudes dos engenheiros de software O IEEE Computer Society e a ACM IEEE99 desenvolveram um c digo de tica e pr ticas profissionais baseada em oito princ pios para ajudar os engenheiros de software a refor ar atitudes relacionadas qualidade e independ ncia do seu trabalho b Valor e Custo da Qualidade A no o de qualidade n o t o simples quanto pode parecer Para qualquer produto desenvolvido existem v rias qualidades desejadas relevantes para determinadas perspectivas do produto que devem ser discutidas e determinadas durante a defini o dos requisitos Caracter sticas de qualidade podem ser requeridas ou n o podem ser requeridas em maior ou menor grau e ainda podem existir trade offs entre elas Pfl01 O custo da qualidade pode ser diferenciado em custo de prevengao custo de avalia o custo de fracasso interno e custo de fracasso externo Hou99 A motiva o por tr s de um projeto de software o desejo de se c
335. u Qu bec Montr al Montr al Fevereiro de 1999 Baseado na vers o Straw Man nas discuss es mantidas e expectativas afirmadas na reuni o de in cio do Conselho Consultivo Industrial e no trabalho subsequente este documento prop e uma lista b sica de Disciplinas Relacionadas e reas do Conhecimento dentro dessas Disciplinas Relacionadas Este documento foi submetido e discutido com o Conselho Consultivo Industrial e uma lista reconhecida de reas do Conhecimento ainda tem de ser identificada para certas Disciplinas Relacionadas Os editores associados ser o informados sobre a evolu o deste documento c P Bourque R Dupuis A Abran J W Moore L Tripp K Shyne B Pflug M Maya e G Tremblay Guia do Corpo de Conhecimento de Engenharia de Software Vers o Straw Man relat rio t cnico Universit du Qu bec Montr al Montr al Setembro de 1998 206 Este relat rio a base do projeto inteiro Ele define a estrat gia geral do projeto base l gica e princ pios subjacentes propondo uma lista inicial de reas do Conhecimento e Disciplinas Relacionadas d 4 J W Moore Padr es de Engenharia de Software O Mapa de Caminho do Usu rio IEEE Computer Society Press 1998 Este livro descreve o alcance pap is usos e tend ncias de desenvolvimento dos padr es de engenharia de software mais amplamente utilizados concentrado em importantes atividades de engenharia de software qualidade e gerencia
336. ultiva deliberada e transparente para que outros projetos possam coordenar esfor os com xito A estrat gia atualmente planejada evoluir o guia SWEBOK usando uma abordagem time boxed A abordagem time box selecionada porque permite que o guia SWEBOK coordene e realize revis es de 211 projeto antecipadamente a uma data fixada para converg ncia O time box inicial est planejado atualmente para quatro anos em dura o No inicio de cada time box em consulta com a coordena o de projetos um plano global para revis o de quatro anos precisa ser determinado Durante o primeiro ano mudan as estruturais para o guia SWEBOK isto mudan as em n mero ou escopo de reas de conhecimento precisam ser determinadas Durante o segundo e o terceiro anos a sele o e o tratamento de t picos de dentro das reas de conhecimento precisa ser revisado Durante o quarto ano o texto das descri es das reas de conhecimento precisa ser revisado e refer ncias atualizadas precisam ser selecionadas O projeto global precisa ser gerenciado por um comit de volunt rios da Sociedade de computa o e representantes projetos de coordena o O comit precisa ser respons vel por definir planos globais coordenado com as partes envolvidas e recomendar a aprova o de uma revis o final O comit deve ser ajudado por um comit conselheiro do SWEBOK SWAC composto de utilizadores do guia SWEBOK O SWAC precisa tamb m focar para obter s
337. ultura necess rio que mudar Uma vis o geral dos sistemas de SCM e de sele o das considera es dada em Dar90 C3 apare e um estudo de caso sobre a sele o de um sistema de SCM dada em Mid97 As informa es complementares sobre ferramentas SCM podem ser encontradas em Engenharia de Software Ferramentas e M todos KA Um projeto de software pode adquirir ou utilizar a aquisi o de produtos de software tais como compiladores e outras ferramentas SCM considera o planejamento e como estes itens ser o adquiridas sob o controle de configura o por exemplo integra o das bibliotecas no projeto e como mudan as e atualiza es ser o avaliadas e gerenciadas Considera es semelhantes aplicam se terceiriza o de software Neste caso os requisitos SCM devem ser impostos ao subcontratante da SCM como parte do processo de terceiriza o e os meios de controlar o cumprimento tamb m s o necess rios para ser estabelecido Este ltimo inclui a considera o de que informa es de SCM devem estar dispon veis para o cumprimento da monitora o efetiva Quando um item de software ir interagir com outros itens de hardwares ou softwares uma mudan a em qualquer item pode afetar outros O planejamento para SCM considera o processo de como os itens de interface ser o identificados e como as mudan as para os itens ser o gerenciadas e comunicadas O papel SCM pode fazer parte de um maior processo de n veis de si
338. uporte financeiro corporativo para a evolu o do guia SWEBOK Suporte financeiro corporativo passado permitiu tornar o guia SWEBOK dispon vel gratuitamente em um Web Site Suporte futuro ir permitir continuar a pr tica para edi es futuras De forma fict cia cada dos quatros anos precisa incluir um ciclo de oficina elabora o vota o e resolu o por voto Um ciclo anual precisa envolver as seguintes atividades Uma oficina organizada como parte de uma confer ncia maior precisa especificar problemas para tratamento durante o pr ximo ano priorizar os problemas recomendar abordagens para lidar com eles e nomear redatores para implementar as abordagens e Cada redator deve escrever ou modificar a descri o da rea de conhecimento usando a abordagem recomendada pela oficina e refer ncias dispon veis No ano final do ciclo os redatores devem recomendar refer ncias espec ficas atualizadas para cita o no guai SWEBOK Redatores tamb m devem ser respons veis para modificar suas reda es em resposta a coment rios de votantes e Cada ciclo anual deve incluir vota es nas revis es para as descri es das 212 reas de conhecimento Votantes devem revisar as reda es das descri es das reas de conhecimento e refer ncias recomendadas oferecer coment rios e votar a aprova o das revis es Vota o deve ser aberta a membros da sociedade de computa o e outros participantes qualificados N o membros
339. urante o desenvolvimento O IEEE IEEE610 12 90 define manutenibilidade como a facilidade com que pode o software ser mantido refor ado adaptado corrigido ou satisfazer requisitos especificados ISO IEC define manutenibilidade como uma caracter stica de qualidade ISO9126 01 As subcaracter sticas da manutenibilidade devem ser especificadas revista e controladas durante o desenvolvimento das atividades de software a fim de reduzir os custos de manuten o Se for feito com xito a manuten o do software ir melhorar Isso muitas vezes dif cil de ser concretizado porque as caracter sticas da manutenibilidade n o s o um importante foco durante o processo de desenvolvimento de software Os desenvolvedores est o preocupados com muitas outras coisas e frequentemente ignoram as exig ncias do mantenedor Este fato por sua vez pode 102 e muitas vezes o faz resultar em uma falta de documenta o do sistema o que uma das principais causas das dificuldades no programa de compreens o e avalia o do impacto Tamb m tem foi observado que a presen a de sistemas de processos maduros t cnicas e ferramentas ajudam a refor ar a manuten o de um sistema b Gest o de Problemas Alinhamento com os objetivos organizacionais Ben00 c6sa Dor02 v1c9s1 6 Os objetivos organizacionais descrevem a forma de demonstrar o retorno sobre os investimentos das atividades de manuten o de software Bennett Ben00 afirma que
340. uten o de software Esta lista inclui uma s rie de medidas para cada uma das quatro subcaracter sticas de durabilidade e Analisativas Medidas do esfor o do mantenedor ou recursos gastos na tentativa de diagnosticar defici ncias ou causas de insucesso ou na identifica o de pe as a serem modificadas e Inconst ncia Medidas do mantenedor do esfor o associados a implementa o de uma determinada modifica o Estabilidade Medidas do comportamento inesperado do software incluindo a que surgir durante o ensaio e Testabilidade Medidas do esfor o do mantenedor e usu rio para tentar testar o software modificado Algumas medidas de manuten o do software podem ser obtidas utilizando ferramentas comerciais dispon veis Lag96 Apr0O0O IEEE1061 98 A 2 Pig97 c14s14 6 Gra87 Tak97 c6s6 1 c6s6 3 2 1 3 5 3 Processo de manuten o O Processo de Manuten o fornece refer ncias de subzona de padr es utilizados para implementar o processo de manuten o de software Atividades de Manuten o diferencia o t pico Desenvolvimento da manuten o e mostra a rela o da engenharia de software para outras atividades A necessidade da engenharia de software um processo bem documentado Os modelos CMMI se aplicam aos processos de manuten o de 106 software e s o semelhantes aos processos de desenvolvimento SEIO1 Manuten o de Software Capability Maturity descreve os nicos processos de manuten o
341. valida o e Processo de revis o e Processo de auditoria Estes processos incentivam a qualidade e tamb m localizam poss veis problemas Mas eles diferem um pouco na sua nfase Processos SQM ajudam garantir melhor qualidade de software em um determinado projeto Eles tamb m fornecem como um produto secund rio informa es gerais para gerenciamento inclusive uma indica o da qualidade de todo o processo de engenharia de software As KAs Processo de Engenharia de 177 Software e Gest o da Engenharia de Software discutem programas de qualidade para as organiza es de desenvolvimento de software SQM pode fornecer feedback relevante para estas reas Processos SQM consistem em tarefas e t cnicas para indicar como os planejamentos de software por exemplo ger ncia desenvolvimento gest o de configura o est o sendo implementados e o quanto os produtos intermedi rios e finais est o de acordo com os requisitos especificados Os resultados destas tarefas s o reunidos em relat rios de ger ncia antes das a es corretivas serem tomadas A ger ncia de um processo SQM encarregada de garantir que os resultados destes relat rios sejam precisos Como descrito nesta KA processos SQM est o intimamente ligados eles podem se sobrepor e s vezes at mesmo se combinar Eles parecem largamente reativos por natureza porque abordam os processos como praticados e os produtos como produzidos mas eles t m um papel importante
342. ve uma estimativa dos recursos necess rios para realizar a mudan a 101 Art88 Al m disso o risco de fazer a mudan a determinado A mudan a pedida s vezes chamada de Pedido de Modifica o MR e muitas vezes requerem um relat rio problema PR que deve em primeiro lugar ser analisado e traduzido em termos de software Dor02 realizado ap s a entrada de um pedido de mudan a de software no gerenciamento de configura o processo Arthur Art88 afirma que os objetivos de an lise de impacto s o e Determina o do mbito de uma mudan a no sentido de planejar e executar trabalhos e Desenvolvimento de estimativas precisas dos recursos necess rios para executar o trabalho An lise dos custos benef cios das altera es solicitadas e Comunica o a terceiro da complexidade de uma dada mudan a A gravidade de um problema frequentemente utilizada para decidir como e quando um problema ser corrigido O engenheiro de software ent o identifica os componentes afetados V rias solu es potenciais s o apresentadas e em seguida feita uma recomenda o quanto ao melhor curso de a o O Software projetado com a manuten o em mente facilita e muito a avalia o de impacto Mais informa es podem ser encontradas na Ger ncia de Configura o de Software KA Manutenibilidade IS014764 99 s6 8s6 8 1 Pfl01 c9s9 4 Pig97 c16 Como que um acompanhamento pode promover as questdes de manutenibilidade d
343. ware de uma forma mais gen rica Sha96 51 Isso deu origem a uma s rie de ideias interessantes sobre a concep o do software em diferentes n veis de abstra o Alguns desses conceitos podem ser teis durante a concep o arquitet nica por exemplo estilo arquitet nico de um software espec fico bem como durante a sua concep o pormenorizada por exemplo a concep o de n vel mais baixo padr es Mas eles tamb m podem ser teis para a concep o de sistemas gen ricos levando concep o de fam lias de programas tamb m conhecidas como linhas de produtos Curiosamente a maior parte destes conceitos pode ser visto como tentativas de descrever e deste modo o reuso conhecimentos design gen ricos a Estruturas arquitet nicas e Viewpoints Diferentes facetas de high level de design de software podem e devem ser descritos e documentados Estes aspectos s o muitas vezes chamados views Uma view representa um parcial aspecto de uma arquitetura de software que mostra propriedades espec ficas de um sistema de software Bus96 c6 Estas distintas views pertencem a distintas quest es relacionadas com a design de software por exemplo a l gica view que satisfa a as exig ncias funcionais vs os processos view quest es de concurrency vs f sico views quest es de distribui o vs o desenvolvimento view o modo como o projeto dividido em unidades de implementa o Outros autores usam diferentes terminol
Download Pdf Manuals
Related Search