ENGENHARIA DE SOFTWARE I

Unidade II
3 PROCESSO DE SOFTWARE

3.1 Conceitos preliminares

Weber et al. ([s.d.]), no artigo escrito para apresentar os resultados alcançados e as lições aprendidas
com a implantação do modelo MPS.BR de melhoria do processo de software brasileiro, afirmam:

Hoje, todos (no governo, academia e indústria) reconhecem a importância

da melhoria dos processos de software para a competitividade, qualidade
e produtividade sistêmica do setor de software brasileiro; mas poucos têm
ideia da magnitude, complexidade e duração do esforço quando se trata de
superar este desafio em um país com as dimensões e características do Brasil
(WEBER et al, [s.d.]).

Para tratar especificamente dos processos de software, é muito importante localizá-los no contexto
da engenharia de software.

Como já foi visto, a engenharia de software estuda e propõe soluções que abrangem todo o ciclo
de vida de um produto de software. Para isso, deve incluir diversas facetas que se apresentam nesse
contexto.

A figura a seguir apresenta uma visão holística, em forma de pilares, do desenvolvimento de software,
que abrange todos os aspectos envolvidos nos modelos de engenharia de software.

Ciclo de vida de software (visão da ES)

Métodos/Técnicas

Gerenciamento
Ferramentas

Qualidade
Processos

Figura 4 – Visão holística do ciclo de vida do software

Os pilares verticais apresentados na figura representam os principais aspectos envolvidos com o

desenvolvimento e a manutenção de software, obtidos a partir de livros, materiais didáticos e modelos
da engenharia de software e definidos conforme a seguir.

45
 Unidade II

• Processos de software:

— são o estudo, os conhecimentos adquiridos e as práticas que apoiam as atividades envolvidas

com o desenvolvimento e a manutenção de software durante toda a vida de um determinado
produto de software;

— precisam ser descritos, normatizados e divulgados para todas as pessoas da organização

envolvidas com software;

— têm como resultado do processo de software o produto de software, constituído de códigos

programados que formam um sistema de informação, que é considerado o elemento central, já
que realiza estruturas complexas e flexíveis que fornecem funções, utilidade e valor ao sistema;

— incorporam as pessoas, os documentos e as regras de execução de suas atividades, inclusive,

determinando as responsabilidades na sua execução.

• Métodos e técnicas:

— as atividades de um processo de software envolvem conhecimento na sua execução, disciplina

e padrões predefinidos;

— para isso, a engenharia de software propõe um conjunto de técnicas e métodos para que os
desenvolvedores consigam executar suas tarefas com o máximo de produtividade e qualidade.

• Ferramentas:

— ao longo de quarenta anos, e ainda em evolução, têm surgido ferramentas de automação que
dão suporte às atividades do processo de software;

— ferramentas para desenho, descrições, testes de software e, principalmente, para os trabalhos

colaborativos entre as equipes de desenvolvimento.

• Qualidade:

— com a pressão cada vez maior pela qualidade nos produtos de software, a engenharia de
software vem propondo e desenvolvendo diversos modelos para a garantia da qualidade, tanto
no nível dos processos quanto no dos produtos desenvolvidos e mantidos dentro das áreas de
software das organizações.

• Gerenciamento:

— são todas as propostas para a gestão da área de software e para os projetos de software. A
grande procura é pelo aumento da eficiência no uso dos recursos e na eficácia na produção de
sistemas de informação;
46
ENGENHARIA DE SOFTWARE I

— atualmente a gestão ou o gerenciamento de software vem atuando, também, no nível de

governança, criando modelos e aplicando práticas próprias ou oriundas de outras áreas da
engenharia que têm sucesso registrado e provado nos últimos tempos;

— diversos aspectos do gerenciamento são abrangidos por esse pilar: gerência de equipe, gerência
de projetos, gerência da qualidade, governança de TI etc.

Esses pilares se inter-relacionam e trabalham juntos (ou de forma paralela) na busca das melhores
práticas nos processos de software, como mostra a figura 5.

Métodos e técnicas

Processo de
desenvolvimento

Gerenciamento Ferramentas

Qualidade de
software

Figura 5 – Relação dos pilares de sustentação da engenharia de software

Lembrete

Dominar o ciclo de vida de software significa conhecer todos os pilares

e suas funcionalidades. A complexidade está em trabalhar ao mesmo tempo
nos projetos executando os diversos papéis que permeiam esse modelo.

Um aspecto importante a ser considerado é que o desenvolvimento de software envolve empresas

de todos os tamanhos e quantidades de recursos disponibilizados.

Os modelos brasileiros têm, ao longo do tempo, dado especial atenção às pequenas empresas de
software, em virtude da seguinte constatação: as pequenas empresas de desenvolvimento de software
possuem poucos recursos financeiros para investir na utilização das melhores práticas do mercado;
diante disso, perdem competitividade no mercado nacional e no internacional, e deixam de atender a
padrões de qualidade.

Uma das alternativas que o mercado vem implementando é o uso de métodos ágeis que foram
desenvolvidos exatamente para atender aos pequenos projetos e para pequenas equipes de
desenvolvimento. Esses métodos procuram deixar os processos de software mais simples, menos
burocráticos, porém não menos organizados, com o intuito de se construir softwares de forma mais
47
 Unidade II

rápida e com grande qualidade. A garantia de que as empresas praticam processos com qualidade tem
advindo dos processos de certificação, tanto nacionais como internacionais.

Saiba mais

Existem diversas certificações, tanto para empresas quanto para

profissionais de software, tais como: certificação em teste de software do
Instituto IBQTS; certificações das normas ISO para as empresas da ABNT em
processos de qualidade de software, como o CMMI-DEV, do SEI americano,
e o modelo nacional de melhoria de processos MPS.BR etc.

Todas essas organizações possuem portais disponibilizados na internet,

que podem ser acessados para busca de maiores detalhes a respeito:

<http://www.abnt.org.br>.

<http: www.ibqts.com.br>.

<http://www.sei.cmu.edu/>.

<http://www.softex.br/mpsbr/>.

3.2 Etapas do processo de software

Como acontece com todo produto industrial, o software tem um ciclo de vida que possui os seguintes
elementos ou fases:

• é concebido a partir da percepção das necessidades de uma área da organização ou de clientes-

usuários, partindo de uma realidade;

• é desenvolvido, transformando-se em um conjunto de itens entregáveis ao cliente ou ao usuário

final;

• entra em operação, sendo utilizado dentro de algum processo de negócio, por um tempo
indeterminado, e podendo sofrer evoluções ao longo do tempo;

• é retirado de operação, ao final de sua vida considerada útil.

O esquema a seguir mostra uma visão do ciclo de vida de um produto de software que segue os
mesmos princípios do ciclo de vida de qualquer produto da manufatura ou industrial.

48
ENGENHARIA DE SOFTWARE I

Decadência
Evolução
Criação

Figura 6 – Visão do ciclo de vida de produtos de software

No ciclo criação ocorre o desenvolvimento de uma aplicação ou de um sistema de informação.

Existem diversas metodologias e modelos para representar esse ciclo inicial de software. Este possui um
tempo predeterminado para ocorrer e é dependente do planejamento do software a ser construído.

No ciclo evolução ocorre a alteração de um produto de software existente. Inclui melhorias,

novas funcionalidades ou necessidades de adaptação para novas tecnologias. Não existe um tempo
predeterminado para acontecer evolução em um produto de software, e isso vai depender do tipo de
sistema, das funcionalidades às quais ele atende e/ou de eventos aleatórios que acontecem ao longo do
ciclo de vida do produto.

O ciclo decadência ocorre quando o produto de software atingiu um ponto em que não existem mais
possibilidades para sua evolução. Ele entra em decadência por diversos motivos, tais como: obsolescência
da tecnologia, mudanças de regras de negócio, mudanças radicais nas regras dos órgão públicos etc.

O ciclo de vida do software apresentado na figura pode, ainda, ser dividido em diversas etapas
detalhadas, e cada modelo existente, norma certificadora e/ou autor do mercado apresenta uma visão
diferenciada dessas divisões.

O quadro 3 apresenta visão típica da estrutura do ciclo de vida de um processo de software, mas que
não necessariamente seria apresentada por outros autores ou modelos existentes.

Quadro 3 – Visão do ciclo de vida de um produto de software

Percepção das necessidades do cliente ou usuário final (requisitos do software)
Concepção (análise do software – modelagem)
Elaboração (definição da arquitetura do software)
Desenho inicial
Desenho detalhado
Implementação Codificação
Desenvolvimento Construção
Teste de unidade
Testes de integração
Transição (entregas parciais e testes de homologação pelo cliente/
usuário final)
Operação (utilização do software pelo cliente-usuário)
Manutenção (melhorias do software e acertos de defeitos)
Retirada (troca ou cancelamento do produto de software)

49
 Unidade II

Algumas considerações devem ser feitas sobre o processo de desenvolvimento de um produto de

software:

• o desenvolvimento de software deve ser feito por profissionais treinados e capacitados em

engenharia de software e deve ocorrer dentro do conceito de projetos;
• todo projeto de software deve ter uma data de início e uma de fim, uma equipe alocada e outros
recursos de apoio, tais como arquitetos de sistemas, analistas de negócio, administradores de
banco de dados, testadores etc.;
• o cronograma do projeto deve ser feito a partir de métricas de estimativas e representa a execução
de um processo de software;
• todo processo bem-definido tem subdivisões que permitem avaliar o andamento de um projeto e
corrigir seus rumos quando ocorrerem problemas;
• todas as etapas e atividades do processo de software devem ser terminadas por meio de marcos
predefinidos. Esses marcos são pontos de controle que representam estados significativos do projeto;
• geralmente os marcos são associados a resultados concretos, como documentos, modelos ou
porções do produto, que fazem parte do conjunto prometido ao cliente ou têm apenas utilização
interna ao projeto;
• o próprio produto final, o software propriamente dito, é um resultado associado ao marco de
conclusão do projeto.

