O que é processo de software?
Procurei no dicionário michaelis online definições da palavra “processo”. A que se encaixa aqui é: “Série de ações sistemáticas visando a certo resultado”. Adaptando para processo de software, se tornaria: Série de ações sistemáticas visando a produção de software. Na definição de Sommerville, “processo de software é um conjunto de atividades que leva à produção de um produto de software”. Ou seja, o processo é tudo que é feito após o desejo de um cliente por um software até a manutenção do mesmo.
Qual a principal diferença entre estas duas definições?
Sommerville não menciona a palavra “sistemática”(ou qualquer outra com o significado semelhante). Portanto, utilizando seu ponto de vista, poderíamos considerar que uma série de atividades quaisquer como um processo de software. Ou seja, qualquer um que produz software utiliza um ou mais processos de software. Logicamente, quem produz software sem haver determinado atividades sistemáticas tem grandes chances de, em ciclos diferentes, utilizar atividades diferentes, executar atividades de formas diferentes, ou em ordens diferentes.
Por isso, a primeira forma citada por Sommerville para aprimorar o processo de software em uma empresa seria a padronização dos processos. É importante destacar que a qualidade do produto software está intimamente ligada à qualidade do processo que o produz e mantém. Por isto, existe toda esta preocupação em desenvolver bons processos de software.
A indústria de software está cheia de exemplos de projetos fracassados, atrasados, ou que custaram muito mais do que o previsto. Grande parte destas faltas são atribuídas a processos de software inadequados. É sabido que os maiores problemas das organizações de spftware são gerenciais, e não técnicos.
Segundo Sommerville, processos padronizados reduzem os custos dos projetos, aumentam a qualidade do produto e facilitam a inserção de um novo participante na equipe.
De acordo com o discurso lúdico do professor Fabrício Mello, uma pessoa só pode afirmar que entendeu algo quando é capaz de explicá-lo para uma menina de 7 anos. Portanto, aí vai:
Dorothy, se você fizer seu leite achocolatado todo dia do mesmo jeito, lembrando todos os passos, o leite sempre ficará saboroso. Além disso, sua irmã conseguirá observar e aprender rápido como você faz, então em pouco tempo você somente precisará preparar o seu próprio leite.
Apesar da lógica simples deste pensamento, e de a engenharia de software já o ter evoluído bastante, muitas empresas continuam sem padronização dos processos. É importante que se entenda que a melhoria dos processos por parte de uma equipe necessita da padronização. A primeira fase de qualquer ação de aperfeiçoamento é a avaliação do que está sendo feito até o momento. Caso não haja padronização, é difícil perceber os pontos falhos do processo corrente.
“Se você não sabe onde está, um mapa não o ajudará” Provérbio de Humphrey
Para dar suporte às organizações, foram criados alguns modelos de qualidade de processos. O mais famoso é o CMM/CMMI. O CMM é um modelo de maturidade dos processos, é um guia para melhorar os processos da organização e sua capacidade para gerenciá-los. O CMM descreve caminhos tornar o processo de software algo repetível e previsível.
Existem diversos modelos de processo de software. A maioria deles é baseada em alguns modelos genéricos, que não são exclusivos, ou seja, podemos usar um pouco de cada um. Segundo Sommerville, existem algumas atividades que são comuns a todos. Quatro delas são: Especificação; Projeto e Implementação; Validação; e Evolução. Neste ponto, me permito uma pequena observação. A atividade de Evolução somente é possível graças a natureza facilmente mutável e intangível do produto software. Assim como existe a dualidade onda-partícula da luz, existe a dualidade produto-serviço do software. Voltarei a abordar esse assunto em uma postagem posterior.
Modelo Cascata
O modelo genérico mais conservador, e que se assemelha com os processos industriais é o modelo Cascata(Waterfall, em inglês). Nele, as atividades de desenvolvimento são bem definidas, e produzem um documento após sua conclusão. A próxima atividade só começa quando a anterior já estiver acabada. Desta forma, mudanças na definição de requisitos implicam em um custo alto de alteração. Este modelo é indicado caso a confiança no sistema seja importante, já que a documentação produzida é bastante completa. Este modelo também é mais natural que os demais para quem está acostumado com processos de engenharia.
Desenvolvimento Evolucionário
É comum o cliente não saber o que quer. Ou então, mesmo quando ele sabe o que quer, não sabe como quer. Para esses clientes, o desenvolvimento em cascata é caro, já que várias correções terão que ser feitas nas etapas anteriores devido a insatisfações nas etapas posteriores. Com o fim de reduzir os custos de produção do software devido a problemas com os requisitos, sugeriu-se o desenvolvimento evolucionário. Nele, o software é produzido em ciclos menores, apresentando ao cliente implementações anteriores à distribuiçãofinal para aperfeiçoar os requisitos.
O desenvolvimento evolucionário pode ser do tipo exploratório, ou prototipação throwaway.
No exploratório, o protótipo contem os requisitos entendidos, adicionando características solicitadas pelo cliente. Ao exibir este protótipo para o cliente, o desenvolvedor deveria dizer: “Isto nós já entendemos. O que mais falta?” No throwaway, o que está mal compreendido que é implementado, para tentar a satisfação do cliente. Neste caso, o desenvolvedor diria: “É isso que você deseja?”
Engenharia de Software Baseada em Componentes
Este modelo idealiza um processo de software onde todos os pedaços para a construção de um software já estão prontos. A tarefa principal seria agrupá-los para que façam em conjunto o que se espera do sistema final. Caso os componentes selecionados para compor o sistema não atendam aos requisitos, o que se faz é tentar ajustar os requisitos ou procurar componentes alternativos que entrem em maior conformidade.
Referências: SOMMERVILLE, Ian Engenharia de Software, 8a edição – São Paulo : Pearson Addison Wesley, 2007.
