Uma Abordagem sobre Processos de Software

Heitor Silva Temp¹, Luciano Estanislau Sturza¹

¹Tecnólogo em Análise e Desenvolvimento de Sistemas – ADS

Instituto Federal Farroupilha Campus São Vicente do Sul – IF Farroupilha-SVS
CEP 97420-000 – São Vicente do Sul – RS – Brasil

{heitorsilvatemp@gmail.com, lucianosturza@yahoo.com.br}

Resumo
Este artigo aborda alguns tipos de processos de software utilizados na
atualidade, na qual a comunidade acadêmica e as empresas têm aplicado diversos
esforços. Tendo como objetivo apresentar os principais conceitos sobre os processos
para se construir um software, sobre os ciclos de vida utilizados e uma definição para
CMMI(Capability Maturity Model Integration - Modelo de melhoria de processo de
software), entendendo-se o quanto é importante a maturidade dos processos de software
para a análise, desenvolvimento e manutenção de um software. A qualidade de software
está diretamente dependente do processo de desenvolvimento deste.

Palavras-chave: Processo de Software, Qualidade de Software, ciclo de vida.

Abstract
This article discusses some types of software processes currently used, in which
the academic community and companies have implemented various efforts. Aiming to
present the main concepts of the processes for building software on the cycles of life
and used a definition for CMMI, understanding how important the maturity of software
processes for analyzing, developing and maintaining a software. The quality of software
is directly dependent on the process of developing this.

Keywords: Software Process, Software Quality, life cycle.

1 Introdução
O processo de desenvolvimento de software, ou processo de software,
corresponde ao conjunto de atividades relacionadas que são desempenhadas pelos
desenvolvedores desde a concepção até a liberação do produto. Uma forma de analisar e
amadurecer tal processo é através de sua descrição, a qual consiste de um modelo de
processo de software. A descrição formal de um processo de software é a atividade que
permite que o mesmo seja analisado, compreendido e automatizado (executado).
Hoje, todos (no Governo, Academia e Indústria) devem reconhecer a
importância que a melhoria dos processos de software auxiliam para a competitividade,
qualidade e produtividade sistêmica do setor de software; mas, poucos têm idéia da
importância, magnitude, complexidade e duração do esforço quando se trata de superar
este desafio. Com análise neste cenário em que estamos, vimos o quanto é importante a
abordagem dos tipos de processos de software à nossa realidade em nível acadêmico e a
nível de indústrias de software. Pois muitas empresas hoje que estão no setor de
produção de software tem grandes prejuízos por não terem um controle dos processos
aplicados, e também não tem uma preocupação em utilizar metodologias de maturidade
a seus processos.
Este artigo tem como objetivo apresentar os principais conceitos sobre os
modelos de ciclo de vida, pois o ponto de partida para a arquitetura de um processo é a
escolha de um modelo de ciclo de vida[1], também abordaremos os processos para a
construção de um software, e uma definição para CMMI(Capability Maturity Model
Integration - Modelo de melhoria de processo de software) e também definiremos o
MPS.BR(Melhoria de Processo do Software Brasileiro), entendendo-se o quanto é
importante a maturidade dos processos de software para a análise, desenvolvimento e
manutenção de um software.

2 Modelos de Ciclo de Vida