Saiba mais
Não deixe de ler:
PEZZÉ, M.; YOUNG, M. Teste e análise de software: processos, princípios
e técnicas. Porto Alegre: Bookman, 2008.
Nesse livro, os autores fazem um estudo profundo com relação ao
processo de teste de software e às diversas técnicas que permitem a
melhoria de sua qualidade.
PRADO, J. C. S. Gerenciando a qualidade de software com base em
requisitos. Rio de Janeiro, [s.d.]. Disponível em: <http://www-di.inf.puc-rio.
br/~julio/Slct-pub/Livro-qualidade.pdf>. Acesso em: 31 mar. 2014.
Nesse ensaio, o autor discute a obtenção da qualidade no
desenvolvimento de software. O autor faz uma análise do capítulo 17 do
livro Qualidade de Software, de Rocha, Maldonado e Weber (2001), que dá
uma visão simples e clara sobre os problemas e as alternativas na busca da
qualidade em software.
50
ENGENHARIA DE SOFTWARE I

Fechando o entendimento de processo de software, a próxima figura apresenta todos os aspectos

envolvidos com o ciclo de vida de software.
Construção
Construção
Processo de
construção de
software Artefatos Nível abstração
Produtos
Controle
do Alto
sistema

Processo de
gestão de
software Médio

Baixo

Pessoas, Notação/linguagens
organização, Ferramentas (automação)
cultura

Processo de qualidade

Figura 7 – Visão holística do processo de software

O subprocesso de construção é apresentado em camadas que indicam o nível de entendimento e

abstração com relação aos domínios da tecnologia envolvida no processo. Quanto mais se desce nos
níveis de conhecimento específico das tecnologias, mais os desenvolvedores deverão ter entendimento,
e quanto mais alto nos níveis, maior será a necessidade de conhecimento do negócio.

3.3 Processo Pessoal de Software (PSP)

Para um entendimento dos processos de software apresentados a seguir, é interessante observar

como o Software Engineering Institute (SEI) os organiza. Essa visão é apresentada na figura a seguir.

Modelo CMMI voltado para a

capacitação organizacional Organização

Modelo TSP voltado para a

capacitação de equipes ou Time 1 Time 2
times de desenvolvimento de
software
Modelo PSP voltado para a
capacitação de indivíduos

Figura 8 – Visão dos processos como entendido pelo SEI

51
 Unidade II

De acordo com Maldonado e Fabbri (2001):

• seguindo um modelo de gerenciamento de processos de software, as organizações têm alcançado

melhorias significativas nos seus processos e modos de trabalho, e muitas perceberam que, para
obter índices melhores, dependem do talento individual de seus funcionários;
• como um grande modelo de qualidade tipo ISO 15504 ou Capability Maturity Model Integration
(CMMI) poderia ser aplicado no trabalho individual ou em pequenas equipes de projeto, em que
os profissionais de software pudessem, individualmente, aplicar princípios do nível máximo de
capacidade e maturidade almejados?
• surge, então) a proposta do Personal Software Process – PSP (2009), de propriedade do Instituto
de Engenharia de Software (SEI – Software Engineering Institute), como recurso para melhoria e
otimização do processo individual de trabalho.

O modelo PSP (2009) sugere práticas e métodos para que o próprio indivíduo consiga identificar e
corrigir seus pontos fracos. É uma sugestão para organizar e disciplinar os processos individuais e não
diminui nem restringe a capacidade criativa dos indivíduos.

O modelo foi originalmente derivado do modelo de qualidade Capability Maturity Model (CMM), e
o autor desse processo é o mesmo, Whatts Humphrey, que adaptou 12 das 18 áreas-chave de processo
CMM (Key Process Area – KPA) da época ao trabalho individual de profissionais de software. Aplica
conceitos importantes de engenharia de software em nível individual para desenvolver softwares, e não
apenas para codificar programas.

O modelo PSP (2014) faz uso de um conjunto de sete etapas sequenciais e progressivas, cada uma
com um conjunto de roteiros, formulários e gabaritos associados. É apoiado por um livro-texto e um
curso introdutório oferecido por esse mesmo livro (exercícios de programação e relatórios), principal
veículo de aprendizado.

De acordo com Humphrey, autor do PSP, à medida que os profissionais de desenvolvimento de software
aprendem a avaliar seus trabalhos, a analisar essas medidas e a definir e atingir metas de melhoria, passam a
enxergar os benefícios de usar o processo definido e são motivados constantemente a isso.

Observação
De acordo com o SEI (2014), a qualidade de um software é governada
pelo indivíduo que o desenvolve (rotinas ou componentes) e exige
conhecimento, disciplina e comprometimento.

O modelo PSP tem os seguintes objetivos básicos:

• demonstrar os princípios do processo individual;

• determinar a situação do processo atual de software individual;
52
ENGENHARIA DE SOFTWARE I

• elaborar um processo de planejamento para desenvolvimento de software;

• medir o tamanho do software, como parte do processo de planejamento;
• fazer uma estimativa antecipada do tamanho do software;
• fazer uma estimativa do cronograma e dos recursos necessários para o software;
• realizar medições apropriadas do processo individual;
• fazer revisões significativas de projeto e código;
• executar gerenciamento da qualidade do software;
• executar projeto de software de modo mais formal;
• verificar o projeto usando métodos como máquinas de estados finitos e rastreamento de programa;
• aumentar a escala de PSP para problemas maiores;
• ajudar a elaborar planos mais precisos;
• determinar as etapas necessárias para melhorar a qualidade do produto;
• estabelecer um padrão de referência para se medir as melhorias do processo pessoal;
• determinar o impacto das mudanças sobre a eficiência profissional.

A figura a seguir apresenta a estrutura visual do modelo PSP (2009).

Processo cíclico
PSP3
Desenvolvimento cíclico

Qualidade pessoal
PSP 2.1
PSP 2 Gabaritos de projeto
Revisões de código
Revisões de projeto

Planejamento pessoal
PSP 1.1
PSP1 Planejamento de tarefa
Estimativa de tamanho Planejamento deescalonamento
Relatório de teste

Medição pessoal
PSP 0.1
Padrão de codificação
PSP 0 Medição de tamanho
Processo atual Proposta de melhoramento do processo
Registro de tempos e defeitos

Figura 9 – A evolução do processo PSP (2009)

53
 Unidade II

O PSP 0 representa o processo de construir software que permanece o mesmo. Os profissionais de

software aprendem a aplicar os formulários e roteiros do PSP aos seus trabalhos pessoais, medindo
tempo e defeitos de desenvolvimento, defeitos estes injetados ou removidos.

O PSP 0.1 adiciona um padrão de codificação, medição de tamanho e formulário de proposta de

melhoramento do processo (PMP). Os profissionais de software registram no PMP os problemas, os tópicos
importantes para discussão e argumentação e as ideias a serem usadas futuramente, aperfeiçoando,
assim, os seus processos pessoais.

O PSP 1 introduz o Proxy-Based Estimating Method (Método PROBE) para estimar tamanhos e
tempos de desenvolvimento para novos programas, com base nos próprios dados individuais, utilizando
regressão linear para calcular parâmetros de estimativa e gerar intervalos de confiança para indicar a
qualidade dessa estimativa de tamanhos e tempos.

Já no PSP 1.1, adicionam-se o escalonamento e o planejamento de tarefas.

O PSP 2 introduz o gerenciamento de defeitos. Com esses dados reunidos previamente, os profissionais
de software constroem e usam listas de verificação para revisão de projeto e código (checklists).

O PSP 2.1 introduz as técnicas de especificação de projeto e análise em acréscimo à prevenção de

defeitos, análise e comparação de processos. Os profissionais de software aprendem a avaliar e melhorar
a eficiência individual.

No PSP 3, os profissionais de software combinam múltiplos PSP 2.1, de uma forma cíclica, para
construir módulos com milhares de linhas de código (Kilo Lines of Code – KLOC). Exploram os métodos
de verificação de projeto, assim como os princípios e métodos de definição de processo.

Lembrete

O PSP, diferentemente do CMMI, que atua no nível de ambiente

organizacional (áreas de processos), equipa os profissionais para fazerem
tal trabalho de alta qualidade e para participarem ativamente no
melhoramento do processo de software da organização.

No paradigma do PSP, cada desenvolvedor estabelece metas pessoais, define os métodos que usará,
mede seu trabalho, analisa seus resultados e os ajusta para se aproximar das metas. O PSP tem sido
usado com sucesso em atividades pessoais estruturadas, tais como escrever um livro e desenvolver um
autotreinamento.

De acordo com o PSP (2009) é muito útil, caso seja empregado em conjunto com o modelo de
qualidade CMMI. Tem mostrado resultados significativos:

• aumento de 30% na produtividade;

54
ENGENHARIA DE SOFTWARE I

• precisão em estimativas aumentada para +/- 10%;

• injeção de erros/defeitos no desenvolvimento reduzido em 60%;

• erros/defeitos, encontrados no teste de unidade, reduzidos em 75%.

Observação

Como conclusão, pode-se dizer que o PSP é um processo definido para

ajudar o desenvolvedor a fazer melhor o seu trabalho, bem como a ajustá-
lo e estendê-lo para atender às suas necessidades futuras.

