Por: Rafael Azevedo     15543 visualizações     Tempo leitura: 8 min

Figura 1 – Retirada de http://www.agenciars.com.br/blog/conteudo-de-qualidade-fatores-para-seo/

21% dos projetos de software iniciados fracassam, 42% são entregues com falhas detectadas, atrasados ou com o orçamento estourado e somente 37% são finalizados com sucesso. O Standish Group, organização que reporta periodicamente estatísticas sobre sucesso e fracasso de projetos de software ficou notadamente conhecido pelas suas estatísticas caóticas a cerca do sucesso e fracasso de projetos de software indica com tais números uma melhora no panorama da área de software em 2010. Melhora? Isto sim, melhora. A título de comparação, em 2008 a taxa de sucesso foi avaliada em 32%. Em 2000 eram míseros 28% e acredite se quiser em 1994 era de 16%. Imagine agora uma construtora reportando com orgulho aos seus clientes que em cada 10 projetos, apenas dois caem? Ou um médico ou qualquer outra classe de profissionais apresentando estatísticas deste tipo? Alarmante.

Não é por acaso que uma das áreas olhadas com maior desconfiança pelo mercado é justamente a tecnologia de informação e também não é estranho que a nossa área, em vários levantamentos, seja apontada como uma das áreas mais estressantes para se trabalhar. Afinal, não é nada fácil lidar com eminência de cancelamento de projetos, estouro de orçamento e prazos além de toda a dificuldade técnica envolvida.

Produzir software com qualidade é portanto uma tarefa árdua. Esta dificuldade é maior no contexto das empresas de pequeno porte, já que raramente trabalham com processos formais e geralmente enfrentam problemas de escassez de recursos humanos e financeiros. A falta de um processo sistemático de desenvolvimento de software é citada no relatório de 2005 do Ministério de Ciência e Tecnologia (MCT, 2005 apud Soares, 2007) como um dos pontos que prejudicam a pequena empresa na qualidade e produtividade do processo e do produto desenvolvido.

Cenário tão alarmante fez levantar a seguinte hipótese: “A qualidade de um sistema de software e o sucesso de um projeto de software são largamente definidos pela qualidade do processo utilizado para desenvolvê-lo”.

O fato é que percebeu-se que uma equipe que “sabe programar” e um “cliente querendo resolver um probleminha” não são suficientes para se produzir um software usável, rentável e em tempo hábil para mercado. É essencial definir processos capazes de casar demandas e competências de maneira adequada para produzir software de qualidade.

Dentro deste contexto, modelos de maturidade como o MPS-BR e o CMMI surgiram com o intuito de auxiliar as empresas na busca pela melhoria na qualidade de seus processos produtivos. A implantação destes modelos carregam porém o fardo de contarem curva de aprendizado longa, exigirem um esforço alto para que os resultados desejados sejam alcançados.

OK! Mas a minha empresa é pequena, não temos dinheiro e nem tempo disponíveis para suportar a implementação de modelos como MPS-Br ou CMMI de uma tacada só, mas ainda assim achamos uma necessidade urgente começar a melhorar nossos processos. Como fazer isto?

Dividir para conquistar! A melhoria de processos nestes casos deve ser realizada em passos curtos, que se encaixem dentro das limitações comuns às pequenas empresas. A ideia é substituir a adoção compulsória de processos pela adoção gradual de pequenas práticas que gerem impacto positivo na produção de software e possam servir posteriormente para compor processos mais sofisticados.

A adoção de práticas não pode ser realizada de maneira ad-hoc. Da mesma forma que um médico só prescreve um medicamento depois de realizado o diagnóstico da situação do paciente, é necessário identificar o perfil do ambiente da empresa, descobrir os principais gargalos, e selecionar práticas condizentes com este perfil. Em outras palavras, será que uma prática que funciona bem em uma equipe com dez pessoas funcionará com a mesma efetividade em uma equipe com cinquenta pessoas? Será que um processo que prioriza a entrega rápida ao custo de uma especificação rasa de requisitos e poucos testes seria o mais adequado em um sistema onde um bug representa a perda de uma vida? É possível que não.

