jun 26 2015
A Engenharia de Software com BPMS Par. 2
Parte 2 Modelos de Processos de Softwares
Antes de falar e entender o que é Processos de Softwares, devemos entender o que é a Engenharia de Softwares. Ela pode ser definida com a aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção do software. O estudo de abordagens e princípios a fim de obter economicamente softwares confiáveis e que executem de forma eficiente nas máquinas e ambientes reais.
Desta definição podemos elencar um conjunto de três elementos básicos fundamentais: métodos, ferramentas e procedimentos. Os métodos proporcionam os detalhes de “como fazer” para construir o software. As ferramentas dão suporte automatizado aos métodos. Os procedimentos constituem o elo entre os métodos e ferramentas fornecendo a sequência em que os métodos serão aplicados. O conjunto de etapas que envolve métodos, ferramentas e procedimentos são conhecidas como componentes do Ciclo de Vida de Software ou Processo de Software.
O Processo de Software pode ser definido como um conjunto de atividades necessárias para transformar os requisitos dos usuários em um sistema de software. Existem vários processos de software, contudo podemos citar um conjunto de atividades genéricas de todo processo de software: especificação, o que o sistema deve fazer e suas restrições; desenvolvimento, produção do sistema de software; validação, verifica se o software é o que o cliente deseja; evolução, mudanças no software e respostas as novas solicitações.
Um dos objetivos do Processo de Software é oferecer orientação quanto à ordem das atividades de uma equipe de desenvolvimento de software. Uma definição de quem faz o que e como. Desta forma cada pessoa envolvida na equipe de desenvolvimento entende o que precisa fazer para desenvolver o sistema e membros da equipe passam a conhecer as atividades de todos os outros membros. Os Processos de Softwares possuem diferentes abordagens e, com o tempo, constituiu-se modelos teóricos para estas abordagens. Estes modelos são uma representação abstrata de um processo de software, que explica diferentes abordagens do desenvolvimento do software. Aqui citamos: Cascata; Prototipação; Evolutivo; Orientado a Reuso; Híbridos; Iterativo e Incremental (RUP); Espiral.
O RUP, abreviação de Rational Unified Process (ou Processo Unificado Rational), é um processo proprietário de Engenharia de software Iterativo e Incremental que fornece técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade no processo de desenvolvimento. Ela usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação. Utiliza técnicas e práticas aprovadas comercialmente, contudo é um processo considerado pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos, porém o fato de ser amplamente customizável torna possível que seja adaptado para projetos de qualquer escala (Wikipédia, a enciclopédia livre, 2015, p. com adaptações). Algumas vertentes, ao utiliza-se de tais modelos, achavam sua formalização excessiva ou o consideram um processo moroso, mesmo depois de adaptações. Sugiram então outros modelos Interativos e Incrementais com o objetivo de tornar o desenvolvimento mais ágil e diminuir a documentação e controles que os modelos até então existentes utilizavam. Apareceram então as Metodologias ágeis como Scrum e Extreme Programming (XP).
Ambos Scrum e Extreme Programming (XP) pregam que a equipe complete alguma parte palpável de trabalho que seja entregável ao fim de cada iteração. Eles não perseguem o desenho do diagrama UML – (Unified Modeling Language – linguagem de modelagem que permite representar um sistema de forma padronizada) perfeito em ferramentas case, a escrita do documento de requisitos perfeito, ou a escrita do código que poderá acomodar todas as mudanças futuras imagináveis. Ao invés disso, equipes Scrum e XP focam em ter as coisas prontas. (Kniberg, 2007)
Figura 2 Project Carton .com (The Project Cartoon Beta, 2015)
Este problema se dá porque colaboradores não têm uma visão sistêmica da organização. A analogia seria a entrega de uma peça de um quebra cabeça, onde quem o está entregando não sabe qual é a imagem que deve formar ao final. Os colaboradores sabem descrever como é uma peça do quebra-cabeças, mas por não ter a visão da imagem que o quebra-cabeças tem que formar, não sabe descrever bem as “curvas” para que a peça se encaixe com outras e forme a imagem final, que seria o sistema de informação da organização ponta a ponta. O problema então não está restrito ao Modelo de Processo de Software e sim a cultura organizacional. Para mitigar este e outros problemas, abordagens sistêmicas foram propostas para a cultura organizacional. Todos os modelos têm suas vantagens e desvantagens, contudo o equilíbrio entre os modelos e a adaptabilidade para cada realidade organizacional passou a ser chave para resolver problemas que se apresentaram e ainda persistiam deis de a “Crise do Software”. Mesmo conseguindo o “equilíbrio” e “adaptabilidade” de algum modelo a realidade organizacional, a mesma, ao final, poderia ainda ter sistemas que não atendem todas as suas necessidades, e, muitas vezes, passa a desenvolver sistemas a altos cursos com poucos retornos reais.
Este problema se dá porque colaboradores não têm uma visão sistêmica da organização. A analogia seria a entrega de uma peça de um quebra cabeça, onde quem o está entregando não sabe qual é a imagem que deve formar ao final. Os colaboradores sabem descrever como é uma peça do quebra-cabeças, mas por não ter a visão da imagem que o quebra-cabeças tem que formar, não sabe descrever bem as “curvas” para que a peça se encaixe com outras e forme a imagem final, que seria o sistema de informação da organização ponta a ponta. O problema então não está restrito ao Modelo de Processo de Software e sim a cultura organizacional. Para mitigar este e outros problemas, abordagens sistêmicas foram propostas para a cultura organizacional.
Assine nossa Newsletter para receber por e-avisos sobre novas publicações na página e aguarde as outras duas partes deste artigo e compartilhe nas redes sociais para divulgação da página.
Leave a Reply
You must be logged in to post a comment.