Saiba mais

O modelo PSP é de propriedade do Instituto de Engenharia de Software

ou Software Engineering Institute (SEI).

Para saber mais, acesse o site, disponível em:<http://www.sei.cmu.edu>.

3.4 Processo para equipe de software (TSP)

O Team Software Process (TSP) (2010), de acordo com o SEI, significa um guia ou framework para:

• planejar e gerenciar um projeto em equipe;

• processos definidos;

• papéis distribuídos;

• princípios de teamwork e teambuilding;

• baseado no PSP;

• construído a partir de métodos comprovados de engenharia e trabalho em equipe.

Uma equipe é um grupo de pessoas que deve estar comprometido com um objetivo comum e dispor
de um quadro de trabalho comum; é composta de, no mínimo, duas pessoas, e cada uma tem um papel
específico atribuído. A conclusão da missão requer alguma forma de dependência entre os membros do
grupo.

55
 Unidade II

Para serem eficazes, as equipes devem estar devidamente qualificadas e ser capazes de funcionar
como unidades coesas. Equipes eficazes têm certas características comuns:

• os membros são qualificados;

• o objetivo da equipe é importante, definido, visível e realista;

• os recursos são suficientes para o trabalho;

• os membros estão motivados e empenhados a cumprir o objetivo da equipe;

• os membros cooperam uns com os outros e se apoiam;

• os membros são disciplinados em seu trabalho.

Outra característica das equipes eficazes é sua capacidade de inovar. A inovação é mais do
que pensar somente em ideias brilhantes, já que exige criatividade e muito trabalho. Praticamente
todas as tarefas de engenharia são parte de um esforço inovador, e equipes inovadoras devem
ter pessoas qualificadas e capazes, além de muito motivadas. Elas devem ser criativas, flexíveis e
disciplinadas.

Equipes ou times devem se esforçar para cumprir prazos apertados, enquanto se ajustam às novas
necessidades. Devem também manter os custos e os horários sob controle, mantendo a gerência
informada de seu progresso; são compostas por pessoas que podem sentir falta de confiança no projeto.
Quando os engenheiros não se sentem seguros e respeitados, muitas vezes, sentem-se hostilizados e
manipulados.

Para estabelecer essas condições, são dez as orientações do TSP (2010), no modelo do SEI:

• os membros da equipe estabelecem metas comuns e definem os papéis dos membros;

• a equipe desenvolve uma estratégia;

• os membros da equipe definem um processo comum para o seu trabalho;

• todos os membros participam na elaboração do plano, e cada um sabe o seu papel;

• a equipe negocia o plano com a gerência;

• os membros fazem o trabalho da maneira que planejaram;

• a equipe se comunica livremente e com frequência;

• forma um grupo coeso: os participantes cooperam, e todos estão empenhados em atingir a meta;
56
ENGENHARIA DE SOFTWARE I

• os engenheiros conhecem sua situação, buscam o feedback sobre seu trabalho e têm uma liderança
que sustenta a sua motivação;

• essas condições não são óbvias: o TSP fornece orientação explícita do que as organizações
necessitam para construir equipes de engenharia eficazes.

De acordo com o modelo TSP, cada papel nesse processo é considerado como uma espécie de gerente
e será responsável por uma lista de tarefas. O gerente de desenvolvimento decide o número de iterações
que a equipe precisa executar na construção do software e desenvolve uma estratégia para fabricar
o produto; o gerente de planejamento acompanha as iterações planejadas, para auxiliar a equipe na
estimativa e no balanceamento de carga; o gerente de qualidade produz artefatos como o plano de
gerência de configuração e os testes de aceitação.

O gerente de processo deve ter respostas para a maioria das questões sobre o processo. É responsável
pela alocação de recursos, pela execução de reuniões e pela gerência de riscos, tendo, no entanto,
responsabilidade menor nos demais processos. Ele precisa da participação de diversos atores na
organização: os gerentes, os desenvolvedores, os usuários e os clientes.

O desenvolvimento de software é colaborativo, no sentido de que o trabalho deve ser alinhado e

sintonizado. O objetivo é capacitar a equipe para que se gerencie, distribuindo entre si as responsabilidades
pelas atividades gerenciais e de apoio; deve ocorrer em ciclos incrementais, de forma que mitigue os
riscos de cada um dos ciclos (launch). Para tanto, antes de se lançar no desenvolvimento, a equipe deve
traçar suas estratégias, conhecendo suas forças, disponibilidades e fraquezas, e só depois disso elaborar
o planejamento e a execução de desenvolvimento.

A missão do framework TSP é ser simples e baseado nos fundamentos do PSP, para:

• utilizar o modelo de ciclo de vida incremental (ciclos);

• estabelecer medidas-padrão para qualidade e performance;

• prover métricas precisas para equipes e desenvolvedores;

• usar avaliações de papéis e de equipe;

• requerer disciplina de processo;

• prover orientações para solução de problemas com equipes.

57
 Unidade II

A figura a seguir apresenta uma visão holística dos princípios do modelo TSP.

Equipes
autogerenciáveis

Gerência da Coaching
qualidade (tutorial)
Fatores -
princípios
do TSP

Arcabouço Personal
(framework) Software
de medição Process
integrada (PSP)

Figura 10 – Visão holística dos princípios do TSP

Os princípios-base do TSP são:

• estabelecimento de objetivos e papéis comuns;

• definição de um processo comum de trabalho;

• envolvimento de todos na produção do plano;

• negociação do plano entre o time e a gerência;

• revisão e aceite final pela gerência;

• comunicação livre e frequente;

• exigência de que a pessoa tenha sido previamente treinada em PSP;

• possibilidade de formar a base para a adoção do CMMI.

Com relação aos indicadores, o TSP apresenta um conjunto necessário para a avaliação dos produtos
desenvolvidos pelas equipes de projeto. Os indicadores apresentados pelo modelo são:

• precisão de estimativas;

• intervalos de previsibilidade (tamanho, esforço e defeitos);

• distribuição de esforço e defeitos nas fases;

• remoção de defeitos nas fases;

• produtividade;
58
ENGENHARIA DE SOFTWARE I

• porcentagem de reúso;

• índice de desempenho;

• valor agregado (earned value);

• densidade de defeitos total e por fase;

• eficácia dos filtros de defeitos;

• custo da qualidade;

• perfis de qualidade;

• índice de perfis de qualidade;

• taxas de revisão;

• rendimento do processo;

• rendimento das fases.

Com relação ao processo TSP (2010), o SEI afirma que:

• é baseado na melhoria de processos de uma equipe de desenvolvimento, usando a noção de time

(grupo de pessoas) com o mesmo objetivo;

• provê um conjunto de scripts de processos, formulários, métodos, métricas;

• esses elementos guiam os desenvolvedores a criarem equipes eficazes e estabelecer metas e

planos para a equipe acompanhar e reportar o trabalho.

Para o TSP, o desenvolvimento de software está dividido em oito fases, que estão definidas como:

• lançamento da equipe do projeto;

• desenvolvimento da estratégia;

• desenvolvimento do plano;

• definição dos requisitos;

• design de alto nível;

• implementação;

• testes de integração e de sistema;

• post mortem.
59
 Unidade II

Oferece, ainda, métodos prontos para serem utilizados de forma que não precisem ser reinventados
ou descobertos e possam, portanto, ser reutilizados, diminuindo, assim, o tempo do projeto.

O TSP baseia-se no PSP, utilizando as medidas de tamanho, tempo e defeito, e, ainda, adiciona a data
de término das tarefas.

Para todas as medidas e projeções, os dados são coletados individualmente e, ainda, são analisados
semanalmente pela equipe, para que esta possa ter ideia do andamento do projeto em relação ao seu
plano.

Com relação à estrutura do modelo TSP, tem-se:

• que o primeiro requisito para aplicações do TSP é que cada membro da equipe tenha sido treinado
no PSP;

• que este é o primeiro passo para montar uma equipe de trabalho no TSP;

• o TSP adiciona elementos necessários para que se possa realizar o trabalho em equipe, como
mostrará a próxima figura;

• todos os membros da equipe devem trabalhar para executar uma determinada tarefa, que, no TSP,
são denominadas de lançamentos do time.

A figura que segue apresenta a estrutura do TSP, a partir da proposta do autor Koscianski e Soares
(2007).

PSP TSP TSP

Aquisição de habilidades Construção de times Trabalho de times

Disciplinas de engenharia Disciplinas de times Disciplinas de administração

Planos pessoais Comprometimento Prioridade da qualidade

Métodos de planejamento
Valores aprendidos
Dados de proocesso
Medidas de qualidade
Processos definidos
Planos agressivos
Possessão da qualidade
Objetivos do projeto
Possessão do plano
Detalhamento do plano
Papéis do time
Recursos do time
Custo da qualidade
Respeito dos processos
Revisão de status
Revisão da qualidade
Comunicação
Gerência de mudanças

Times integrados

Figura 11 – Estrutura do TSP da SEI

60
ENGENHARIA DE SOFTWARE I

Como mostra a figura, é necessário que o pessoal tenha formação no PSP antes de dar início à
implantação do modelo TSP. Os engenheiros de software devem ser treinados nas habilidades do PSP
antes que possam participar das equipes ou times do TSP.

Equipes TSP são relançadas periodicamente, pois o processo segue uma estratégia de desenvolvimento
iterativo e evolutivo. Os relançamentos periódicos são necessários para que cada fase ou ciclo possam
ser planejados com base nos conhecimentos adquiridos no ciclo anterior. O relançamento também é
necessário para atualizar os planos dos engenheiros em detalhes, os quais, normalmente, são necessários
apenas por alguns meses.

