Entendendo a Engenharia de Software e Seus Paradigmas

O que é Engenharia de Software?

Engenharia de Software é uma disciplina da engenharia que se ocupa de todos os aspectos da produção de software. Isso vai desde os estágios iniciais de especificação de um sistema até a manutenção para que esse mesmo sistema sobreviva ao longo do tempo. A construção de software é uma das atividades mais complexas e vitais para o pleno sucesso de um sistema informatizado. A Engenharia de Software tenta, através dos princípios básicos de outras engenharias, trazer um pouco mais de luz para essa atividade complexa.

A “cobrança” hoje das áreas de Informática e de T.I. (Tecnologia da Informação) é desenvolver sistemas de forma rápida, com qualidade e com custos cada vez menores. Somente através de tecnologias adequadas e com as melhores práticas podemos atender a esses novos desafios.

Componentes da Engenharia de Software

A Engenharia de Software é constituída de metodologias (processos), métodos (procedimentos) e ferramentas que permitem ao profissional especificar, projetar, implementar e manter sistemas, avaliando e garantindo as qualidades especificadas pelos usuários.

Engenharia de Sistemas

A Engenharia de Sistemas é mais genérica e abrangente do que a Engenharia de Software. Na verdade, a segunda faz parte da primeira. A Engenharia de Sistemas é mais antiga do que a de Software. Enquanto a primeira está mais envolvida com o sistema como um todo e seus detalhes, a Engenharia de Software é mais específica no que tange aos componentes do sistema, em especial ao hardware e software.

Método de Engenharia de Software

O método de Engenharia de Software é uma “abordagem estruturada” para o desenvolvimento de software. Podemos definir como “abordagem estruturada” a estratégia de desenvolver algo com uma estrutura previamente estudada ou baseada nas melhores práticas. O objetivo maior de tudo isso é facilitar a produção, em curto espaço de tempo, de software de alta qualidade, apresentando uma relação custo-benefício interessante.

Metodologia

Metodologia é um conjunto recomendado de filosofias, fases, procedimentos, técnicas, regras, ferramentas, documentação, gerenciamento e treinamento para o desenvolvimento de um sistema de informação, como também o estudo de um ou mais métodos.

Diferenças das Metodologias

Tanto a abordagem estruturada quanto a orientada a objetos promovem soluções práticas. A diferença entre as duas metodologias é a vida útil e a facilidade de manutenção de projetos. A possível reutilização de um código estruturado não é comum, enquanto que um código orientado a objetos, por possuir embutido em sua própria filosofia as facilidades de reutilização e de descrição, utilizando UML (Unified Modeling Language), aumenta naturalmente a vida útil dos códigos.

Abordando o software sob um ponto de vista puramente estruturado, define-se os dados do sistema em uma posterior sequência de eventos que acarretará na transformação do estado do sistema. Por outro lado, numa abordagem focada em orientação a objetos, definem-se estruturas abstratas, denominadas classes, que serão responsáveis por partes da solução do problema. Cada classe incorporará dados (forma) e métodos (comportamentos). Projetos orientados a objetos utilizam da linguagem de modelagem UML (Unified Modeling Language). Esta linguagem é fruto dos esforços, em conjunto, dos autores Booch, Rumbaugh e Jacobson.

Teoria de Sistemas - Interdependência de Sistemas

Um sistema é uma coleção significativa de partes integrantes inter-relacionadas, que trabalham em conjunto para atingir alguns objetivos (Sommerville). É organizado para executar certo método, procedimento ou controle ao processar informações. Automatiza ou apoia a realização de atividades humanas através do processamento de informações. As complexas relações entre os componentes de um sistema significam que o sistema em si é maior do que simplesmente a soma de suas partes. As arquiteturas de sistema são normalmente descritas com o uso de diagramas de blocos, mostrando os subsistemas principais e suas relações.

Quais são os atributos de um bom Software?

Os atributos de um bom software refletem seu comportamento quando em funcionamento, a estrutura e a organização do programa fonte, e também a documentação associada (Sommerville). Como exemplos temos o tempo de resposta do software à consulta de um usuário e a facilidade de compreensão do código do programa. Esses mesmos exemplos também podem ser chamados de atributos não funcionais. Resumidamente, o software deve proporcionar ao usuário a funcionalidade e o desempenho requeridos e deve ser passível de manutenção, confiável, eficiente e de fácil uso.

