Quando aprendemos a programar, tão pouco imaginamos o quanto é extenso o mundo de Processo de Software ou tão pouco sabemos que ele existe. Em alguns casos, quando somos apenas “meros” programadores, o fato de dominar uma linguagem em si e ter uma excelente lógica de programação, nos passa uma falsa segurança de achar que são suficientemente únicos para gerar um produto de “qualidade”.
Acredito que todo bom programador já deve ter tido sua fase de modo “REC”, no qual já inicia o desenvolvimento do código enquanto o cliente “expõe” suas ideias.
No final, os resultados são sempre os mesmos. Frustrações! Produto gerado sem conformidades com o que realmente o cliente precisa, gastos excessivos com manutenções e correções, etc. Contudo, isso não quer dizer que o programador é ruim. Apenas faltou o emprego de um Processo de Software.
Mas o que é afinal, um Processo de Software?
Um Processo Software é um conjunto de atividades, parcialmente ordenadas com a finalidade de obter um produto de software e é considerado um dos principais mecanismos para se obter um software de qualidade. (Wikipédia)
Então, tudo que precisamos para gerar um produto de software de qualidade é um bom Processo de Software que se adapte a realidade de uma empresa. Porém, não basta “apenas” implementá-lo, ou seja, deve-se ter o gerenciamento do processo como um todo a fim de garantir que ele seja executado corretamente entre os envolvidos, ou caso contrário, o caos tomará conta de tudo trazendo o resultado inverso do que se esperava.
Ao implementar o processo, você poderá encontrar algumas pedras pelo caminho. Implementar um processo confronta diretamente a cultura da empresa, resistência e falta de cooperação dos envolvidos, falta de estrutura, de pessoal qualificado, etc. Porém, é como a maioria das coisas, que no início, é muito complicado e trabalhoso.
Como vimos na definição, o Processo de Software visa à qualidade do produto de software. Mas como podemos definir esta qualidade?
Este conceito pode ser considerado como um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos especificados, prevenindo e eliminando defeitos.
Em outras palavras, a qualidade de software é estar em conformidade com requisitos funcionais e de desempenho explicitamente declarados de desenvolvimento, que devem ser claramente documentados e as características implícitas que são esperadas de todo o software desenvolvido.
Para que isso seja possível, as fases do processo devem ser bem elaboradas e trabalhadas, efetuando devidas revisões para uma contínua melhoria e amadurecimento do processo e de seus artefatos. Um exemplo de modelo, podemos citar como fases: Concepção, Elaboração, Construção e Transição, no qual é feito um estudo de viabilidade, coletas de casos de uso, análise de requisitos, modelagem, desenvolvimento, revisões, etc.
Outra característica importante de um Processo de Software é que ele visa à diminuição de falhas, ou seja, elaborar de forma sistemática Casos de Teste a fim de identificar e corrigir erros já na fase inicial do projeto. Corrigir erros no início do projeto é bem mais barato do que depois de entregue. Em outras palavras, entregar um produto de software sem falhas garante a confiabilidade, eficiência e integridade do produto.
Mas, por que utilizar um Processo de Software?
Dentre os fatos acima e muitos outros, posso citar também que:
- Mais de 30% dos projetos são cancelados antes de serem finalizados.
- Mais de 70% dos projetos falham nas entregas das funcionalidades.
- Os custos extrapolam em mais de 180% do orçamento inicial.
- Os prazos excedem em mais de 200% os cronogramas originais.
Existem alguns modelos de Processos de Software, como os modelos em Cascata (CMMI), Espiral, Ciclo de Vida, Ágeis (SCRUM, XP), etc.
Para escolher o modelo ideal, é preciso conhecer um pouco sobre cada um deles e ver qual se adapta melhor à realidade da empresa, levando em consideração fatores como: investimento, tamanho de equipe, pessoal qualificado, entre outros.
Sem dúvidas, podemos definir que o Processo de Software amadurece a equipe e a visão sobre o desenvolvimento como um todo, garantindo um produto de software com qualidade e de consequência, a satisfação do cliente.
Fonte: Blog Rafael Amaral
Twitter: @rafaelamaralll
4 Comentários
Comecei a ler com o maior entusiasmo, até que cheguei na parte que o autor cita a Wikipedia… Gente, por favor, ali qualquer um escreve o que quiser… Usem a internet para buscar artigos acadêmicos, sites de empresas que têm credibilidade… Wikipedia é demais… Perdi a vontade de ler o resto.
Prezada Danielle,
Você tem razão quando diz que a “qualquer um escreve para Wikipédia”. Porém, se equivoca no restante do comentário. A Wikipédia é baseada na web 2.0 onde as pessoas deixam simplesmente de serem apenas leitores e passam a serem colaboradores de conteúdo.
Na minha ignorância, desconheço quaisquer órgãos que valide um conteúdo da internet como relevante e/ou verdadeiro. A Wikipédia é usada por muitos profissionais, professores, alunos e tantas outras pessoas, e que garantia tenho de que um artigo acadêmico não tem como base algo retirado da Wiki?
De fato, concordo que não devemos dar credibilidade a tudo que achamos na internet, neste ponto, posso citar como exemplo uma compra online, no qual as pessoas não devem digitar os números de seus cartões em qualquer site para efetuar uma compra. Devemos usar o bom senso para isto.
Entretanto, já fiz muitas pesquisas e troquei conhecimentos com os conteúdos colaborativos da Wiki, e no contexto do meu artigo, a definição foi de muita relevância para o conteúdo do mesmo.
Com todo respeito, caso a definição retirada da Wiki esteja equivocada, desafio-a a postar outra bem como sua fonte.
Totalmente errado: “Existem alguns modelos de Processos de Software, como os modelos em Cascata (CMMI), Espiral, Ciclo de Vida, Ágeis (SCRUM, XP), etc.”
São exemplo de ciclo de vida, além do CMMI não ser considerado um modelo cascata e sim um modelo reconhecido internacionalmente que visa a mensuração dos processos de software por graus de maturidade, o que garante um produto de qualidade.
Mas o artigo é valido. 😉
Olá Jonas,
olhando pelo seu ponto de vista, o Scrum também não se encaixaria como um processo, pois ele é um framework e pode ser utilizado dentro de um processo já existente. Porém, pensando no lado didático e evitando a complexidade de detalhes, podemos citar conforme o artigo, pois o CMMI pode ser tanto usado como um modelo Cascata como outro qualquer e devido a sua burocracia, acredito que se encaixe mais no modelo citado.
Grande abs!