Para que haja um melhor gerenciamento dos processos, o gerente ou a
organização executora deve dividir seus projetos em fases, o que é conhecido como
“Ciclo de vida”. O ciclo de vida serve para definir o inicio e o fim do projeto e qual
trabalho ou atividade deve ser realizado em cada fase (ou etapa) e quem deve estar
envolvido.
Cada organização define o ciclo de vida, aqueles que geram produtos ou serviços
menos complexos tendem a ter ciclos de vida menores, já os mais complexos podem
possuir ciclos de vida maiores, por exemplo: O projeto de desenvolvimento de um
software pode passar por fases como definição de requisitos, projeto, programação e
implementação, sendo assim cabe ao gerente do projeto ou a organização definir o ciclo
de vida ideal dos seus projetos.
Ciclos de vida do software descrevem como um software deve ser desenvolvido.
Basicamente definem a ordem global das atividades envolvidas em um contexto de
projeto de software e propõe uma estratégia de desenvolvimento que pode ser aplicada a
um determinado contexto de projeto de software. Ciclos de vida normalmente são vagos
nas descrições de detalhes das condições de início e término de uma atividade, recursos
utilizados, artefatos consumidos ou produzidos, papéis desempenhados etc. Dentre os
diversos ciclos de vida de software, pode-se citar: Codifica-remenda, Cascata, Espiral,
Prototipação Evolutiva, Prototipação Incremental, Prototipação Descartável,
Refinamento Iterativo, Ciclo de Vida Progressivo, Desenvolvimento Incremental,
Sashimi. Abordaremos especificamente os modelos: Codifica-remenda, Cascata e o
Espiral.

2.1 Codifica-remenda

Infelizmente, é provavelmente o modelo mais utilizado, pois não exige nenhum

sofisticação técnica ou gerencial, sendo assim um modelo de alto risco impossível de
gerir e assumir compromissos confiáveis. Parte apenas de uma especificação, ou nem
isso, começa diretamente pela codificação, sendo remendado a partir do que os erros
vão sendo descobertos (Fig. 2.1).
Nenhum processo com definições específicas é seguido.
 Fig. 2.1 Modelo de Ciclo de vida codifica-remenda

2.2 Cascata

A proposta do modelo Cascata (Fig. 2.2) consiste na execução das atividades em

uma seqüência ordenada e bem definida. Desta forma, a passagem para determinada
atividade exige como critério a finalização da atividade anterior, facilitando a gestão dos
projetos, assim os processos são confiáveis e utilizáveis em qualquer escala. É sempre
necessário permitir que em fases posteriores haja revisão e alteração de resultados das
fases anteriores [1].
As principais atividades do modelo são: requisitos de sistema, análise, projeto
de programa (desenho), codificação (Implementação), teste e operação (Fig. 2.2).

Fig. 2.2 Modelo de ciclo de vida em Cascata

 Os modelos e documentos de desenho podem ser alterados durante a
implementação à medida que os problemas vão sendo descobertos. Uma variante que
permite superposição entre fases e a realimentação de correções é um modelo mais
realista, com realimentação entre as fases, chamado de cascata com realimentação (Fig.
2.3), esta realimentação entre as fases torna difícil o gerenciamento de processos
baseada neste modelo [1].
Este ciclo de vida é adequado a projetos de pequena duração também
conveniente para mini-processos.

Fig. 2.3 Modelo em cascata com realimentação

2.4 Espiral

Reúne características dos modelos Cascata e Prototipação acrescentando ainda

em sua base a análise de riscos. Esse processo evolutivo permite que novas versões
possam ser construídas progressivamente, e apresenta alta flexibilidade e visibilidade.
Esse modelo permite que em pontos bem definidos, os usuários possam avaliar partes
do produto e fornecer realimentação quanto às decisões tomadas. É de fácil
acompanhamento do progresso de cada projeto tanto por parte dos seus gerentes como
dos seus clientes, mas requer gestão sofisticada e o desenho deve ser muito robusto para
que a estrutura do produto não se degenere ao longo das suas constantes mudanças.
Uma desvantagem do modelo refere-se a situações em que o projeto é
considerado simples e os riscos são modestos. Nesse contexto, muitos projetos não
precisam da flexibilidade e gerenciamento de riscos proporcionados pelo modelo.
 Fig. 2.4 Modelo de ciclo de vida em espiral

