07/04/2017 O processo de Software

           O processo de Software

A utilização de um processo de software têm sido apontada como um fator primordial

para o sucesso de empresas de desenvolvimento de software.

Para poder melhor compreender o assunto é necessário definir o que é um processo de

software.

Um processo de software pode ser entendido como um conjunto estruturado de

atividades exigidas para desenvolver um sistema de software. Assim Sommerville[1]
trás a seguinte definição:

"[O processo é] um conjunto de atividades e resultados associados que produzem um

produto de software".

Jalote[7] conclui que um processo de software é :

"é um conjunto de atividades, ligadas por padrões de relacionamento entre

ela, pelas quais se as atividades operarem corretamente e de acordo com os
padrões requeridos, o resultado desejado é produzido. O resultado desejado
é um software de alta qualidade e baixo custo. Obviamente , um processo
que não aumenta a produção (não suporta projetos de software grandes) ou
não pode produzir software com boa qualidade não é um processo
adequado."

A partir destas definições podemos considerar que de forma geral um processo de

software padrão pode ser visto como um conjunto de atividades, métodos, ferramentas
e práticas que são utilizadas para construir um produto de software. Na definição de
um processo de software devem ser consideradas as seguintes informações: atividades
a serem realizadas, recursos necessários, artefatos requeridos e produzidos,
procedimentos adotados e o modelo de ciclo de vida utilizado [3].

Sucintamente podemos definir o processo de software  como um conjunto de atividades

uniformizadas a serem aplicadas sistematicamente que se encontram agrupadas em fases, cada
uma das quais com os seus intervenientes com responsabilidades, que possui diversas entradas e
produz diversas saídas. Isto é, define quem faz o quê, quando e como para atingir um certo
objetivo.

Humphrey[4] define as seguintes razões para a definição de um processo padrão:

Redução dos problemas relacionados a treinamento, revisões e suporte à

ferramentas;
http://www.macoratti.net/proc_sw1.htm 1/12
07/04/2017 O processo de Software

As experiências adquiridas nos projetos são incorporadas ao processo padrão e

contribuem para melhorias em todos os processos definidos;
Economia de tempo e esforço na definição de novos processos adequados a
projetos.

Fases de um processo de Software

Para Schwartz[5] as principais fases de um processo de software são :

1. Especificação de Requisitos: tradução da necessidade ou requisito operacional

para uma descrição da funcionalidade a ser executada.
2. Projeto de Sistema: tradução destes requisitos em uma descrição de todos os
componentes necessários para codificar o sistema.
3. Programação (Codificação): produção do código que controla o sistema e realiza
a computação e lógica envolvida.
4. Verificação e Integração (Verificação): verificação da satisfação dos requisitos
iniciais pelo produto produzido.

Ao contrário do que possa parecer não existe uma sequência obrigatória de fases,
sendo que diversos autores apontam a natureza não simultânea das fases como
uma realidade na aplicação de processos de software, e também defendem que o
processo de software é muito mais iterativo e cíclico do que a ideia de fases
simples pode sugerir.[6]

Atividades do Processo de Software

Em cada fase de um processo de software definido são executadas as atividades
básicas para que sejam atingidos os objetivos propostos. Segundo Pressman[2]
estas atividades constituem um conjunto mínimo para se obter um produto de
software.

Realizando uma combinação de classificações dadas por Schwartz[5] , Pressman[2]

e Sommerville[1] podemos identificar as seguintes atividades[6]:

1. Especificação
1. Engenharia de Sistema: estabelecimento de uma solução geral para o
problema, envolvendo questões extra software.
2. Análise de Requisitos: levantamento das necessidades do software a ser
implementado. A Análise tem como objetivo produzir uma especificação de
requisitos, que convencionalmente é um documento.

http://www.macoratti.net/proc_sw1.htm 2/12
07/04/2017 O processo de Software

3. Especificação de Sistema: descrição funcional do sistema. Pode incluir um