No lançamento TSP, as equipes fazem um plano global e outro detalhado, por cerca de três a quatro
meses. Após os membros (todos ou a maioria) da equipe terem completado a fase do projeto ou ciclo,
é feita uma revisão do plano global e, se necessário, um novo plano detalhado para cobrir os próximos
três ou quatro meses. Eles são guiados a fazer isso pelo processo de relançamento do TSP.

O lançamento da equipe compreende a fase inicial do processo TSP, na qual são discutidos
vários temas, durante os quatro dias de duração dessa fase. Segundo Koscianski e Soares (2007),
o processo de lançamento é composto por uma série de atividades de planejamento do trabalho
a ser realizado.

Após o lançamento da equipe, é preciso que esta desenvolva uma estratégia de trabalho. Essa etapa
tem como principal objetivo minimizar o risco de o desenvolvimento exceder o tempo programado para
a conclusão do projeto. Para o modelo, definiram-se os seguintes passos:

• no primeiro ciclo de desenvolvimento, deve-se fabricar um produto executável com as funções

mínimas do produto final;

• esse produto, resultante do primeiro ciclo, deve ser uma base para o restante do produto, para que
possa facilmente ser estendida;

• em todos os ciclos, gerar um produto com alta qualidade, permitindo que este possa ser facilmente
testado;

• ter uma arquitetura modular, para que membros da equipe possam trabalhar independentemente.

Com relação ao desenvolvimento do plano, o modelo indica que o planejamento ajuda os engenheiros
da equipe a trabalharem de maneira mais eficiente, com mais produtividade e sem desperdício de tempo.
Além disso, algumas atividades poderão ser esquecidas, se não forem planejadas. Portanto, planejar um
projeto não é uma tarefa muito fácil, pois projetos grandes e complexos consomem muitas horas de
planejamento.

Com a utilização do TSP, é possível analisar a sobrecarga de tarefas de alguns membros da equipe,
enquanto outros estão mais “folgados”. Isso faz aqueles que não estão sobrecarregados terem, em alguns
casos, de esperar pela conclusão do trabalho daqueles sobrecarregados, atrasando, assim, o grupo. Para
61
 Unidade II

resolver esse problema, o TSP propõe que, nessa fase de planejamento, seja feito um balanceamento de
trabalho entre os membros da equipe.

Já na fase de implementação, está definida a etapa de construção das partes do produto, e,

consequentemente, o produto em sua totalidade. O desenvolvimento de cada parte projetada na fase
anterior será, preferencialmente, realizado por quem a projetou. Porém, mesmo que o engenheiro seja
o mais indicado para programá-la, isso pode ser diferente, pois a estratégia que será adotada não é
imposta pelo TSP.

Observação

O SEI (2014) relatou que, antes do TSP, a empresa Teradyne tinha,

nos testes de integração, testes do sistema, testes de campos e testes em
clientes, em média, vinte defeitos por KLOC (mil linhas de código).

O projeto TSP, primeiro, reduziu estes níveis para um defeito por

KLOC (mil linhas de código). Uma vez que o custo médio é de 12 horas de
engenharia para encontrar e corrigir cada defeito, a Teradyne economizou
228 horas de engenharia para cada KLOC de programa desenvolvido.

4 MODELOS DE CICLO DE VIDA DE SOFTWARE

4.1 Introdução a ciclo de vida de software

De acordo com Gordon e Gordon (2006), o ciclo de vida do desenvolvimento de sistemas (Systems
Development Life Cycle – SDLC), conhecido também como ciclo de vida do software, refere-se aos
estágios de concepção, projeto, criação e implementação de um Sistema de Informação (SI). Um
desdobramento possível para SDLC é mostrado na figura a seguir.

Levantamento das
necessidades

Manutenção Análise das alternativas

Implementação Projeto

Desenvolvimento

Figura 12 – Ciclo de vida do desenvolvimento de software (SDLC)

Analisando-se as atividades propostas para o ciclo SDLC, com base em Gordon e Gordon (2006),
tem-se o exposto a seguir.
62
ENGENHARIA DE SOFTWARE I

• Levantamento de necessidades:

— essa atividade compreende diversas tarefas para o entendimento e o levantamento das

necessidades da área de negócio, dos clientes ou dos usuários que precisam de um software de
automação de suas atividades;

— tem como resultados mais importantes a lista de requisitos do sistema a ser construído, as
informações que serão tratadas e armazenadas e, se necessário, um protótipo das interfaces
entre os usuários e o sistema de software.

• Análise de alternativas:

— essa atividade consiste na identificação e na avaliação de alternativas sistêmicas que melhor

atendam aos requisitos do software a ser construído;

— seria interessante, para que essa atividade fosse padronizada e a organização possuísse uma
arquitetura de referência, que a base fosse para todas as soluções de tecnologia de todos os
sistemas da empresa.

• Projeto:

— trata da construção das especificações detalhadas para o projeto selecionado;

— essas especificações incluem projeto das interfaces, banco de dados, características físicas
do sistema, tais como número, tipos e localizações das estações de trabalho, hardware de
processamento, cabeamento e os dispositivos de rede; deve especificar os procedimentos para
testar o sistema completo antes da instalação.

• Desenvolvimento:

— inclui o desenvolvimento ou a aquisição do software, a provável aquisição do hardware e o

teste do novo sistema.

• Implementação:

— ocorre após o sistema ter passado satisfatoriamente por testes de aceitação. O sistema é
transferido do ambiente de desenvolvimento para o ambiente de produção;

— o sistema antigo (se existir) deve migrar para o novo.

• Manutenção:

— refere-se a todas as atividades relacionadas a um sistema depois que ele é implementado,

devendo incluir atividades como a correção de software que não funcione corretamente, a
adição de novos recursos aos sistemas em resposta às novas demandas dos usuários etc.

63
 Unidade II

Observação

Não há modelo de SDLC uniformemente aceito. Alguns combinam

desenvolvimento e implementação em uma única etapa. Outros combinam
o levantamento e a análise das necessidades, também, em uma única etapa.
Alguns modelos dividem o projeto em lógico e físico.

4.2 Os principais modelos de ciclo de vida de software

4.2.1 O modelo codifica-remenda

O modelo codifica-remenda significa um processo de ciclo de vida de software mais caótico.

Partindo apenas de uma especificação ou simplesmente de uma reunião de trabalho, os desenvolvedores
começam imediatamente a codificar, remendando, à medida que os erros vão sendo descobertos. Não
existe nenhum processo definido e nenhum é seguido.

Esse modelo, provavelmente e infelizmente, seja o ciclo de vida mais usado na atualidade. Para
alguns desenvolvedores, ele é atraente porque não exige nenhuma sofisticação técnica ou gerencial.
Todavia, é considerado um modelo de alto risco, impossível de ser gerenciado e que não permite assumir
compromissos confiáveis.

Esse modelo persistiu durante algumas décadas, e, como não existia separação de papéis, todos
faziam um pouco de tudo. Às vezes, uma única pessoa analisava, codificava e testava um sistema inteiro.

Na busca de eliminar os problemas causados pelo método codifica-remenda, foram sendo criadas
as metodologias conhecidas hoje como tradicionais, sendo a mais conhecida a chamada cascata, que é,
também, referida como o modelo clássico de desenvolvimento de software.

4.2.2 O modelo cascata (waterfall)

O modelo clássico ou cascata, que também é conhecido por abordagem top-down, surgiu na década
de 1970. Até meados da década de 1980, foi o único modelo com aceitação geral; derivado de modelos
de atividade de engenharia com o fim de estabelecer ordem no desenvolvimento de grandes produtos
de software. Comparado com outros modelos, este é mais rígido e menos administrativo. Um dos mais
importantes, é referência para muitos outros, servindo de base para projetos modernos. A versão original
desse modelo foi melhorada e retocada ao longo do tempo, e este continua a ser muito utilizado hoje
em dia.

Grande parte do sucesso do modelo cascata está no fato de ser orientado para a documentação.
No entanto, esta abrange mais do que arquivo e texto: incluindo representações gráficas e mesmo
simulações. Uma abordagem que incorpora processos, métodos e ferramentas deve ser utilizada pelos
criadores de software.

64
ENGENHARIA DE SOFTWARE I

O paradigma do ciclo de vida clássico demanda uma abordagem sistemática e sequencial para o
desenvolvimento de software. Começa no nível do sistema e progride, através da análise, do design, da
codificação, do teste e da manutenção, como apresentado na figura a seguir.

Engenharia de
sistemas
Análise

Design
Codificação
Testes
Manutenção

Figura 13 – Visão do ciclo clássico ou cascata de desenvolvimento de software

Problemas encontrados no ciclo clássico de desenvolvimento de software são fartamente

documentados pelos autores consagrados da engenharia de software:

• os projetos reais raramente seguem o fluxo sequencial que o modelo propõe; ocorrem interações,
bem como voltas a níveis anteriores, provocando problemas na aplicação do paradigma;

• frequentemente os usuários têm dificuldade de estabelecer explicitamente todos os requisitos do

software, acompanhada das incertezas naturais que existem no início de muitos projetos;

• uma versão do software somente estará disponível quando todo o sistema for definido e
desenvolvido; qualquer alteração pode ocasionar um desastre no desenvolvimento do sistema;
isso requer paciência dos usuários.

Observação

Esses problemas são reais, porém o paradigma do ciclo clássico de

software tem um definitivo e importante lugar na engenharia de software:
proporciona um modelo real para a colocação e uso dos métodos para
analisar, projetar, codificar, testar e manter softwares.