3 Processos de software
Processos de software são as diversas fases necessárias para produzir e manter
um produto de software. Requerem a organização lógica de diversas atividades técnicas
e gerenciais envolvendo agentes, métodos, ferramentas, artefatos e restrições que
possibilitam disciplinar, sistematizar e organizar o desenvolvimento e manutenção de
produtos de software.
Segundo o IEEE(Instituto de Engenheiros Eletricistas e Eletrônicos), é uma
seqüência de passos executados com um determinado objetivo; Segundo o CMMI
(Capability Maturity Model Integration - Modelo de melhoria de processo de software),
é um conjunto de ações e atividades inter-relacionadas realizadas para obter um
conjunto especificado de produtos, resultados ou serviços. Na UML(Unified Modeling
Language), processo é, unidade pesada de execução concorrente, em oposição a uma
linha de execução(thread), que representa a implementação de um processo leve.
Um processo é uma receita que é seguida por um projeto; o projeto concretiza
uma abstração, que é o processo. Não se deve confundir um processo com o respectivo
produto ou com a execução do processo através de um projeto. Um processo é
representado na forma de um grafo, etapas, papéis, insumos e resultados estão entre os
elementos de um processo, Tabela 3.1, segundo o autor[1].
Termo Definição
Insumo (Praxis) Coisa que é consumida num processo.
Papel (SPEM)Conjunto correlato de proficiências, competências e
responsabilidades, desempenhado por uma ou mais pessoas.
Etapa (Praxis) Termo genérico para uma divisão temporal de um processo.
Processo de (UML)Conjunto de passos e diretrizes para o desenvolvimento de
desenvolvimento um produto.
Produto 1. (PMBOK)Um objeto produzido, quantificavel, e que pode
ser um item final ou um item componente.
2. (CMMI)Resultado que se pretende entregar a um cliente ou
usuário.
Produto de 1. (SPEM)Qualquer coisa consumida, produzida ou modificada
trabalho por tarefas.
2. (CMMI)Coisa útil que resulta de um processo.
Projeto 1. (CMMI)Conjunto gerido de recursos inter-relacionados, que
entrega um ou mais produtos a um cliente ou usuário, com
inicio definido e que, tipicamente, opera conforme um plano.
Conforme produto.
2. (PMBOK)Um empreendimento temporário realizado para
criar um produto, serviço ou resultado distinto.
Resultado (PMBOK)Uma saída dos processos e atividades de um projeto.
Tabela 3.1 Definições referentes a processos.

4 Os processos de Humphrey

Watts Humphrey propôs um processo de software individual, chamado de

Processo pessoal de software (Personal Software Process), ou PSP, que é descrito em
um livro [3]. Como conseqüência natural do PSP, Humphrey introduziu em [4], o
processo de software para Times (Team software process), ou TSP, esse processo já tem
escala para ser utilizado em projetos maiores.

4.1 O Processo pessoal de Software.

O PSP não é realmente um único processo, mas uma série de processos pessoais
que é uma seqüência de pequenos projetos, estes devem ser realizados seguindo
rigorosamente os processos, que incluem um conjunto de formulários, scripts e
relatórios predefinidos.

4.1.1 Os estágios do PSP:

•PSP0 –Gerenciamento Básico

–Medidas de Tempo e Defeito
•PSP1 –Gerenciamento de Projeto
–Planejamento e Acompanhamento
 •PSP2 –Gerenciamento de Qualidade
–Revisões de Código e Design
•PSP3 –Ciclo de Desenvolvimento Pessoal
–Escala e Produtividade

Fig. 3.1 O processo pessoal de software

O PSP3 tem um ciclo de vida de entrega em estágios. Não existe um tratamento

separado dos requisitos. O planejamento inclui a estimativa de tamanhos(medidos em
linhas de código, com base em um modelo conceitual orientado a objetos), de
esforços(medidas em tempo de desenvolvimento), de cronograma(tempo físico) e de
defeitos.
O desenho é feito de acordo com padrões rigorosos, que usam conceitos de
orientação a objetos, síntese lógica e máquinas seqüenciais e submetido a uma fase
rigorosa de verificação.
Ao final de cada ciclo, o planejamento é reavaliado. O PSP sempre termina com
uma fase de post-mortem, na qual é feito um balanço final do projeto. As lições
aprendidas são documentadas e analisadas, para melhoria do processo no projeto
seguinte.

4.2 O processo de Software para Times