Atributos de um bom software:

• Facilidade de Manutenção: O software deve ser escrito de modo que possa evoluir para atender às necessidades mutáveis dos clientes. Esse é um atributo crucial, porque as modificações em um software são uma consequência inevitável de um ambiente de negócios em constante mutação.
• Nível de Confiança: O nível de confiança do software tem uma gama de características que incluem confiabilidade, proteção e segurança. O software confiável não deve ocasionar danos físicos ou econômicos, no caso de um defeito no sistema.
• Eficiência: O software não deve desperdiçar os recursos do sistema, como memória e ciclos do processador. A eficiência, portanto, inclui a rapidez de resposta, o tempo de processamento, a utilização da memória, entre outros.
• Facilidade de Uso: O software deve ser utilizável, sem esforços indevidos, pelo tipo de usuário para quem foi projetado. Isso significa que ele deve dispor de uma interface apropriada com o usuário e de documentação adequada.

Crise do Software e o início da Engenharia de Software

A crise do software, termo usado nos anos 70, referia-se às dificuldades do desenvolvimento de software da época. Por haver um rápido crescimento da demanda por software, imaginava-se que com toda a complexidade no desenvolvimento, haveria uma forte crise. Com a inexistência da Engenharia de Software nessa época, não havia técnicas estabelecidas para o desenvolvimento de sistemas que funcionassem adequadamente ou que pudessem ser validadas. Já em 1988, AMBLER afirmava: “Desenvolver software não é somente modelar e escrever código. É criar aplicações que resolvam os problemas dos usuários. É fazer isso dentro do prazo, de forma precisa e com alta qualidade”. Logo, com a crise de software, os desafios para a criação da disciplina de Engenharia de Software eram muito grandes.

Desafios da Engenharia de Software

• O desafio do legado: Os grandes sistemas de software existentes foram desenvolvidos no passado, e com importantes funções corporativas. O desafio é fazer a manutenção e atualização desses softwares a custos baixos e com qualidade.
• O desafio da heterogeneidade: Os sistemas exigem em ambientes distribuídos por redes de diferentes tipos de computadores e sistemas de apoio. O desafio é desenvolver técnicas para construir softwares flexíveis para lidar com a heterogeneidade.
• O desafio do fornecimento: Nos dias atuais existe uma demanda enorme de sistemas que sejam desenvolvidos no menor tempo possível e com facilidade de adaptação. O desafio é fornecer sistemas cada vez maiores e complexos com a qualidade desejada, e em curto espaço de tempo.

Conceitos sobre a Engenharia de Software

A Engenharia de Software basicamente tenta apresentar processos, ferramentas e métodos que permitam desenvolver de forma racional e controlável um sistema computacional. Todo o foco é a qualidade, utilizando um método eficaz e o uso de ferramentas adequadas.

Características do Software

É desenvolvido/projetado por engenharia, não é fabricado, não se “desgasta”, mas se deteriora. Ainda hoje, a maioria é feita sob encomenda em vez de ser montada a partir de componentes.

Tipos de Software:

• Software básico
• Sistema de informação
• Embutido
• Técnicos
• Especialistas
• Apoio à decisão
• Jogos
• De apoio (processador de textos)

Mitos do Software

1. “Já temos um manual repleto de padrões e procedimentos para a construção de software. Isso já é suficiente para o pessoal do desenvolvimento.”
2. “Meu pessoal tem ferramentas de última geração, afinal de contas compramos os mais novos computadores.”
3. “Se nós estamos atrasados nos prazos, podemos adicionar mais programadores e tirar o atraso.”
4. “Uma declaração geral dos objetivos é suficiente para se começar a escrever programas, podemos preencher os detalhes mais tarde.”
5. “Os requisitos de projeto modificam-se continuamente, mas as mudanças podem ser facilmente acomodadas, porque o software é flexível.”
6. “Assim que escrevermos o programa e o colocarmos em funcionamento, nosso trabalho estará completo.”
7. “Enquanto não tiver o programa, ‘funcionando’, eu não terei realmente nenhuma maneira de avaliar sua qualidade.”
8. “A única coisa a ser entregue em um projeto bem-sucedido é o programa funcionando.”