4.2.3 O modelo incremental

De acordo com Pressman (2006), Sommerville (2007), Paula Filho (2003) e outros autores, o modelo
incremental seria a aplicação do modelo cascata por diversas vezes em um mesmo projeto. Isso ocorre
ao se dividir o desenvolvimento de um sistema complexo em pequenas partes, o que pode ocorrer de
forma sequencial, parte a parte ou em paralelo, com equipes diferentes desenvolvendo partes diferentes.
65
 Unidade II

Para apresentar o modelo, é utilizada uma visão do ciclo de vida em cascata considerada por Peres,
Laskoski e Radaelli (2014), mostrada na próxima figura.

Comunicação

Planejamento

Modelagem

Construção

Implantação

Figura 14 – Modelo em cascata

As fases desse modelo, de acordo com Peres, Lakosky e Radaelli (2014, p. 2) significam:

• comunicação: consiste de atividades para o levantamento dos requisitos do sistema e envolve a

comunicação entre os desenvolvedores e o cliente;

• planejamento: consiste de atividades para o estabelecimento de um plano de desenvolvimento

do sistema ou projeto de software. Descreve, também, as técnicas a serem conduzidas, os riscos
prováveis, os recursos que serão necessários, os produtos de trabalho a serem produzidos e um
cronograma;

• modelagem: composta de atividades que incluem a criação de modelos que permitem ao

desenvolvedor e ao cliente entender melhor os requisitos do software e o projeto que vai satisfazer
a esses requisitos;

• construção: essa fase combina a geração de código e os testes necessários para revelar erros no
código implementado;

• implantação: o software é entregue ao cliente, que avalia o produto e fornece feedback com base
na avaliação.

Se essas fases se repetirem e pequenos pedaços do software forem sendo liberados ou agrupados
para serem entregues ao cliente, teremos o que se chama de modelo incremental, mostrado na figura
a seguir.

66
ENGENHARIA DE SOFTWARE I

Incremento n

Comunicação

Planejamento
Funcionalidades e características do software

Modelagem
Incremento 2
Construção
Comunicação
Implantação
Planejamento
Entrega do n
Incremento 1 Modelagem incremento

Comunicação Construção
Entrega do 2º
Planejamento Implantação incremento
Modelagem

Construção
Entrega do 1º incremento
Implantação Núcleo do produto

Figura 15 – Modelo incremental

Vantagens apontadas pelos autores para o modelo incremental em relação ao modelo em cascata
puro:

• entregas parciais facilitam a identificação e a correção de erros entre os componentes do software;

• necessidades não especificadas nas fases iniciais podem ser desenvolvidas nos incrementos;

• cada iteração produz um conjunto de itens utilizáveis (se possível);

• os feedbacks de iterações anteriores podem ser usados nos próximos incrementos;

• os incrementos podem ser desenvolvidos por menos profissionais;

• a entrega dos incrementos permite o cumprimento do prazo especificado.

Como todo modelo conceitual, porém, o modelo incremental apresenta algumas desvantagens:

• o número de iterações não pode ser definido no início do processo, o que pode não ser aceito pelo
cliente;

• o fim do processo também não pode ser previamente definido;

67
 Unidade II

• o gerenciamento e a manutenção do sistema completo podem se tornar complexos, principalmente,

se ocorrem durante o desenvolvimento dos incrementos;

• o gerenciamento do custo do projeto é mais complexo, em razão do número de iterações que

pode acabar com a verba disponível.

4.2.4 O modelo Rapid Application Development (RAD)

Na busca de produtividade e qualidade no processo de desenvolvimento de sistemas, especialistas e

autores da engenharia de software, baseados nos problemas do ciclo clássico (cascata), na evolução das
técnicas estruturadas, no impacto das linguagens de programação orientadas a objetos e no surgimento
dos conceitos de qualidade, no final da década de 1980 e início da década de 1990, propuseram um
novo paradigma denominado de Rapid Application Development (RAD).

A metodologia RAD propõe um conjunto de elementos que criaram um novo paradigma incluindo
a prototipação interativa, o desenvolvimento espiral e o uso intensivo de ferramentas de automação do
desenvolvimento (CASE), com uso de linguagens de quarta geração, orientação a objetos e modelos-
padrão de desenvolvimento, como a Unified Modeling Language (UML).

O RAD foi originalmente utilizado por James Martin, em seu livro RAD, publicado em 1991.

De acordo com Ramos (2009), tem-se sobre o modelo RAD:

• é sequencial linear e enfatiza um ciclo de desenvolvimento extremamente curto;

• o desenvolvimento rápido é obtido usando uma abordagem de construção baseada em

componentes;

• os requisitos devem ser entendidos corretamente, e o alcance do projeto deve ser restrito;

• é usado principalmente para aplicações de sistemas de informação;

• cada função principal pode ser direcionada para uma equipe RAD separada e, então, integrada
para formar o todo.

A próxima figura mostra uma visão gráfica do modelo RAD proposta por Ramos (2009).

68
ENGENHARIA DE SOFTWARE I

Equipe nº3
Equipe nº1 Equipe nº2
Modelagem
Modelagem do negócio
Modelagem do negócio Modelagem
do negócio dos dados
Modelagem
dos dados Modelagem
Modelagem do processo
dos dados Modelagem Geração de
do processo aplicação
Modelagem
do processo Geração de Teste e
aplicação modificação

Geração de Teste e
aplicação modificação

Teste e
60 a 90 dias modificação

Figura 16 – O modelo RAD

Alguns autores consideram que nem todos os tipos de aplicação são apropriados para o modelo
RAD. Para que este seja aplicado corretamente, as seguintes considerações devem ser levadas em
conta:

• a aplicação deve permitir uma efetiva modularização, com ciclos curtos de desenvolvimento;

• se a aplicação exigir alto desempenho e se este for obtido sintonizando as interfaces dos
componentes, a abordagem RAD poderá não funcionar a contento;

• a prototipação interativa e viva, aliada ao desenvolvimento incremental e não linear, são aspectos
extremamente positivos para atingir os objetivos do desenvolvimento rápido;

• a adoção da orientação a objetos ou o uso de linguagens de quarta geração é também um fator

altamente positivo, principalmente, na aplicação de reúso de código;

• o modelo RAD propõe-se a ser um método leve, flexível e adaptável às novas tecnologias
emergentes que considerem o RAD um processo organizado, gerenciado e padronizado.

Saiba mais

Consulte o material do autor Ricardo Argenton Ramos, da Univasf, que

detalha os modelos apresentados nesta unidade.

RAMOS, R. A. Processos de desenvolvimento de software. Univasf,

Juazeiro, 2009. Disponível em: <http://www.univasf.edu.br/~ricardo.
aramos/disciplinas/ESI2009_2/Aula02.pdf>. Acesso em: 13 fev. 2014.

69
 Unidade II

4.2.5 Os modelos evolucionários

Os modelos evolucionários ou modelos evolutivos, como o próprio nome sugere, são os explicitamente
projetados para acomodar um produto de software que evolui com o tempo. A cada iteração, os modelos
evolucionários ou evolutivos têm por objetivo produzir uma versão melhor e mais completa do software.

Dois modelos se encaixam nessa definição: o de prototipagem e o espiral.

4.2.5.1 O modelo de prototipagem

A prototipação é uma ferramenta que pode ser usada em qualquer um dos modelos apresentados
até agora. Essa técnica auxilia o engenheiro de software e o cliente a entenderem melhor o que deve ser
construído quando os requisitos estão confusos. Um protótipo é uma espécie de versão preliminar do
software. Pode ser um software ou um plano no papel e concentra-se na representação dos aspectos do
software que são visíveis para o cliente.

O objetivo é entender os requisitos do usuário e, assim, obter melhor definição dos requisitos do
sistema. Possibilita que o analista crie um modelo (protótipo) do software que será construído. Esse
protótipo é apropriado para quando o cliente não tiver definido detalhadamente os requisitos, mas
tiver prazo curto para o desenvolvimento. O protótipo dá maior assertividade ao projeto com relação às
necessidades do cliente ou usuário.

A figura a seguir dá uma visão do funcionamento do modelo de prototipagem.

Obter requisitos

Elaborar projeto rápido

Refinamento do protótipo

Construir protótipo
Avaliar protótipo

Figura 17 – Modelo de processo de prototipagem

A função da atividade obter requisitos é permitir que desenvolvedor e cliente definam os objetivos
gerais do software, identifiquem quais requisitos são conhecidos e as áreas que necessitam de definições
adicionais; elaborar projeto rápido é aquela em que se faz a representação dos aspectos do software
que são visíveis ao usuário por meio de abordagens de entrada e formatos de saída; a atividade construir

70
ENGENHARIA DE SOFTWARE I

protótipo é a implementação rápida do projeto; avaliar protótipo é quando o desenvolvedor e o cliente

avaliam o protótipo; e a atividade refinamento do protótipo é o momento em que o desenvolvedor
refina os requisitos do software a ser desenvolvido na tecnologia final.

Percebe-se claramente que a intenção desse modelo é apoiar o entendimento do software a ser
construído e que o resultado da prototipagem não pode ser considerado a aplicação final que será
colocada em produção ou operação. Quando todos os requisitos estiverem identificados e detalhados, e
as interfaces, totalmente definidas, o protótipo deverá ser descartado, e a versão de produção, construída,
considerando os critérios de qualidade.

4.2.5.2 O modelo espiral

O modelo espiral foi proposto por Barry Boehm, em 1986, e tem como objetivo acoplar a natureza
iterativa da prototipação aos aspectos controlados e sistemáticos do modelo em cascata; é dividido
em uma série de atividades de trabalho ou regiões de tarefas e combina as características positivas da
gerência de baselines (conjunto de documentos associados ao processo).