O TSP usa um modelo em espiral, os participantes do time de desenvolvedores

são organizados de tal forma que cada desenvolvedor desempenhe um ou dois papéis
gerenciais bem-definidos, além de dividir a carga de desenvolvimento. Os papéis
suportados pelo processo são os de gerente de desenvolvimento, de planejamento, de
qualidade, de processo e de suporte, além do líder do time.
Áreas enfatizadas do TSP e não são tratadas pelo PSP:
• Gestão dos requisitos;
• Planejamento (pode ter no PSP) e controle de projetos;
• Garantia da qualidade;
• Gestão de configurações;
5 Os processos da linguagem MBase – RUP

Combina o modelo de ciclo de vida em espiral com princípios de negociação

ganha-ganha (win-win negotiation) e com o conceito de evitar choques entre modelos
(model clashes). O processo deve ter consistência entre os modelos:
• Modelos de produtos (requisitos, arquitetura, código);
• Modelos de processo (tarefas, atividades, marcos);
• Modelos de propriedade (custo, prazo, desempenho, confiabilidade);
• Modelos de sucesso (visão de negócio);

5.1 O Processo Unificado

O processo Unificado (Unified Process) [Jacobbson+99], que utiliza a UML

como notação de uma série de modelos que compõem os principais resultados das
atividades do processo.
Características centrais do Processo Unificado:
• Dirigido por casos de uso, “uma série de fluxos de trabalho derivados
dos casos de uso”[Jacobson+99];
• Centrado na arquitetura – casos de uso são baseados em uma
arquitetura global, definida nas fases iniciais;
• Iterativo – repetição de etapas similares;
• Incremental – as iterações acrescentam novas funções ao produto;
O ciclo de vida de um projeto é dividido em fases. Os fluxos de trabalho
(workflows), são subprocessos das atividades técnicas, cada fluxo de trabalho tem um
tema técnico específico, e as fases constituem divisões gerenciais, estas tem a
característica de atingir metas bem-específicas.

5.2 - O RUP

Tem as mesmas raízes que o Processo Unificado, o RUP (Rational Unified

Process), detalha e amplia o material técnico, complementa com aspectos gerencias, e
não pode ser confundido com o Processo Unificado, pois o RUP tem estrutura diferente,
usa as mesmas fases e mesmas características básicas, mas as coleções de atividades
técnicas são diferentes, e é chamado de Disciplinas, termo atualmente padronizado pelo
SPEM (Software Process Engineering Metamodel).
O RUP se norteia em princípios largamente utilizados no desenvolvimento de
software desde o seu surgimento até os dias presentes. O processo, ao contrário que
muitos pensam, não prega que devemos fazer tudo exatamente como está no papel, ele
prega que devemos seguir as boas práticas de desenvolvimento de software e ele se
propõe a ser um guia que ajuda na construção de software de qualidade.
O processo é iterativo Incremental, sendo que ele possui marcos. Esses marcos
nos ajudam a nos situarmos no projeto e ver se o projeto tem condições de continuar em
termos de riscos e se estamos no rumo correto.
 Fig. 4.2 Fases do RUP

A figura 4.2, que também é conhecida como gráfico de baleias, é mostrar as

disciplinas do projeto como (construção, requisitos, configuração, etc..) através das
iterações e com os marcos de fases. O gráfico de baleias mostra a intensidade das
disciplinas através das iterações e fases. Não confunda esse processo com ciclo de vida
em Cascata, de acordo com o autor [5].

6 - Processos Ágeis
São caracterizados por princípios comuns, mais baseados no trabalho cooperativo do
que no formalismo e na documentação escrita. Esses princípios foram reunidos por um
grupo de metodologistas conhecidos em um documento chamado Manifesto Ágil. Neste
documento proclamam os seguintes valores:
• Indivíduos e iterações, em relação a processos e ferramentas.
• Software funcional, em relação à documentação abrangente.
• Colaboração com o cliente, em relação a negociações contratuais.
• Resposta à mudança, em relação a seguir planos.