plano de testes para verificar adequação.
2. Projeto
1. Projeto Arquitetural: onde é desenvolvido um modelo conceitual para o
sistema, composto de módulos mais ou menos independentes.
2. Projeto de Interface: onde cada módulo tem sua interface de comunicação
estudada e definida.
3. Projeto Detalhado: onde os módulos em si são definidos, e possivelmente
traduzidos para pseudocódigo.
3. Implementação
1. Codificação: a implementação em si do sistema em uma linguagem de
computador.
4. Validação
1. Teste de Unidade e Módulo: a realização de testes para verificar a presença
de erros e comportamento adequado a nível das funções e módulos básicos
do sistema.
2. Integração: a reunião dos diferentes módulos em um produto de software
homogêneo, e a verificação da interação entre estes quando operando em
conjunto.
5. Manutenção e Evolução
1. Nesta fase, o software em geral entra em um ciclo iterativo que abrange
todas as fases anteriores.

Desta forma as atividades relacionadas a um processo de software estão diretamente

vinculadas com a produção do software como produto final . Afim de especificar quais
atividades devem ser executadas e em qual ordem temos diversos modelos de
desenvolvimento de software.

Modelos de Processo de Desenvolvimento de Software

Os modelos de processos de desenvolvimento de software surgiram pela necessidade de
dar resposta às situações a analisar, porque só na altura em que enfrentamos o
problema é que podemos escolher o modelo.

Nos modelos de processo de software é dado uma atenção especial à representação

abstrata dos elementos do processo e sua dinâmica, não estabelecendo métodos de
desenvolvimento, pois este trabalha num nível mais alto de abstração do que os
modelos de ciclo de vida.WWW[7]

A seguir descrevemos os principais modelos :

http://www.macoratti.net/proc_sw1.htm 3/12
07/04/2017 O processo de Software

O modelo Cascata
Modelo idealizado por Royce em 1970 , também conhecido como abordagem ‘top‐down’
, tem como principal característica a sequência de atividades onde cada fase
transcorre completamente e seus produtos são vistos como entrada para uma nova
fase. Sofreu diversas ajustes e aprimoramentos sendo muito utilizado nos dias atuais.

Descrição Visual do Modelo

A ideia principal do modelo é que as diferentes etapas de desenvolvimento seguem

uma sequência, ou seja,

a saída da primeira etapa "fluí" para a segunda etapa e a saída da segunda etapa "fluí"
para a terceira e assim por diante. As atividades a executar são agrupadas em tarefas,
executadas sequencialmente, de forma que uma tarefa só poderá ter início quando a
anterior tiver terminado. Uma das vantagens do modelo é que só avança para a tarefa
seguinte quando o cliente valida e aceita os produtos finais da tarefa atual.

O modelo pressupõe que o cliente participa ativamente no projeto e que sabe muito
bem o que quer. Este modelo minimiza o impacto da compreensão adquirida no decurso
de um projeto, uma vez que se um processo não pode voltar atrás de modo a alterar os
modelos e as conclusões das tarefas anteriores, é normal que as novas ideias sobre o
sistema não sejam aproveitadas. Numa tentativa de resolver este tipo de problema foi
definido um novo tipo de processo baseado no clássico em cascata, designado por
modelo em cascata
http://www.macoratti.net/proc_sw1.htm 4/12
07/04/2017 O processo de Software

revisto, cuja principal diferença consiste em prever a possibilidade de a partir de

qualquer tarefa do ciclo se poder regressar a uma tarefa anterior de forma a
contemplar alterações funcionais e/ou técnicas que

entretanto tenham surgido, em virtude de um maior conhecimento que entretanto se

tenha obtido. O risco desta abordagem é que, na ausência de um processo de gestão do
projeto e de controlo das alterações bem definido, podemos passar o tempo num ciclo
infinito, sem nunca se atingir o objetivo final, ou seja disponibilizar o sistema a
funcionar.[8]

As desvantagens deste modelo são :

Dificuldade em acomodar mudanças depois que o processo está a ser

executado;
Partição inflexível do projeto em estágios distintos;
Dificuldade em responder a mudanças dos requisitos;
É mais apropriado quando os requisitos são bem compreendidos;
Os projetos reais raramente se adaptam ao modelo linear e sequencial;
É difícil capturar os requisitos de uma só vez;
Cliente tem de pacientemente esperar o resultado final;
Os programadores são frequentemente atrasados sem necessidade;
Alto custo de correção das especificações quando nas fases de Teste e
Implantação.