A seguir, a figura apresenta o modelo de Boehm, de 1986, com quatro regiões de tarefas.

Definir objetivos Analisar riscos

(planejamento)

Avaliar e planejar
próxima fase Desenvolvimento
engenharia

Figura 18 – O modelo espiral adaptado de Barry Boehm

O modelo espiral é uma evolução dos modelos clássicos e da prototipagem. Valoriza os pontos
positivos desses modelos, desprezando os considerados negativos. Organiza o desenvolvimento como
um processo iterativo em que vários conjuntos com quatro fases se sucedem, até que seja obtido o
sistema ou software final.

Um novo ciclo se inicia (primeira fase) com a determinação de objetivos, alternativas e restrições, em
que ocorre o comprometimento dos interessados e o estabelecimento de uma estratégia para alcançar
os objetivos. Na segunda fase, a avaliação de alternativas, bem como a identificação e a solução de
riscos se executam numa análise de riscos. Na terceira fase, ocorre o desenvolvimento do produto de
71
 Unidade II

software. Nesse quadrante, outros modelos podem ser empregados, inclusive, o modelo cascata. Na
quarta e última fase, o produto é avaliado e prepara-se para iniciar um novo ciclo.

4.2.6 Os modelos especializados

Um modelo de processo especializado leva em conta muitas das características de um ou mais

modelos tradicionais, tais como o modelo em cascata, o espiral, o evolucionário, entre outros. Todavia,
existe a necessidade de aplicação, em produtos de softwares muito específicos, de uma abordagem mais
especializada de engenharia de software, ou, quando definida, de uma forma mais restritiva. Os autores
organizam esses modelos especializados em modelo de desenvolvimento, baseado em componentes,
e modelo de métodos formais.

Com relação ao modelo de desenvolvimento baseado em componentes, tem-se:

• o modelo baseado em componentes tem como ênfase criar sistemas de software que envolvam
a composição de componentes, permitindo que sejam adicionadas, adaptadas, removidas
e substituídas partes do sistema sem que seja necessária sua completa substituição; é a
implementação do conceito da reusabilidade no desenvolvimento de software, tão comum em
outras engenharias;

• esse tipo de desenvolvimento auxilia a manutenção dos sistemas, visto que foca a integração de
novos componentes já prontos ou, então, a atualização dos já existentes;

• dessa forma, essa abordagem enfatiza a criação ou a adaptação de componentes para que
sejam utilizados em diversos sistemas; com isso, temos como resultado a reutilização, que busca
flexibilizar o desenvolvimento;

• um tipo de desenvolvimento que utiliza essa filosofia é o formado pelos componentes de software
comercial de prateleira, ou Commercial Off-The-Shelf (COTS), componentes desenvolvidos por
vendedores que os oferecem como produtos e disponibilizam as suas funcionalidades juntamente
com interfaces bem-definidas que permitem que esses componentes sejam integrados ao software
a ser desenvolvido;

• nesse caso, a equipe de desenvolvimento do sistema ou da aplicação conhece pouco ou nada

sobre o funcionamento interno de um componente, porém é fornecida uma interface externa
bem-definida com a qual se deve trabalhar;

• esses componentes podem ser comprados, e a sua principal desvantagem, na maioria dos casos, é
que não há código-fonte disponível; assim, a definição de como usar o componente é dada pelo
fabricante e deve ser documentada, além de ser oferecido suporte na instalação e no uso desses
componentes;

• o que se procura em um componente é algo quase independente e uma parte substituível de um

sistema que tem função bastante clara; os componentes possuem interface e, também, empregam
72
ENGENHARIA DE SOFTWARE I

regras de herança oriundas da tecnologia de objetos;

• o modelo de desenvolvimento baseado em componentes possui uma abordagem iterativa e

evolucionária; a essência é desenvolver aplicações comerciais ou científicas a partir de componentes
de software pré-empacotados;

• uma característica importante nesse modelo é que as atividades de modelagem e construção

começam com a identificação de possíveis candidatos a componentes, que podem ser projetados
como módulos de software convencionais, como classes ou pacotes;

• de acordo com Medeiros, E. (2004), o modelo de desenvolvimento baseado em componentes

possui as seguintes etapas: diversos produtos baseados em componentes existentes no mercado
são pesquisados e avaliados; os itens de integração de componentes são considerados; projeta-
se uma arquitetura de software para acomodar os componentes; integram-se os componentes à
arquitetura; e realizam-se todos os testes para assegurar a funcionalidade adequada; todas essas
etapas são independentes da tecnologia utilizada para criar os componentes.

Saiba mais

Veja material interessante sobre os modelos especializados de

software, com exemplo de uso do modelo de desenvolvimento baseado em
componentes com a tecnologia Enterprise Java Beans (EJB).

MEDEIROS, H. Modelos de desenvolvimento especializados. [s.d.].

Disponível em: <http://www.devmedia.com.br/modelos-de-processo-
especializado-conceitos-e-principios/29898>. Acesso em: 13 fev. 2014.

Com relação ao modelo de métodos formais, tem-se:

• o modelo de métodos formais possui um conjunto de atividades que conduzem a uma especificação
matemática formal do software e possibilita a especificação, o desenvolvimento e a verificação de
um sistema baseado em computador por meio da aplicação de uma rigorosa notação matemática;

• os métodos formais oferecem três diferentes níveis de atividades:

— nível 0: em que o software é descrito por meio de uma especificação formal que será usada
como base para a implementação do sistema; esse nível é opcional e deve ser de custo-benefício
menor;

— nível 1: em que o desenvolvimento e a verificação formal são utilizados para produzir um

software de maneira mais formal; esse nível é mais apropriado para sistemas de alta integridade
que necessitem de segurança ou confiança;
73
 Unidade II

— nível 2: em que provadores de teoremas ou simuladores podem ser utilizados, a fim de conduzir
testes completos das propriedades de um sistema, de forma mais automatizada; esse nível é
mais apropriado em sistemas nos quais o custo provocado por erros é extremamente alto.

• a vantagem dos métodos formais durante o desenvolvimento é que eles oferecem a eliminação
de diversos problemas encontrados em outros modelos, como a ambiguidade, a incompletude e a
inconsistência;

• todos esses problemas podem ser descobertos e corrigidos mais facilmente com a aplicação
da análise matemática; os métodos formais, quando utilizados durante o projeto, servem para
verificar a programação, possibilitando, assim, a descoberta e a correção de erros que poderiam
passar despercebidos;

• em razão da sua característica, os modelos de métodos formais são mais utilizados quando se
desenvolvem softwares que possuem fator crítico de segurança, ou quando a empresa pode sofrer
pesados problemas econômicos caso ocorram erros no software;

• alguns exemplos de software em que os métodos formais são aplicados são os sistemas de controle
de aeronaves, engenharia aeroespacial e equipamentos médicos.

4.2.7 O Unified Process (UP)

O Processo Unificado (PU) ou Unified Process (UP) é um processo configurável de engenharia de

software e um guia de como usar efetivamente a UML.

A UML é uma linguagem unificada de modelagem de sistemas, abrangendo desde as funcionalidades

até as soluções de implementação de códigos orientadas a objetos.

O UP foi desenvolvido na década de 1990 pela empresa Rational, que hoje pertence à IBM.
É caracterizado como um arcabouço (framework) que pode ser personalizado de acordo com as
necessidades específicas e os recursos disponíveis para cada projeto.

Todo UP deve descrever quem (papel) está fazendo o que (artefatos das atividades), como
(execução das atividades) e quando (no tempo, representa a disciplina no processo). Artefato é
qualquer documento ou modelo que precisa ser construído nas atividades do processo. Dentro do
processo unificado, aparece a figura do trabalhador ou ator, que é alguém que desempenha um
papel e é responsável pela realização de atividades para produzir ou modificar um artefato. Um
trabalhador pode ser um analista de negócio, um analista de sistema, um programador, um testador
etc. Atividade, no UP, representa uma tarefa a ser realizada por um trabalhador ou ator, a fim de
produzir ou modificar um artefato. Como exemplos, podemos citar os requisitos do sistema, o plano
do projeto, os códigos, os casos de testes etc.

O UP apresenta, também, o conceito de disciplinas, que descrevem as sequências das atividades

que produzem algum resultado significativo e mostram as interações dos participantes. As atividades
74
ENGENHARIA DE SOFTWARE I

das disciplinas são realizadas a qualquer momento durante o ciclo de desenvolvimento, que, no UP, é
denominado de fase do UP. Como exemplo de uma sequência de atividades, temos: requisitos, análise,
projeto, implementação e teste.

O modelo unificado UP apresenta os seguintes princípios básicos: desenvolvimento iterativo; baseado

em casos de uso; e centrado em arquitetura.

Com relação ao desenvolvimento iterativo, tem-se:

• o desenvolvimento de um software é dividido em vários ciclos de iteração, cada qual produzindo

um pedaço do sistema testado, integrado e executável;

• em cada ciclo ocorrem as atividades de análise de requisitos, projeto, implementação e teste, bem
como a integração dos artefatos produzidos com os artefatos já existentes.

A figura a seguir mostra o funcionamento do modelo unificado em ciclos e incremental.

Requisitos Requisitos
Projetos Projetos
Implementação e Tempo Implementação e O sistema cresce
testes testes incrementalmente
Integração e testes Integração e testes
de sistema de sistema
Ciclo 1 Ciclo N
As iterações são
de tamanho fixo
Vinte dias, ou limitadas pelo
por exemplo tempo