Esses princípios geralmente se traduzem nas seguintes atitudes:

• Satisfazer o cliente com entregas rápidas e freqüentes de software útil.
• A funcionalidade é a principal medida do progresso.
• Mesmo alterações tardias de requisitos são bem vindas.
• Colaboração próxima e diária entre gerentes e desenvolvedores.
• Comunicação face a face, facilitada pela co-localização.
• Ênfase na confiança em pessoas motivadas.
• Atenção continua a excelência técnica e ao bom desenho.
• Simplicidade.
 • Equipes auto-organizadas.
• Adaptação rotineira a mudanças de circunstâncias.

Entre os métodos ágeis mais populares podem-se citar os métodos Scrum,

Crystal Clear, Adaptive Software Development, Feature Driven Development (FDD),
Dynamic System Development Method (DSDM), e principalmente Extreme Programing
(XP), o mais difundido de todos. Agile Modeling não é um processo separado, e sim
uma metodologia para adicionar práticas de modelagem aos métodos ágeis, proposta por
Scott Ambler1, que também desenvolveu o Agile Unified Process2(AUP), que se propõe
a ser uma versão ágil do RUP.
Críticas freqüentes aos métodos ágeis:
• Faltam-lhes estrutura e documentação realmente necessárias.
• Requerem desenvolvedores muito experientes e disciplinados.
• Costumam em resultar em desenho insuficiente.
• Requerem mudança cultural muito grande.
• Dificultam negociações contratuais
• Podem ser ineficientes se as alterações de requisitos forem freqüentes.
• Dificultam as estimativas de esforços, custos e prazos.
• Mostram dificuldades de tratamentos dos requisitos não-funcionais.

Área Característica Métodos Ágeis Métodos dirigidos por

planos
Cultura Mais informal Mais formal
Desenvolvedores Tamanho da equipe Menor Maior
Experiência Maior Menor
Localização Única Espalhada
Relacionamento Mais Mais formal
Clientes cooperativo
Localização Próxima Distante
Requisitos Natureza Emergentes Bem conhecidos
Variabilidade Alta Baixa
Foco Solução Expansibilidade
Arquitetura imediata
Refatoramento Fácil Difícil
Projeto Tamanho Menor Maior
Objetivo Valor rápido Alta garantia
Tabela 6.1 métodos ágeis x métodos dirigidos por planos

7 - O processo Praxis

Um processo desenhado para dar suporte a projetos didáticos em disciplinas de

engenharia de software e em programas de capacitação profissional em engenharia de
software. A sigla Praxis significa PRocesso para Aplicativos eXtensíveis InterativoS,
refletindo uma ênfase no desenvolvimento de aplicativos gráficos interativos, baseados
na tecnologia orientada a objetos. Este é desenhado para suportar projetos de pequenas

1
Material disponível em http://www.agilemodeling.com/.
2
Material disponível em http://www.ambysoft.com/unifiedprocess/agileUP.html.
equipes com duração de seis meses a um ano. Com isso, pretende-se que ele seja
utilizável para projetos de fim de curso de graduação ou similares, segundo o autor [1].
Os principais elementos que compõe o processo são: disciplinas, tarefas,
atividades, artefatos, papéis e orientações.
O Praxis tem semelhanças com o RUP, é um processo concreto, é definido por
meio da aplicação do SPEM (Software Process Engineering Metamodel), através do uso
do EPF (Eclipse Process Framework).
Nomenclatura utilizada pelo PRAXIS:
– Passo:
• divisão formal de um processo
– Fase:
• corresponde aos pontos principais de aceitação, por parte do cliente.
– Iteração:
• passo constituinte de uma fase,atinge um conjunto bem definido,de metas
parciais de um projeto.
– Script:
• conjunto de instruções;
• define como uma iteração deve ser executada.
– Fluxo:
• subprocesso caracterizado por um tema;
• técnico ou gerencial.
– Subfluxo:
• conjunto de atividades mais estreitamente correlatas;
• faz parte de um fluxo maior.

7.1 Fases do Praxis