Modelo Espiral
Neste modelo o projeto é atacado como uma série de pequenos ciclos, cada um
finalizando um versão de um software executável.

O modelo em espiral foi proposto por Boehm em 1988 como forma de integrar os
diversos modelos existentes à época, eliminando suas dificuldades e explorando seus
pontos fortes. Este modelo foi desenvolvido para abranger as melhores características
tanto do ciclo de vida clássico como da prototipação, acrescentando, ao mesmo tempo,
um novo elemento ‐ a análise de riscos ‐ que falta a esses paradigmas.

Entretanto a integração não se dá através da simples incorporação de características

dos modelos anteriores. O modelo em espiral assume que o processo de
desenvolvimento ocorre em ciclos, cada um contendo fases de

avaliação e planejamento, onde a opção de abordagem para a próxima fase (ou ciclo) é
determinada. Estas opções podem acomodar características de outros modelos.

http://www.macoratti.net/proc_sw1.htm 5/12
07/04/2017 O processo de Software

O modelo original em espiral organiza o desenvolvimento como um processo iterativo

em que vários conjuntos de quatro fases se sucedem até se obter o sistema final. Um
ciclo se inicia com a determinação de

objetivos, alternativas e restrições (primeira tarefa) onde ocorre o comprometimento

dos envolvidos e o estabelecimento de uma estratégia para alcançar os objetivos. Na
segunda tarefa, análise e avaliação de alternativas, identificação e solução de riscos,
executa‐se uma análise de risco.Prototipação é uma boa ferramenta para tratar riscos.
Se o risco for considerado inaceitável, pode parar o projeto. Na terceira tarefa ocorre
o desenvolvimento do produto. Neste quadrante pode‐se considerar o modelo cascata.
Na quarta tarefa o produto é avaliado e se prepara para iniciar um novo ciclo.

Variações do modelo espiral consideram entre três e seis tarefas ou setores da espiral,
que podem ser:

‐ comunicação com o cliente;

‐ planejamento;
‐ análise de risco;
‐ engenharia;
‐ construção e liberação;
‐ avaliação do cliente.

O modelo espiral é, atualmente a abordagem mais realística para desenvolvimento de

software em grande escala, e usa uma abordagem que capacita a empresa que presta o
serviço, e o cliente a entender e reagir aos riscos em cada etapa evolutiva. Este tipo

http://www.macoratti.net/proc_sw1.htm 6/12
07/04/2017 O processo de Software

de modelo exige considerável experiência na determinação de riscos e depende dessa

experiência para ter sucesso, pode ser difícil convencer os clientes que uma
abordagem evolutiva é controlável.

Vantagens deste modelo

modelo em espiral permite que ao longo de cada iteração se obtenham versões do

sistema cada vez mais completas, recorrendo à prototipagem para reduzir os
riscos.

Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em

cascata, mas que incorpora um enquadramento iterativo que reflete, de uma
forma bastante realística, o processo de desenvolvimento.

Desvantagens

Pode ser difícil convencer grandes clientes ( particularmente em situações de

contrato) de que a abordagem evolutiva é controlável.

A abordagem deste tipo de modelo exige considerável experiência na avaliação

dos riscos e baseia‐se nessa experiência para o sucesso. Se um grande risco não
for descoberto, poderão ocorrer problemas.

Este tipo de modelo é relativamente novo e não tem sido amplamente usado.

É importante ter em conta que podem existir diferenças entre o protótipo e o

sistema final. O protótipo pode não cumprir os requisitos de desempenho, pode
ser incompleto, e pode refletir somente alguns aspectos do sistema a ser
desenvolvido.

O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas

partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é
necessário o uso de técnicas específicas para estimar e sincronizar
cronogramas, bem como para determinar os indicadores de custo e progresso
mais adequados.

Modelo de do processo de desenvolvimento iterativo e

incremental
Este modelo é uma extensão do modelo espiral sendo porém mais formal e rigoroso.

http://www.macoratti.net/proc_sw1.htm 7/12
07/04/2017 O processo de Software

O desenvolvimento de um produto comercial de software é uma grande tarefa que pode

