Os Desafios da Implantação de um Processo de software

[pic 1]

Link original: https://www.devmedia.com.br/artigo-engenharia-de-software-14-implantacao-de-processo/13249

Implantação de Processo

Os desafios da implantação de um processo de software

 

De que trata o artigo:

Neste artigo veremos quais são os principais desafios e benefícios da implantação de um processo de desenvolvimento de software. Serão descritos aspectos importantes do processo que foi definido, bem como as ferramentas que foram desenvolvidas para dar suporte à sua implantação.

 

Para que serve:

A implantação de um processo de desenvolvimento tem se mostrado como um fator primordial de sucesso para as empresas de software. Entretanto, para ser um projeto de sucesso, deve ser planejado para refletir a realidade e dinâmica da empresa, caso contrário pode se tornar algo oneroso e difícil de manter.

 

Em que situação o tema útil:

Para as empresas que estão planejando implantar um processo de desenvolvimento de software.

 

A necessidade de um processo de software

O processo de software é uma seqüência lógica de atividades com o objetivo final de produzir ou evoluir um produto de software. Essas atividades englobam a especificação dos requisitos, análise e design, implementação, testes e implantação, e caracterizam-se pela interação de ferramentas, pessoas e métodos.

Estabelecer um processo significa definir todas as atividades a serem realizadas, bem como a seqüência e dependência entre elas, como as atividades serão executadas e quem é responsável por cada uma. A execução bem sucedida de um processo requer um conjunto de ferramentas de apoio e, principalmente, a conscientização da equipe sobre a necessidade do processo.

A implantação de um processo de software em uma empresa é um investimento custoso, porém tem se mostrado o fator primordial para o sucesso das empresas no alcance de seus objetivos, principalmente aqueles que se referem a satisfação dos clientes e previsibilidade de custo e prazo.

O estabelecimento de um processo, bem definido, diminui a dependência da empresa em relação às pessoas e possibilita a disseminação de melhores práticas, documentos e conhecimento. Atualmente, existem vários modelos de processo de software e um dos mais conhecidos e utilizados é o RUP – Rational Unifed Process, comprado pela IBM.

O RUP é baseado em orientação a objetos e documentado utilizando a linguagem UML – Unified Modeling Language. É considerado um processo pesado, que preferencialmente deve ser utilizado em grandes projetos e equipes.  Porém, como é fortemente customizável, é possível adaptá-lo para qualquer empresa.

Quando o RUP foi lançado, grandes empresas tentaram aplicá-lo em suas áreas de desenvolvimento de software. Foram realizados grandes investimentos e nem todos obtiveram o sucesso almejado. O principal problema foi acreditar que o RUP poderia ser utilizado da forma como estava definido sem que fosse gasto esforço e tempo para identificar de que forma o RUP se encaixaria na estrutura da empresa.

O caso que iremos detalhar é exatamente como a Dextra Sistemas (www.dextra.com.br) extraiu do RUP o que era realmente aplicável às suas necessidades e como esse esforço e investimento culminou na melhoria do resultado dos seus projetos e na avaliação MPS.BR nível F obtida em Março de 2009.

Definição do processo

A Dextra teve um crescimento muito expressivo nos anos de 2006 e 2007 e com isso surgiu a necessidade da definição e implantação de um processo mais formal. A empresa já contava com o ProUD (Processo Unificado Dextra) que se baseava fortemente no RUP. A versão 1.0 do ProUD era bastante enxuta e se aplicava muito bem ao tamanho e características da empresa e de suas equipes de trabalho até então.

O objetivo da evolução e melhoria do processo da Dextra era ter um nível maior de formalização das atividades e papéis, bem como coletar e analisar indicadores de projeto que dessem a visibilidade necessária em relação à qualidade do produto, pontualidade nas entregas e previsibilidade de custo.

Diante disso, a estratégia da empresa foi novamente aplicar o RUP, utilizando o feedback já obtido no uso do ProUD 1.0 em diversos projetos. A principal meta da Dextra era definir um processo que representasse o que a empresa fazia de melhor nos seus projetos e corrigisse o que ainda poderia melhorar. Com esse foco o plano de trabalho contou com a formação de grupos de trabalho formados por membros das equipes de projetos. Os líderes de cada grupo eram membros do SEPG – Software Engineer Process Group e davam o direcionamento necessário às atividades. O resultado de um ano de trabalho foi o ProUD 2.0.

 

[pic 2]

Figura 1. Fases do ProUD 2.0

 

O processo foi dividido em quatro grandes fases, como se vê na Figura 1. Na versão 1.0 do ProUD, os nomes das fases eram exatamente iguais às do RUP – Concepção, Elaboração, Construção e Transição. Porém, com a utilização do processo percebeu-se que havia atividades que no RUP eram feitas na fase de Elaboração e que na Dextra fazia mais sentido que fossem executadas na fase de Construção e vice-versa. Desta forma, quisemos desvincular as fases do ProUD das fases do RUP, criando fases e atividades dentro delas que representam a realidade da empresa e a melhor forma de trabalho de suas equipes. Segue abaixo uma breve descrição de cada uma das fases:

 

Planejamento

Nesta fase ocorre a definição do escopo do projeto e de suas fronteiras, assim como o planejamento detalhado de sua execução. São gerados todos os planos do projeto – plano de comunicação, riscos, infra-estrutura, recursos humanos, gestão de configuração e etc. Todos os compromissos internos e com o cliente são formalizados e aprovados. Esta fase recebe muitos insumos da fase de proposta, que também segue um processo bem definido e formal. Parte das atividades desta fase é feita durante a fase de Concepção do RUP.

 

Refinamento da Solução

Nesta fase os requisitos levantados durante a fase de proposta são detalhados, bem como a arquitetura final da solução e os aspectos de integração com outros sistemas. Deve-se, também, fazer uma extensiva análise dos riscos do projeto associados aos requisitos e à tecnologia utilizada. O resultado desta fase é o detalhamento inicial dos requisitos, protótipos de telas e a definição da arquitetura do sistema. As atividades desta fase são executadas parte na fase de Concepção e parte na fase de Elaboração do RUP.