Os elementos do Praxis são inspirados no UP(Unified Process).

– Concepção:
• decisão de desenvolver um produto;
– Elaboração:
• a especificação é detalhada o suficiente para modelar;
• dimensionamento firme;
– Construção:
• desenvolvimento entrega de produto completo;
– Transição:
• passagem ao ambiente de uso.
 Tabela 7.1 – Iterações do Praxis padrão

Tabela 7.2 – Detalhamento da Fase de Concepção

8 Capacitação em Processos

Descreve a faixa de resultados esperados que podem ser alcançados seguindo-se

um processo de software. A capacidade do processo de software de uma organização
fornece uma maneira de se predizer vários resultados a serem esperados no próximo
projeto de software da organização.
Os paradigmas chamados de Modelos de Maturidade de capacitação(CMM -
Capability Maturity Model) é um modelo de desenvolvimento para aplicação específica
ao software, dentro de um contexto de qualidade total no âmbito de uma organização. É
uma estrutura, para avaliação e melhoria, aplicada somente ao processo de software.
O CMM, são modelos que contém os elementos essenciais de processos eficazes
para uma ou mais disciplinas e descrevem um caminho de melhoria evolutiva que parte
de processos imaturos e ad-hoc, até chegar a processos maduros e disciplinados, que
melhoram de forma significativa a qualidade dos produtos e a eficácia do trabalho,
conforme [7].

8.1 – O modelo CMMI

O primeiro modelo de capacitação para a área de software foi o SW-
CMM(Software capability Maturity Model), formulado pelo SEI(Software Engineering
Institute). Originalmente conhecido como CMM, recebeu a denominação SW-CMM
para distinguir-se de modelos de capacitação em outras áreas, que foram formuladas
posteriormente pelo SEI. Em 200, foi publicado o CMMI v1.1, entretanto o SW-CMM
em fase de retirada, em 2006 foi publicado o CMMI v1.2, com organização ligeiramente
diferente da versão inicial, os componentes usados para construir modelos, documentos
de avaliação e material de treinamento são agrupados em conjuntos denominados de
constelações. O conjunto existente foi denominado CMMI para Desenvolvimento, tendo
sido iniciada a construções de constelações para Serviços e Aquisição.
O CMMI é dividido em níveis de maturidade, onde são divididas as práticas
específicas e genéricas, existem 5 níveis, Figura 8.1.

Figura 8.1 – Níveis de maturidade do CMMI

8.2 – Os modelos ISSO

8.2.1 – ISO 9000

A denominação ISSO-9000 abrange uma família de padrões, com
âmbitos diferentes, oficializados pela ISSO(International Organization for
Standardization), atualmente a família de padrões vigente é a 2000. Os padrões dessa
família referem-se a sistemas de gestão da qualidade, com os seguintes documentos
principais:
ISO-9000:2005 – Fundamentos e vocabulários: descreve conceitos e termos
básicos dos sistemas de gestão da qualidade.
ISO-9000:2000 – Requisitos: descreve os requisitos que devem ser satisfeitos
por organizações que desenham, desenvolvem, fabricam, instalam ou mantém produtos
e serviços, para garantir a satisfação dos clientes.
ISO-9004:2000 – Diretrizes para a melhoria de desempenho: trata da melhoria
contínua de sistemas maduros.

8.2.2 – ISO/IEC-12207
Este modelo conhecido no brasil como NBR-ISO/IEC-12207, descreve os
principais processos componentes do ciclo de vida do software e os relacionamentos
entre eles.

8.2.3 – ISO-15504
A ISO, desenvolveu o arcabouço (framework) ISO-15504, que não apresenta
diretamente requisitos para a maturidade de processos, mas sim um guia para a
avaliação dessa maturidade. Este pode ser considerado um meta-modelo, a partir do
qual podem ser derivados modelos específicos de capacitação.