Importância do Software:

Um dos pontos fundamentais da importância do software é pelo seu uso cotidiano, onde praticamente no mundo moderno, inexiste a possibilidade de não utilizá-lo. E o outro ponto é pela manipulação da informação (dado - informação - conhecimento).

SWEBOK

(Guide to the Software Engineering Body of Knowledge) é o documento técnico desenvolvido com o apoio do IEEE (Instituto de Engenheiros Elétricos e Eletrônicos, também popularmente chamado de I3E). Esse documento estabelece uma classificação hierárquica dos tópicos tratados pela Engenharia de Software, onde o nível mais alto são as Áreas do Conhecimento. As dez Áreas do Conhecimento tratadas pelo SWEBOK são: Requisitos de Software, Projeto de Software, Construção de Software, Teste de Software, Manutenção de Software, Gerência de Configuração de Software, Gerência da Engenharia de Software, Processo de Engenharia de Software, Ferramentas e Métodos da Engenharia de Software e Qualidade de Software. É importante ressaltar as diferenças entre o SWEBOK e o PMBOK, enquanto o SWEBOK é dirigido especificamente para a Engenharia de Software, o PMBOK é mais generalizado quanto a Gerenciamento de Projetos como um todo.

Modelos de Processo de Software

Os Modelos de Processo de Software descrevem basicamente as principais etapas do desenvolvimento de software, desde a produção até a sua própria manutenção. Existem vários Modelos de Processo de Software, mas praticamente todos eles seguem o princípio das três principais macro-etapas:

Requisitos

O analista deve obter respostas a várias perguntas junto aos usuários: O que exatamente se espera que seja feito? Qual a abrangência do software? Quais os limites, ou o escopo do sistema? Por que se faz aquilo daquela forma? Quais as restrições que existem nos procedimentos e dados utilizados? E muitas outras.

Projeto/Desenvolvimento

O analista faz especificações técnicas detalhando a solução criada para atender ao usuário conforme os requisitos anteriores. Os programadores codificam os programas em alguma linguagem de programação. Deve-se testar os programas exaustivamente para atingir um alto nível de qualidade, e após isso liberá-los para o uso.

Implantação/Manutenção

Na implantação do software podem ocorrer vários problemas não previstos nas fases anteriores. E a manutenção permanecerá durante toda sua vida útil e pode ocorrer motivada por três fatores: a correção de algum problema existente no software, sua adaptação decorrente de novas exigências (internas ou externas da empresa) e algum melhoramento funcional que seja incorporado ao software. Cabe ressaltar que não existe um consenso sobre o nome mais adequado para Modelos de Processo de Software. Os principais autores se referem a esse mesmo conceito com os seguintes nomes: Modelos de Ciclo de Vida de Software, Modelos Prescritivos de Processo, Paradigmas do Ciclo de Vida, Paradigmas do Desenvolvimento de Software e Modelagem do Ciclo de Vida.

Modelo Balbúrdia

Como falamos anteriormente, no início da computação, poucos programadores seguiam algum tipo de metodologia, baseando-se, em sua maioria, na própria experiência. Era o que chamamos hoje de Modelo Balbúrdia, sistemas desenvolvidos na informalidade sem nenhum tipo de projeto ou documentação. Neste modelo, o software tende a entrar num ciclo de somente duas fases: o de implementação e de implantação. E os ajustes ao software para atender aos novos requisitos sempre são em clima de urgência e de stress, motivados por vários fatores, e principalmente por pressão política. Portanto, havia a necessidade de se criar um “Ciclo de Vida” mais inteligente para o desenvolvimento de Software. Ou seja, um “Ciclo de Vida” semelhante à própria natureza, com início, meio e fim bem definidos.

Modelo Cascata