ser estendida por vários meses, possivelmente um ano ou mais.Por isso, é mais prático
dividir o trabalho em partes menores ou iterações.Cada iteração resultará num
incremento.

Iterações são passos em fluxo de trabalho e incrementos são crescimentos do produto.

O princípio subjacente ao processo incremental e iterativo é que a equipa envolvida

possa refinar e alargar paulatinamente a qualidade, detalhe e âmbito do sistema
envolvido.

Por exemplo, numa primeira iteração deve‐se identificar a visão global e determinar a
viabilidade econômica do sistema, efetuar a maior parte da análise e um pouco de
desenho e implementação.Numa segunda geração,

deve‐se concluir a análise, fazer uma parte significativa do desenho e um pouco mais
de implementação.

Numa terceira iteração, deve‐se concluir o desenho, fazer‐se parte substancial da

implementação, testar e integrar um pouco, etc. Ou seja, a principal consequência da
aproximação iterativa é que os produtos finais de todo o processo vão sendo
amadurecidos e completados ao longo do tempo, mas cada iteração produz sempre um
conjunto de produtos finais.

A cada iteração são realizadas as seguintes tarefas:

‐ Análise (refinamento de requisitos, refinamento do modelo conceitual)

‐ Projeto (refinamento do projeto arquitetural, projeto de baixo nível)
‐ Implementação (codificação e testes)
‐ Transição para produto (documentação, instalação, ...)

http://www.macoratti.net/proc_sw1.htm 8/12
07/04/2017 O processo de Software

Vantagens do
processo incremental e iterativo

‐ Possibilidade de avaliar mais cedo os riscos e pontos críticos do projeto, e identificar

medidas para os eliminar ou controlar;
‐ Redução dos riscos envolvendo custos a um único incremento.Se a equipa que
desenvolve o software precisar repetir a iteração, a organização perde somente o
esforço mal direcionado de uma iteração,
não o valor de um produto inteiro;
‐ Definição de uma arquitetura que melhor possa orientar todo o desenvolvimento;
‐ Disponibilização natural de um conjunto de regras para melhor controlar os
inevitáveis pedidos de alterações futuras;
‐ Permite que os vários intervenientes possam trabalhar mais efetivamente pela
interação e partilha de comunicação daí resultante;

Modelo de Prototipagem
O modelo de desenvolvimento baseado na prototipação procura suprir duas grandes
limitações do modelo cascata. De acordo com Jalote[6] a ideia básica deste modelo é
que ao invés de manter inalterado os requisitos durante o projeto e codificação, um
protótipo é desenvolvido para ajudar no entendimento dos requisitos. Este
desenvolvimento passa por um projeto , codificação e teste, sendo que cada uma
destas fases não é executada formalmente. Usando assim os protótipos o cliente pode
entender melhor os requisitos do sistema.

A sequência de eventos deste modelo esta exibido na figura abaixo:

http://www.macoratti.net/proc_sw1.htm 9/12
07/04/2017 O processo de Software

O protótipo é desenvolvido com uma versão inicial do documento de especificação dos

requisitos. Depois do protótipo estar pronto o cliente o utiliza e baseado na sua
avaliação do cliente é fornecido ao as impressões do que precisa ser alterado, o que
esta faltando e o que não é preciso. O protótipo é então modificado incorporando as
sugestões de mudança e o cliente usa o protótipo novamente repetindo o processo até
que o mesmo seja válido em termos de custo e tempo. No final os requisitos iniciais
são alterados para produzir a especificação final dos requisitos. [9]

Segundo Pressman e Jalote este modelo pode trazer os seguintes benefícios:

O modelo é interessante para alguns sistemas de grande porte nos quais

representem um certo grau de dificuldade para exprimir rigorosamente os
requisitos
È possível obter uma verão do que será o sistema com um pequeno investimento
inicial
A experiência de produzir o protótipo pode reduzir o custo das fases posteriores
A construção do protótipo pode demonstrar a viabilidade do sistema.

Questões a serem consideradas quanto a utilização do modelo:

A Prototipação deve ser utilizada apenas quando os usuários podem participar

ativamente no projeto
Não descuidar de uma boa análise que deve ser conduzida durante todo o processo
de prototipação
Esclarecer aos usuários que o desempenho apresentado pelo protótipo não
necessariamente será o mesmo do sistema final
Evitar que o sistema final seja um protótipo em que foram implementados todos
os requisitos especificados, pois corre‐se o risco de ter‐se um sistema mal
implementado, uma vez que as técnicas utilizadas para desenvolver um protótipo

http://www.macoratti.net/proc_sw1.htm 10/12
07/04/2017 O processo de Software

são diferentes daquelas utilizadas na implementação de um sistema (relaxamento

de regras de negócio, manipulação de exceções etc)
Durante a etapa de prototipação, documentar todos os pontos levantados e
implementados no protótipo, que não constavam dos requisitos iniciais, para
incluí‐los na documentação final

Conclusão
Não existe um processo correto ou incorreto , como não existe um modelo de
desenvolvimento que seja a panacéia universal para o problema do desenvolvimento de
software.

Dependendo de sua aplicação , ambiente e objetivo , a utilização de um processo ou

modelo específico pode ser vantajoso ou não. Cabe a cada organização avaliar o seu
problema com cuidado e usar os modelos apresentados como um guia para o
desenvolvimento do seu próprio processo de desenvolvimento.

Referências:

Veja os Destaques e novidades do SUPER DVD

Visual Basic (sempre atualizado) : clique e
confira !

Quer migrar para o VB .NET ?

Veja mais sistemas completos para a

plataforma .NET no Super DVD .NET ,
confira...

Curso Básico VB .NET ‐ Vídeo Aulas

Quer aprender C# ??

Chegou o Super DVD C# com exclusivo

material de suporte e vídeo aulas com
curso básico sobre C#.

Curso C# Basico ‐ Video Aulas

             Gostou ?   Compartilhe no Facebook   Compartilhe no Twitter

 

http://www.macoratti.net/proc_sw1.htm 11/12
07/04/2017 O processo de Software

Referências:

Seção VB .NET do Site Macoratti.net

Super DVD .NET ‐ A sua porta de entrada na plataforma .NET
Super DVD Vídeo Aulas ‐ Vídeo Aula sobre VB .NET, ASP .NET e C#
Seção C# do site Macoratti.net
Super DVD C#
Super DVD Visual Basic
Curso Básico VB .NET ‐ Vídeo Aulas
Curso C# Básico ‐ Vídeo Aulas
Estudo de Caso de Aplicação da Métrica de Pontos de Casos de Uso
Medição de Pontos por Função a Partir da Especificação de Requisitos
Quanto vale o software que você produz ?
VB.NET ‐ Estimativa de tamanho e  preço com Análise de Pontos de Função ‐ APF
Pontos de Função ou Pontos por Caso de Uso? Como Estimar Projetos ...
[1] SOMMERVILLE, I. Software engineering. 5th. ed. Addison‐Wesley, 1995.
[2] PRESSMAN, R. S. , Software engineering: A practitioner's approach. 4th. ed.
McGraw‐Hill, 1997. p. 22‐53.
[3] Falbo, Ricardo A., Integração de Conhecimento em um Ambiente de
Desenvolvimento de Software. Tese de Doutorado, COPPE/UFRJ, Rio de Janeiro,
Brasil, 1998.
[4] Humphrey, Watts S., Managing the Software Process. Addison‐Wesley
Publishing,Company, Massachussets, 1990.
[5] SCHWARTZ, J. I. ,Construction of software. In: Practical Strategies for
Developing Large Systems. Menlo Park: Addison‐Wesley, 1st. ed., 1975.
[6] Christian Reis . , Caracterização de um Modelo de Processo para Projetos de
Software Livre .teste de mestrado.Instituto de Ciências Matemática e
Computação. São Carlos, São Paulo Abril de 2001
WWW[7] http://www.administradores.com.br/colunas_membro.jsp?
idColuna=233&idColunista=555 ‐ Glaucia Gabriel Sass ‐ O Processo de
Desenvolvimento Baseado em Componentes: O impulso das novas tecnologias ,
acessado em 19 de agosto de 2005.

José Carlos Macoratti

http://www.macoratti.net/proc_sw1.htm 12/12