8.3 – MPS.BR
O MPS.BR(Melhoria de Processo de Software Brasileiro) é o resultado de um
programa coordenado pela SOFTEX(Associação para Promoção da Excelência do
Software Brasileiro), com o patrocínio do Ministério da Ciência e tecnologia e de outras
instituições. Segundo o seu documento[], o modelo foi desenvolvido em conformidade
com as referências ISO/IEC-12207, ISO/IEC-15504 e CMMI para desenvolvimento.
Ele classifica as instituições em sete níveis de maturidade, denominados A a G, do mais
alto para o mais baixo, ver figura 8.3.

Figura 8.3 – Níveis do MPS.BR

8.4 - PMBOK
O PMBOK(Project Management Body of Knowledge) reúne um guia publicado
pelo PMI(Project Management Institute) um conjunto de práticas geralmente aceitas de
gestão de projetos. Contempla as seguintes áreas de conhecimento em gestão de
projetos: integração, escopo, tempo, custos, qualidade, recursos humanos,
comunicações, riscos e aquisições.

8.5 - COBIT
O COBIT(Control Objectives for Information and Related Technology) é um
conjunto de boas práticas para gestão de tecnologia da informação criado pela
ISACA(Information Systems Audit And Control Association), que também concede
certificação profissional, e pelo ITGI(IT Governance Institute). O COBIT define níveis
de maturidade semelhantes aos do CMMI e um conjunto de processos, agrupados em
quatro domínios: Planejamento e organização, Aquisição e Implementação, Entrega e
Suporte, Monitoração e Avaliação.

9 Considerações Finais

Qualquer tipo de experiência pode ser reutilizado com intuito de evitar

retrabalho e melhorar a qualidade de um sistema, mas analisando todos os fatos
envolvidos no desenvolvimento de um sistema, vimos a necessidade de seguirmos
padrões específicos para desenvolver um projeto de software, como citado nas
especificações dos processos de software e na capacitação dos mesmos.
Em uma empresa possuímos pessoas, ferramentas e processos, as duas primeiras
podem ser substituídas por motivos diversos, no entanto se não tivermos processos,
podemos ocasionar a ruína desta organização nestas substituições.
Os processos trazem a padronização da forma como a empresa faz software,
retira o conhecimento do sistema do analista, desenvolvedor, entre outros e o
disponibiliza para a empresa de forma geral, facilitando o aprendizado de novos
membros na equipe, a localização de falhas, entre outros casos.
Neste contexto, a utilização e a realimentação do processo padrão não são tarefas
simples e requerem um suporte baseado na experiência.
Neste artigo, abordaram-se os processos de software em uma visão ampla, pois a
finalidade deste foi de levantarmos os processos utilizados na atualidade pelas
empresas, e como estes processos podem ser melhorados utilizando os modelos de
capacitação dos processos.
O processo de software mais utilizado na atualidade é o RUP, mas este já
não pode ser considerado um processo único, e sim uma plataforma que permite
construir uma grande família de processos personalizados para muitos portes de projeto
e muitas aplicações diferentes.
10 – Referências Bibliográficas
[1]Filho, W. P. P., Engenharia de Software: Fundamentos, métodos e padrões. Terceira edição. 2009.
[2] Weber, K. C., Rocha, A. R., Montoni, M., Santos,G., Barbieri,C., Antonioni, J. A., MPS.BR - Melhoria de
Processo do Software Brasileiro: resultados alcançados e lições aprendidas (2004-2008) – Setembro 2009
[3]Humphrey, W. S., A Discipline for Software Engineering. Addison-Wesley, 1995.
[4]Humphrey, W. S., Introduction of the Team Software Process. Addison-Wesley, 1999.
[5] Pacheco, D.; RUP – Verdade e mitos. Disponível em:
http://imasters.uol.com.br/artigo/11624/gerenciadeprojetos/rup_verdade_e_mitos/ - Fevereiro de 2009
[6] Jacobson, I.; Rumbaugh, J., The unified software development process. Addison-Wesley, 1999.
[7]CMMI product team. CMMI for Development, Version 1.2. CMU/SEI-2006-TR-008. Software
Engineering Institute. Ago. 2006.