Essa foi a proposta do Modelo Cascata (ou do inglês Waterfall), da década de 70. Onde cada etapa do ciclo de vida pressupõe atividades que devem ser completadas antes do início da próxima etapa. Ou ainda, um modelo basicamente de atividades sistemáticas e sequenciais onde para cada etapa cumprida, segue-se a etapa imediatamente posterior, como se fosse uma “cascata”. O Modelo Cascata é extremamente clássico e antigo, por isso é também chamado de Ciclo de Vida Clássico. Originou-se dos velhos modelos de engenharia na elaboração de projetos. E na verdade, hoje em dia, é somente uma grande referência. Vivemos num mundo de atividades paralelas, e esse modelo de atividades sequenciais provocaria demoras excessivas, esperas indesejadas e problemas quando houvesse necessidade de voltar em etapas anteriores. Embora sendo clássico, para cada autor existe uma interpretação de cada etapa e é criado um nome distinto. O próprio Pressman, outro papa da Engenharia de Software, na última edição do seu famoso livro de Engenharia de Software, alterou os nomes da quinta edição, colocando o nome dessas fases respectivamente de: Comunicação, Planejamento, Modelagem, Construção e Implantação.

Paradigmas do Desenvolvimento de Software (continuação)

Modelo Incremental

Como vimos anteriormente, o tradicional Modelo Cascata é mais um modelo teórico do que prático. Na prática, o usuário quer sempre o sistema para ontem, e com qualidade. Para tanto, o Modelo Incremental parte do pressuposto que é preferível o usuário receber o sistema em partes, permitindo que esses recursos já sejam utilizados, enquanto os demais estão sendo desenvolvidos.

O Modelo Incremental, ou Iterativo, é desenvolvido com o conceito de versões. Nesse modelo, o sistema será especificado na documentação dos requisitos e “quebrado” em subsistemas por funcionalidades. As versões são definidas, começando com um pequeno subsistema funcional e então adicionadas mais funcionalidades a cada versão. Pode-se então dizer que o Modelo Incremental chega lentamente à funcionalidade total, por meio dessas novas versões.

Importante observar a diferença entre INTERATIVO e ITERATIVO. As duas palavras, embora com escrita extremamente parecidas e muitas utilizadas em Informática, possuem significados distintos. Quanto à palavra ITERATIVO, que significa, pelo próprio Aurélio, “diz-se de procedimento (como algoritmo, programa, etc.) que se baseia no uso ou aplicação da iteração”. Por sua vez, ITERAÇÃO possui o significado de: “Processo de resolução (de uma equação, de um problema) mediante uma sequência finita de operações em que o objeto de cada uma é o resultado da que a precede”. Ainda do próprio Aurélio podemos extrair a definição de INTERATIVO: “de, ou relativo a sistemas ou procedimentos computacionais, programas, etc. em que o usuário pode (e, por vezes, necessita) continuamente intervir e controlar o curso das atividades do computador, fornecendo novas entradas (de dados ou comandos) à medida que observa os efeitos das anteriores”. Portanto, no nosso caso específico utilizamos o processo INTERATIVO, e não ITERATIVO.

Prototipação

A Prototipação tem o mesmo objetivo que uma maquete para um arquiteto. Antes da entrega final do sistema, desenvolve-se rapidamente um esboço para melhorar o entendimento de desenvolvedores e clientes sobre todas as problemáticas das questões. Dentro dessa visão, o projeto passa por várias investigações para garantir que o desenvolvedor, usuário e cliente cheguem a um consenso sobre o que é necessário e o que deve ser proposto. Como muitos usuários não possuem uma visão ampla sobre a tecnologia, esse método de desenvolvimento é bastante interessante, permitindo que o usuário interaja significativamente no sistema. A prototipação é um procedimento que possibilita desenvolvedor e usuários a examinarem antecipadamente os requisitos. Com isso, se reduz os riscos e as incertezas do desenvolvimento.

Basicamente, as etapas de desenvolvimento desse modelo são:

1. Começar com um conjunto bem simples de requisitos fornecidos pelos clientes e usuários;
2. Clientes e usuários fazem testes e experimentações, e assim que eles decidem o que querem, os requisitos são revisados, alterados, detalhados, documentados e o sistema passa a ser codificado;
3. Novamente as alternativas são apresentadas e discutidas com os usuários, e voltamos para a etapa 2, até a entrega definitiva do sistema.