OK! Mas como diagnosticar o perfil da minha empresa?

Existem muitos trabalhos em Engenharia de Software destinados a avaliar o perfil do ambiente e da complexidade dos problemas enfrentados por empresas que desenvolvem software. Apresentamos a seguir alguns parâmetros que podem ser analisados para diagnosticar o perfil de uma empresa de software, levantados por (SOARES, 2007) e (BRUNO, 2010) em suas respectivas dissertações de mestrado.

1. Escala

O tamanho médio dos projetos desenvolvidos pela empresa afeta diretamente o grau de sofisticação das práticas a serem escolhidas.

2. Dinamismo

Refere-se à quantidade de mudanças de requisitos relacionados ao problema. Um ambiente onde o grau de dinamismo é alto, requer práticas que suportem alta taxa de mudança de requisitos e possibilitem estas mudanças sejam gerenciadas de forma compatível com o andamento do projeto.

3. Criticalidade / Flexibilidade

Refere-se ao rigor contratual imposto pelos projetos e criticalidade envolvida nos projetos desenvolvidos. A melhor forma de ilustrar este parâmetro é pensar em quão grave é um sistema produzido por sua empresa possuir “bugs”. Decerto, se a sua empresa trabalha com sistemas de controle de tráfego aéreo, um defeito no sistema pode significar a queda de um avião e a perda de vidas, ou seja, você lida com sistemas de criticalidade altíssima. Em outros casos, um bug representa algum tipo de prejuízo financeiro ou mesmo apenas um contratempo. Um conjunto de práticas adequados a cada um destes contextos deve ser considerado, até por questões financeiras e de cronograma envolvido em cada um deles.

4. Cultura / Maturidade em Processo

Refere-se à predisposição da equipe a trabalhar com processos formais e pré-definidos. As práticas escolhidas devem estar adequadas ao perfil da equipe envolvida nos projetos. Algumas equipes se sentem mais confortáveis em um ambiente onde os papéis, regras e procedimentos são bem definidos, ao estilo linha de fábrica, onde cada um é responsável por uma parte específica do software. Há equipes porém que apresentam perfil mais dinâmico com profissionais capazes de se reorganizar conforme as demandas e trabalhar com grau maior de liberdade. Estes profissionais se sentem mais confortáveis ao decidir ‘como’ as coisas devem ser feitas do que apenas recebendo ‘scripts’ com as tarefas a serem realizadas.

5. Previsibilidade Arquitetural

Refere-se à previsibilidade técnica média do projeto em termos de desempenho, robustez e confiabilidade. As práticas escolhidas devem estar adequadas com o grau de complexidade arquitetural exigido pelos projetos desenvolvidos pela empresa. Vale lembrar, que complexidade não está diretamente relacionada ao tamanho do projeto, uma vez que um projeto pode ser considerado grande, mas pode apresentar poucos desafios do ponto de vista arquitetural.

6. Experiência no Domínio

Refere-se ao nível de experiência adquirida pela corporação no domínio do problema dos projetos.

7. Competência Pessoal

Refere-se à competência pessoal dos integrantes da equipe.

O objetivo deste artigo era questionar a viabilidade de empresas de pequeno porte em aderir a algum modelo de maturidade do mercado como MPS-Br e CMMI e apresentar uma alternativa mais coerente com a realidade delas. Mostramos também que práticas não devem ser escolhidas aleatoriamente, mas sim, em termos de um diagnóstico do perfil da empresa. Introduzimos ainda um framework que pode servir de base para fazer o diagnóstico deste perfil.

Nos próximos artigos aprofundaremos no relacionamento entre o diagnóstico do perfil de uma empresa produtora de software e as práticas propriamente ditas, mostrando, sempre que possível, que melhores práticas foram adotadas em nossa empresa de acordo com o diagnóstico que obtivemos ao analisar o perfil dos problemas que enfrentamos.

Sucesso!

Bibliografia

Fonte: http://dinnitec.dinnisoft.com.br

Data da publicação: 07/06/2014

Gostou do artigo? Para receber nossos informativos clique aqui.