Qualidade de software

1.688 visualizações

Publicada em

0 comentários
4 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.688
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
112
Comentários
0
Gostaram
4
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Qualidade de software

  1. 1. Engenharia de Software engenharia Saiba seu significado e para que serve magazine de software Edição Especial Entenda os principais conceitos sobre Testes e Inspeção de Software Verificação, Validação & Teste Ferramentas Open Source e melhores práticas na gestão de defeitos Requisitos Projeto Conheça os principais conceitos envolvidos Entenda o conceito de Arquitetura de Software e na Engenharia de Requisitos como trabalhar com os Estilos Arquiteturais Especial ProcessosMelhore seus processos através da Veja como integrar conceitos de Veja como integrar o Processo análise de risco e conformidade Modelos Tradicionais e Ágeis Unificado ao desenvolvimento Web
  2. 2. Atendimento ao Leitor engenharia magazine A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Se você tiver algum problema no recebimento do seu exemplar ou de software precisar de algum esclarecimento sobre assinaturas, exemplares anteriores, endereço de bancas de jornal, entre outros, entre em contato com: Carmelita Mulin – Atendimento ao Leitor www.devmedia.com.br/central/default.asp (21) 2220-5375Ano 1 - 1ª Edição 2007 - - Impresso no Brasil Kaline Dolabella Gerente de Marketing e Atendimento kalined@terra.com.brCorpo Editorial (21) 2220-5375Colaboradores PublicidadeRodrigo Oliveira Spínola Para informações sobre veiculação de anúncio na revista ou no site entrerodrigo@sqlmagazine.com.br em contato com:Marco Antônio Pereira Araújo Kaline DolabellaEduardo Oliveira Spínola publicidade@devmedia.com.br Fale com o Editor! É muito importante para a equipe saber o que você está achando da revista: que tipo deEditor de ArteVinicius O. Andrade artigo você gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou.viniciusoandrade@gmail.com Fique a vontade para entrar em contato com os editores e dar a sua sugestão! Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine,Capa entre em contato com os editores, informando o título e mini-resumo do tema que vocêVinicius O. Andrade gostaria de publicar:viniciusoandrade@gmail.com Rodrigo Oliveira Spínola - ColaboradorNa Web editor@sqlmagazine.com.brwww.devmedia.com.br/esm Apoio Parceiros:ÍNDICEÍNDICE04 - Alguns Fundamentos da Engenharia de Software Wilson de Pádua Paula Filho10 - Melhorando Processos Através da Análise de Risco e Conformidade Rafael Espinha, João Sousa22 - Agilidade ou Controle Operacional? Os dois! Alexandre Bartie28 - O processo unificado integrado ao desenvolvimento Web Rodrigo S. Prudente de Aquino38 - Arquitetura de Software Antonio Mendes da Silva Filho46 - Introdução à Engenharia de Requisitos Ana Luiza Ávila e Rodrigo Oliveira Spínola54 - Introdução a Teste de Software Arilo Cláudio Dias Neto60 - Gestão de defeitos Cristiano Caetano68 - Introdução à Inspeção de Software Marcos Kalinowski e Rodrigo Oliveira Spínola
  3. 3. Alguns Fundamentos da Engenharia de Software O que é Engenharia de Software? duzem grande quantidade de software, ou É a mesma coisa que Ciência da Com- até naquelas em que o desenvolvimento putação? Ou é uma entre muitas espe- de software é atividade fim. Programas cialidades da Ciência da Computação? e exames de certificação em Engenharia Ou dos Sistemas de Informação, ou do de Software são pouco conhecidos, ao Processamento de Dados, ou da Informá- contrário do que acontece com algumas tica, ou da Tecnologia da Informação? Ou linguagens e tecnologias usados por esses é uma especialidade diferente de todas profissionais. as anteriores? Em outros países, a situação é um pouco Na maioria das instituições brasileiras diferente. Algumas universidades ameri- de ensino superior, o conjunto de co- canas oferecem programas de graduação, nhecimentos e técnicas conhecido como mestrado e doutorado na área. O IEEE Engenharia de Software é ensinado em (Institute of Electrical and Electronics Engi- uma ou duas disciplinas dos cursos que neers), principal organização internacional têm os nomes de Ciência da Computação, de profissionais de Engenharia Elétrica, Wilson de Pádua Paula Filho Informática ou Sistemas de Informação. através da Computer Society, que forma o (wppf@ieee.org) Raramente, em mais disciplinas, muitas seu ramo em Computação, oferece a qua- Engenheiro Mecânico pelo ITA, Doutor em vezes opcionais, e muitas vezes oferecidas lificação de Profissional Certificado para Engenharia Elétrica pela Escola Politécnica da USP, Professor Titular aposentado do Departa- apenas em nível de pós-graduação. Algu- o Desenvolvimento de Software. mento de Ciência da Computação da UFMG. mas instituições oferecem cursos de pós- Autor dos Livros “Engenharia de Software: graduação em Engenharia de Software, Ciência, Engenharia e Valor Fundamentos, Métodos e Padrões” e “Multi- geralmente no nível de especialização. Sem pretender fazer distinções defini- mídia: Conceitos e Aplicações” Atualmente é . O uso do termo para designar uma tivas, vamos explorar o que dizem os di- consultor em Engenharia de Software e traba- lha no Synergia – Laboratório de Engenharia carreira profissional também não é muito cionários. O Dicionário Aurélio Eletrônico de Software e Sistemas da UFMG. comum, mesmo em organizações que pro- V.2.0 assim define Ciência e Engenharia:4 Engenharia de Software Magazine – Alguns Fundamentos da Engenharia de Software
  4. 4. engenharia Ciência - Conjunto organizado de conheci- tes das Belas Artes, e valorizam critérios tosos, e, em certos casos, até riscos à vidamentos relativos a um determinado objeto, es- estéticos na criação de seus programas. humana; muitas vezes empreendimentospecialmente os obtidos mediante a observação, a Isso pode ter conseqüências boas e ruins, de software são afetados por um contextoexperiência dos fatos e um método próprio. do ponto de vista de gerar valor. Por um econômico, político ou social. Engenharia - Arte de aplicar conhecimen- lado, a busca da elegância pode levartos científicos e empíricos e certas habilitações à economia e simplicidade de formas, Produtos e Ciclos de Vidaespecíficas à criação de estruturas, dispositi- fazendo com que resultados de melhor A íntima relação entre a Engenharia devos e processos que se utilizam para converter qualidade sejam obtidos de maneira mais Software e a noção de valor significa querecursos naturais em formas adequadas ao produtiva. E, principalmente, levando essa profissão trata o software como pro-atendimento das necessidades humanas. a escrever programas que possam ser duto. Estão fora do escopo da Engenharia mais facilmente reutilizados, mantidos e de Software programas que são feitos Vê-se que, pelas definições acima, a expandidos. Por outro lado, a auto-satisfa- com objetivo exclusivamente lúdico: aCiência focaliza acumulação do conheci- ção do programador pode ter como preço diversão do programador. Estão fora demento através do método científico, combase em experimentos e observações. Jáa Engenharia aplica esses conhecimen-tos “ao atendimento das necessidades A íntima relação entre a Engenharia de Software e a noçãohumanas”. Embora o conhecimento sejacertamente uma necessidade humana, de valor significa que essa profissão trata o software comotrata-se de uma entre várias outras,sejam necessidades materiais, como produto.alimentação, moradia, segurança, ouimateriais, como afeição ou auto-estima.A tudo aquilo que satisfaz a necessidades,atribui-se um valor. A Engenharia está, os interesses de quem está pagando pelo seu escopo também pequenos programasportanto, ligada à noção de valor, e a En- trabalho dele, ou de quem o usará. Seja, descartáveis, feitos por alguém apenasgenharia de Software busca gerar valor por exemplo, produzindo programas que para resolver um problema dessa pessoa,com o processamento de informação. A ninguém entende, senão o próprio autor e que não serão utilizados por outros.noção de valor tem muitas conseqüên- (e, depois de certo tempo, nem ele mesmo). Mas, se um desses programas interessarcias práticas importantes, e, de fato, a Seja, como outro exemplo, introduzindo a outras pessoas, e assim passar a ter va-teoria conhecida como “Engenharia de funções que o autor achou interessantes, lor, aparecerão demandas para melhorarSoftware Baseada em Valor” representa mas não são realmente necessárias, nem suas qualidades, aumentar suas funções,uma importante escola de pensamento foram solicitadas. prolongar sua vida. E aparecerá quemdentro da área. E muito próxima de “Arte” está a esteja disposto a investir nisso, com a palavra “Artesanato”, que lembra pro- expectativa de ganhar dinheiro. NesseArte, Técnica, Artesanato, Indústria? dução caseira, em pequena escala, sem momento, o programa entrou no escopo Outros termos constantes da definição a utilização de métodos industriais, que da Engenharia de Software e se tornou umde Engenharia podem ser explorados são caracterizados pela padronização e produto. Muitos dos produtos de softwarede várias formas, com conseqüências pela repetição. E, realmente, parece mais mais usados seguiram esse caminho.interessantes. Por exemplo, é usada a difícil aplicar esses métodos industriais Todo produto tem usuários: aqueles quepalavra “Arte”, que o mesmo dicionário na confecção de software, do que nos efetivamente usam o produto. Algunsdefine como a “capacidade que tem o ramos da engenharia do mundo material. produtos são feitos por encomenda de umhomem de pôr em prática uma idéia, Nestes, as leis físicas impõem limites cliente: aquele que pagará por sua produ-valendo-se da faculdade de dominar a claramente visíveis ao que pode ser feito. ção. Outros, chamados de produtos dematéria”, ou “a utilização de tal capa- Na Engenharia de Software, a criativida- prateleira, são vendidos no mercado aber-cidade, com vistas a um resultado que de não é limitada por leis físicas, e sim to, a quem se interessar. Neste caso, quempode ser obtido por meios diferentes”. pela capacidade humana de entender e faz o papel do cliente é quem define queNa Engenharia de Software, a matéria dominar a complexidade. recursos e funções se esperam do produto;dominada pelas faculdades humanas Mas não se pode escapar do fato de que a talvez um departamento de vendas, ou deconsiste em máquinas de processamento Engenharia de Software tem que resolver marketing, ou de definição de produtos deda informação, devidamente configura- muitos problemas de ordem industrial. uma organização, ou até, para produtosdas e programadas. Nesse sentido, os Raramente é possível construir software menores, os próprios desenvolvedores, co-conceitos de “Arte” e “Técnica” são bem profissional sem envolver equipes, às ve- locando o chapéu de investidores de risco.próximos; aliás, a palavra grega techné zes de dezenas ou até centenas de pessoas; E existem todos os casos intermediários,significa, exatamente, Arte. raramente é possível trabalhar na área em que um produto parcialmente pronto O termo “Arte” abre outras discussões. sem a pressão de prazos e orçamentos é completado, adaptado ou incrementado,Não poucos programadores se conside- apertados; freqüentemente defeitos de por encomenda de um cliente.ram como artistas, no sentido de pratican- software podem acarretar prejuízos vul- Como todo produto industrial, o produ- Edição 01 – Engenharia de Software Magazine 5
  5. 5. to de software tem seu ciclo de vida: notação é usada para descrever muitos mostram detalhes; cada seta representa • ele é concebido para tentar atender a aspectos diferentes do desenvolvimento uma transição entre atividades; as barrasuma necessidade; de software, inclusive as seqüências de paralelas representam início e término • é especificado, quando essas necessida- atividades que compõem esse desenvol- de atividades executadas em paralelo;des são traduzidas em requisitos viáveis; vimento. O tipo específico de diagrama um retângulo de cantos arredondados • é desenvolvido, transformando-se que é mostrado na figura é o Diagrama de com detalhes internos representa umaem um conjunto formado por código e Atividades, que representa uma evolução atividade estruturada, que é compostaoutros itens, como modelos, documentos dos tradicionais fluxogramas, usados pe- de outras atividades.e dados; los programadores há décadas. • passa por algum procedimento de É interessante observar que a codifica- Projetos, Atividades e Estruturasaceitação e é entregue a um cliente; ção, que representa a escrita final de um Analíticas • entra em operação, é usado, e sofre programa em forma inteligível para um Normalmente, o software é desenvolvi-atividades de manutenção, quando ne- computador, é apenas uma pequena parte do dentro de projetos. Todo projeto temcessário; do ciclo de vida. Muitas pessoas, inclu- uma data de início, uma data de fim, uma • é retirado de operação ao final de sua sive alguns profissionais da informática, equipe e outros recursos. O responsávelvida útil. acham que a codificação é a única tarefa por um projeto é chamado de gerente de de um engenheiro de software. projeto. O trabalho realizado dentro de um O ciclo de vida compreende muitas ativi- Nos Diagramas de Atividades da UML, projeto pode ser descrito por um conjuntodades, que são assunto das diferentes áre- a bolinha cheia representa Início; a boli- de atividades, que podem possuir relaçõesas da Engenharia de Software. A Figura 1 nha com um anel adicional representa de dependência, paralelismo, e decom-mostra um modelo do ciclo de vida do sof- fim; cada retângulo simples de cantos posição em atividades mais elementares,tware, usando a notação conhecida como arredondados representa uma ação, ou como no diagrama da Figura 1.UML (Unified Modeling Language). Essa seja, uma atividade simples, da qual não As atividades são delimitadas por mar- cos, isto é, pontos que representam esta- dos significativos do projeto. Geralmente, os marcos são associados a resultados concretos: documentos, modelos ou por- ções do produto, que podem fazer parte do conjunto prometido aos clientes, ou ter apenas utilização interna ao projeto. O próprio produto é um resultado concreto associado ao marco de conclusão do pro- jeto, que pode ser utilizado sozinho, ou como componente de um sistema. O PMI (Project Management Institute) é uma organização internacional, com seções em muitos países, inclusive o Brasil, que tem o objetivo de promover e difundir boas práticas de gestão de pro- jetos. Para isso, administra programas de certificação de profissionais nessa área, e publica o guia conhecido PMBOK (Project Management Body of Knowledge). Nesse guia, define-se um projeto como um empreendimento temporário reali- zado para criar um produto, serviço ou resultado distinto. Um produto, por sua vez, é definido como um objeto produzi- do, quantificável e que pode ser um item final ou um item componente. Uma ativi- dade é definida como um componente de trabalho realizado durante o andamento de um projeto. Os relacionamentos entre as atividades que compõem um projeto são mostrados em uma estrutura analítica, que o PM- BOK define como uma decomposição hie-Figura 1. Modelo UML do ciclo de vida do software rárquica orientada à entrega do trabalho6 Engenharia de Software Magazine – Alguns Fundamentos da Engenharia de Software
  6. 6. engenhariaa ser executado pela equipe do projeto, na Engenharia de Software é o CMMI Projeto - Conjunto gerido de recursospara atingir os objetivos do projeto e (Capability Maturity Model Integration), que inter-relacionados, que entrega um ou maiscriar as entregas necessárias. Estruturas foi formulado pelo Software Engineering produtos a um cliente ou usuário, com inícioanalíticas de projeto podem ser apresen- Institute da Carnegie-Mellon University. O definido e que, tipicamente, opera conformetadas de muitas maneiras. Diagramas de CMMI foi encomendado e patrocinado um plano.atividade são uma das representações pelo Departamento de Defesa ameri- Estrutura analítica do projeto - Um ar-mais usadas atualmente. Outro tipo cano, popularmente conhecido como ranjo dos elementos do trabalho e dos relaciona-de representação usual é fornecida por Pentágono, que o utiliza para avaliação mentos deles entre si e com o produto final.planilhas e cronogramas, como aqueles da capacidade de seus fornecedores deque são produzidos pela ferramenta Mi- software. Sendo o Pentágono provavel- Ao contrário do PMBOK, o CMMI nãocrosoft Project (Figura 2). mente a maior organização compradora se limita aos conhecimentos sobre gestão de software do mundo, o CMMI tem de projetos. Cobre também áreas técni-Modelos de Referência e Fatores de grande aceitação da indústria americana cas, e focaliza principalmente a aplicaçãoProdução de software, e considerável influência no dos processos ao desenvolvimento de O PMBOK é um exemplo de modelo de resto do mundo. A rigor, suas práticas não produtos. Um processo, segundo o IEEE,referência: uma estrutura de conheci- são restritas à indústria de software, po- é uma seqüência de passos executadosmento que organiza conceitos, práticas dendo ser aplicadas ao desenvolvimento com um determinado objetivo; segundoe padrões de uma área. No caso do de outros tipos de produtos. o PMBOK, é um conjunto de ações ePMBOK, a área focalizada é a gestão de Os conceitos do CMMI têm raízes em atividades inter-relacionadas, realizadasprojetos de qualquer natureza, cobrindo comum com o PMBOK, como se pode para obter um conjunto especificado deassuntos como integração, escopo, tempo, observar pela similaridade das definições produtos, resultados ou serviços.custos, qualidade, recursos humanos, que adota: Um projeto representa a execução decomunicações, riscos e aquisições. Produto - Resultado que se pretende entre- um processo, e um processo é uma receita Outro modelo de referência importante gar a um cliente ou usuário. que é seguida durante a realização umFigura 2. Cronograma de um projeto. Edição 01 – Engenharia de Software Magazine 7
  7. 7. projeto; em outras palavras, o projeto é menos produtivas, durante algum tempo. esperado. E a principal contribuição deo empreendimento que concretiza uma Algumas tecnologias mais complexas só modelos de referência como o CMMI éabstração, que é o processo. Não se deve se pagam depois de muitos projetos. indicar o caminho das pedras e o mapa daconfundir um processo (digamos, uma Investir na capacitação das pessoas é mina: onde a experiência coletada indicareceita de bolo) com o respectivo produto certamente necessário. Entretanto, for- que o investimento em melhorias é mais(o bolo) ou com a execução do processo mar pessoas é difícil, caro e demorado. rentável, em cada passo da evolução dasatravés de um projeto (a confecção de Recrutar pessoas capacitadas também: organizações.um bolo por determinada pessoa, em não há sinais de que a oferta de pessoasdeterminado dia). com alta qualificação no desenvolvi- Processos, pessoas e tecnologia consti- mento de software venha a se igualar Conclusãotuem os fatores de produção, que deter- à demanda, em futuro próximo. Além A Engenharia de Software visa à criaçãominam o grau de sucesso dos projetos, disso, muitas pessoas produzem menos de produtos de software que atendam asou seja: se eles conseguem entregar um que a sua capacidade permitiria, por necessidades de pessoas e instituições e,produto de qualidade suficiente, dentro falta de liderança, por deficiência de fer- portanto, tenham valor econômico. Parade um prazo aceitável e com custos viá- ramentas e suporte, ou por inadequação isso, usa conhecimentos científicos, téc-veis. Portanto, desses fatores dependem de processos. nicos e gerenciais, tanto teóricos quantoa rentabilidade e a sobrevivência das Dos investimentos nos fatores de pro- empíricos. Ela atinge seus objetivos deorganizações produtoras. dução, os investimentos nos processos produzir software com alta qualidade Para muitos profissionais, a tecnologia é são geralmente aqueles que podem trazer e produtividade quanto é praticada poro fator mais atraente; muitas vezes, há um retorno em prazo mais curto. Processos profissionais treinados e bem informa-otimismo exagerado quanto aos resulta- também não fazem milagres, mas a dos, utilizando tecnologias adequadas,dos da aplicação de novas tecnologias. melhoria dos processos costuma trazer dentro de processos que tirem proveitoEntretanto, tecnologias aparentemente benefícios em prazos relativamente cur- tanto da criatividade quando da raciona-promissoras podem levar para um beco tos, como é ilustrado por inúmeros relatos lização do trabalho.sem saída, e, às vezes, tecnologias con- de experiência publicados. No mínimo,sideradas inferiores pelos especialistas contribuem para reduzir o desperdíciolançam raízes permanentes, graças a for- e o retrabalho, o que geralmente já trazças de mercado. Além disso, a tecnologia ganhos muito significativos. Linkssó se paga quando colocada nas mãos de A melhoria dos três fatores (tecnolo- SEIpessoas capacitadas, trabalhando dentro gias, pessoas e processos) também requer http://www.sei.cmu.edu/de processos adequados. Toda introdução seu próprio processo: ela deve ser feita CMMIde nova tecnologia tem uma curva de em etapas bem-definidas e controladas, http://www.sei.cmu.edu/cmmi/aprendizado: as pessoas precisam ser para que as organizações, em prazos PMI Brasiltreinadas, cometem inicialmente muitos relativamente curtos, possam avaliar se http://www.pmi.org.br/erros e, por isso, podem até se tornarem seu investimento está tendo o retorno8 Engenharia de Software Magazine – Alguns Fundamentos da Engenharia de Software
  8. 8. Desde 2004 Trazendo Teoria para a Prática Treinamento e Consultoria em Engenharia de Software Profissionais com ampla experiência prática (Consusltores Certificados) e acadêmica (Professores Universitários, Mestres e Doutores) Know-how para implementar processos de software de acordo com modelos de qualidade (MPS e CMMI) e maximizar o retorno de investimento Certificados emitidos pela Kali Software Cursos 2008: Inscrições Abertas Aulas aos sábados na Zona Sul do Rio, próximo ao metrô Para outras localidades, por favor entre em contatoMarço | Abril Processos de Software com ênfase em CMMI e MPS – 32 horas Teste de Software – 16 horasMaio | Junho Engenharia de Requisitos – 32 horas Gerência de Configuração de Software – 16 horasJulho | Agosto Gerência de Projetos de Software – 32 horas Projeto Orientado a Objetos com UML e Padrões – 32 horasConfira as ementas, investementos e condições de pagamento: www.kalisoftware.comOferecemos também cursos de programação (Java, Java para Web e Ajax)Inscrição e outras informações: info@kalisoftware.comkalisoftware.com | info@kalisoftware.com
  9. 9. Melhorando Processos Através da Análise de Risco e Conformidade U m dos fatores importantes para ISO/IEC 15504 e 12207 definem um con- a construção de um software junto de boas práticas e características de qualidade é o processo de que devem estar presentes em um pro- desenvolvimento utilizado e como este é cesso para que este possa ser gerenciado implantado na organização. A inexistên- e resulte na entrega de produtos de qua- cia ou a não utilização de processos bem lidade. Entretanto, como têm o objetivo definidos e de boas práticas de desen- de serem aplicáveis a quase todo tipo de volvimento, mesmo que informais, faz organização, estes modelos ou normas Rafael Espinha com que o desenvolvimento de software muitas vezes não definem como estas rafael.espinha@primeup.com.br seja realizado de forma ad-hoc, ficando boas práticas e características devem ser É Engenheiro de Computação e Mestre em altamente dependente da experiência e implementadas e implantadas. Uma das Engenharia de Software pela PUC-Rio. Foi do conhecimento das pessoas envolvidas. maiores dificuldades de organizações pesquisador do Laboratório de Engenharia a de Software da PUC-Rio e atualmente é con- Este cenário resulta na realização de pro- que iniciam um programa de melhoria sultor e diretor da PrimeUp, onde desenvolve jetos cujos resultados são imprevisíveis, de processos enfrentam é a dificuldade projetos na área de melhoria de processos e onde cada um realiza as suas atividades de adaptar este conjunto de boas práticas qualidade de software. Possui cursos e certifi- da forma que lhe convém, e dificulta a para a sua realidade, identificando quais cações em CMMI e MPS.BR. reutilização de boas práticas e de lições áreas são mais relevantes e devem ser aprendidas. abordadas com maior urgência. Cada or- João Sousa joaomss@primeup.com.br Com a crescente demanda por qualida- ganização possui políticas, crenças e uma É Bacharel em Informática pela UERJ e pós- de dos produtos de software, a adoção cultura específica, que deve ser levada em graduado pela UFRJ. Possui mais de 15 anos de modelos de maturidade, normas de conta para que as melhorias sejam bem de experiência no desenvolvimento de sis- qualidade e guias de boas práticas na aceitas e realmente contribuam com um temas e melhoria de processos. Atualmente definição de processos tem se tornado desenvolvimento mais eficiente. é consultor da PrimeUp, onde desenvolve projetos na área de melhoria de processos e cada vez mais freqüente. Modelos como Para orientar a necessidade de adapta- qualidade de software. CMMI-DEV e MPS.BR e normas como a ção apresentada acima, utilizamos o con-10 Engenharia de Software Magazine – Melhorando Processos Através da Análise de Risco e Conformidade
  10. 10. proc ess oceito de risco associado à não utilização tunidades de melhoria. Em geral, nesta A próxima seção apresenta algunsdas boas práticas de desenvolvimento fase é realizado um estudo no qual um conceitos básicos sobre riscos e comode software nos projetos e processos da cenário esperado é definido e o cenário este conceito é utilizado neste domínio.organização. Consideramos também que atual é avaliado segundo algum critério Em seguida a estratégia e a ferramentaa qualidade do produto (software) está de qualidade (“Gap Analysis”). O cenário que compõem a abordagem serão apre-diretamente relacionada à qualidade dos esperado pode ser definido a partir de um sentadas e um exemplo da sua utilizaçãoprocessos utilizados na sua produção e ou mais modelos ou normas de referência, será discutido.ao conhecimento técnico que os usuários como, CMMI-DEV 1.2 ou ISO 9001:2000.deste processo têm sobre as práticas de- Dessa forma, obtém-se a diferença entre Análise de Riscofinidas (institucionalização do processo). o que se espera dos processos da organi- Risco é a “exposição à chance de perdasPartindo-se destas premissas pode-se zação e onde eles realmente estão. A partir ou danos”. Embora exista também umaconcluir que qualquer risco à qualidade e daí, elaboram-se planos de ação para que chance de alguma coisa sair melhor doà institucionalização do processo se refle- esta distância seja diminuída ou elimina- que o esperado, o risco geralmente cos-te em riscos na qualidade do produto que da, a partir da priorização e seleção dos tuma ser associado a possíveis perdas ouserá entregue e, consequentemente, em planos de ação que serão implantados danos. O conceito de risco resulta da incer-riscos para a organização. Sendo assim, (fase de Estabelecimento). teza quanto a eventos futuros e é parte deações de gerência de risco nos processospodem contribuir diretamente com agarantia da qualidade do produto finale fornecem dados que permitem identi- Por mais controlada e precisa que seja a execução de umaficar quais ações devem ser tomadas commaior urgência. atividade de desenvolvimento, sempre existe o risco, mes- Neste artigo apresentamos uma abor-dagem de análise de processos na qual é mo que muito remoto, de algo dar errado.identificado de forma customizada tantoo nível de conformidade (quantidade derecomendações do modelo de referência A abordagem que apresentaremos todas as atividades de desenvolvimento.implementadas nos processos da organi- facilita a realização das fases de Diag- Um processo de desenvolvimento bemzação) quanto o nível de risco (quantidade nóstico e Estabelecimento de um ciclo de definido e institucionalizado visa reduzirde riscos presentes no processo de desen- melhoria contínua, identificando clara- a chance de ocorrência de ameaças (perdasvolvimento devido às recomendações não mente os riscos associados aos processos ou danos). Toda oportunidade de sucessoimplementadas) em cada área de processo. definidos (Diagnóstico) e fornecendo um sempre carrega consigo uma possibilidadeDessa maneira, uma análise dos processos critério de priorização destes riscos (Es- de falha, cabendo a cada empresa avaliarda organização fornece duas classes de tabelecimento). Para isso, são utilizadas a relação risco versus retorno e determinardados para a tomada de decisão e dire- uma estratégia de avaliação e atividades se “estar” sujeito a esta perda é aceitável,cionamento de recursos, indicando o que de avaliação e melhoria de processos se este evento é muito grave, ou aindadeve ser feito para melhorar o processo de desenvolvimento de software. A se o procedimento para a mitigação não(conformidade) e quais ações devem ser avaliação verifica tanto a dimensão de oferece um retorno satisfatório.tomadas primeiro (risco). conformidade entre o processo e modelos Por mais controlada e precisa que seja a Uma das formas mais indicadas para a de maturidade ou normas de qualidade, execução de uma atividade de desenvol-definição e implantação de processos de quanto à dimensão dos riscos que a não vimento, sempre existe o risco, mesmomaneira eficiente é a utilização de um utilização das boas práticas definidas que muito remoto, de algo dar errado.ciclo de melhoria contínua. Esta forma nestas referências oferecem à qualidade Este fato decorre do grande número depode ser comparada ao desenvolvimento do produto desenvolvido pela organiza- variáveis que podem influenciar no resul-iterativo de um sistema, onde o processo é ção e aos seus objetivos de negócio. Esta tado final e da sua natureza muitas vezesdefinido e implantado na organização em ferramenta também indica como estes imprevisível. A partir desse cenário,fases direcionadas pelas necessidades e pontos podem ser solucionados de forma torna-se necessário aprender a convivercaracterísticas da organização. O modelo que a organização obtenha uma maior com riscos, minimizando suas possíveisIDEAL, desenvolvido pelo Software Engi- qualidade ou resultados a partir deste conseqüências negativas.neering Institute (SEI), ilustra a utilização ciclo. O diferencial desta abordagem é a As principais atividades da disciplinadeste conceito. A implantação deste ciclo utilização da análise de risco como um de gerência de riscos são:de melhoria faz com que os processos de instrumento de priorização das ações que • Identificação corresponde à identifi-uma organização sejam constantemente devem ser tomadas pelas empresas para cação dos riscos inerentes a uma etapa doavaliados e melhorados. mitigar (reduzir as chances de ocorrên- desenvolvimento (fase, processo, itera- No modelo IDEAL destacam-se duas cia) os riscos identificados durante a fase ção). Isto é feito através do levantamentofases: Diagnóstico e Estabelecimento. A de diagnóstico fornecendo um critério das ameaças presentes e do impacto quefase de Diagnóstico consiste em avaliar o concreto para definição do escopo de podem provocar caso se realizem.ambiente produtivo e identificar as opor- cada ciclo de melhoria. • Análise corresponde à reflexão so- Edição 01 – Engenharia de Software Magazine 11
  11. 11. bre os riscos identificados, a partir da é possível obter um retrato mais preciso são definidas quais áreas devem ser oidentificação do nível de exposição de da distribuição e do impacto dos riscos. foco de uma avaliação mais rigorosa ecada projeto. É também realizado um A estratégia de diminuição de riscos da próxima iteração do ciclo de melhoriaestudo de classificação dos riscos no qual, utilizada nos planos elaborados durante contínua (qual é o problema e como elebaseando-se no relacionamento entre a a atividade de planejamento pode tentar pode ser solucionado). Em cada umaexposição e conseqüência negativa do reduzir sensivelmente a probabilidade do das etapas, são realizadas as fases derisco e o benefício da oportunidade, de- risco se realizar, fazendo com que a con- Diagnóstico (identificação dos riscos) etermina-se quais serão eliminados, quais cretização da perda seja algo muito difícil Estabelecimento (priorização e definiçãoserão mitigados, quais serão aceitáveis e de ocorrer. É possível tentar reduzir o dos planos de ação). Na etapa de Abran-quais serão acompanhados. impacto do risco, fazendo com que a con- gência o diagnóstico é mais abrangente e • Planejamento observa e determina seqüência da materialização dele seja tão os planos de ação são menos detalhados e,como e quando os riscos serão aborda- pequena que a sua ocorrência pouco afe- na etapa de Profundidade, o diagnósticodos ao longo do projeto. Comumente tará o resultado final do projeto. Por fim, é mais específico e os planos de ação sãosão elaborados planos de mitigação, é possível reduzir tanto a probabilidade mais detalhados.eliminação e acompanhamento de riscos quanto a severidade do risco, resultando O objetivo desta estratégia é com-que serão utilizados como base para a em um balanceamento razoável entre as plementar métodos como SCAMPI,gerência de riscos. possíveis perdas e a probabilidade de sua MA-MPS e ISO/IEC 15504, oferecendo propostas de soluções a alguns potenciais problemas encontrados na aplicação des- tes métodos. Os princípios que guiam a A eliminação total dos riscos associados a um projeto ou estratégia são: • Mapear resultados aos objetivos do iniciativa é um conceito utópico. negócio da organização; • Minimizar o esforço de avaliação se- gundo critérios de importância definidos pela própria organização; • Controle corresponde à execução e ao ocorrência no projeto. • Obter maior aproveitamento dos re-acompanhamento dos planos elaborados A eliminação total dos riscos associados sultados gerados;para o projeto. Os riscos identificados a um projeto ou iniciativa é um conceito • Utilizar duas dimensões de análise:são analisados constantemente para a utópico. Cada ação de identificação, conformidade e risco.identificação do seu estado atual e atu- acompanhamento e controle (redução,alização dos planos elaborados. Novos mitigação ou contenção de riscos) possui O primeiro princípio tem como objetivoriscos podem ser identificados também. um custo associado, cabendo a cada indi- sanar uma característica identificada A gerência de riscos utiliza como base o víduo ou organização identificar o ponto na maioria dos métodos de avaliaçãoconceito de exposição de risco. Para cada de equilíbrio entre o nível de exposição de processos de desenvolvimento. Deameaça ou possível fonte de problema aos riscos e o custo de redução. Para cada forma geral, a aplicação destes métodosque possa causar perdas ao projeto, a projeto ou iniciativa deve-se determinar gera conclusões ou resultados que estãoexposição (Exp) é definida como o pro- um índice aceitável de exposição aos restritos ao nível das diretivas do modeloduto da probabilidade da perda ocorrer riscos, que seja suficiente para as carac- de maturidade ou norma de qualidade(P) e do tamanho da perda (impacto I terísticas do projeto e tenha um custo que utilizada. Este fato faz com que o trabalhono projeto, artefato, ativo ou qualquer não comprometa os resultados. de convencimento da alta gerência (geral-elemento que seja o foco da análise de mente não técnica) acerca da importânciarisco): Exp = P * I . A Estratégia de Avaliação dos investimentos em engenharia de Na abordagem apresentada, o conceito A estratégia de avaliação que utiliza- software ou qualidade seja dificultado e,de exposição foi estendido, permitindo remos se baseia no conceito de análise consequentemente, o projeto de melhoriauma melhor determinação do impacto de risco na verificação dos processos de processos fique ameaçado devido àda concretização de um risco. Para cada de uma organização e compreende os falta de comprometimento dos patrocina-ativo da organização ou projeto avaliado conceitos apresentados na ISO/IEC 17799. dores. O objetivo destes princípios é dar(pessoa que participa do desenvolvimen- Esta estratégia recomenda a avaliação ênfase às necessidades e prioridades dato ou processos utilizados) é determinado de uma equipe de desenvolvimento ou empresa, ao invés de impor uma estru-um índice de exposição balanceado. Este processo de software em duas etapas, tura que pode não ser a mais adequada aíndice, denominado PSR, determina a onde a primeira (etapa de Abrangência) ela. O mapeamento dos resultados do ní-exposição através da probabilidade da representa uma verificação mais abran- vel de TI para o nível de negócios facilitaocorrência do risco (P), a severidade gente e menos rigorosa da implementação o seu entendimento, podendo orientar adessa ocorrência para o projeto ou para dos modelos e normas de referência, para empresa a como atingir suas metas.a organização (S) e a relevância do ativo identificar quais são as áreas críticas para O segundo e terceiro princípio é resul-da organização (pessoa ou processo) na a organização (onde está o problema). Na tado da constatação de um ponto fracoqualidade do produto final. Dessa forma etapa seguinte (etapa de Profundidade) identificado nos métodos mais utilizados.12 Engenharia de Software Magazine – Melhorando Processos Através da Análise de Risco e Conformidade
  12. 12. proc ess oA grande maioria realiza inspeções e de quando a avaliação foi realizada, a capacidade esperada e a avaliada, qualanálises rigorosas, que abrangem todo o tornando obsoletos os dados relativos às deve receber os recursos?). A utilizaçãomodelo de referência e geram relatórios áreas de processos e as oportunidades de uma análise de risco oferece um cri-com uma grande quantidade de informa- de melhoria que não foram abordadas. tério de desempate ou uma opção para ações sobre diversas áreas da engenharia A utilização de uma estratégia em duas priorização de investimentos.de software mas, na maioria dos casos, etapas permite identificar, através deoutra grande quantidade de informações uma análise menos elaborada, as áreas Ferramenta de apoio à avaliaçãoé desperdiçada. Uma avaliação indica mais relevantes e realizar uma análise Para auxiliar a realização da avalia-o estado atual da organização e aponta mais elaborada apenas nestas áreas. ção dos processos de uma organizaçãoas oportunidades de melhoria na im- Finalmente, o quarto princípio tem utilizamos uma ferramenta de apoio àplementação das diretivas do modelo como objetivo oferecer dados de um ní- execução de avaliações.de maturidade ou norma de qualidade vel de abstração menos granular para a A metodologia de análise de riscoutilizada como referência. Entretanto, tomada de decisão. Embora a utilização implementada pela ferramenta se baseiadevido a restrições de orçamento e ao da capacidade de processo e do nível de na avaliação de características de ativosimpacto que elas representam no am- maturidade seja o parâmetro mais utili- da organização, que podem representarbiente produtivo, apenas uma pequena zado no direcionamento de recursos na pessoas da organização, processos uti-parte destas recomendações pode ser área de desenvolvimento de software, lizados, tecnologias e características doimplementada na próxima iteração do estes conceitos são um tanto abstratos ambiente de desenvolvimento. Cada ativoprograma de melhoria. Após a implemen- e em muitos casos dificultam esta ativi- é mapeado em componentes de negóciotação da primeira iteração de melhoria, o dade (se vários processos apresentam a (para o contexto de desenvolvimento deestado da organização já não é o mesmo mesma capacidade e o mesmo gap entre software foram utilizados objetivos doFigura 1. Mapeamento dos ativos em objetivos do negócio da organização Edição 01 – Engenharia de Software Magazine 13
  13. 13. negócio ou de TI) da organização e pos- possui uma estrutura com os seguintes pode ser implementado para diminuirsui uma relevância que está diretamente elementos: a exposição da organização aos riscos erelacionada à relevância dos objetivos aos • Nome do Controle indica uma carac- atingir a conformidade desejada com oquais ele se relaciona. A Figura 1 ilustra terística (boa prática ou requisito) que modelo ou norma de referência.este conceito. deve estar presente no ativo para que o • Referências relacionam referências A cada ativo podem ser associados um controle seja considerado implementado bibliográficas para que mais informaçõesou mais componentes, que represen- e seu risco associado seja eliminado. acerca do controle e da sua implementa-tam características que serão avaliadas • Justificativa define os termos e concei- ção possam ser obtidas.em um projeto de avaliação que estão tos necessários para o entendimento do • Probabilidade representa a probabili-relacionadas à participação deste ativo, controle e fornece uma justificativa que dade de uma ameaça se manifestar caso oou seja, ao adicionar um componente a explique porque aquele controle deve ser controle não esteja implementado na or-um ativo estamos dizendo que ele é um implementado. Neste elemento são apre- ganização. Este elemento é representadocoletor de dados que indicam o estado sentadas as vantagens que se obtém com por um número de 1 (menor) a 5 (maiorde implementação de um conjunto de a implementação do controle e as conse- probabilidade).boas práticas na organização. Um pro- qüências da sua não implementação. • Severidade indica o grau do impactojeto de avaliação pode utilizar todos os • Ameaças indicam quais elementos po- negativo na organização, caso uma oucomponentes ou apenas um conjunto dem se aproveitar da não implementação mais ameaças se manifestem. Este ele-que seja relevante para esta instância de do controle para se manifestar e causar mento é representado por um númeroavaliação. Cada componente possui um danos ao negócio da organização. de 1 (menor) a 5 (maior severidade).checklist associado, composto por um ou • Recomendação fornece razões e dados • Agrupamento indica a qual agrupa-mais controles, que representam os itens para a elaboração de um plano de ação mento o controle pertence. Os agrupa-atômicos de verificação da implemen- após a realização da avaliação, através mentos são comuns a todos os checklists,tação das boas práticas. Cada controle de uma sugestão de como o controle permitindo verificar o estado da imple- Controle Processo - CMMI – Gerência de Configuração – Prática 3.1 - 2 - As versões anteriores de um item de configuração devem ser passíveis de recuperação. Uma versão anterior de um item de configuração deve ser recuperada caso uma modificação não seja corretamente implementada, caso os arquivos atuais (na nova configuração Justificativa do software) estejam corrompidos, caso seja efetuada uma junção (merge) incorretamente entre um ramo (linha temporária de desenvolvimento) e a linha principal de desenvolvimento. Nestas situações, pode ser apropriado restaurar uma versão anterior para que esta se torne a atual. Este controle pode ser implementado através dos seguintes procedimentos: - Disponibilizar as versões dos itens de configuração. - Reportar os procedimentos para: (1) recuperar uma versão anterior, (2) verificar as revisões de um item de configuração e (3) analisar as diferenças entre a versão anterior e a atual. Essas informações devem constar no plano de gerência de configuração e nos procedimentos de controle de versões. Caso não estejam, sugere-se alterá-los. - Garantir a integridade e a disponibilidade dos repositórios de configurações. Recomendação Observação: A ferramenta de controle de versões deve facilitar a visualização e recuperação das versões dos itens de configuração. Portanto, contém funcionalidades que facilitam a implementação deste controle. Exemplos de Artefatos Produzidos: - Lista de versões de itens de configurações - Procedimentos para controle de versões Probabilidade 4 Severidade 3 Std 1042 - IEEE Guide to Software Configuration Management, Institute of Electrical and Electronics Engineers, 1987. ISO/IEC 12207 - Information technology - Software life cycle processes, International Organization for Standardization, 1995. ISO/IEC 15504 - Information technology - Process Assessment, International Organization for Standardization, 2004. Referências CMMI-Dev: Área de Processo: Gerência de Configuração Bibliografia de apoio: H. R. Berlack, Software Configuration Management. New York: John Wiley & Sons, 1992. Baixa manutenibilidade Ameaças Perda de controle de solicitações de mudança Agrupamento Gerência de ConfiguraçãoTabela 1. Exemplo de controle14 Engenharia de Software Magazine – Melhorando Processos Através da Análise de Risco e Conformidade
  14. 14. proc ess omentação de características espalhadas de um processo padrão para a área de ganização, das pessoas, dos fornecedoresem vários checklists. processo de definida em algum modelo ou do projeto ao qual ele pertence. Sendo ou norma de referência, como Gerência assim, chegou-se a seguinte taxonomia A Tabela 1 apresenta um exemplo de de Configuração e Solução Técnica do para os ativos:controle de uma prática de gerência de CMMI, ou grupo de áreas de processo, • Processos representam fluxos de tra-configuração. que será utilizado como base para a balho, áreas de processo ou disciplinas da A avaliação consiste em responder aos elaboração das recomendações de im- organização. Cada checklists associadochecklists associados aos ativos e sele- plementação de controles. Esta atividade a este tipo de ativo possui o escopo decionados na configuração do projeto de possui tarefas de elaboração e revisão uma área de processo do modelo deavaliação. Estes podem ser respondidos de conteúdo e aderência aos modelos ou maturidade ou norma de qualidade. Adiretamente ou através de questionários normas de qualidade utilizadas como utilização destes ativos define uma di-enviados via WEB, onde o conteúdo dos referência. Em seguida, atividades de mensão da avaliação onde os processoscontroles pode ser interpretado para um geração e revisão de arquitetura dos che- são o principal fator para o alcance dosdomínio específico, por exemplo, para cklists são executadas de forma iterativa objetivos da organização e, consequen-os diversos papéis de uma organização. e concorrente, até que um produto com temente, a principal fonte de evidênciasA utilização dos questionários permiteum ganho de escala e de cobertura daavaliação, ao mesmo tempo em que di-minui o impacto da avaliação e aumenta A arquitetura do checklist consiste da identificação dosa aceitação das melhorias no processo dedesenvolvimento uma vez que todos se controles que serão desenvolvidos e dos questionários quesentem parte da avaliação e podem con-tribuir com comentários e sugestões. serão utilizados como coletores automáticos de dados. Após a coleta dos dados, é gerado umconjunto de relatórios contendo tabelas egráficos que indicam o estado da imple- qualidade assegurada seja desenvolvido. da implementação do modelo ou normamentação das boas práticas e os riscos A arquitetura do checklist consiste da de referência.presentes na organização e fornecem identificação dos controles que serão • Pessoa representa os atores da orga-dados para a tomada de decisão (o que e desenvolvidos e dos questionários que nização. Os checklists associados a estecomo deve ser feito). Cada controle não serão utilizados como coletores automá- tipo de ativo verificam as diretivas daimplementado ou implementado parcial- ticos de dados. norma relativas a um papel da organi-mente, contribui com um índice de risco Tendo um conjunto revisado dos contro- zação (desenvolvedor, gerente, analista(PSR) que é obtido pela multiplicação da les que devem ser implementados e um de requisitos, etc.) que é assumido pelarelevância do ativo avaliado (R), da pro- questionário que interpreta e responde pessoa que é referenciada pelo ativo. Ababilidade da concretização das ameaças estes controles do checklist através de utilização de ativos do tipo Pessoa defi-possíveis (P) e da severidade desta con- uma lógica bem definida para as suas ne uma dimensão da avaliação onde ascretização (S) . Além do PSR, os seguintes perguntas, inicia-se uma nova etapa de pessoas e os papéis que elas executamindicadores são utilizados: implementação e revisão dos controles, são o principal fator para o alcance dos onde o conteúdo dos controles iden- objetivos da organização e, consequen-Índice de PSR controles (elemento ) tificados é elaborado e o questionário temente, a principal fonte de evidênciasSegurança = implementados PSR (Total) desenvolvido é refinado. Finalmente, os da implementação do modelo ou norma checklists são homologados e adiciona- de referência. dos à ferramenta. • Ambiente representam o ambienteÍndice de € Num.Controles Im plementado s Tendo um guia para a elaboração dos organizacional, caracterizado pelasConformidade = Num.ControlesTotal checklists, o segundo passo é a identifica- acomodações, aspectos inter-pessoais, ção dos checklists que seriam utilizados política motivacional e outros fatores A partir destes índices, pode-se gerar para a realização das avaliações. Como que afetam indiretamente a execução dosum grande número de interpretações, os checklists são associados aos ativos da processos. Os checklists associados a esteatravés da filtragem e agrupamento de organização, através dos componentes, tipo de ativo verificam as característicasdados das áreas de processo, ativos, esta atividade foi realizada utilizando gerais da organização e como ela contri-ameaças, departamentos ou objetivos como parâmetro os tipos de ativos. bui ou não com o alcance dos objetivosde negócio. A ferramenta define quatro tipos de da organização. ativo para a realização das avaliações: • Tecnologia representa a estruturaUtilizando a Abordagem “Pessoa”, “Processo”, “Ambiente” e “Tec- tecnológica da organização, definida por Para utilização desta abordagem em nologia”. Para o domínio de processos de suas máquinas e ferramentas. Os che-uma avaliação, utilizamos um conjunto desenvolvimento, definiu-se que cada cklists associados a este tipo de ativo ve-de atividades. ativo funciona como uma dimensão de rificam características da infra-estrutura A primeira atividade consiste na criação coleta de dados sobre os processos da or- referenciada pelo ativo, como segurança Edição 01 – Engenharia de Software Magazine 15
  15. 15. em servidores, funcionalidades de ferra- Organizacional, Desenvolvimento de análise da atomicidade. Esta análise temmentas, entre outros. Requisitos, Foco no Processo Organiza- como objetivo quebrar o item em ele- cional, Garantia da Qualidade, Gerência mentos de verificação atômicos, evitando Como terceiro passo da customização, de Configuração e Gerência de Requisi- situações de falha no preenchimento doa estrutura para a geração de checklists tos que representam as características controle (se existem dois ou mais pontosfoi elaborada. Esta atividade contou com específicas de cada área de processo e o de verificação conectados por um ope-a definição dos agrupamentos, ameaças agrupamento GG2 – Processo Gerenciado rador “e” ou “ou” em um controle, comoe do escopo dos controles. representa as características genéricas. respondê-lo no caso de alguns estarem Como o objetivo da avaliação é obter Estão também ilustrados controles dos implementados e outras não?).resultados mapeados nas áreas de proces- agrupamentos de Gerência de Configu- Finalmente, para uniformizar as análi-so do modelo ou norma de qualidade de ração e Gerência de Requisitos. Cada ses de risco e conformidade em processosreferência, independente de quais ativos agrupamento contém um conjunto de de desenvolvimento realizados com aforam utilizados para coletar os dados, foi controles. utilização da ferramenta, foi elaboradadefinido que os agrupamentos utilizados Com a estrutura de agrupamentos defi- uma lista de ameaças.seriam as áreas de processo. nida, os resultados das análises de risco Tendo em vista que a grande maioria Uma área de processo possui carac- e conformidade podem ser consolidados dos métodos de avaliação de processosterísticas específicas, que determinam pelos agrupamentos, resultando em rela- de desenvolvimento (SCAMPI, MA-MPS,a sua implementação, e características tórios (exemplificados no próximo tópi- ISO/IEC 15504) utiliza uma estruturacomuns a todas as áreas, que indicam a co), que indicam risco e conformidade de de níveis para a classificação da imple-sua capacidade. Para facilitar a utilização cada área de processo, e que deixam de mentação de uma diretiva do modelo oude modelos de maturidade que utilizam forma transparente quais tipos de ativo norma, utilizamos nesta solução a mesmao conceito de capacidade de processos foram utilizados. abordagem. Desta forma, cada controlefoi definido também que deve existir Para o escopo dos controles, foi definida pode ser classificado como “Implemen-um agrupamento para cada nível de a utilização do item de menor granulari- tado”, “Não Implementado” ou “Parcial-capacidade. dade do modelo ou norma de referência. mente Implementado”. Partindo do fato A Figura 2 ilustra este conceito para o Como em muitos modelos e normas o de que um controle parcialmente imple-CMMI-DEV 1.2, onde um Checklist para item de menor granularidade possui mais mentado não se encontra implementado,o ativo desenvolvedor (papel) contém os de um item de verificação em seu escopo, foi determinado que, quando a análiseagrupamentos Definição do Processo foi definida também a realização de uma realizada indicasse que um controle nãoFigura 2. Checklist com agrupamentos para características específicas e genéricas16 Engenharia de Software Magazine – Melhorando Processos Através da Análise de Risco e Conformidade
  16. 16. proc ess ofoi totalmente atendido, este deve ser os controles parcialmente implementados de desenvolvedor, portanto o peso daspreenchido como “Não implementado”. contribuirão com menos risco do que os áreas técnicas do modelo será maior queUtilizando a premissa de que um controle controles do mesmo tipo classificados o peso das áreas de gestão ou das áreasparcialmente implementado possui uma como não implementados. organizacionais. Além disso, nesta etapa,probabilidade menor de causar danos do os objetivos do negócio da organizaçãoque um controle não implementado, foi Utilizando a abordagem não foram identificados e mapeados nosdeterminado que, para cada nível de im- Para demonstrar a aplicabilidade da ativos de software.plementação atingido pelo controle, a sua abordagem proposta, foram realizados Abaixo são apresentados os resultadosprobabilidade será diminuída em uma vários estudos de caso, nos quais o da avaliação:unidade, até chegar ao valor mínimo 1. processo utilizado por equipes de desen- Conforme apresentado na Tabela 3 e Para exemplificar a abordagem, consi- volvimento de software de organizações na Figura 3, as áreas de Planejamentodere um controle cuja probabilidade seja distintas foi avaliado. A seguir, é apre- de Projetos, Solução Técnica e Defini-quatro. Em uma avaliação que utiliza sentado um resumo de uma das avalia- ção do Processo Organizacional têm oo modelo CMMI como referência, um ções realizadas onde se realizou apenas maior índice de Segurança indicando quecontrole classificado como parcialmente a etapa de Abrangência. Para preservar a maior parte das práticas destas áreasimplementado será preenchido como Não a confidencialidade, as informações estão implementadas. Ao contrário, asImplementado e a sua probabilidade será apresentadas foram descaracterizadas áreas de Treinamento Organizacional,alterada para três. O resultado desta abor- (ver Tabela 2). Gerência de Requisitos, Integraçãodagem é que, ao final da análise de risco, A avaliação considerou somente o perfil do Produto e Gerência de Configura- Empresa ABC Objetivos: Avaliar o processo utilizado no desenvolvimento dos softwares da organização utilizando o modelo CMMI DEV 1.2 como referência e identificar oportunidades de melhoria nas áreas de processo de maior impacto no desenvolvimento dos softwares. Fase de Abrangência Escopo Organizacional Participantes Escopo do Modelo Duração (h/dias) Projetos de desenvolvimento de - 9 Desenvolvedores do Setor 1 Áreas de níveis 2 e 3 do CMMI DEV 1.2, exceto : Garantia da Qualidade, Gerencia de Fornecedores, 16/4 sistemas internos da organização - 9 Desenvolvedores do Setor 2 Gerência de Risco, Gerenciamento Integrado e Análise de Decisões e ResoluçõesTabela 2. Resumo do objetivo e escopo da avaliação PSR Controles PSR Controles Não Índice de Conformidade Índice de Segurança Área de Processo PSR Total Implementados Implementados (%) (%) Avaliação e Melhoria do Processo 64 194 256 32,16 25,00 Definição do Processo Organizacional 160 96 256 85,13 62,50 Desenvolvimento de Requisitos 304 1328 1632 19,16 18,63 Gerência de Configuração 388 1912 2300 25,34 12,52 Gerência de Requisitos 72 1152 1224 0,00 5,88 Integração do Produto 148 1364 1512 15,05 9,79 Medição e Análise 248 264 512 76,18 48,44 Monitoramento e Controle de Projetos 580 780 1360 74,05 42,65 Planejamento de Projetos 1024 200 1224 78,15 83,66 Solução Técnica 2140 852 2992 67,12 71,52 Treinamento Organizacional 8 400 408 0,00 1,96 Validação 108 468 576 22,25 18,75 Verificação 316 1472 1788 18,15 17,67 Total 5560 10482 16040 67,15 53,04Tabela 3. Resultados da avaliação em abrangência por área de Processo Edição 01 – Engenharia de Software Magazine 17
  17. 17. V is ão G eral - Área P roc es s o Planejamento de Projetos Solução Técnica Definição do Processo Organizacional Medição e Análise Monitoramento e Controle de Projetos Avaliação e Melhoria do Processo Segurança Validação Conformidade Desenvolvimento de Requisitos Verificação Gerência de Configuração Integração do Produto Gerência de Requisitos Treinamento Organizacional 0 20 40 60 80 100 %Figura 3. Resultados da avaliação em Abrangência – Gráfico de Índices de conformidade e segurança para cada área de Processo (Ordenação decrescentepelas áreas de maior índice de Segurança) R is c o Abs oluto - Área P roc es s o Gerência de Configuração Verificação Integração do Produto Desenvolvimento de Requisitos Gerência de Requisitos Solução Técnica Monitoramento e Controle de Projetos Validação Treinamento Organizacional Medição e Análise Planejamento de Projetos Avaliação e Melhoria do Processo Definição do Processo Organizacional 0 500 1000 1500 2000 2500 PSR PSR Implementado PSR Não ImplementadoFigura 4. Resultados da avaliação em Abrangência – Gráfico de PSR por área de Processo (Ordenação decrescente pelas áreas de maior PSR)18 Engenharia de Software Magazine – Melhorando Processos Através da Análise de Risco e Conformidade
  18. 18. proc ess o R is c o Abs oluto - S etor 1 Gerência de Configuração Solução Técnica Integração do Produto Verificação Desenvolvimento de Requisitos Gerência de Requisitos Monitoramento e Controle de Projetos Validação Treinamento Organizacional Medição e Análise Avaliação e Melhoria do Processo Planejamento de Projetos Definição do Processo Organizacional 0 200 400 600 800 1000 1200 PSR PSR Implementado PSR Não ImplementadoFigura 5. Resultados da avaliação em Abrangência – Gráfico de PSR do Setor 1 por Processo (Ordenação decrescente pelas áreas de maior PSR) R is c o Abs oluto - S etor 2 Verificação Desenvolvimento de Requisitos Gerência de Configuração Integração do Produto Gerência de Requisitos Monitoramento e Controle de Projetos Validação Solução Técnica Treinamento Organizacional Planejamento de Projetos Avaliação e Melhoria do Processo Medição e Análise Definição do Processo Organizacional 0 200 400 600 800 1000 1200 1400 PSR PSR Implementado PSR Não ImplementadoFigura 6. Resultados da avaliação em Abrangência – Gráfico de PSR do Setor 2 por Processo (Ordenação decrescente pelas áreas de maior PSR) Edição 01 – Engenharia de Software Magazine 19
  19. 19. ção têm o menor índice de Segurança Verificando as informações apresen- mais relevantes estão relacionadas com:indicando que poucas práticas destas tadas na Tabela 4 e nas Figuras 5 e 6, o áreas estão implementadas. As áreas de conclui-se que na organização, as áreas Produto não atender às necessidades dosDefinição do Processo Organizacional, de Gerência de Configuração, Verifi- clientes - Desenvolvimento de Requisitos,Medição e Análise, Monitoramento cação, Integração do Produto, Desen- Verificação e Validação;e Controle de Projetos e Gerência de volvimento de Requisitos e Gerência o Configuração têm um índice de Confor- de Requisitos têm maior probabilidade Requisitos incompletos, inconsistentes oumidade relativamente maior que o índice de manifestação dos riscos durante sua incorretos - Gerência e o Desenvolvimen-de Segurança indicando a implementação execução. Entretanto, quando os dois to de Requisitos e Verificação;de práticas pouco eficientes na mitigação setores são avaliados separadamente o oftware apresentar falhas – Solução Téc- Sdos riscos. conclui-se que: nica, Integração do Produto e Verificação; De acordo com a Figura 4, pode-se o o verificar que as áreas de Gerência de No Setor 1 as áreas de Gerência de Confi- Perder controle sobre as solicitações de mu-Configuração, Verificação, Integração guração, Solução Técnica, Integração do dança - Gerência de Requisitos e Gerênciado Produto, Desenvolvimento de Re- Produto, Verificação, Desenvolvimento de Configuração.quisitos e Gerência de Requisitos têm de Requisitos e Gerência de Requisitosmaior PSR Não implementado indicando têm maior probabilidade de manifestação Como resultado final da avaliação,maior probabilidade de manifestação dos dos riscos durante sua execução, ou seja, definiu-se um plano priorizando açõesriscos durante sua execução. Ao contrá- a área de Solução Técnica tem um peso de melhoria nas áreas de Gerência derio, as áreas de Definição do Processo importante nos riscos das atividades do Configuração, Desenvolvimento deOrganizacional, Avaliação e Melhoria Setor 1; Requisitos e Gerência de Requisitos,do Processo, Planejamento de Projetos o que apresentaram um alto PSR não im-e Medição e Análise têm menor PSR No Setor 2, as áreas de Verificação, De- plementado, combinado com um baixonão implementado, indicando menor senvolvimento de Requisitos, Gerência índice de segurança. Para um melhorprobabilidade de manifestação dos riscos de Configuração, Integração do Produto detalhamento das ações de melhoria foidurante sua execução. e Gerência de Requisitos têm maior sugerida também a realização de uma As áreas de Solução Técnica, Planeja- probabilidade de manifestação dos riscos avaliação em Profundidade para cadamento de Projetos e Monitoramento e durante sua execução, ou seja, o mesmo uma das três áreas mencionadas.Controle de Projetos têm maior PSR im- resultado da organização com a inversão Em um segundo momento, foram su-plementado, indicando a implementação de algumas posições. geridas ações de melhoria para as áreasde práticas que evitaram a manifestação de Verificação e Integração do Produto,de um maior número de riscos. Pelo apresentado na Figura 7, as ameaças devido ao alto PSR não implementado Setor 1 Setor 2 PSR Controles PSR Controles Não PSR Controles PSR Controles Não Área de Processo PSR Total PSR Total Implementados Implementados Implementados Implementados Avaliação e Melhoria do Processo 30 98 128 34 94 128 Definição do Processo Organizacional 82 46 128 78 50 128 Desenvolvimento de Requisitos 272 544 816 32 784 816 Gerência de Configuração 16 1134 1150 372 778 1150 Gerência de Requisitos 72 540 612 0 612 612 Integração do Produto 70 686 756 78 678 756 Medição e Análise 82 174 256 166 90 256 Monitoramento e Controle de Projetos 316 364 680 264 416 680 Planejamento de Projetos 518 94 612 506 106 612 Solução Técnica 796 700 1496 1244 252 1496 Treinamento Organizacional 4 200 204 4 200 204 Validação 84 204 288 24 264 288 Verificação 256 638 894 60 834 894 2598 5422 8020 2862 5158 8020Tabela 4. Resultados da avaliação em Abrangência – por Setor e Área de Processo20 Engenharia de Software Magazine – Melhorando Processos Através da Análise de Risco e Conformidade

×