Logo, este modelo propicia duas grandes vantagens: velocidade de desenvolvimento no sentido de propiciar ao usuário uma visão mais real do software que se está projetando (o usuário poderá “enxergar” as telas e os relatórios resultantes do software) e o envolvimento direto do usuário na medida em que o desenvolvimento do software evolui, o usuário passa a ser um co-autor do desenvolvimento.

Modelo Espiral

Este modelo se confunde com o da Prototipagem. Mas em princípio é mais adequado para sistemas mais complexos, e que exigem um alto nível de interações com os usuários para possibilitar a abordagem de todos os problemas desse sistema. Foi criado por Barry W. Boehm, ainda em 1988, e ao invés de representar o processo de software como uma sequência de atividades, a exemplo do Modelo Cascata, ele é representado através de uma espiral.

Cada ciclo da espiral representa uma fase do processo de software. Na parte mais interna relaciona-se o início da visão da viabilidade do sistema. E a cada ciclo, passando por várias etapas, vai evoluindo a visibilidade do sistema como um todo.

O Modelo Espiral basicamente é dividido em quatro setores:

• ATIVAÇÃO: Define-se os objetivos específicos, identifica-se as restrições para o processo e é preparado um plano de gerenciamento detalhado. Identifica-se também os riscos sem analisá-los profundamente (foco da próxima fase).
• ANÁLISE de RISCOS: Com base nos riscos identificados na fase anterior, são realizadas análises detalhadas e tomadas providências para amenizar esses riscos. Criam-se várias versões de protótipos para apoiar essa fase.
• DESENVOLVIMENTO: Fundamentado pelas fases anteriores, escolhe-se o modelo mais adequado para o desenvolvimento do sistema. A bagagem profissional e a vivência do desenvolvedor em outros sistemas são estratégicas para essa fase. Dependendo da complexidade do sistema, às vezes, é necessária a presença de um consultor especialista.
• PLANEJAMENTO: O projeto é revisto nessa fase, e é tomada uma decisão de realizar um novo ciclo na espiral ou não. Se continuar com o aperfeiçoamento do sistema, é traçado um plano para a próxima fase do projeto. Um diferencial nesse modelo comparado com outros é a explícita consideração de riscos dentro do projeto como um todo. Para tanto, criou-se uma fase específica de Análise de Riscos nesse modelo.

Modelos Mistos e Outros

Existem mais modelos fora os clássicos que nós vimos anteriormente. Alguns não deixam de ser um mix desses modelos. Misturam dois ou mais conceitos dos modelos estudados. Mas gostaria de concentrar nos modelos mais atuais, e que são aplicados hoje em dia. Um deles é o Modelo RAD (Rapid Application Development). Em contraposto aos modelos clássicos que ficavam na tentativa de abordar todos os principais tópicos, o RAD focou na variável tempo.

Ele é um processo de software incremental que enfatiza um ciclo de desenvolvimento curto (Pressman). A estratégia para isso é o uso da abordagem de construção baseada em componentes. Com isso, o desenvolvimento completo de um sistema, de relativa complexidade, chega a atingir 60 a 90 dias. Os pontos a serem ressaltados nesse modelo são que se o sistema não puder ser adequadamente modularizado, a construção de componentes necessários ao RAD será problemática. E outro ponto é que o RAD pode não ser adequado quando os riscos técnicos são altos, por exemplo, se existir a necessidade de uma aplicação usufruir tecnologias novas não dominadas pela equipe.

Um outro modelo é o Processo Unificado Racional, RUP em inglês, que utiliza maciçamente do UML (Unified Modeling Language). Utilizando métodos e linguagens de programação orientada a objetos, aprimora o modelo RAD. A ênfase desse modelo é na arquitetura de software.

Paradigmas da Engenharia de Software: Processo, Métodos e Ferramentas

A Engenharia de Software é uma tecnologia em camadas (Pressman). Conforme a figura a seguir, podemos observar que todo o foco desta disciplina é na qualidade, que é a base de todas as camadas. O alicerce da Engenharia de Software, para tal, fica sendo no PROCESSO, onde a partir daí temos os MÉTODOS a serem aplicados, e as FERRAMENTAS como apoio a todo esse esquema. O arcabouço deste conjunto é conhecido como paradigma de Engenharia de Software.