Figura 19 – Desenvolvimento iterativo e incremental do modelo UP

Com relação ao princípio baseado em casos de uso, tem-se:

• um caso de uso ou use case da UML é uma sequência de ações executadas por um ou mais
atores e pelo próprio sistema, que produz um ou mais resultados de valor para um ou mais
atores;

• o modelo unificado UP é dirigido por casos de uso, pois os utiliza para dirigir todo o trabalho de
desenvolvimento, desde a captação inicial e a negociação dos requisitos até a aceitação do código
(testes).

• os casos de uso são centrais ao processo UP e a outros métodos iterativos, pois os requisitos
funcionais são registrados, preferencialmente, por meio deles; ajudam a planejar as iterações,
podem conduzir o projeto, e o teste é baseado neles.

75
 Unidade II

Com relação ao princípio centrado na arquitetura, tem-se:

• arquitetura é a organização fundamental do sistema em sua totalidade; inclui elementos estáticos,

dinâmicos, o modo pelo qual trabalham juntos e o estilo arquitetônico total que guia a organização
do sistema;

• a arquitetura também se refere a questões como desempenho, escalabilidade, reúso e restrições

econômicas e tecnológicas; no UP, a arquitetura do sistema em construção é o alicerce fundamental
sobre o qual ele se erguerá;

• deve ser uma das preocupações da equipe de projeto;

• a arquitetura, juntamente com os casos de uso, deve orientar a exploração de todos os aspectos
do sistema;

• a arquitetura é importante porque ajuda a entender a visão global e a organizar o esforço de

desenvolvimento, facilita as possibilidades de reúso, facilita a evolução do sistema e guia a seleção
e a exploração dos casos de uso.

O processo unificado é apresentado em quatro fases, como mostra a figura a seguir.

Fases do processo
unificado

Concepção Elaboração Construção Transição

Entrega do
produto para a
produção

Figura 20 – As quatro fases do modelo unificado

Na fase de concepção se estabelece a viabilidade de implantação do software/sistema a ser

desenvolvido, define-se o escopo do sistema, estimam-se os custos e o cronograma, identificam-se os
potenciais riscos que devem ser gerenciados ao longo do projeto e se faz o esboço da arquitetura, que
servirá como alicerce para sua construção.

Na fase de elaboração se desenvolve a visão detalhada do sistema, contendo a definição

dos requisitos funcionais, o detalhamento da arquitetura criada na fase de concepção e o
gerenciamento dos riscos.

Na construção, o sistema é efetivamente desenvolvido e já pode ser colocado em produção, mesmo

que seja em ambiente de teste.

76
ENGENHARIA DE SOFTWARE I

Na fase de transição, o sistema é entregue ao cliente para uso em produção; testes detalhados são
realizados, e um ou mais incrementos são implantados; erros ou defeitos são corrigidos, caso apareçam
nesse momento.

Com relação às disciplinas que determinam as atividades de trabalho, são realizadas a qualquer
momento no ciclo de desenvolvimento do UP e entrecortam todas as fases do processo unificado,
podendo ter maior participação em uma fase e menor influência em outras, mas ocorrendo em qualquer
uma delas.

A próxima figura mostra uma visão da organização das disciplinas no modelo UP. O gráfico também
é chamado de Gráfico das Baleias, em razão do seu formato peculiar.

Concepção Elaboração Construção Transição

Requisitos

Análise

Análise

Implementação

Testes

Iter. Iter. Iter. Iter.

nº 1 nº 2 nº 1 nº 2

Figura 21 – Visão da distribuição das disciplinas no UP nas fases

O processo unificado propõe que as disciplinas ocorram em paralelo nas fases e que podem ocorrer
a qualquer momento. Isso significa que diversas atividades ou trabalhos são realizados de forma
simultânea, dependendo do momento em que estão ocorrendo e de acordo com o plano do projeto.
Cada disciplina pode gerar um ou mais artefatos, que são documentos produzidos, modelos, diagramas,
especificações, códigos, planos de testes etc.

4.2.8 O Rational Unified Process (RUP)

O RUP é uma instância do Processo Unificado desenvolvido pela empresa Rational e hoje mantido
pela IBM. Trata-se de um processo configurável de engenharia de software e serve como um guia de
como se deve usar a linguagem de modelos UML no ciclo de desenvolvimento de software.

Os objetivos do RUP são:

• assegurar uma produção de alta qualidade de software, que realiza a necessidade do usuário
seguindo os prazos e o orçamento;

77
 Unidade II

• com o advento do Capability Maturity Model/Capability Maturity Model Integration (CMM/CMMI),

as organizações focalizam a qualidade em primeiro plano, e o RUP pode ser bastante útil quando
se quer atingir níveis maiores.

O RUP, como processo de desenvolvimento de software, tem quatro regras básicas, semelhantes ao
processo unificado UP:

• servir de guia;
• especificar quais artefatos devem ser desenvolvidos e quando devem ser desenvolvidos;
• dirigir as tarefas individuais e do time em sua totalidade;
• oferecer critérios para monitorar e medir os produtos e atividades do projeto.

O RUP, semelhante ao processo unificado UP, apresenta os seguintes princípios:

• é dirigido por casos de uso (use cases);

• é baseado em componentes;
• é centrado em arquitetura;
• é iterativo e incremental (modelo espiral);
• é framework genérico de um processo de desenvolvimento.

Esse processo também apresenta as quatro fases semelhantes às do processo unificado: concepção
ou iniciação, elaboração, construção e transição. As disciplinas, dentro das fases, são orientadas por
modelos desenvolvidos com o uso da UML, como mostra a próxima figura.

Modelo de negócio, lista de requisitos, casos de uso,

modelo de domínio, protótipo preliminar

Modelo de classes, diagrama de atividades, diagrama de

Modelo de estados, e casos de testes
Requisitos use case
Deployment, diagrama de componentes, diagramas de
Modelo de sequência e modelagem visual
Análise análise

Modelo
Design design

Modelo de
Implementação implementação

Modelo de
Testes teste

Figura 22 – O uso dos modelos da UML nas disciplinas do RUP

78
ENGENHARIA DE SOFTWARE I

As disciplinas no RUP são atividades conduzidas em todas as fases de um ciclo, variando de

intensidade conforme a fase. Dão origem aos artefatos do projeto. Em cada fase são desenvolvidas
várias atividades do processo:

• modelagem de negócio;

• levantamento de requisitos;

• análise e design;

• implementação;

• testes (entre outras).

Saiba mais

O artigo a seguir mostra como o processo RUP captura as seis

melhores práticas do desenvolvimento moderno de software: desenvolver
softwares interativamente; gerenciar requisitos; arquitetura baseada em
componentes; modelagem visual de software; verificação da qualidade; e
controle de mudanças para software.

BLEAKLEY, G.; COLLYER, K.; SCOULER, J. Best practices for software

development teams. IBM, 17 sept. 2013. Disponível em: <http://www.
ibm.com/developerworks/rational/library/systems- software -lifecycle-
development/systems-software-lifecycle-development-pdf.pdf>. Acesso
em: 31 mar. 2014.

4.2.9 O processo Praxis

É um processo de desenvolvimento de software, para uso educacional, com o objetivo de dar

suporte ao treinamento em engenharia de software e à implantação de processos em organizações que
desenvolvem, mantêm ou contratam softwares; é baseado na experiência do professor Wilson de Pádua
Paula Filho, assim como em alguns dos mais importantes paradigmas da área (PAULA FILHO, 2003):

• o modelo CMMI de maturidade em processos de software;

• a notação orientada a objetos da linguagem de modelos UML;

• o processo unificado (unified process);

• os padrões do Institute Eletric Eletronic Engineering (IEEE) para a engenharia de software.

79
 Unidade II

O processo Praxis é desenhado para dar suporte a projetos realizados individualmente ou por
pequenas equipes, com duração de seis meses a um ano. Com isso se pretende que ele seja utilizável
para projetos de fim de curso de graduação e congêneres, ou similares de aplicação de disciplinas de
engenharia de software. Abrange tanto métodos técnicos, como requisitos, análise, desenho, testes e
implementação, quanto métodos gerenciais, como gestão de requisitos, gestão de projetos, garantia da
qualidade e gestão de configuração. Propõe um ciclo de vida composto por fases que produzem um
conjunto precisamente definido de artefatos (documentos e modelos). Para construir cada um desses
artefatos, o usuário do processo (estudante ou engenheiro de software) precisa exercitar um conjunto
de práticas recomendáveis da engenharia de software. Na construção desses artefatos, o usuário do
processo é guiado por padrões e auxiliado pelos modelos de documentos e pelos exemplos constantes
do material de apoio.

Saiba mais

Toda a estrutura do processo Praxis encontra-se definida no livro:

PAULA FILHO, W. P. Engenharia de software: fundamentos, métodos e

padrões. São Paulo: LTC, 2003.

Leia uma breve apresentação em:

PAULA FILHO, W. P. Processo Praxis 3.0. Disponível em: <http://

homepages.dcc.ufmg.br/~wilson/praxis/>. Acesso em: 31 mar. 2014.

4.2.10 O processo cleanroom (sala limpa)

Esse processo é considerado como uma aplicação prática de matemática e da estatística para produzir
software de alta qualidade. Também considera o conceito de hardware cleanroom. Aplica fortemente
prevenção de erros versus remoção de erros, o design correto com certificação por teste e apresenta as
metas: processo de desenvolvimento gerenciável mais prevenção de erros.

Com relação ao gerenciamento dos projetos, o processo considera:

