Classificação Dos Fatores de Risco Que Podem Afetar a Implantação Da Linha De Produto De Software.

Classificação Dos Fatores de Risco Que Podem Afetar a Implantação Da Linha De Produto De Software. Danilo M. Ribeiro FACITEC - Universidade de Pernambuco (UPE) Universidade de Pernambuco, Campus de Caruaru. Rodovia 104 - Km 62 Nova Caruaru 55024-970 - Caruaru, PE – Brasil, Telefone (81) 3719-9448 {[email protected]}

Abstract. The use of software product line in industry has been growing in recent years, many companies think of adopting it, however the deployment of the line containing a number of risks for these companies and should be handled with care. This paper proposes the classification of the factors can affect the deployment of the product line of software for enterprises can be better prepared for deployment. Resumo. A utilização de linha de produto de software pela indústria vem crescendo nos últimos anos, várias empresas pensam em adotá-la, contudo a implantação da linha contêm vários riscos para essas empresas e deve ser feita com cuidado. Este artigo propõe a classificação dos fatores que podem afetar a implantação da linha de produto de software para que as empresas possam se preparar melhor para a implantação.

1. Introdução A atividade de desenvolvimento de software enfrenta crescentes desafios em busca da diminuição de custos, esforço e tempo de chegada dos produtos no mercado, contudo os produtos estão aumentando sua complexidade e tamanho. De acordo com LAZILHA (2002), a reutilização está entre as técnicas mais relevantes para ajudar a resolver os desafios. Isto vem do princípio que reutilizando partes bem especificadas, desenvolvidas e testadas pode-se construir software em menor tempo e com maior confiabilidade. Buscando atender as novas demandas têm sido propostas diferentes abordagens que favorecem o reuso de artefatos de software, entre elas a Linha de Produto de Software. LOBO e RUBIRA (2009) afirma que empresas que desenvolvem produtos de software em um determinado domínio de aplicação podem obter ganhos significativos em termos de redução de esforço e custos, utilizando o enfoque de linha de produto, desenvolvendo assim vários produtos similares ao mesmo tempo ao invés de focar no desenvolvimento de um único produto por vez. Segundo CLEMENTS e NORTHROP (2001), uma Linha de Produto de Software é um conjunto de produtos de software com alto grau de similaridade entre si, que atendem

às necessidades específicas de um segmento de mercado ou missão, e que são desenvolvidos de forma prescritiva a partir de um conjunto de artefatos básicos. BOEHM e DEMARCO (1997) afirmam que os riscos no desenvolvimento de software são faceis de se reconhecer no abstrato, contudo são difíceis de reconhecer em situações reais. Portanto, é de suma importancia prever e controlar riscos para que se tenha sucesso no desenvolvimento do software. Este artigo visa classificar em humanos, técnicos e organizacionais os fatores de risco que podem afetar a implantação da Linha de Produto de Software com um objetivo de obter um melhor gerenciamento de risco nas organizações que desejam aderir à Linha de Produto de Software. Ele está dividido da seguinte maneira: na Seção 2 encontra-se uma breve contextualização sobre Linha de Produto de Software e os benefícios que ela pode trazer para a organização, na Seção 3 as caraterísticas de uma implantação de Linha de Produto de Software serão apresentadas, os principais fatores encontrados na literatura que podem afetar a implatação da linha de produto aparecerão na Seção 4, e finalmente na Seção 5 a classificação proposta será exposta.

2. Linha de Produto de Software Segundo CLEMENTS e NORTHROP (2001), uma Linha de Produto de Software (LPS) representa um conjunto de sistemas, que também pode ser chamado de família de produtos, que compartilham características (features) comuns, satisfazendo às necessidades de um segmento particular do mercado. Um conjunto de sistemas é desenvolvido a partir de uma coleção comum de artefatos da Linha de Produto de Software, ou seja, a Linha de Produto de software define um seguimento comum para os softwares desenvolvidos que compartilham características para não ser necessário desenvolver os esforços novamente. De acordo LUCENA (2010), uma feature pode ser definida como uma propriedade de um sistema que é relevante para algum usuário e que é usada para capturar pontos em comum ou para discriminar entre produtos numa linha de produção. Um conjunto de feature é importante para caracterizar se os softwares estão na mesma linha de produto. COHEN (2003) classificou os benefícios da Linha de Produto de Software em duas categorias: (i) Tangíveis, que são aqueles que podem ser medidos metricamente; (ii) Intangíveis, que são aqueles que se sente o efeito, contudo não podem ser medidos diretamente. DURSCKI et al (2004) sugeriram uma adaptação das tabelas proposta por COHEN (2003) apresentando diversas características das duas categorias, conforme a Tabela 1: Tabela 1. Benefícios tangíveis e intangíveis de uma LPS por Durscki. Lucratividade