Processo

O Processo de Software é um conjunto de atividades, métodos, práticas e transformações ordenadas com a intenção de atingir a qualidade do software. Sua meta fundamental é entregar, de maneira eficiente e previsível, um produto de software capaz de atender as necessidades de negócio, definidas pela análise de requisitos dos usuários. Pode-se também definir sucintamente como um conjunto completo de atividades necessárias para transformar os requisitos do usuário em um produto de qualidade de software. Um processo define QUEM está fazendo O QUE, QUANDO e COMO para atingir esse objetivo.

Métodos

Método é uma palavra que vem do grego méthodos, que significa “caminho para se chegar a um fim”. O termo metodologia é bastante controverso nas ciências em geral e na Engenharia de Software em particular. Muitos autores parecem tratar metodologia e método como sinônimos, porém seria mais adequado dizer que uma metodologia envolve princípios filosóficos que guiam uma gama de métodos que utilizam ferramentas e práticas diferenciadas para realizar algo. As metodologias de Engenharia de Software objetivam ensinar “como fazer” para construir softwares. Esses métodos incluem atividades de modelagem, construção de programas, testes e manutenção. Na Engenharia de Software, as principais abordagens de metodologias são:

• Metodologia Estruturada: é a mais clássica das abordagens. Utiliza como ferramental Dicionário de Dados, Diagrama de Fluxo de Dados (DFD) e o Modelo Entidade Relacionamento (MER).
• Metodologia Orientada a Objetos: Exemplo RUP.
• Metodologias de Desenvolvimento Ágil: Existem várias metodologias que podem ser consideradas como abordagens ágeis: XP, ASD, DSDM, Scrum, Crystal, FDD, AM, entre outras.

Ferramentas

Ferramenta é uma palavra que vem do latim ferramentum, significando “qualquer utensílio empregado nas artes e ofícios” (Aurélio). As ferramentas de Engenharia de Software fornecem apoio automatizado, ou semi-automatizado, para o processo e para os métodos. Quando ferramentas são integradas de modo que a informação criada por uma ferramenta possa ser usada por outra, um sistema de apoio ao desenvolvimento de software, chamado de “engenharia de software apoiada por computador” (CASE), é estabelecido (Pressman).

Características de um bom processo

Características de um bom ambiente de desenvolvimento

Processo de software, ou processo de Engenharia de Software, é uma sequência coerente de práticas, que objetiva o desenvolvimento ou evolução de sistemas de software. Estas práticas englobam as atividades de especificação, projeto, implementação, testes e caracterizam-se pela interação de ferramentas, pessoas e métodos. As principais características de um bom processo são:

• Configurável para diferentes organizações.
• Adaptável para diferentes tamanhos e tipos de projetos.
• Bem definido, gerenciável e repetível.
• Com nomenclatura universal e métricas para planejamento e gerenciamento do projeto.
• Integrado com ferramentas que o suportem.

Características de um bom ambiente de desenvolvimento

• Processo de desenvolvimento definido.
• Integração entre processo e ferramentas.
• Gerenciamento de configuração.
• Gerenciamento de mudanças.
• Gerenciamento de projetos.
• Automação de testes funcionais e de desempenho.
• Documentação consistente.

Introdução ao RUP (Rational Unified Process)

RUP (Rational Unified Process) 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 pelo mercado. Atualmente, o RUP é um produto desenvolvido e mantido pela Rational Software (Divisão IBM). Sistemas concebidos por esse processo normalmente são desenvolvidos em uma linguagem de programação orientada a objetos, como Java ou C++. As principais características do RUP são: Desenvolvimento Iterativo, Gerência de requisitos, Uso de arquitetura baseada em componentes, Modelagem visual, Controle contínuo da qualidade, Gerência de mudanças. A solução iterativa requer uma compreensão crescente do problema por meio de aperfeiçoamentos sucessivos e de desenvolvimento incremental em vários ciclos.

Modelagem

A abstração do sistema de software através de modelos que o descrevem é um poderoso instrumento para o entendimento e comunicação do produto final que será desenvolvido. A maior dificuldade nesta atividade está no equilíbrio entre simplicidade (favorecendo a comunicação junto ao usuário) e a complexidade (favorecendo a precisão com detalhes) do modelo. É comum a utilização de linguagens para modelagem como UML.