• controle sobre o processo – progresso evidente mais garantia de integridade dos artefatos;

• trabalho em equipe com processos de engenharia bem-definidos;

• gerenciamento de complexidade, redução de riscos, eliminação do refazer e atendimento dos

requisitos do negócio dentro de prazos e orçamentos estabelecidos;

• controle depende da tecnologia empregada pelos times (tecnologia e processos adequados);

80
ENGENHARIA DE SOFTWARE I

• métodos para especificação e projeto precisos, verificação de correção, teste e medidas de

qualidade e confiabilidade;

• completude e consistência matemática que leva à verificação de correção.

De acordo com Linger e Trammell (1996), o cleanroom combina métodos formais de requisitos e
desenho com uso no teste estatístico para produzir software com quase nenhum ou nenhum defeito.

Passos para aplicação do processo cleanroom:

• análise de requisitos: produzindo e revendo especificações informais;

• desenho de alto nível: convertendo o requisito em máquinas de estado e funções;

• desenho detalhado: refinamento das funções;

• codificação por incremento: desenvolver código e verificá-lo usando métodos informais; compilar
código ou efetuar teste às unidades é proibido;

• pré-teste por incremento: geração de casos de teste;

• teste estatístico por incremento: o código é compilado, linkado e testado; os resultados são
validados.

Linger e Trammell (1996) apontam, ainda, as razões para que uma organização adote a abordagem
do cleanroom quando, com o mesmo trabalho, poderia usar sua estratégia tradicional de engenharia de
software:

• os métodos tradicionais de desenvolvimento de software já são tão usuais nas organizações em

que o processo de descobrir defeitos nas aplicações é considerado como fato normal;

• a organização que pretende adotar o cleanroom tem de estar preparada para uma mudança
radical; adotar uma filosofia “sem erros na cultura da empresa”;

• uma vez que o principal objetivo do cleanroom é prevenir erros, o produto final é praticamente
sem erros, com um certificado de fiabilidade científica;

• isso faz baixar o preço de produção e manutenção de um produto feito em grande escala;

• os autores apontam, ainda, os mitos e as realidades em torno do processo cleanroom:

— mito: o cleanroom irá substituir as técnicas de engenharia de software existentes.

– Não. O cleanroom utiliza muitas das práticas existentes e, ao contrário do que dizem as
críticas, não vai substituir todas as técnicas tradicionais.
81
 Unidade II

— Mito: é um conjunto de práticas e princípios ortodoxos.

– Não existem princípios e práticas ortodoxas no cleanroom. Os programadores ajustam de

modo que sirva para o projeto específico no qual estão trabalhando, no entanto os princípios
fundamentais mantêm-se os mesmos, seja qual for o projeto.

— Mito: o cleanroom irá substituir as técnicas SE existentes.

– Não. O cleanroom utiliza muitas das práticas existentes e, ao contrário do que dizem as
críticas, não vai substituir todas as técnicas tradicionais do SE.

Esses princípios apontam para um número de práticas específicas em que a única regra é que fiquem
nos limites dos princípios fundamentais. É vital para o sucesso do projeto que o cleanroom seja adequado
à necessidade.

Saiba mais

Diversos sites e portais apresentam detalhes e casos de sucesso do

processo cleanroom.

LINGER, R. C.; TRAMMELL, C. J. Cleanroom software engineering

reference model: Version 1.0. nov. 1996. Disponível em: <http://resources.
sei.cmu.edu/asset_files/technicalreport/1996_005_001_16502.pdf>.
Acesso em: 31 mar. 2014.

CLEANROON software engineering. University of Texas, Arlington, [s.d.].

Disponível em: <http://www.uta.edu/cse/levine/fall99/cse5324/cr/clean/
page.html>. Acesso em: 31 mar. 2014.

Resumo

Nesta unidade foi possível apresentar e discutir os principais conceitos

envolvidos com os processos de software que abrangem tanto os processos
quanto os produtos.

Ao longo dos últimos trinta anos, o processo de desenvolvimento de

software tem evoluído. Essa evolução vem propondo alternativas na forma
de construção e manutenção de software que acompanha as necessidades
que a tecnologia e o mercado impõem às empresas fornecedoras de
sistemas de informação.

82
ENGENHARIA DE SOFTWARE I

Para minimizar os efeitos da complexidade nos processos de software,

diversas alternativas e metodologias foram aparecendo; algumas persistem,
e outras foram abandonadas, por não terem surtido os efeitos desejados.

O texto apresenta os conceitos envolvidos com o ciclo de vida de

software, bem como discute os principais modelos existentes, colocados
em uma visão histórica. Detalha esses modelos, iniciando com o codifica-
remenda, passando pelos modelos cascata, incremental, RAD e chegando
aos evolucionários. Discute o modelo unificado, que é a base do processo
RUP, e termina com o modelo cleanroom.

Finalmente, a unidade se encerra, deixando o conhecimento de que,

como todos os processos de ciclo de vida de software mantêm uma
coerência em relação às atividades para a construção de um software de
qualidade, cada organização deverá optar por aquele que atender melhor
às suas necessidades, ou poderá construir soluções customizadas com base
nas melhores práticas apresentadas por esses processos já conhecidos e
praticados há algum tempo.

Exercícios
Questão 1. Um dos pilares da engenharia de software é a qualidade, que indica, de acordo com
os autores Pressman (2006) e Sommerville (2007), que as empresas também precisam desenvolver
um processo de garantia da qualidade de software. A partir dessa constatação, analise as seguintes
afirmativas:

I – Os requisitos de software são a base a partir da qual a qualidade é medida. A falta de conformidade
com os requisitos significa falta de qualidade.

II – Padrões especificados definem um conjunto de critérios de desenvolvimento que orientam a

maneira segundo a qual o software passa pelo trabalho de engenharia. Se os critérios forem seguidos, o
resultado, isto é, o produto de software construído, quase seguramente será de qualidade.

III – A engenharia de software, para atender à pressão pela qualidade nos produtos, vem desenvolvendo
diversos modelos para a garantia da qualidade de software.

IV – O pilar dos processos de software da ES especifica padrões que definem um conjunto de

critérios de desenvolvimento que orientam a maneira segundo a qual o software passa pelo trabalho de
engenharia e da qualidade.

V – Deve-se observar o conjunto de critérios de desenvolvimento independentemente de a empresa

utilizar processos propostos pela engenharia de software.

83
 Unidade II

Assinale a alternativa correta:

A) As afirmativas I, III e V estão corretas.

B) As afirmativas I, II, III e IV estão corretas.

C) As afirmativas II, III e V estão corretas.

D) As afirmativas I, IV e V estão corretas.

E) Todas as afirmativas estão corretas.

Resposta correta: alternativa B.

Análise das afirmativas

I) Afirmativa correta.

Justificativa: os requisitos de software são a base da construção de um produto de qualidade. Se os

requisitos não forem bem-explicitados e se não estiverem de acordo com as necessidades do cliente ou
do usuário, não adiantará ter as outras práticas executadas de forma perfeita, pois se estará criando um
excelente produto que não atenderá aos objetivos do projeto.

II) Afirmativa correta.

Justificativa: se os critérios definidos nos padrões ou nas metodologias de software forem seguidos,
o resultado quase seguramente será a existência de qualidade no software produzido.

III) Afirmativa correta.

Justificativa: assegurar a qualidade de um software não é tarefa trivial, uma vez que produtos
de software são geralmente complexos, mas, ao longo do tempo, modelos como o CMMI do SEI, o
MPS.BR brasileiro e as normas ISO têm contribuído significativamente para a qualidade dos softwares
desenvolvidos.

IV) Afirmativa correta.

Justificativa: existem diversas normas internacionais e nacionais, bem como modelos de qualidade
de software que definem um conjunto de critérios de desenvolvimento que orientam a maneira pela
qual o processo de software é semelhante a um trabalho de engenharia. Se esses critérios, segundo as
normas de qualidade, não forem seguidos, o resultado quase seguramente será a falta de qualidade.
Relativamente ao processo de software, a ISO 12207, o RUP e o SCRUM têm estabelecido padrões e
normas de suporte aos processos ativos no mercado.

84
ENGENHARIA DE SOFTWARE I

V) Afirmativa incorreta.

Justificativa: pois os critérios de qualidade estão intrinsecamente amarrados aos processos definidos
na engenharia de software.

Questão 2. Os processos de software são normalmente divididos em fases, etapas e atividades

para facilitar o entendimento, a alocação de recursos e a atribuição de responsabilidade no ciclo de
desenvolvimento de software. A partir dessa afirmação, têm-se os seguintes tópicos sobre processos de
software:

I – Um processo de software tem um ciclo de vida como os outros produtos das outras engenharias
(engenharia naval, engenharia mecânica, engenharia civil etc.).

II – No ciclo de evolução, o software sofre intervenções, tanto para melhorá-lo como para corrigir
possíveis distorções.

III – É no modelo PSP de software que o SEI (2014) se preocupa com a melhoria e a otimização dos
trabalhos dos times de software.

IV – O modelo TSP é um guia voltado para os times de software e os prepara para estarem
comprometidos com um objetivo comum, que é o sucesso do projeto.

V – O processo Praxis para desenvolvimento de software não segue os princípios dos modelos
internacionais (já que é brasileiro) e propõe um caminho próprio no desenvolvimento de software.

Assinale a alternativa correta:

A) As afirmativas III e V estão corretas.

B) As afirmativas I, II, IV estão corretas.

C) As afirmativas III, IV e V estão corretas.

D) As afirmativas III e IV estão corretas.

E) A afirmativa V está correta.

Resolução desta questão na plataforma.

85