Qualidade Desempenho dos produtos de

Benefícios Tangíveis Já que o repositório de ativos permite que se tenham produtos voltados para um segmento específico de mercado pode ter um aumento da participação de mercado e aumento da lucratividade. É comum notar uma redução no número de defeitos. A qualidade também pode ser medida em termos de redução do tempo de correções. A utilização de ativos aumenta a desempenho em relação

software Tempo de integração Produtividade

Desgaste de profissionais Aceitabilidade dos desenvolvedores Satisfação profissional

Satisfação do Cliente

ao desenvolvimento tradicional, especialmente com o aumento da maturidade da linha, o que faz com que os ativos estejam cada vez mais otimizados. O tempo de integração no desenvolvimento incremental é facilitado. A equipe de desenvolvimento pode ser reduzida; O custo total de desenvolvimento é cortado consideravelmente; O cronograma é reduzido (maior velocidade de lançamento); O sistema possui uma flexibilidade documentada, o que facilita o atendimento das solicitações de modificações do cliente; Benefícios Intangíveis Menor desgaste dos profissionais, o que resulta em uma redução do turnover de membros da equipe. Após um treinamento inicial, os desenvolvedores relatam satisfação em trabalhar com a abordagem baseada em ativos e arquitetura comuns. Os desenvolvedores relatam que o trabalho braçal já foi realizado (desenvolvimento dos ativos de software), assim eles podem se concentrar em atividades mais interessantes, como o aperfeiçoamento e / ou inovação de elementos específicos. Os ativos reduzem os riscos, aumentando a previsibilidade da entrega e diminuindo a taxa de defeitos. Esses fatores afetam positivamente o cliente (induzindo-o a preferir produtos derivados de linhas de produto).

A Tabela 1classifica os benefícios tangíveis em cinco (Lucratividade, Qualidade, Produtividade, Tempo de integração e Desempenho dos produtos) e os benefícios intangíveis em quatro (Menor desgaste de profissionais, Aceitabilidade dos desenvolvedores, Satisfação profissional e Satisfação do cliente), contudo, existem fatores que podem dificultar o desenvolvimento de uma linha de produção de software de acordo com DURSCKI et al (2004), como por exemplo, o processo de implantação da Linha de Produto de Software que pode ser muito complexo e levar muito tempo para obtenção das vantagens apresentadas.

3. Características da implantação da Linha de Produção de Software De acordo com CLEMENTS e NORTHROP (2001), um projeto de implantação de uma Linha de Produto de Software pode ser considerado um projeto de inovação tecnológica, ou uma nova maneira de fazer negócio. Levando em consideração que as duas classificações são possíveis, DURSCKI et al (2004) acreditam que existe uma complexidade a mais ao projeto, pois pode encontrar resistência dos envolvido a alguma das classificações ou ainda dificuldade do gestor para escolha de alguma das possibilidades. DURSCKI et al (2004) entendem que o projeto para implantação da Linha de Produto de Software abrange uma avaliação organizacional, uma articulação do estado

desejado e um planejamento para atingir este estado, ou seja, a implantação de uma LPS requer um auxílio dos tomadores de decisão da empresa. DURSCKI et al (2004) também afirmam que no caso de linhas de produto, fatores extras-tecnológicos devem ser considerados, como a adaptabilidade das pessoas, e o tipo de treinamento necessário. Levando em consideração esses fatores a implantação de uma LPS pode ser ainda mais difícil, pois pode mudar a estrutura da organização. DURSCKI et al (2004) ainda afirmam que o projeto de implantação de LPS pode ser definido de duas maneiras distintas: • Repentino ou completo: A empresa que escolhe essa abordagem pode interromper ou diminuir consideravelmente sua produção para concentrar esforços no desenvolvimento de repositórios ativos. Levando em consideração que a empresa pode até parar o desenvolvimento de produtos, DURSCKI et al (2004) consideram essa abordagem a mais radical e em alguns casos economicamente inviável. • Gradual ou incremental: Com essa abordagem a organização escolhe por desenvolver seus produtos normalmente, contudo nas fases dos projetos são feitas contribuições para a estrutura da LPS. Segundo CLEMENTS e NORTHROP (2001), essa abordagem acaba sendo preferida pela indústria, pois as etapas são divididas em vários produtos podendo diminuir os riscos, além disso, a empresa não precisa parar sua produção, porém nesta abordagem o custo para implementação é maior e está dividido nos projetos realizados.

4. Fatores que podem afetar a Linha de Produção de Software Os principais fatores que podem ocasionar problemas para a Linha de Produção de Software, levantados por COHEN (2002), são: • Falta de um líder comprometido: Para o sucesso do processo de adoção é necessário que se tenha um líder motivando, apoiando e controlando. Esta pessoa deve acreditar no modelo para que a implementação ocorra com sucesso. • Falta de compromisso da gerência: Assim como o líder, a gerência deve acreditar na possibilidade de que o projeto tenha sucesso, pois caso isso não ocorra pode acarretar em perda de foco dos membros e de recursos, trazendo prejuízos para a empresa. • Abordagem inadequada: Se ocorrer dos produtos da Linha de Produto de software não terem um numero significante de features semelhantes para garantir a viabilidade do modelo, a linha poderá trazer prejuízo para empresa. • Falta de compromisso da equipe: Semelhante ao problema relatado em falta de compromisso da gerencia. Caso a equipe não entenda ou ainda não queira aplicar o modelo, pode se ter um fator de risco para empresa que queira utilizar Linha de Produto de Software. • Interação insuficiente entre as equipes: Como é necessário que diferentes áreas da organização (Marketing e Desenvolvimento, por exemplo), ou até mesmo equipes diferentes da mesma área se comuniquem, para que se tenha sucesso na implantação, este fator acaba sendo mais um risco a ser analisado pela organização. • Padronização desapropriada: Ao se implantar linha de produto de software em uma organização deve se tomar cuidado para que não se escolha um padrão impróprio para a realidade da organização.

• Falta de Adaptação: A falta de adaptação dos componentes pode reduzir o desempenho da equipe e desenvolver problemas para a linha, pois é necessário que os componentes tenham adaptabilidade para serem utilizados em outros produtos. • Incapacidade de melhoria contínua: O processo da linha de produto precisa ser revisado periodicamente para garantir qualidade e para que ele não utilize práticas obsoletas. • Problemas na Disseminação: Para que se tenha sucesso na implantação de uma linha de produto de software é necessário que se tenha um líder comprometido para que ele tenha a responsabilidade de desenvolver e distribuir as documentações para cada nível da organização, treinar os envolvidos e apoiar o processo. Além dos fatores encontrados por COHEN (2002) outros fatores também serão levados em consideração nesse trabalho: • Falta de Certificações: BIRK e HELLER (2007) acreditam que os artefatos gerados por uma LPS deveriam ser certificados e utilizados em diferentes produtos sem a necessidade de obter outra certificação, contudo o que acontece é que a certificação apenas acontece quanto o produto está completo. • Problemas na Definição das features: Segundo NORTROP (2002), a Modelagem por features é a técnica de modelagem de requisitos que normalmente é utilizada na Linha de Produto de Software. NORTROP (2002) afirma que essa técnica é uma maneira boa e fácil de obter uma visão geral das partes da Linha de Produto de Software. • Falha na identificação de requisitos: LOBATO et al (2010) acredita que a engenharia de requisitos e a gestão deles são consolidação dos ativos na plataforma e na criação de tarefas de desenvolvimento da linha de produto de software. Definir corretamente os requisitos de software é de suma importância para o desenvolvimento da linha de produto. Em uma organização que se predispõe a implantar Linha de Produto de Software levar em consideração esse fatores é essencial para seus objetivos, caso eles não sejam avaliados e trabalhados a organização pode se prejudicar financeiramente e ter seu cronograma afetado.

5. Classificação dos fatores que afetam a Linha de Produto de Software Para o desenvolvimento deste trabalho foi realizado uma revisão da literatura em que foi considerado que os fatores que afetam a Linha de Produto de Software podem ser divididos em três: organizacional, humano e técnico. (i) Organizacional: Segundo a ISSO/IEC 12207 (2008) são fatores que podem ser empregados fora do domínio de projetos e são de responsabilidades da gerência geral e da organização. SANDHOF (2004) afirma que esses fatores são influenciadores de atividades rotineiras, sejam elas relacionadas a software ou não; (ii) Humanos: De acordo com SANDHOF (2004) Os fatores humanos no desenvolvimento de software estão relacionados, por exemplo, com a motivação, treinamento, a dificuldade no desempenho das tarefas e de liderança. São fatores que diferem de cada individuo; (iii)Técnicos: Conforme PALVIA et al(2001), os fatores técnico abordam a natureza da tarefa/processo a ser executada e as tecnologias de apoio. Os fatores técnicos estão relacionados ao como fazer, por exemplo, a linguagem e o paradigma utilizados, a

metodologia escolhida, o tipo de linha de produto de software escolhida, bem como sua implantação. De acordo com as características de cada fator, está sendo proposta a classificação dos principais fatores que afetam a Linha de Produto de Software levantados na Seção três na Tabela 2. Tabela 2. Classificação dos fatores que afetam a LPS. Fatores que afetam a Linha de Produto de Software

Falta de um líder comprometido Falta de compromisso da gerência Abordagem inadequada Falta de compromisso da equipe Interação insuficiente entre as equipes Padronização desapropriada Falta de Adaptação Incapacidade de melhoria contínua Problemas na Disseminação Falta de Certificações Problemas na Definição das features Falha na identificação de requisitos

Fator Organizacional

Fator Humano X

Fator Técnico

X X X X X X X X X X X

Os fatores classificados como organizacionais foram: (i) A falta de compromisso da gerência; (ii) Falta de Certificações; (iii) Incapacidade de melhoria contínua; (iv) Adaptação insuficiente. Estes fatores foram escolhidos, pois são responsabilidades da gerência da organização ter compromisso com a implantação da linha de produto, O primeiro fator, a gerência deve acreditar nas vantagens e viabilidade que a implantação pode trazer para a organização, já o segundo é de responsabilidade da organização fazer a certificação de cada componente para que ao invés de certificar somente o sistema completo, se tenha uma certificação de cada componente. A incapacidade de melhoria contínua está ligada aos critérios organizacionais, pois a organização deve prover recursos para que isso aconteça. A adaptação deve estar ligada as práticas organizacionais para permitir que se tenha um grau de adaptabilidade aceitável. Foram identificados os seguintes fatores humanos: (i) Falta de um líder comprometido; (ii) Falta de compromisso da equipe; (iii) Interação insuficiente entre as equipes; (iv) Problemas na Disseminação. Estes fatores foram agrupados nesta classificação, pois estão ligados a problemas vinculados as características humanas, um

líder comprometido deve acreditar no modelo, motivar as pessoas e desenvolver uma comunicação entre os membros, caso as pessoas não se sintam motivadas a organização podem enfrentar problemas com o compromisso da equipe, e mesmo que se tenha a motivação, a falta de interação e problemas na disseminação podem causar problemas relacionados ao desenvolvimento, como por exemplo, uma equipe desenvolver um componente muito parecido com outro componente desenvolvido por outra equipe. Os fatores identificados como técnicos são apresentados a seguir: (i) Abordagem inadequada; (ii) Padronização desapropriada; (iii) Problemas na definição das features; (iv) Falha na identificação de requisitos. A utilização da Linha de Produto de Software deve ser um projeto para atingir objetivos corporativos, caso ocorra um erro no processo de planejamento dos produtos da linha, ela pode não atingir seus objetivos. A Padronização desapropriada pode ocorrer de problemas relativos à escolha da abordagem que levam a escolha de uma abordagem diferente da ideal. Problemas de requisito estão ligados aos métodos e modelos utilizados para obtê-los. Já a definição corretas das features está ligada diretamente aos métodos escolhidos para conseguir esse objetivo.

6. Conclusão A utilização de Linha de Produto de Software pode ser uma solução viável para o desenvolvimento de software, contudo a sua implantação deve ser criteriosa para que se tenha sucesso diante dos riscos existentes. Perante o que foi apresentado, podemos concluir que a classificação dos fatores que podem afetar a implantação da Linha de Produto de Software em técnicos, humanos ou organizacionais, pode ser algo valioso para implantação da Linha de produto de software, pois ajuda no estudo das dificuldades encontradas na empreitada que é a implantação da linha. Foi observado também que os problemas existentes têm diversas origens e que a Gestão de Risco de Software deve observar atentamente diversas vertentes. O trabalho está identificando e classificando os riscos para que posteriormente esses riscos sejam estudados de forma mais sucinta e consistente para que no futuro os riscos possam ser tratados e controlados com eficiência e eficácia. A pesquisa apoia o estudo do gerenciamento de risco na linha de produto de software enfocando e caracterizando no processo, fornecendo sugestões sobre quais aspectos a organização deve focar. Também é notado que a adoção da linha de produto por uma organização requer muito esforço e modificações na estrutura da organização. Reutilizando alguns pontos positivos desenvolvido em outras pesquisas foi possível caracterizar os tipos de risco existentes na implantação da Linha de Produto de forma a atingir o objetivo geral deste estudo que é a classificar os riscos envolvidos na adoção de uma Linha de Produto de software.

7. Agradecimento Agradecemos ao CNPq/FACEPE pelo apoio financeiro de bolsa de estudo de Iniciação Científica e a Universidade de Pernambuco (Campus Caruaru) pela infraestrutura disponibilizada. O trabalho correspondente foi realizado ao abrigo do contrato 116120/2010-0 do CNPq/FACEPE.

Referências Birk, A.; Heller, G. (2007) “Challenges for Requirements Engineering and Management in Software Product Line Development. Requirements Engineering: Foundation for Software Quality,” 13th International Working Conference, REFSQ 2007, Trondheim, Norway, Proceedings. Volume 4542 of Lecture Notes in Computer Science, pages 300305. Boehm, B. W. and DeMarco, T.(1997) “Guest Editors Introduction: Software Risk Management. IEEE Software”, 14(3):17-19. Clements, P.; Northrop, L. (2001) “Software product lines: practices and patterns.” 1. ed. Boston: Addison-Wesley. Cohen, Sholom.(2002) “Product Line State of http://www.sei.cmu.edu/reports/02tn017.pdf.Setembro.

the

Practice

Report”

Cohen, Sholom;(2003)“Predicting when Software Product Lines http://www.sei.cmu.edu/pub/documents/03.reports/pdf/03tn017.pdf, Março.

Pays.”:

Durscki, C. R.; Spinola, M. M.; Burnett, C. R.; Reinehr, S.S. (2004) “Linhas de Produto de Software: riscos e vantagens de sua implantação” http://www.simpros.com.br/Apresentacoes_PDF/Artigos/Art_14_Simpros2004.pdf, Maio. ISO/IEC 12207:1995/Amd 2:2008 (2008)-“The International Organization for Standardization and the International Electrotechnical Commission.” ISO/IEC 12207 Amendment: Information Technology - Amendment 2 to ISO/IEC 12207,Geneve: ISO. Lazilha, R.F; (2002) “Uma proposta de arquitetura de linha de produto para sistemas de gerenciamento de workflow” http://hdl.handle.net/10183/2626, Abril. Lobato L.L.;, O’Leary Padraig, Almeida de S. E., Meira L.R.S. (2010) “The importance of Documentation, Design and Reuse in Risk Management for SPL” portal.acm.org/citation.cfm?id=1878475,Abril. Lobo C.E. Ana.; Rubira F.M. Cecília (2009) “Um Estudo para Implantação de Linha de Produto de Software baseada em Componentes” www.ic.unicamp.br/~reltech/2009/0917.bib, Março. Lucena, P. J.C.; (2010) “A carreira de pesquisador em Engenharia de Software: Princípios conceitos e direções”. Clube dos Autores. Northrop, L. M. (2002). “SEI's Software Product Line Tenets.” IEEE Software. 19, 4, 3240. http://portal.acm.org/citation.cfm?id=626425, Abril. Palvia, S.C; Sharma,R.S; Corath,D.W (2001) “A sócio-technical framework fo quality assessment of computer information system.” Industrial management & Data Systems . http://w3.cyu.edu.tw/ccwei/PAPER/ERP/Quality%20assessment%20in%20IS(IMDS).pdf, Abril.

Sandhof, Karen (2004) “Fatores humanos no processo de desenvolvimento de software: um estudo visando qualidade.” http://www.teses.usp.br/teses/disponiveis/3/3141/tde15122004-075221/pt-br.php, Abril.