Fases

Estruturar um projeto junto à dimensão de tempo envolve a adoção das seguintes fases baseadas em tempo:

• Iniciação (Inception): Estabelece a visão, o escopo e o plano inicial para o projeto.
• Elaboração (Elaboration): Projeta, implementa e testa a arquitetura do sistema e completa o plano do projeto.
• Construção (Construction): Desenvolve a primeira versão do sistema.
• Transição (Transition): Implantar o produto no ambiente de produção.

Workflow de Processo

Estruturar um projeto junto à dimensão de componente de processo inclui as seguintes atividades:

• Modelagem do negócio: Descreve o negócio através de casos de uso de negócio.
• Requisitos: Narrativa da visão do sistema. Descrição das funções do sistema.
• Análise e Projeto: Descrição de como o sistema será realizado na etapa de implementação.
• Implementação: Produção do código que resultará em um sistema executável.
• Testes: Verificar a integração entre todos os componentes de software, identificar e corrigir erros de implementação.
• Distribuição: Gerar um release do produto. Entrega do produto e treinamento dos usuários.
• Gestão de Projetos: Especifica um conjunto de princípios a aplicar na gestão de projetos no nível da alocação de recursos, planejamento, identificação e gestão de riscos, etc.
• Gestão de Configuração e Mudança: Controla as mudanças e mantém a integridade dos artefatos do projeto.
• Definição do Ambiente: Cobre a infraestrutura necessária para desenvolver um sistema (seleção de ferramentas, definição das regras de negócio, interface, testes, etc).

Modelos de Maturidade – CMM (Capability Maturity Model)

O conceito de Modelo de Maturidade de Capacitação para Software, que é um metamodelo de PROCESSO, foi desenvolvido pela Carnegie Mellon University através do seu órgão SEI (Software Engineering Institute). O SEI é um centro de pesquisa e desenvolvimento criado, em 1984, pelo Departamento de Defesa dos Estados Unidos. Podemos definir “Capacitação para Software” como sendo a habilitação que a organização tem em sistematicamente produzir software possuindo a qualidade esperada, dentro dos prazos concordados e com os recursos alocados. Quanto maior a capacitação, menor será a variação dos erros de estimativa (de custos, prazos, etc.) em torno da média. CMM (Capability Maturity Model) é o mais famoso representante desse conceito. Ele basicamente é uma metodologia de diagnóstico e avaliação da maturidade da capacitação em desenvolvimento de softwares numa organização (empresa ou instituição). O objetivo maior do CMM é determinar em que estágio de maturidade uma empresa está em seu ciclo de desenvolvimento de software. Nasceu da necessidade do Departamento de Defesa americano em como avaliar as empresas terceirizadas que desenvolviam softwares para eles.

O uso de estratégia de melhoria de processos através de avaliação contínua, identificação de problemas e suas devidas ações corretivas permite estabelecer cinco níveis de maturidade.

CMMi (Capability Maturity Model Integration)

CMMi é o modelo de maturidade surgido recentemente com o fim de unificar e agrupar as diferentes usabilidades do CMM e de outros modelos de processos de melhoria corporativo. Somente por curiosidade, raras são as empresas no mundo que conseguem atingir o nível 5, a grande maioria fica nos estágios iniciais. No Brasil, até o ano 2007, existiam 4 empresas que tinham alcançado o nível 5 do CMMi.

Estágios de Descrição

• Nível 1 – Inicial: Caótico, estágio onde a maioria das empresas de software se encontram.
• Nível 2 – Repetitivo: Capacidade de repetir sucessos anteriores através do acompanhamento de custos, cronogramas e funcionalidades.
• Nível 3 – Definido: O processo de software é bem definido, documentado e padronizado.
• Nível 4 – Gerenciado: Realiza uma gerência quantitativa e qualitativa do processo de software e do produto.
• Nível 5 – Em Otimização: Usa a informação quantitativa para melhorar continuamente e gerenciar o processo de software.

Para podermos visualizar melhor, de forma gráfica, todos os níveis de maturidade e a interação entre eles, podemos observar a figura a seguir: