1

Universidade de Pernambuco
Faculdade de Cincia e Tecnologia de Caruaru
Bacharelado em Sistemas de Informao

UMA SOLUO ORIENTADA A PROCESSOS PARA AUXILIAR A

IMPLANTAO DO NIVEL G DO MPS.BR

Trabalho de Graduao
Sistemas de Informao

Ana Letcia Ferreira da Costa

Orientador: Prof. Msc. Rmulo Csar Dias de Andrade

ANA LETCIA FERREIRA DA COSTA

UMA SOLUO ORIENTADA A PROCESSOS PARA AUXILIAR A

IMPLANTAO DO NVEL G DO MPS.BR

Monografia
parcial

para

apresentada
obteno

como
do

requisito

diploma

de

Bacharel em Sistemas de Informao pela

Faculdade de Cincia e Tecnologia de
Caruaru Universidade de Pernambuco.

Caruaru, dezembro, 2014

Dedico este trabalho aos meus pais, Otvio

Jos

(in

memoriam)

Amparo,

pela

motivao aos estudos, amor e ensinamentos.

Agradecimentos

A Deus, por me dar perseverana, fora, auxlio e f para que esse trabalho pudesse ser
concludo.
A minha me, Amparo, por ser um verdadeiro amparo em minha vida, me orientando e
incentivando nos momentos de aflio.
Ao meu pai, Otvio Jos (in memoriam), que embora no esteja fisicamente comigo, seus
ensinamentos prevalecero para sempre em minha vida.
As minhas avs, Valdeci (in memoriam), com seu modo simples de enxergar o mundo,
Marlene (in memoriam), que viu em mim aptido para com os estudos e a minha bisav Rosa,
com seu modo peculiar de apreciar o conhecimento.
A toda minha famlia pelo apoio incondicional, em especial aos tios: Z Carlos, por ser um
exemplo de perseverana em relao aos estudos, Hozana, por sempre ver o lado bom das
coisas e J, que, por tantas vezes me acolheu em sua casa.
Ao meu namorado, Felipe, pela compreenso durante todos os momentos necessrios para
elaborao deste trabalho.
Aos meus vizinhos, que indiretamente me forneceram internet.
Aos professores, que contriburam com minha formao acadmica, em particular ao meu
orientador, Rmulo Csar, pelo incentivo e fora nos momentos de fraquejo.
Aos meus amigos pelo apoio dado durante toda a graduao, de modo notvel, Polly, Karine e
lida, que mostraram que uma amizade verdadeira pode surgir independentemente de onde se
esteja.
E a todos, que de uma forma ou de outra contriburam para que este trabalho acontecesse.

Resumo

Atualmente o cenrio de competio e profissionalismo obriga organizaes a buscarem

efetividades nos seus processos de desenvolvimento de software como uma forma de
aumentar a qualidade dos servios prestados. essencial que as etapas do desenvolvimento de
software bem como as fases de levantamento dos requisitos estejam claras e definidas,
garantido conformidade para empresas e clientes e assim reduzindo os custos com retrabalho
e falta de entendimento devido a requisitos de sistemas que foram mal relatados. A demanda
por desenvolvimento de softwares inevitvel, ocasionando requisitos de implementao
cada vez mais complexos, onde as fbricas de softwares utilizam modelos de referncias para
guiar os seus processos. As empresas vm melhorando os seus procedimentos de
especificao de requisitos, tendo em vista que as adoes de boas prticas trazem resultados
significativos para as mesmas. Diante desse cenrio de processo e especificao de requisitos,
este trabalho apresenta um estudo sobre automao de processos com nfase em BPMS
(Busines Process Management System) juntamente com a especificao de requisitos com
nfase no Nvel G do MPS.BR (Melhoria do Processo de Software Brasileiro). A finalidade
do trabalho proposto de gerenciar a especificao de requisitos, controlando e dando
visibilidade de todas as etapas do processo e com isso melhorando a comunicao entre
empresas e clientes evitando assim interpretaes erradas destes requisitos e garantido as
entregas nos prazos corretos, tendo em vista que a ferramenta proposta controla os tempos em
cada fase e assim gera relatrios gerencias para as partes interessadas. Em virtude do uso de
um processo definido previamente, ser possvel identificar possveis gargalos e trabalhar de
forma efetiva para corrigir eventuais problemas que possam existir na fase de especificao de
requisitos.
Palavras-chave: Qualidade de Software; Requisitos; BPMS; MPS.BR Nvel G; Processo;

Abstract

Currently the competition scenario and professionalism requires organizations to seek

effectivities in their software development processes as a way to increase the quality of
services provided. It is essential that the stages of software development and the lifting phase
of the requirements are clear and definite, guaranteed compliance for businesses and
consumers and thereby reducing the cost of rework and lack of understanding due to system
requirements that were poorly reported. The demand for development of software is
inevitable, causing implementation requirements increasingly complex , where the software
factories use reference models to guide their processes. Companies have improved their
requirements specification procedures, given that the adoption of best practices bring
significant results for the same. Given this scenario process and requirements specification,
this paper presents a study on process automation with emphasis on BPMS (Busines Process
Management System) together with the specification requirements with emphasis on Level G
of MPS.BR (Improving the Software Process Brazilian). The purpose of the proposed work is
to manage the requirements specification, thus controlling and giving visibility of all stages of
the process and thereby improving communication between businesses and customers
avoiding misinterpretation of these requirements and guaranteed deliveries at the right time,
with a view that the proposed tool controls the times when each phase and thus generates
management reports for stakeholders. Due to the use of a process defined previously, you can
identify potential bottlenecks and work effectively to address any problems that may exist in
the requirements specification phase.
Keywords: Software Quality; Requirements; BPMS; MPS.BR Level G; Process;

INDICE DE FIGURAS

Figura 1 - Estrutura do Modelo de Prototipao ...................................................................... 21

Figura 2 - Correspondncia entre o CMMI e o MPS.BR. ........................................................ 30
Figura 3 - reas de Conhecimento em BPM ............................................................................ 34
Figura 4 - Fases da Modelagem, adaptado ............................................................................... 36
Figura 5 - Interface Principal do BizAgi Studio ....................................................................... 37
Figura 6 - BizAgi Studio, Aba do Model Process .................................................................... 38
Figura 7.1 - Fase em que um Processo se Encontra ................................................................. 39
Figura 8.1 - Fases da Modelagem, Etapa de Elicitao dos Requisito ..................................... 46
Figura 9 - Modelagem de Dados na Ferramenta ...................................................................... 48
Figura 10 - Implementao da Fachada .................................................................................... 49
Figura 11 - Regra de Negcios ................................................................................................. 50
Figura 12 - Separao dos Grupos de Requisitos ..................................................................... 51
Figura 13 - Tela de login .......................................................................................................... 52
Figura 14 - Tela de Afazeres .................................................................................................... 52
Figura 15 - Grfico para Acompanhamento de Projetos .......................................................... 53
Figura 16.1 - Criao e Definio do Papel de Analista .......................................................... 53
Figura 17 - Trabalhos em Andamento por Usurio .................................................................. 55
Figura 18 - Resumo do Tempo de Ciclo................................................................................... 55

INDICE DE TABELA

Tabela 1 - Fases da Ferramenta ................................................................................................ 46

LISTA DE SIGLAS

ABPMP

Association of Business Process Management Professionals

ASD

Adaptive Software Development

BPM

Business Process Management

BPMN

Business Process Model and Notation

BPMS

Business Process Management Suite

CMM

Capability Maturity Model

CMMI

Capability Maturity Model Integration

CBoK

Guia para o Gerenciamento de Processos de Negcios

DSDM

Dynamic Systems Development Methodology

ISO

International Organization for Standardization

MCT

Ministrio da Cincia e Tecnologia

MPS

Melhoria do Processo de Software

MPS.BR

Melhoria do Processo de Software Brasileiro

MR-MPS

Modelo de Referncia do MPS.BR

PMBOK

Project Management Body of Knowledge

Sepin

Secretaria de Poltica de Informtica

SEI

Software Engineering Institute

SWEBoK

Software Engineering Body of Knowledge

SW-CMM

Software Capability Maturity Model

TI

Tecnologia da Informao

UML

Linguagem de Modelagem Unificada

10

SUMRIO
1 INTRODUO ................................................................................................................... 11
1.1 CARACTERIZAO DO PROBLEMA .......................................................................... 12
1.2 OBJETIVOS ....................................................................................................................... 13
1.3 JUSTIFICATIVA ............................................................................................................... 13
1.4 METODOLOGIA DA PESQUISA .................................................................................... 14
1.5 ORGANIZAO DO TRABALHO ................................................................................. 16
2 REFERENCIAL TERICO .............................................................................................. 16
2.1 ENGENHARIA DE SOFTWARE ..................................................................................... 17
2.1.1 Prototipagem de Software ............................................................................................... 20
2.2 MODELAGEM DE SOFTWARE ..................................................................................... 21
2.2.1 Engenharia de Requisitos ................................................................................................ 22
2.3 GESTO DE QUALIDADE ............................................................................................. 24
2.3.1 Qualidade de Software..................................................................................................... 26
2.3.2 Melhoria do Processo de Software Brasileiro (MPS.BR) ............................................... 28
2.3.3 Nvel G de Qualidade ...................................................................................................... 31
2.4 GERENCIAMENTO DE PROCESSOS DE NEGCIOS (BPM) .................................... 32
2.4.1 Tecnologia da Informao Aplicada Gesto por Processos (BPMS) ........................... 35
2.5 CONSIDERAES FINAIS ............................................................................................. 39
3 RESULTADOS E DISCUSSES ...................................................................................... 41
4 CONCLUSES.................................................................................................................... 56
5. REFERNCIAS BIBLIOGRFICAS ............................................................................. 57

11

1 INTRODUO

A inveno dos computadores foi algo que revolucionou a humanidade, pois, a partir do
surgimento e evoluo destes objetos, Filho (2013), pessoas passaram a depender cada vez
mais da comodidade oferecida por estes. Para tanto, necessrio que os softwares
desenvolvidos atendam sempre aquilo que o usurio final anseie. neste cenrio que se
destaca a engenharia de software e todas as facilidades oferecidas por esta rea to promissora
Filho (2013).
Portanto, para que o produto de software desenvolvido tenha qualidade, seja entregue no
prazo definido, tenha um custo razovel e ainda atenda s necessidades dos usurios
essencial que possua qualidade em seu desenvolvimento j que estes fatores influenciam de
forma direta o produto produzido e proporcionam destaque junto ao mercado competitivo,
Anjos e Moura (2014). O que no se deve esquecer que, softwares caticos e ineficientes
levam organizaes desenvolvedoras a perderem mercado, Filho (2013).
Motivar organizaes s prticas proporcionadas pela qualidade um desafio constante j
que muitas das organizaes deixam esta prtica como segundo plano; investir em qualidade
algo que s traz benefcios, uma vez que sero observados os produtos de softwares
desenvolvidos assim como o grau de maturidade em que a empresa se encontra com a
finalidade de obter certificao de qualidade, Gomes (2000).
Presentemente existem alguns rgos responsveis por ditar as normas de qualidade que
um produto de software deve ter; tanto internacionais, CMMI (Capability Maturity Model
Integration), ISO (International Organization for Standardization) e suas normas, bem como
nacional, MPS.BR (Melhoria do Processo de Software Brasileiro).
Uma vez que softwares so desenvolvidos, estes necessitam de uma equipe de
gerenciamento e desenvolvimento; tais equipes precisam estar cientes do grau de
produtividade em que o projeto se encontra.
Fazer uso de gerenciamento de processos de negcios (BPM) no desenvolvimento de
softwares algo muito til e quando agregado as prticas de qualidade transformam-se em
algo extraordinariamente proveitoso. Utilizar BPM em um processo de software possibilita a
transformao deste processo, BPM, CBOK (2013), pois possvel representa-lo
graficamente bem como automatiza-lo, no esquecendo de que tambm possvel fazer o
gerenciamento destes processos em desenvolvimento.

12

Antes de se pensar que impossvel fazer esta integrao entre dois processos distintos,
sendo um voltado a qualidade e o outro automao, lembremo-nos das oportunidades
oferecidas pelo Busines Process Management System (BPMS), como forma de automatizar a
gesto de processos de negcios.
Sendo assim, este projeto busca criar uma soluo orientada a processos com o uso de
BPMS, o mesmo toma como nfase o modelo de melhoria e avaliao do processo de
software MPS.BR nvel G para que micro, pequenas e mdias empresas possam adotar esta
ferramenta como metodologia de trabalho.

1.1 CARACTERIZAO DO PROBLEMA

Entende-se por engenharia de software o estabelecimento e uso de slidos princpios

que integra mtodos, ferramentas e procedimentos para o desenvolvimento de softwares.
Quanto qualidade so todos os artefatos produzidos durante seu desenvolvimento, ou seja,
modelos, documentos, relatrios, cdigo fonte, cdigo executvel, cronograma, etc., estes,
tem que satisfazer as necessidades dos clientes, colaboradores, acionistas e usurios finais.
Uma pesquisa realizada com organizaes nacionais mostrou que 43% dos processos
de software foram cancelados ou entregues com falhas comprometedoras no produto
(ATALLA apud RIBEIRO, et, al., 2011). Segundo Furtado, certos tipos de falhas que
ocorrem em projetos de software so ocasionados quando o cliente, ou usurio final
ignorado, pois, a falta de envolvimento desta parte, durante todo o desenvolvimento do
projeto, est diretamente relacionada ao fracasso.
Analisando tal cenrio, em 2003 a Associao para Promoo da excelncia do
Software Brasileiro (SOFTEX), que conta com o apoio de diversas empresas e ministrios
criou o MPS.BR (Melhoria de Processos do Software Brasileiro), este programa, busca
atender as necessidades do mercado e, ao mesmo tempo, manter os padres de qualidade
exigidos por rgos competentes, o MPS.BR subdivide-se em 7 nveis, que vo do G (sendo
este, o nvel mnimo de qualificao) ao A (sendo este, o nvel mximo de qualificao) .
Sabe-se, que o mercado de Tecnologia da Informao (TI), est cada vez mais
crescente e cada vez mais quebrando barreiras geogrficas; nesse cenrio que, em
Pernambuco, destaca-se um grande polo de desenvolvimento e solues inovadoras, o Porto

13

Digital, que age como uma incubadora de empresas, onde, para se desenvolver softwares,
essencial que se tenha certificao nvel G.
diante desse cenrio que surge a seguinte problemtica: Como utilizar processos
automatizados para auxiliar na implantao do MPS.BR nvel G?
De acordo com Sommerville (2011), um software alm de corresponder s
expectativas do usurio, precisa ser confivel; e para ser confivel, precisa seguir padres de
qualidade, tais padres so ditados pelo MPS.BR, que segue modelos e normas internacionais
a fim de que a indstria de software nacional atenda cada vez mais as necessidades dos seus
clientes.

1.2 OBJETIVOS

Este trabalho tem como objetivo geral propor uma soluo automatizada que guie as
empresas a partir dos processos Nvel G do MPS.BR na implantao deste programa.
E como objetivos especficos:
o Compreender os processos do MPS.BR Nvel G e relacionar suas boas prticas com
BPM.
o Definir um modelo de implantao do MPS.BR nvel G orientada a processos atravs
de um BPMS(Tecnologia da Informao Aplicada a Gesto de Processos)
o Estimar o tempo para as atividades de implantao.
o Criar papis e fases de implantao.
o Definir fluxos de trabalho.

1.3 JUSTIFICATIVA

Como j costume, a maior parte de micro, pequenas e mdias empresas utilizam

metodologias tradicionais para realizarem suas tarefas, porm nem sempre utiliza-las surte o
efeito esperado, Magalhes e Pinheiro (2007).

14

A pratica de Business Process Model and Notation (BPMN) contribui para um ambiente
de trabalho mais dinmico, alm de proporcionar maior comodidade quanto s atividades de
execuo de estratgia de negcios que estas empresas estabelecem. J as normas de
qualidade MPS.BR servem para atribuir mtricas a fim de que estas empresas possuam
certificao de qualidade, SOFTEX (2013).
Sendo assim, este trabalho visa integrar estas duas ferramentas, sendo uma voltada a
processos, BPMN, que tem como intuito gerir um conjunto de boas prticas no processo de
negcios e a outras voltada a qualidade, MPS.BR, como forma de melhorar gradativamente o
processo de software destas empresas, para tanto daremos nfase ao Nvel G de qualidade por
ser este o nvel mnimo de qualificao que uma empresa deve ter.
A proposta de implantao do Nvel G do MPS.BR atravs de uma ferramenta orientada a
processos, para micro, pequenas e mdias empresas sobressai-se por ser dinmica, gil e
intuitiva assim como proposto pelo BPMN. Porm, de acordo com Magalhes e Pinheiro
(2007) mudar a cultura organizacional de empresas uma tarefa rdua, mesmo que o objetivo
seja aumentar a produo e a qualidade dos produtos e servios pois os gestores esto
acostumados com o modelo j existente.
Mesclar diferentes ferramentas pode contribuir para que a empresa tenha mais controle
acerca dos artefatos de software produzidos, j que a ferramenta proposta facilita o modo
como os gestores administram os projetos.
A ferramenta desenvolvida prope s empresas automao dos seus processos para que a
partir disto o tempo de desenvolvimento de cada fase de um projeto de software possa ser
acompanhado assim como cada pessoa responsvel por uma fase, ou seja, a ferramenta indica
a definio do fluxo dos trabalhos correntes na empresa.

1.4 METODOLOGIA DA PESQUISA

Entende-se por metodologia, um conjunto de regras e mtodos, ou seja, procedimentos

organizados que conduzem a certo resultado. De acordo com Cervo, Bervian e Da Silva
(2006), nos estudos cientficos, os mtodos so conjuntos de processos utilizados para
investigar a demonstrao da verdade. Sendo assim, como forma de validar esta pesquisa,
algumas etapas consideradas cruciais foram abordadas.

15

A presente pesquisa caracteriza-se por ser exploratria, pois, segundo Cervo, Bervian e Da
Silva (2006), este tipo de pesquisa realiza descries precisas e quer descobrir as relaes
existentes entre seus elementos componentes. Para tanto ser desenvolvida uma ferramenta
orientada a processos; esta auxiliar a implantao do nvel G em empresas desenvolvedoras
de software, seguindo as normas estabelecidas pelo MPS.BR.
Ainda de acordo com Cervo, Bervian e Da Silva (2006) qualquer espcie de pesquisa e em
qualquer rea de estudo, primrdio que seja feita uma pesquisa bibliogrfica; seguindo este
pensamento, um estudo bibliogrfico detalhado sobre engenharia e modelagem de software,
gesto de qualidade com base no MPS.BR nvel G e Busines Process Management Suite
(BPMS) foi realizado, tendo como objetivo criar embasamento terico para esta pesquisa.
Para que pudesse ser feito o acompanhamento do desenvolvimento da ferramenta, foi adotado
o modelo de prototipagem de software, este, gera verses parciais e preliminares de um
sistema de software que esteja sendo desenvolvido, Souza (2014), como este trabalho tem por
objetivo desenvolver uma ferramenta de software orientada a processos, este modelo de
desenvolvimento enquadrou-se de forma satisfatria ao desenvolvimento desta ferramenta,
uma maior explanao acerca do assunto ser exibido no captulo 2.
Ao ser efetivada a reviso da literatura, descrita no captulo 2 observou-se a importncia
de conectar gerenciamento de processos qualidade de software, tendo em vista viabilizar o
desenvolvimento de softwares realizado por micro, pequenas e mdias empresas.
Para finalizar foi realizada uma pesquisa qualitativa, que, de acordo com Otani e Fialho
(2011), so levados em conta a relao diligente entre objetividade e subjetividade o qual no
pode ser traduzido em nmeros; para Flick (2009) este tipo de pesquisa consiste na relevncia
e anlise de diferentes perspectivas para o pesquisador, j que so levadas em conta variedade
das abordagens bem como os mtodos reflexivos no que diz respeito ao processo de produo
do conhecimento. Uma pesquisa qualitativa no requer o uso de mtodos e tcnicas
estatsticas (OTANI, FIALHO, 2011, p. 38) j que, ainda de acordo com Otani e Fialho
(2011) os dados necessrios para realizao da coleta esto disponveis no meio natural, e, o
pesquisador o instrumento-chave para coleta-las.
Pesquisas do tipo qualitativas tendem a ser descritivas, pois o pesquisador tende a
analisar os dados indutivamente, e o processo e seu significado so os focos principais da
abordagem. (OTANI, FIALHO, 2011, p. 38).

16

1.5 ORGANIZAO DO TRABALHO

O contedo deste trabalho est estruturado em cinco captulos:

o No captulo 1 foi feita uma breve introduo acerca dos principais motivos que
levaram a realizao deste trabalho, seus objetivos e metodologia utilizada;
o No captulo 2 foi feita a reviso da literatura que aborda assuntos como engenharia de
software e o modelo de prototipagem de desenvolvimento, modelagem e gesto da
qualidade de software e para finalizar, foi tratado do tema BPM;
o Captulo 3 apresenta os resultados, assim como as discusses acerca do estudo
realizado;
o E para finalizar, o captulo 4 aborda as concluses deste trabalho.

2 REFERENCIAL TERICO

Como forma de embasar a pesquisa aqui apresentada, foi-se analisado o estudo da arte
referente engenharia de software. O presente referencial terico traz como peas chave, a
modelagem de software, que de acordo com Pfleeger (2004), modelar softwares analisar os
procedimentos necessrios para que aes possam ser acompanhadas e tomadas de forma
correta; gesto da qualidade de software, que, segundo Pressman (2011) o processo onde se
verifica os requisitos existentes no projeto, bem como o grau de satisfao do cliente;
MPS.BR com nfase no nvel G de qualidade, de acordo com o guia de implementao
desenvolvido pela SOFTEX tal programa busca atender as necessidades do mercado ao
mesmo tempo que mantm os padres de qualidade exigidos por rgos competentes; BPM,
para Barrios(2012), BPM nada mais que o conhecimento dos processos executados a fim de
gerencia-los, para, da realizar melhorias e evoluir tais processos; BPMS, a empresa
MasterHause, especializada em consultorias e treinamentos nos diz que o BPMS um
conjunto de funes que tem por objetivo modelar processos de negcios de maneira
padronizada.

17

2.1 ENGENHARIA DE SOFTWARE

Assim como aconteceu humanidade, com o software no foi diferente; ambos

sofreram intensas evolues, cada uma ao seu tempo e com sua importncia.
O software passou a fazer parte da vida das pessoas de tal forma que no conseguimos
imaginar o mundo sem as facilidades oferecidas a ns por eles. Mas nem sempre foi assim,
segundo Wirth (2012), no princpio havia muitas limitaes e por isso a nfase no hardware
era substancial; ainda de acordo com este autor, os anos 50 foram marcados pelo
desenvolvimento de diversas linguagens de programao baixo nvel; foi apenas nos 60,
quando os computadores ganharam caractersticas multiprogramao que houve a
popularizao destes, porm, tal popularizao trouxe consigo a necessidade de se
desenvolver programas e aplicativos cada vez mais robustos; para tanto, era necessria a
contnua evoluo do hardware agregada experincia dos programadores, na prtica, as
coisas no funcionavam desta forma, as melhorias no hardware, prometidas pelas grandes
empresas que fabricavam os computadores no eram cumpridas, nem to pouco, os
programadores eram dotados de experincia nesta nova rea.

Em 1968, uma conferncia patrocinada pela NATO, foi dedicada ao tema (1968 em
Garmisch-Partenkirchen, Alemanha). Apesar de crticas terem ocasionalmente sido
expressas anteriormente, s aps a conferncia as dificuldades foram discutidas
abertamente e confessadas com franqueza incomum, e os termos Engenharia de Software
e Crise de Software foram criados. (Niklaus, 2012).

De acordo com Pressman (2011), atualmente o software assume duplo papel e estes
papeis sofreram mudanas expressivas ao longo dos ltimos cinquenta anos. Algumas dessas
mudanas foram,

Aperfeioamento significativo no desempenho do hardware, mudanas profundas nas

arquiteturas computacionais, vasto aumento na capacidade de memria e armazenamento, e
uma ampla variedade de exticas opes de entrada e sada, tudo isso resultou em sistemas
computacionais mais sofisticados e complexos. (Pressman, 2011, p.31).

18

Para Falbo (2005) desenvolver softwares no deve ser confundido com programar
softwares. Estas so duas realidades diferentes; ao tratarmos do termo desenvolver softwares,
visamos melhorar a qualidade dos produtos de software e aumentar a produtividade no
processo de desenvolvimento, atravs de mtodos, tcnicas, ferramentas, dentre outros
(FALBO, 2005, Introduo), a este conjunto de mtodos atribumos o nome de engenharia de
software. Para Frana (2012), programar softwares escrever cdigos a partir de uma
linguagem de programao existente, revisar e realizar testes de modo que haja uma interao
entre o hardware, o sistema operacional e o usurio final.
Ambos os processos so estritamente parecidos, porm, para Sommerville (2011) a
engenharia de software foca todas as metodologias de desenvolvimento, desde o estgio
inicial, onde so obtidas as especificaes necessrias do sistema at sua manuteno, ou seja,
quando o sistema desenvolvido j est sendo usado.
No geral, os softwares passam por algumas etapas durante seu desenvolvimento, a esta
cadeia d-se o nome de processo de software, pode-se dizer que algumas atividades so
comuns a todos os projetos, por exemplo: elicitao dos requisitos, onde os clientes e
engenheiros se renem a fim de definir o software a ser produzido, bem como suas restries;
desenvolvimento do software, ou seja, fase onde os requisitos definidos so programados e
feita uma projeo; validao do software, nesta etapa, feita uma anlise do software
produzido, para garantir que o mesmo est de acordo com as especificaes do cliente;
evoluo do software, isto acontece quando h necessidade de modificao, ou seja, quando
h uma atualizao da verso do software produzido.

O modelo de ciclo de vida a primeira escolha a ser feita no processo de software. A partir
desta escolha definir-se- desde a maneira mais adequada de obter as necessidades do
cliente, at quando e como o cliente receber sua primeira verso operacional do sistema.
(DevMedia 36, 2012, p.1).

Pode-se dizer que os modelos de ciclo de vida funcionam como a estrutura onde sero
ajustadas as fases do projeto para que assim, este v tomando forma; outro ponto de
notoriedade nesta etapa a deteco de erros; pois bem, o erro, quanto mais cedo for
descoberto, mais vantajoso o , pois assim evita-se o retrabalho, alm de que contribui para a
qualidade do software, o cumprimento dos prazos, bem como todos os custos associados.

19

Para o professor Prado (2014), essencial, antes do desenvolvimento de um produto,

preparar um plano geral, ou seja, escolher um modelo de ciclo de vida. (PRADO, 2014, p.1).
De acordo com a revista DevMdia (2014), no existe um modelo de ciclo de vida especfico
para cada projeto, a escolha de um ou mais modelos vai depender da complexidade do
negcio do cliente, bem como nvel de confiabilidade, ambiente operacional, custos, equipe
de desenvolvimento, dentre outros fatores.
Para que haja acompanhamento dos desenvolvedores e da empresa contratante e uma
documentao atualizada para assim haver validao de cada uma das etapas, os projetos
fazem uso de modelos de software, alguns desses modelos so:
o Modelo Cascata: Este modelo tem como finalidade de estabelecer ordem no
desenvolvimento de grandes produtos de software. (RAMOS, CARLOS,
LEITO, COSTA, 2010, Introduo); recebe este nome, pois obedece a uma
ordem de classes, aqui, cada fase s inicia quando a anterior termina e a nova
fase iniciada recebe os atributos da classe anterior.
o Modelo em V: Este modelo introduz a criao de testes de dados e cenrios
de teste durante o ciclo de desenvolvimento do software, e trabalha com
diferentes nveis de testes como: unidade, integrao, sistema e aceitao.
(MACORATTI, 2008, p. 1).
o Modelo Incremental: Batista e Santos (2012) afirmam que o modelo
incremental foi sugerido por Barry Boehm, e que seu desenvolvimento
dividido em etapas, e estas etapas so incrementadas at sua verso final, da o
nome modelo incremental. Neste tipo de modelo, o cliente acompanha
diretamente cada fase de desenvolvimento do projeto, alm de poder opinar se
tudo est saindo como o esperado.
o Modelo Evolutivo: Este tipo de modelo tem como desgnio apresentar
caractersticas que possibilitem desenvolver verses cada vez mais complexas
do software. (PRESSMAN, 2011, p. 62).
o Modelo Espiral: De acordo com Pressman (2011), o modelo espiral foi
proposto por Barry Boehm, e tal modelo funciona como uma juno dos
modelos cascata, prototipao e tambm o modelo interativo.
o Rational Unifield Process (RUP): O RUP um processo bem estruturado
para que o desenvolvimento de softwares seja uma tarefa previsvel e repetvel
possui alta qualidade alm de levar em conta a acuidade da comunicao com

20

os clientes, iterativo e incremental, proporcionando a sensao

evolucionria que essencial no desenvolvimento de software moderno.
(PRESSMAN, 2011, p. 72).

2.1.1 Prototipagem de Software

Prototipao, a montagem de prottipos, ela pode ser classificada de acordo com

uma variedade de dimenses. (LESSA, JUNIOR, 2009, p. 4). O que os autores quiseram
dizer foi que as diferentes etapas de desenvolvimento de software, como por exemplo,
levantamento dos requisitos, documentao, codificao, testes, entre outros, so
considerados, porm, no necessariamente estas etapas precisam ser seguidas de modo
formal.
Este tipo de modelo de desenvolvimento oferece vantagens, como por exemplo:
o Requisitos necessrios no precisam ser totalmente declarados no incio de um
projeto, e, podem ainda ser editados caso haja essa necessidade.
o A entrega do prottipo feita ao cliente assim como as especificaes e definies
para que o usurio final saiba utilizar o software; a satisfao e entendimento destes
usurios so levados em conta.
Estas vantagens oferecidas servem para certificar que o ambiente de desenvolvimento
destes softwares est sendo funcional, Lessa, Jnior (2009), pois, o principal objetivo da
prototipagem que a construo total ou parcial de um produto de software seja feita de
forma rpida para que assim a equipe desenvolvedora bem como os usurios finais cheguem a
um consenso do que realmente necessrio para a construo de um software, Pfleeger
(2004).
O modelo de prototipagem, tem como intuito revelar ao cliente uma verso inicial do
sistema, esta primeira verso serve para testar possibilidades, ou seja, mostrar conceitos,
experimentar opes do projeto e, em geral, para conhecer mais sobre os problemas e suas
possveis solues. (BATISTA; SANTOS; 2012, p.1), evitando-se assim, gastos com futuras
correes de erros. A figura 1 mostra a estrutura do modelo de prototipao.

21

Figura 1 Estrutura do Modelo de Prototipao.

Fonte: Pfleeger (2004).

Prottipos de software, servem para auxiliar diligncias no processo de engenharia de

requisitos, j que, na maioria dos projetos, a verso beta serve apenas de orientao quanto ao
bom funcionamento, rapidez na execuo entre outros fatores que dizem respeito qualidade.
Esta prototipao pode ser mostrada aos usurios de diversas formas, modelo executvel, bem
como, projees, prottipos de papel, prottipos existentes, etc.

2.2 MODELAGEM DE SOFTWARE

Modelagem abrange tanto anlise quanto projeto, descrevendo representaes do

software que se tornam progressivamente mais detalhadas. (Pressman, 2011, p. 123).
Para Castilho (2008), modelar software algo parecido planta de uma casa, a
representao simplificada de algo real. Tais representaes servem para que haja um
acompanhamento do que o projeto dever ter e fazer, a isto d-se o nome de fluxos de dados.
Apesar de cada projeto de software ter sua particularidade, de acordo com Pressman
(2011) podemos fazer uso de metodologias existentes para auxiliar o seu desenvolvimento.
Pode-se dizer que o pontap inicial de um projeto de software levantar os requisitos para

22

que assim, o desenvolvimento do projeto esteja como o cliente ou usurio final almeje. De
acordo com Sommerville (2011), atualmente os modelos de software so, na maioria das
vezes representados por algum tipo de notao grfica baseadas em notao UML (linguagem
de modelagem unificada), porm, tambm possvel que tal representao seja feita por
modelos matemticos como forma de se especificar detalhes do sistema.
Desse modo, este trabalho aborda as tcnicas utilizadas a partir das notaes UML sob
uma perspectiva estrutural, j que ser criada uma modelagem a fim de exemplificar os
requisitos que comporo a ferramenta orientada a processos. Neste novo modelo de sistema os
requisitos estaro documentados a fim de facilitar o entendimento e tambm, para seguir
normas de qualidade ditadas pelo MPS.BR.
Os modelos estruturais podem ser modelos estticos, que mostram a estrutura do
sistema, ou dinmicos, que mostram a organizao do sistema quando ele est em execuo.
(SOMMERVILLE, 2011, p. 89). Como ser desenvolvida uma ferramenta orientada a
processos, est ser estruturada de modo esttico e dinmico, pois, aps finalizar a
modelagem, est ser automatizada.
Para tanto, no momento da modelagem, sero utilizados diagramas de classes para que
se tornem mais claras as associaes existentes entre elas; alm disso, tambm ser detalhado
nessa modelagem, modelos semnticos de dados, eles mostram as entidades dos dados, seus
atributos associados, e as relaes entre essas entidades. (SOMMERVILLE, 2011, p. 90),
funcionam como uma espcie de banco de dados, j que, os diagramas UML no os possui;
muitas vezes, os dados podem ter caractersticas em comum, e, quando isto acontece, a UML
dispe de um tipo especial de associao entre as classes, conhecida por agregao de dados,
aqui, um objeto composto por um conjunto de outros objetos (Sommerville, 2011).

2.2.1 Engenharia de Requisitos

Projetar e construir softwares desafiador, criativo e pura diverso. (PRESSMAN,

2011, p. 127). Bem, a tarefa de desenvolver softwares sim empolgante, e, por tal motivo,
muitos desenvolvedores esquecem de levantar os requisitos necessrios para o sucesso do
projeto.

23

Apesar de parecer desnecessrio que haja documentao e acompanhamento do

projeto que est sendo desenvolvido, erros graves podem vir a surgir caso no haja
planejamento das aes que devero ser tomadas; por tudo isso, criou-se o termo engenharia
de requisitos, esta, serve como referncia para as atividades de desenvolvimento e
acompanhamento de projetos de software, pois,

Na perspectiva do processo de software, a engenharia de requisitos uma ao de

engenharia de software importante que se inicia durante a atividade de comunicao e
contnua na de modelagem. Ela deve ser adaptada s necessidades do processo, do projeto,
do produto e das pessoas que esto realizando o trabalho. (Pressman, 2011, p. 127).

a partir da engenharia de requisitos que so analisadas as propostas dos clientes, que,

de acordo com Pressman (2011), seguem sete tarefas distintas onde algumas ocorrem em
paralelo, e ambas so utilizadas de acordo com as necessidades de cada projeto; estas tarefas
so:
o Concepo: Nesta fase os clientes formalizam os requisitos fundamentais,
determinam as restries primordiais dos projetos e abordam as principais
caractersticas e desempenhos que devem estar presentes para que o sistema atenda s
necessidades dos clientes ou usurios finais.
o Levantamento: Na fase de levantamento dos requisitos importante que sejam
realizadas reunies com a presena da equipe desenvolvedora bem como dos clientes,
para que sejam definidas as necessidades bem como as funcionalidades do software
desenvolvido.
o Elaborao: A fase de elaborao responsvel por expandir as necessidades
identificadas nas fases de concepo e levantamento, por meio de conjuntos de
elementos comportamentais, orientados a fluxos e baseados em cenrios e classes, este
modelo, faz ainda aluses a padres de anlises, e solues para problemas recorrentes
em distintas aplicaes, Presman (2011).
o Negociao: Fase em que a prioridade dos requisitos bem como a disponibilidade e os
custos relativos so analisados e negociados pela equipe desenvolvedora e tambm
pelos interessados no projeto.
o Especificao: Descrio sistemtica e abstrata do que o software deve fazer, a partir
daquilo que foi analisado. (LEITE, 2000, p.1). Aps esta anlise, so levantados

24

possveis problemas no software que ser implementado, e, solues so mostradas

para que tais problemas sejam efetuados de forma segura; tem uma viso voltada para
a comunicao sistemtica entre as classes, pois assim, indica quais das propriedades
funcionais so mais diligentes para resolver o problema de domnio.
o Validao: Como certificao que foi feito aquilo que o cliente ou usurio final
deseja, esta responsabilidade recai sobre a validao dos requisitos. Alm disso, esta
fase tambm responsvel por corrigir possveis erros no projeto como um todo,
evitando que sejam necessrios retrabalhos aps a entrega da verso final ao cliente.
o Gesto: Fase de extrema importncia para a engenharia de requisitos j que nesta fase
a equipe de desenvolvimento consegue controlar, identificar e acompanhar as
mudanas feitas ao longo do desenvolvimento do projeto.
Para o Institute of Eletricaland Eletronics Engineers (IEEE, 1990), analisar requisitos
de software uma cadeia onde so ponderadas as necessidades dos clientes, e, a partir delas
so determinados o sucesso ou fracasso do projeto (QUITERIO, 2012). primordial que os
requisitos que foram levantados, sejam relevantes para o projeto,

Pois, eles fornecero a referncia para validar o produto final, estabelecero o acordo entre
cliente e fornecedor sobre o que o software far, e consequentemente reduziro os custos de
desenvolvimento, pois requisitos mal definidos implicam num retrabalho. (QUITERIO,
2012, p.1).

2.3 GESTO DE QUALIDADE

Na engenharia de software estabelecer metas e cumprir prazos de suma importncia

para que se obtenha excelncia no produto produzido. Com a evoluo constante deste
mercado, empresas desenvolvedoras de software esto mais conscientes que nunca de que
qualidade e produtividade andam juntas, e, para que haja eficincia nestas tarefas, o processo
de produo de softwares deve ser eficiente.
Ao pensarmos em qualidade, imaginamos algo livre de erros ou defeitos, e em
excelentes condies, mas, e no ambiente organizacional?

25

Neste tipo de ambiente podemos encontrar diversos significados que nos submetem
qualidade; atendimento as expectativas do cliente, conformidade com a especificao,
conhecimento do processo para melhora-lo, efetividade e usabilidade. (VASCONCELOS et
al., 2006, p. 73).
Como visto, definir qualidade no uma tarefa fcil, j que esta pode ser vista de
vrios ngulos; no campo da engenharia de software este um termo a ser tratado com
delicadeza j que softwares so bens intangveis alm de que podemos estar nos referindo a
qualquer etapa do processo de software, que vai desde uma viso transcendental at uma viso
de mercado. Garvin (1984) comenta detalhadamente quais so as perspectivas de qualidade e
o que elas significam:

Viso Transcendental: Onde a qualidade algo que podemos

reconhecer, mas no podemos definir.

Viso do Usurio: Onde a qualidade adequao ao propsito

pretendido.

Viso do Fabricante: Onde a qualidade a conformidade com a

especificao.

Viso do Produto: Onde a qualidade est relacionada s

caractersticas inerentes ao produto.

Viso do Mercado: Onde a qualidade depende do valor que os

consumidores

esto

dispostos

pagar

pelo

produto.

(GARVIN, 1984, p. 25-45).

De acordo com Pfleeger (2004), devemos considerar a qualidade de software a partir

de trs ngulos:
o Qualidade do Produto: Esta caracterstica deve ser analisada sob dois pontos de
vista; do usurio, estes vo analisar se o software desenvolvido corresponde a suas
expectativas, ou seja, se ele faz aquilo que foi projetado para fazer, o usurio analisa
ainda se o software intuitivo, fcil de ser utilizado e possui alguma falha; e dos
desenvolvedores do produto, estes tem a funo de considerar todas as caractersticas
do produto antes deste ser entregue ao usurio, por exemplo, defeitos, qualidades, etc.

26

o Qualidade do Processo: O processo de anlise da qualidade do software

desenvolvido considerado por muitos engenheiros como sendo de vital importncia
para um bom funcionamento do projeto, pois, projetos passam por muitas fases e
etapas, e caso em alguma destas no for bem realizada, a qualidade pode sofrer algum
tipo de consequncia; por isso deve-se dar nfase ao processo de desenvolvimento, e
este deve ser melhorado constantemente para que hajam evolues na qualidade,
assim como nos produtos resultantes.
o Qualidade no Contexto do Ambiente de Negcios: Aqui o enfoque da observao
est voltado para uma perspectiva de negcios, ou seja, a qualidade mensurada a
partir de produtos e servios que do suporte ao desenvolvimento de softwares; a
partir de pesquisas foi analisado que, ao se melhorar a qualidade do software seu valor
comercial tambm aumenta.
Com os constantes avanos tecnolgicos, com o crescimento do mercado de Tecnologia
da Informao (TI), e com um pblico alvo cada vez mais exigente, a Organizao
Internacional de Padronizao (ISO) foi criada, esta tinha o intuito de realizar auditorias
internas para verificar o funcionamento do sistema de gesto de qualidade (ISO 9000). Pois
bem, controlar a qualidade uma ao que demanda muita responsabilidade, pois, fazer este
controle total implica em uma representao de um sistema funcional, onde so integradas
atividades como qualidade de desenvolvimento, manuteno alm de esforos de melhoria da
qualidade.

2.3.1 Qualidade de Software

Como foi visto, o mercado de TI est em constante crescimento e evoluo, e, a busca

por produtos que ofeream qualidade algo cada vez mais almejado pelos usurios; investir
na qualidade desses softwares uma tarefa que est diretamente relacionada a um
gerenciamento rigoroso de requisitos, uma gerncia efetiva de projetos e um processo de
desenvolvimento bem definido, gerenciado e em melhoria contnua. (VASCONCELOS et
al., 2006, p. 81).

27

No sentido mais geral a qualidade de software deve ser definida como: uma gesto de
qualidade efetiva aplicada de modo a criar produto til que fornea valor mensurvel por
aqueles que o produzem e para aqueles que o utilizam. (Pressman, 2011, p. 360).

Devemos lembrar que os softwares so desenvolvidos por pessoas, e, muitas vezes as

limitaes humanas fazem com que erros de lgica ou erros de interpretao influenciem no
cumprimento das metas estabelecidas; investir na qualidade dos softwares desenvolvidos s
traz benefcios as empresas, pois, so evitados retrabalhos e correes de defeitos aps o
software ser entregue ao usurio, sem contar que h um aumento na produtividade assim
como um melhor relacionamento com os clientes ou usurios finais j que h um melhor
planejamento e gesto por parte da empresa.
Segundo Pressman (2011), existem trs definies importantes para medir a qualidade
dos softwares:
o Gesto da Qualidade: Aqui so estabelecidas informaes e metas que daro
suporte ao processo de criao do software.
o Produto til: Caracteriza-se como tal um produto de software, porm, este
deve atender as necessidades dos clientes, devem ser isentos de erros alm de
fornecer confiabilidade.
o Agregue Valor tanto para o Fabricante quanto para o Usurio: A empresa
desenvolvedora deve disponibilizar o mnimo de atualizaes possveis, ou esta
vai perder credibilidade junto ao mercado consumidor de softwares.
Para Volpe et al. (2004), desde 1993 a Secretaria de Poltica de Informtica (Sepin)
que faz parte do Ministrio da Cincia e Tecnologia (MCT) no Brasil vem realizando um
acompanhamento de qualidade acerca dos processos de software, e a partir destas foi
percebida um progresso significativo na procura de melhoria contnua da qualidade nos
processos de desenvolvimento dos softwares brasileiros.
Adotar um modelo de qualidade traz benefcios em todos os sentidos para uma
organizao, por exemplo,

Aumento de produtividade, reduo no nmero de defeitos em produtos, maior

previsibilidade e visibilidade dos processos, alm do atendimento das metas de custo,
prazo, funcionalidade e qualidade do produto desenvolvido, alm de aumentar a motivao
da equipe. (VOLPE et al. 2004, p. 48).

28

Atualmente existem diferentes modelos de qualidade que podem ser seguidas por
organizaes que desenvolvem de software, so elas (Volpe 2004):
o Capability

Maturity

Model

(CMM):

Desenvolvido

pelo

Software

Engineering Institute (SEI), este modelo descreve um caminho evolucionrio

no que diz respeito a maturidade; possui cinco nveis de qualidade, sendo
assim, quanto maior o nvel, maior a maturidade nos processos de
desenvolvimento de software de uma empresa.
o Capability Maturity Model Integration (CMMI): Tambm desenvolvido
pelo SEI, porm seu foco na melhoria da maturidade dos processos de
softwares em empresas desenvolvedoras.
o Project Management Body of Knowledge (PMBoK): Guia de uso contendo
as melhores prticas em gerencia de projetos; este guia traduz os
conhecimentos mais atuais da prtica de gerenciar projetos no mundo inteiro.
o Software Engineering Body of Knowledge (SWEBoK): Guia de uso
contendo as melhores prticas da engenharia de software.
o ISO 9001 Sistema de qualidade: Modelo para garantia da qualidade em
projetos, desenvolvimento, produo, instalao e servios associados:
Esta norma baseada em uma srie de princpios de gesto da qualidade,
incluindo um forte foco no cliente, a motivao e o envolvimento da gesto,
abordagem de processo e melhoria contnua. (ISO 9001: 2008).
o ISO 12207 Tecnologia da Informao: Avaliao de Processos: Esta
norma prov um processo que pode ser empregado para definir, controlar e
melhorar os processos de ciclo de vida dos softwares.
Este trabalho adotar o modelo de qualidade brasileiro MPS.BR com nfase no nvel
G de qualidade; a prxima seo detalhar melhor as funcionalidades deste mtodo.

2.3.2 Melhoria do Processo de Software Brasileiro (MPS.BR)

O MPS.BR foi criado em dezembro de 2003 pela Associao Para Promoo do

Software Brasileiro (SOFTEX), esta conta com o apoio do Ministrio de Cincia e Tecnologia

29

(MCT), Financiadora de Estudos e Projetos (FINEP), Servio Brasileiro de Apoio s Micro e

Pequenas Empresas (SEBRAE) e o Banco Interamericano de Desenvolvimento (BID).
Seu principal objetivo a Melhoria do Processo de Software e de Servios no Brasil,
porm, com um atendimento voltado s empresas de pequeno e mdio porte. Esta
metodologia busca satisfazer as necessidades deste mercado que se encontra em constante
expanso; tal programa busca ainda reconhecimento nacional bem como internacional por ser
um modelo eficaz e que presta servio s comunidades desenvolvedoras de software.
Como forma de averiguar se este processo est sendo empregado da forma correta, o
MPS.BR dispe de processos e mtodos para que sejam realizadas avaliaes. Agindo deste
modo, embora parea bobagem, o MPS.BR est contribuindo para que os softwares nacionais
possuam certificao de qualidade.
O modelo de qualidade MPS.BR, teve sua inspirao em padres de qualidade
nacionail e internacionais; Norma NBR ISO/IEC 12207, a norma internacional ISO/IEC
12207 e a ISO/IEC 15504, o que permite considerar portanto, que o modelo est em
conformidade com estas normas. (NETO, 2008, p. 57).
Este modelo de referncia para desenvolvimento de software, define sete nveis de
maturidade como nos mostra a figura 2, e de acordo com Fagundes (2014), processos de
maturidade de software precisam seguir um conjunto de atividades, mtodos, prticas e
mudanas, e, as organizaes desenvolvedoras so as responsveis por manter e desenvolver
produtos de software baseados nestas atividades. A figura 2, mostra a correspondncia entre o
CMMI e o MPS.BR.

30

Figura 2 Correspondncia entre o CMMI e o MPS.BR

Fonte: Carvalho (2005).

Estes nveis de maturidade determinam uma escala para medir o quo madura uma
organizao o , e foram inspirados nos cinco nveis de desenvolvimento criados pelo CMMI.
Apesar do padro proposto pelo CMMI comear pelo nvel inicial (1), depois passar para os
nveis de repetvel (2), definido (3), gerenciado (4) e otimizado (5), este ainda era um padro
muito alto para as micro, pequenas e mdias empresas brasileiras, justamente por este motivo,
o MPS.BR desenvolveu sete nveis que atendem ao mercado nacional, so eles:
o Nvel A: Em Otimizao;
o Nvel B: Gerenciado Quantitativamente;
o Nvel C: Definido;
o Nvel D: Largamente Definido;
o Nvel E: Parcialmente Definido;
o Nvel F: Gerenciado;
o Nvel G: Parcialmente Gerenciado;
Segundo Neto (2008, apud Couto 2007), o MPS.BR possui uma srie de vantagens se
tomarmos outros mtodos de processo como modelo; alguns desses diferenciais so:

31

o Os nveis de maturidade propostos pelo MPS.BR, permitem uma implantao mais

gradual, mais de acordo com a realidade de micro, pequenas e mdias empresas
brasileiras que desenvolvem software, alm de ser possvel visualizar estas melhorias;
o Possui compatibilidade com o CMMI, que um modelo de qualidade reconhecido
internacionalmente;
o Foi planejando tendo como foco a realidade de empresas nacionais de pequeno e
mdio porte;
o Custo acessvel;
o Estas qualificaes so avaliadas a cada dois anos;
Cabe lembrar, que no h critrios contraditrios nos diferentes mtodos de processo,
apenas foram feitas adaptaes que se adequaram melhor a realidade do mercado
brasileiro.

2.3.3 Nvel G de Qualidade

O nvel G o primeiro nvel de maturidade do MR-MPS-SW (SOFTEX, 2013, p. 7).

Este deve ser implantado com precauo j que o incio da implantao de melhorias dos
processos de software.
Mudar a cultura de uma organizao sempre uma tarefa meticulosa, tanto nas
empresas que desenvolvem software, como em empresas de qualquer segmento do mercado.
Este justamente o primeiro passo para se implantar o primeiro nvel de qualidade, o nvel G;
em seguida, a empresa deve esclarecer se possui padres organizacionais.
Na maioria dos casos, empresas que desenvolvem software precisam adequar suas
metodologias de trabalho para se tornarem organizaes orientadas a projetos, e isto ocorre
com a evoluo dos produtos de software, ser orientado a projetos significa redefinir
algumas operaes (atividades de rotina) j em andamento, como projeto, estabelecendo
objetivos, prazos e escopo para sua execuo.
Este nvel subdivide-se em:
o Gerncia de Projetos: Tem como propsito estabelecer e manter planos para
definio de atividades, recursos e responsabilidades acerca do projeto alm de

32

corrigir desvios significativos no desenvolvimento do projeto, quando houver;

com o crescimento da maturidade da organizao, este propsito evolui junto.
o Gerncia de Requisitos: Tem como propsito gerenciar os requisitos do
produto bem como dos componentes do projeto, alm disso, responsvel
ainda por identificar inconsistncias entre estes requisitos, os planos de projeto
e os produtos de trabalho. Esta gerncia responsvel por controlar os
requisitos.

2.4 GERENCIAMENTO DE PROCESSOS DE NEGCIOS (BPM)

No ramo da engenharia de software, possuir qualidade no produto desenvolvido algo

extremamente importante, uma vez que o produto de software deve satisfazer as necessidades
dos usurios; para que isto possa se concretizar, importante que um modelo de processo de
negcios seja seguido, sendo assim, o BPMN (Business Process Moddel and Notation)
sobressai-se por prover uma gramtica de smbolos, para mapear de maneira padro todos os
processos de negcio de uma organizao (SGANDERLA, 2012, p.1) buscando com isto
gerar a capacidade de entendimento de todas as partes interessadas no projeto, ou seja,
analistas, desenvolvedores e tambm os usurios do sistema, OMG (2014).
De acordo com Sganderla (2012), desde o seu lanamento, o que ocorreu em 2004,
organizaes do mundo inteiro passaram a utilizar BPMN em seus processos de negcios, e
isto fez com que fossem disseminados conceitos a respeito de processos de negcios,
atualmente, esta considerada uma caracterstica chave de qualquer iniciativa BPM
(SGANDERLA, 2012, p.1). De acodo com o Guia para Gerenciamento de Processos de
Negcios, o CBoK (2013) a maneira correta se se pensar em Business Process Manegement
seria:

Em vez de pensar em BPM como um processo de melhoria de processos, pense em BPM

como um processo de transformao de processos. Isto porque a transformao vai alm da
melhoria, transformao implica repensar inovar e mudar paradigmas. Transformar
liderar e construir novas formas de gerao de valor para os clientes e para a sociedade.
(BPM, CBOK, 2013, p. 1).

33

Utilizar-se de processos para a realizao de tarefas apenas um meio para atingir um

fim. E fazer uso de BPM para se chegar a este fim uma nova forma de articular e aplicar
abordagens, metodologias, estruturas de trabalho, prticas, tcnicas e ferramentas para
processos, j que estes muitas vezes so tratados de forma isolada, BPM, CBOK (2013).
De acordo com Tony Benedict, presidente da ABPMP (Association of Business
Process Management Professionals), gerenciamento de processos de negcios muda a forma
tradicional em que as empresas esto acostumadas a gerenciar seus fluxos de trabalho, este
novo meio, proporciona mudanas rpidas e inovaes para otimizar o trabalho, o
relacionamento com os clientes, fornecedores e colaboradores, BPM, CBOK (2013).
A ABPMP tem sua ateno voltada para os profissionais que adotem este tipo de
processo, a fim de que transformem seus ambientes de trabalho, quer sejam estes pblicos ou
privados, para oferecer produtos e servios mais eficientes e que possuam menos defeitos,
para que assim, os softwares produzidos forneam maior valor para o usurio.
Quando uma empresa resolve adotar BPM como metodologia de trabalho, ela s tende
a ganhar, pois a partir deste momento, atividades que envolvem gerenciamento de
desempenho tornam-se mais equilibradas, e o uso desta ferramenta de processos torna-se mais
vantajosa a medida que a prtica de BPM torna-se mais comum na organizao, alm de
agregar mais valor.
Com a implantao e prtica de ferramentas orientas a processos novas estruturas,
assim como papis organizacionais para oferecer suporte s novas prticas tendem a surgir
junto; o BPM, arremete duas principais abordagens, as que so mais orientadas a projetos de
processo e a outra que v BPM como esforo de transformao de processos, figura 3. Ainda
que ambas as reas tenham foco no gerenciamento de processos, tais abordagens geram
papis e responsabilidades distintos.
Embora adotar a prtica de BPM traga tantos benefcios s organizaes, infelizmente
existe um grave problema a cerca deste processo; no h pessoas qualificadas e com
conhecimento (BPM CBOK, 2013, p. 13) suficiente nesta rea para atender as necessidades
de empresas e organizaes. De acordo com Brett Champlin, fundador da ABPMP
Internacional, (BPM CBOK (2013)), uma sada encontrada por estas empresas foi o
investimento em treinamento e desenvolvimento profissional, como uma forma de suprir tal
necessidade; ele nos diz ainda que algumas empresas

34

Esto construindo seus prprios currculos e programas de treinamento e incorporando

pessoas iniciantes para trabalhar junto com os poucos profissionais talentosos de BPM que
possuem. Outras esto enviando gestores e analistas para treinamento, para comearam a
adquirir conhecimentos e habilidades necessrios. (BPM CBOK, 2013, p. 13).

Vale enaltecer que hoje, a prtica de BPM uma atividade de negcios que s tende a
crescer, esta uma prtica estimulante e que vem conquistando o mercado por oferecer
solues rpidas e inovadoras. Como crdito extra, Champlin, fundador da ABMPM
Internacional (BPM CBOK (2013)) comenta que v os profissionais de BPM como novo
backgraund de treinamento para profissionais que queiram aprender estas prticas no futuro,
como apresentado na figura 3.

Figura 3 reas de Conhecimento em BPM

Fonte: BPM, CBoK (2013).

35

2.4.1 Tecnologia da Informao Aplicada Gesto por Processos (BPMS)

A mudana do foco de funo para processo por parte de empresas e organizaes fez
com que a procura por sistemas de informaes que suportassem este tipo de metodologia
ficasse cada vez mais evidente; utilizar-se destes sistemas, fez com que o ambiente
organizacional se tornasse mais colaborativo, no sentido de que atividades de monitoramento
do desempenho e comunicao entre as pessoas envolvidas no desenvolvimento de softwares
tornaram-se mais eficazes.
Davenport et al. (2004) nos afirmam o quo importante ajustar sistemas de
informao a processos de negcios, uma vez que as organizaes devem buscar melhorias
contnuas; estas empresas devem melhorar o suporte informacional alm de reavaliarem e
reajustarem outros fatores que contribuam para o sucesso de uma gesto orientada a
processos.
Em certos casos, automatizar os processos organizacionais no surte o efeito esperado
pois a automao foi usualmente aplicada aos processos de retaguarda (back office) e s
funes administrativas (GONALVES, 2000, p. 6-19).
Fazer uso de tecnologias wokrflow (conjunto de ferramentas) no ambiente
organizacional possibilita que haja integrao entre a automao de processos nas
organizaes, Thives Jr. (2002). Alguns autores consideram BPM como sendo uma evoluo
da tecnologia workflow, j que BPM um processo de transformao de processos e integra
vrias reas de atuao de uma organizao pela lgica de fluxos de trabalho.
A tecnologia BPMS deve fornecer suporte a modelagem dos processos de software,
como se pode ver na figura 4, alm de integrao entre os atores (regra de negcios),
automatizao dos processos e administrao destes, uma vez que os processos desenvolvidos
necessitam de execuo, monitorao e tambm de anlise, como se pode ver na figura 4:

36

Figura 4 Fases da Modelagem, adaptado.

Fonte: Bizagi (2014).

Um BPMS composto de pelo menos cinco tarefas bsicas:

o Definio de Processos;
o Execuo de Processos;
o Modelagem Grfica de Processos;
o Controle de Atividades;
o Interface do Usurio;
e, durante sua execuo, os dados obtidos devem ser adquiridos, usados, reutilizados e criados
constantemente.
Visando automatizar a gesto do processo de negcio, foi proposto neste projeto a
integrao entre a ferramenta BPMS e o modelo de qualidade MPS.BR nvel G, como forma
de deliberar a criao de uma ferramenta que auxilie organizaes a acompanharem a
desenvoltura das fases de seus projetos. Portanto, foi escolhido o software BizAgi Studio, cuja
interface principal ilustrada na figura 5;

37

Figura 5 Interface Principal do BizAgi Studio.

Fonte: O Autor.

BizAgi um software BPM que possui interface grfica intuitiva e verstil, facilitando
a automao de processos. Tem como objetivo proporcionar resultados imediatos a partir de
suas ferramentas, estas do suporte a modelagem de processos BPMN, regras de negcios,
definio de interface com o usurio, portal web de trabalho, alm de dar suporte a gerncia
com ferramentas de otimizao e balanceamento de cargas de trabalho, bem como
acompanhamento dos indicadores de desempenho de processos, BizAgi (2014).
Vale ressaltar que mesmo os processos j tendo sido automatizados, possvel fazer a
edio destes de forma prtica; isto bastante til para as empresas, pois, caso haja a
necessidade de modificao, os processos so rapidamente alterados sem gerar danos
comerciais, BizAgi (2014).
A seguir, ser detalhado as funcionalidades desta plataforma de automao de
processos, BizAgi (2014):
o Curso BPMN Embutido: Model Process a ferramenta de modelagem de processos
oferecida pelo BizAgi, nela possvel identificar detalhadamente as funcionalidades
de cada objeto, como mostra a figura 6; quando um desenho feito, o interlicense
identifica quais objetos podem ser conectados, fazendo com que erros sejam
impedidos neste primeiro momento, alm disso, ao ser finalizada a modelagem, o
BizAgi tambm permite exportar os grficos para imagem, arquivo PDF, arquivo
Microsoft Visio e Word, XPDL e XML (FACCIO apud SANTOS, 2011, p. 30).
Como se observa na figura 6:

38

Figura 6 BizAgi Studio, Aba do Model Process.

Fonte: O Autor.

o O Processo a Aplicao: Com esta plataforma no necessrio desenvolver

cdigos, pois, a mesma oferece um ambiente para desenvolvimento totalmente grfico
e ainda dispe de funes como if, else, for, etc.
o Acompanhamento Grfico e online: Para auxiliar as tarefas dos gestores, o BizAgi
disponibiliza graficamente da rota pela qual o processo seguiu, qual o responsvel por
aquela etapa do projeto e em que ponto o projeto se encontra.
o Ambiente Web Customizvel: Aqui, pode-se ter um acompanhamento completo da
situao em que as tarefas se encontram, pode-se ainda interagir diretamente com
estas. Diz-se que a visualizao do ambiente customizvel pois pode-se utilizar a
apresentao dos dados tanto em formato de pastas quanto criando consultas on-line,
como presentam as figuras 7.1 e 7.2.

39

Figura 7.1 Fase em que um Processo se Encontra.

Fonte: O Autor.

Figura 7.2 Fase em que um Processo se Encontra.

Fonte: O Autor.

o Integrao Sharepoint | Web: Possui fcil integrao com pginas como HTML,
Java, pginas Wiki, Sharepoint, para publicao das mesmas; isto importante pois a
colaborao na gerao de modelos torna o processo mais gil.

2.5 CONSIDERAES FINAIS

40

Neste captulo foi apresentada uma viso geral sobre engenharia e modelagem de
software, gesto de qualidade e gerenciamento de processos de software.
Foi dado nfase a assuntos como MPS.BR Nvel G, que trata da qualidade, BPMS, e o
software BizAgi para que assim a modelagem e o desenvolvimento da ferramenta orientada a
processos sejam efetuados.

41

3 RESULTADOS E DISCUSSES

Como j foi apresentado em captulos anteriores, para desenvolver um sistema ou

ferramenta de software algumas etapas devem ser seguidas, e, para o desenvolvimento deste
projeto no foi diferente.
A princpio foi analisado minuciosamente o guia de implementao MPS.BR nvel G,
desenvolvido pela SOFTEX para que os requisitos pudessem ser levantados. Com base neste
guia, foi escolhida a gerncia de requisitos para servir como base para o desenvolvimento da
ferramenta. A partir da gerencia de requisitos, as fases para o desenvolvimento da ferramenta
foram levantadas com plena base neste guia, como mostrado na tabela 1:

Fases
Fase_01: Comunicar com o Cliente

Funcionalidades
Fase onde a empresa desenvolvedora e a
empresa contratante especificam quais sero
os meios de comunicao pelos quais ambas
se comunicaro durante o desenvolvimento
do projeto. Estas comunicaes devem ser
registradas formalmente em atas, e-mails,
ferramentas de comunicao ou outros meios
de

Fase_02: Levantar Requisitos

Nesta etapa, a empresa contratante expressa

quais requisitos ela deseja.

Fase_03: Definir Requisitos

Esta etapa funciona como garantia de que os

requisitos estejam claramente definidos a
partir

do

entendimento

dos

requisitos

levantados.
Fase_04: Receber Requisitos

Esta etapa serve para confirmar que os

requisitos

levantados

definidos

aprovao da empresa contratante.

tm

42

Fase_05: Avaliar Requisitos

feita uma avaliao dos requisitos a fim de

garantir que os requisitos propostos atendam
s necessidades e expectativas da empresa
contratante.

Fase_06: Registrar Reprovao

Caso os requisitos sejam reprovados, um

registro de reprovao deve ser obtido pelos
fornecedores de requisitos. Este registro deve
ser tratado como um marco do projeto.

Fase_07: Registrar Aceite

Caso os requisitos sejam aprovados, um

registro de aprovao deve ser obtido pelos
fornecedores de requisitos. Este registro deve
ser tratado como um marco do projeto.

Fase_08: Avaliar Qualidade Tcnica

A avaliao e aprovao por parte do cliente

aps o entendimento dos requisitos por si s
no suficiente para que os requisitos sejam
refinados e refletidos em modelos de anlise
e projeto para a codificao. A avaliao dos
requisitos deve envolver, alm do cliente,
tambm a equipe tcnica da organizao. Em
geral aconselhvel que os requisitos sejam
avaliados pela equipe tcnica antes de serem
submetidos para aprovao pelo cliente para
evitar retrabalho ou a apresentao de um
documento sem qualidade tcnica adequada
para o cliente.

Fase_09: Usar Checklist

interessante que a empresa desenvolvedora

faa uso de Checklist em suas atividades para
que problemas frequentes sejam percebidos.

Fase_10: Realizar Reunies

Realizar reunies possibilita que as diversas

partes envolvidas no desenvolvimento do

43

projeto

possam

opinar,

aprovar

se

comprometer em relao aos requisitos do

projeto.
Fase_11: Reavaliar Qualidades Tcnicas

Caso haja necessidade de modificar algum

requisito, a equipe tcnica dever reavalialos.

Logo

aps,

so

submetidos

para

aprovao da empresa contratante.

Fase_12: Documentar Novos Requisitos

Aps a reavaliao dos requisitos editados

por parte da empresa contratante, um registro
de

aprovao

deve

ser

obtido

pelos

fornecedores de requisitos. Este registro deve

ser tratado como um marco do projeto.
Fase_13: Classificar no Sistema de

importante que se tenha um sistema de

Rastreamento

rastreamento, pois, neste sistema onde h

detalhamento dos requisitos, transformao
em modelos, a codificao, o planejamento e
a execuo de testes so estruturados para
garantir a correta execuo do projeto, tendo
tarefas

previstas

discriminadas

em

um

cronograma ou conforme previsto pelo

processo Gerncia de Projetos - GP (Se
houver).
Fase_14: Rastrear Dependncias

A criao de um sistema de rastreabilidade

tanto pode ser vertical como horizontal;
pressupe-se que diferentes abstraes dos
requisitos, documentos relacionados e o
cdigo fonte sejam rastreveis entre si.

Fase_15: Verificar Itens Implementados

Os requisitos, dentro do ciclo de vida do

projeto, so posteriormente derivados em
elementos de anlise e projeto e ento,

44

transformados em cdigo fonte, para s

depois serem testados.
Fase_16: Avaliar Artefatos

Avaliao da consistncia entre os requisitos

e os produtos de trabalho do projeto.

Fase_17: Identificar Possveis

importante que revises sejam realizadas a

Inconsistncias

fim de identificar possveis inconsistncias

entre os requisitos e os demais elementos do
projeto (planos, atividades e produtos de
trabalho).

Fase_18: Registrar Aceite

Aps

passar

por

todas

as

fases

de

desenvolvimento, e a empresa contratante

decidir que no h inconsistncias e nem h a
necessidade de realizarem-se mudanas, um
registro de aprovao deve ser obtido pelos
fornecedores de requisitos. Este registro deve
ser

tratado

como

um

marco

no

desenvolvimento do projeto.
Fase_19: Resolver Possveis Inconsistncias

Caso haja inconsistncias, estas devem ser

registradas e aes corretivas executadas a
fim de resolv-las.

Fase_20: Examinar Possveis Mudanas

No caso de haver mudanas, importante

examinar se h consistncia em todos os
artefatos modificados.

Fase_21: Adequar Mudanas ao Escopo

Mudanas
documentadas

realizadas
juntamente

devem
aos

ser
outros

requisitos.
Fase_22: Revisar Requisitos

Durante o desenvolvimento do projeto, os

requisitos podem mudar por uma srie de
motivos. Desta forma, requisitos adicionais

45

podem

ser

incorporados

no

projeto,

requisitos podem ser retirados ou ainda

podem ser editados.
Fase_23: Analisar Possveis Mudanas

Caso haja necessidade de realizarem-se

mudanas nos requisitos, estas devem ser
registradas e um histrico das decises
acerca dos requisitos deve estar disponvel.

Fase_24: Analisar Impacto

So analisados aspectos como:

*Influncia de outros requisitos;
*Expectativa dos interessados;
*Esforo;
*Cronograma;
*Riscos;
*Custos;
Vale

ressaltar

que

mecanismo

de

rastreabilidade bidirecional de fundamental

importncia.
Fase_25: Editar Requisitos

Elaborao de um documento onde sejam

declarados os requisitos modificados.

Fase_26: Registrar Reprovao

Caso o cliente ou empresa contratante

aprovem os requisitos editados, esta ao
encaminhada para o nvel de mudana a fim
de resolver este problema. realizado um
registro de reprovao. Este registro deve ser
tratado como um marco do projeto.

Fase_27: Registrar Aceite

Quando h aceitao do cliente ou empresa

contratante, realizado um registro de
aprovao. Este registro deve ser tratado

46

como um marco do projeto.

Fase_28: Realizar Histrico das Decises

So registras as necessidades de mudanas

(se

houver),

informaes

assim

como

tomadas

todas

durante

as
o

desenvolvimento do projeto.
Tabela 1 Fases da Ferramenta.
Fonte: Softex (2013), adaptado.

Aps ter sido feito o levantamento dos requisitos foi realizada a modelagem da
ferramenta utilizando notaes BPMN no software BizAgi, como sero mostradas nas figuras
8.1 8.7;

Figura 8.1 Fases da Modelagem, Etapa de Elicitao dos Requisitos.

Fonte: O Autor.

Figura 8.2 Fases da Modelagem, Etapa de Avaliao dos Requisitos.

Fonte: O Autor.

47

Figura 8.3 Fases da Modelagem, Etapa de Rastreabilidade Bidirecional.

Fonte: O Autor.

Figura 8.4 Fases da Modelagem, Etapa de Reviso.

Fonte: O Autor.

Figura 8.5 Fases da Modelagem, Etapa de Mudana.

Fonte: O Autor.

48

Figura 8.6 Fases da Modelagem, Etapa de Avaliao por parte do Cliente.

Fonte: O Autor.

Figura 8.7 Modelagem Completa da Ferramenta.

Fonte: O Autor.

Ao ser concluda a modelagem dos requisitos, a modelagem dos dados da ferramenta

foi implementada, como se pode ver na figura 9:

Figura 9 Modelagem de Dados na Ferramenta.

Fonte: Autor.

49

O software BizAgi diferencia-se por ser intuitivo e completo, alm de possibilitar que
a interface com o usurio (fachada) tambm seja implementada, como se percebe na figura
10:

Figura 10 Implementao da Fachada.

Fonte: O Autor.

No diferente de outras plataformas para desenvolvimento de softwares, o BizAgi

tambm d suporte a implementao da regra de negcios (algo extremamente importante),
como mostra a figura 11:

50

Figura 11 Regra de Negcios.

Fonte: O Autor.

Desenvolver softwares, sempre uma tarefa realizada em equipe, e, para que cada
equipe tenha acesso a sua parte de interesse no desenvolvimento, o BizAgi permite que a
possibilidade de criar perfis e papeis, aonde os requisitos possam ser divididos em grupos
especficos, como mostra a figura 12:

51

Figura 12 Separao dos Grupos de Requisitos.

Fonte: O Autor.

Tomando como base o modelo de prototipagem de software, o prximo passo tomado

foi o teste da ferramenta, mas, antes que se possa acessar o sistema, preciso logar em uma
rea de atuao especfica de acordo com a funo de cada desenvolvedor, o que pode ser
observado na figura 13:

52

Figura 13 Tela de login.

Fonte: O Autor.

Aps acessar a conta, o desenvolvedor redirecionado para uma outra tela onde
poder iniciar suas tarefas, como mostra a figura 14:

Figura 14 Tela de Afazeres.

Fonte: O Autor.

Os testes no sistema so realizados como uma forma de revisar os requisitos

implementados para que erros e/ou inconsistncias possam ser resolvidos. Mudanas
realizadas foram documentadas como forma de manter controle do desenvolvimento desta
ferramenta.
Por fim, a ferramenta proposta neste projeto tem fortes indcios que atender aos
objetivos geral e especficos, uma vez que esta foi modelada e automatizada tendo como base
os princpios do MPS.BR nvel G.
Como se pode perceber, a ferramenta desenvolvida relacionou Tecnologia da
Informao Aplicada ao Processo de Negcios (BPMS) com as boas prticas do MPS.BR
nvel G, e, definiu um modelo de implantao com tempo especfico para cada tarefa, como
mostra a figura 15:

53

Figura 15 Grfico para Acompanhamento de Projetos.

Fonte: O Autor.

Com definio dos fluxos de trabalho e criao de papis para cada fase da
implementao do software, como est explicito nas figuras 16.1 16.3:

Figura 16.1 Criao e Definio do Papel de Analista.

Fonte: O Autor.

54

Figura 16.2 Criao e Definio do Papel de Equipe Tcnica.

Fonte: O Autor.

Figura 16.3 Criao e Definio do Papel de Gerncia.

Fonte: O Autor.

Para que possa ser feito o acompanhamento da evoluo dos processos, o bizagi gera
grficos onde so descriminadas as tarefas por usurios, alm de mostrar quantas tarefas esto
em dia bem como as atrasadas e informa quem deve faze-las, como mostra a figura 17:

55

Figura 17 Trabalhos em Andamento por Usurio.

Fonte: O Autor.

Para que possa ser acompanhado o tempo total de um ciclo de um processo uma tabela
com tais informaes gerada, como mostra a figura 18:

Figura 18 Resumo do Tempo de Ciclo.

Fonte: O Autor.

56

4 CONCLUSES

Desde o surgimento do termo engenharia de software em 1968, como aborda

Pfleeger (2004), o mundo passou a ser cada vez mais dependente do software, e, isso fez com
que a busca por qualidade se tornasse constante.
Com o aprimoramento dos sistemas computacionais tornou-se necessrio que normas
de qualidade surgissem para que houvesse certificao que os softwares produzidos
atenderiam as necessidades dos usurios, foi assim que surgiu o CMMI (Capability Maturity
Model Integration), e, inspirado neste, no Brasil foi criado o MPS.BR (Melhoria do Processo
de Software Brasileiro), SOFTEX (2013).
Muito embora o principal objetivo do MPS.BR seja auxiliar micro, pequenas e mdias
empresas a desenvolverem softwares de maneira eficiente, SOFTEX (2013), necessrio que
alguns nveis de maturidade sejam seguidos, inicialmente o MPS.BR sugere que seja adotado
o Nvel G em qualidade, por ser este o nvel mnimo para certificao dos produtos de
software, SOFTEX (2014).
Utilizar-se de processos (BPM) para transformar a modelagem (BPMS) de softwares
uma atividade inovadora e que possibilita gerenciar de forma mais eficiente os processos de
software produzidos, BPM, CBOK (2013).
Sendo assim, este trabalho visou unir qualidade a processo uma vez que, para o
desenvolvimento da ferramenta proposta foi adotado o Nvel G em qualidade proposto pelo
MPS.BR e a partir dele a modelagem foi montada com base em gerncia de requisitos. Vale
ressaltar que a principal proposta deste trabalho fazer com que a gerncia bem como as
especificaes dos requisitos possam ser controlados e acompanhados tanto pela empresa
desenvolvedora quanto pela empresa contratante, evitando-se possveis retrabalhos.
Para que o trabalho de desenvolvimento destes softwares seja uma atividade mais
efetiva, a ferramenta dispe de uma plataforma onde possvel controlar o tempo das
atividades alm de gerar grficos discriminatrios dos processos, til para correo de
gargalos identificados e eventuais problemas.

57

5 REFERNCIAS BIBLIOGRFICAS

ANJOS, Lcio Andr Mendona; MOURA, Hermano Perreli de; Um Modelo Para
Avaliao de Produtos de Software. Centro de Informtica - Universidade Federal de
Pernambuco (UFPE), 2014.

ATALLA, Fabiano (2012). Por que os Projetos de TI Fracassam? Disponvel em:

<http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/1532> no dia 03 de
setembro de 2014.

BATISTA, Denys Nepomuceno; SANTOS, Marcio (2012). Modelos Incremental, Espiral e

de
Prototipao.
Disponvel
em:
http://engenhariadesoftwareuesb.blogspot.com.br/2012/12/blog-post.html No dia 28 de
Outubro de 2014.

BARRIOS,
Bruno
(2012).
O
que

BPM?
Disponvel
em:
<http://www.tiespecialistas.com.br/2012/05/o-que-e-bpm/> No dia 14 de outubro de 2014.

CARVALHO,
Pedro
(2005).
O
MPS.BR.
Disponvel
http://www.pedrofcarvalho.com.br/mpsbr.html No dia 27 de Novembro de 2014.

em:

CERVO, Amado L.; BERVIAN, Pedro A.; DA SILVA, Roberto; Metodologia Cientfica.
So Paulo: Pearson Prentice Hall, 2007. 6 Ed.

DA SILVA, Fernando Rodrigues (2011). Testes de Software Nveis de Testes. Disponvel

em: http://www.devmedia.com.br/testes-de-software-niveis-de-testes/22282 No dia 28 de
Outubro de 2014.

DAVEMPORT, T. H.; MARCHAND, D. A. Dominando a Gesto da Informao. Porto

Alegre, Bookman, 2004.

DEVMEDIA, Equipe de Moderao (2012). Ciclos de Vida do Software: Conhecendo os

Bastidores. Disponvel em: http://www.devmedia.com.br/ciclos-de-vida-do-software-artigorevista-engenharia-de-software-magazine-36/21099 No dia 27 de Outubro de 2014.

58

FALBO, Ricardo de Almeida. Engenharia de Software: Notas de Aula. Universidade

Federal do Esprito Santo UFES, 2005.

FACCIO, Letcia Juciara. Qualidade de Software Aplicando Business Process Model and
Notation 2.0. Paran, 2011.

FERREIRA, Dcio; COSTA, Felipe; ALONSO, Filipe; ALVES, Pedro; NUNES, Tiago
(2005); SCRUM: Um Modelo gil para Gesto de Projetos de Software. Disponvel em: <
http://www.emprel.gov.br/files/es_final_19.pdf> No dia 30 de Outubro de 2014.

FILHO, Gilson Teixeira de Almeida (2013). Introduo a Engenharia de Software. Notas

de Aula.

FLICK, Uwe; Introduo a Pesquisa Qualitativa. Porto Alegre: Artmed 2009, 3 Ed.

FRANA, Renato (2014). Diferenas entre Programador e Desenvolvedor de Software.

Disponvel
em:
<renato-franca.com/diferenas-entre-programador-desenvolvedor-desoftware/> No dia 21 de outubro de 2014.

FURTADO, Andr, Pontas de Iceberg do Caos no Desenvolvimento de Software.

Disponvel
em:
http://www.microsoft.com/brasil/msdn/Tecnologias/Carreira/DesenvolvimentoSoftware.mspx
#top No dia 08 de setembro de 2014.

GARVIN, D. What does Product Quality Really Mean? Sloan Management Review,
1984.

GOMES, Alexandre; WILLI, Renato; REHEM Serge (2014); Mtodos geis Para
Desenvolvimento de Software. Disponvel em: < http://livrometodosageis.com.br/ > No dia
01 de Novembro de 2014.

ISO International Organization for Standardization, ISSO 9000: Gesto de Qualidade.

Disponvel
em:
<
http://translate.google.com.br/translate?hl=ptBR&sl=en&u=http://www.iso.org/&prev=search> No dia 08 de Novembro de 2014.

59

IEEE Institute of Eletricaland Eletronics Engineers, Standards Glossary of Software

Engineering Terminology. Std 610.12, N.Y., 1990.

Kent Beck and Cynthia Andres. Extreme Programming Explained: Embrace Change, 2nd
Edition. Addison-Wesley, 2 edition, 2004.

LEITE, Jair C. (2000); Anlise e Especificao de Requisitos. Disponvel em: <

http://www.dimap.ufrn.br/~jair/ES/c4.html> No dia 07 de Novembro de 2014.

LESSA, Rafael Orivaldo; JUNIOR, Edson Orivaldo Lessa; Modelos de Processos de

Engenharia de Software. Santa Catarina, 2009.

MACORATTI, Jos Carlos (2008). Um Esboo Sobre o Processo de Testes de Software.

Disponvel em http://www.macoratti.net/08/08/tst_sw2.htm No dia 28 de Outubro de 2014.

MAGALHES, I. L. E PINHEIRO W. B. (2007). Gerenciamento de Servios de TI na

Prtica: Uma abordagem com base na ITIL Editora Novatec 1 edio, ISBN: 978-857522-106-8.

MASTERHAUSE. O que BPM? Disponvel em: <http://www.masterhouse.com.br/sobrebpm/> No dia 14 de outubro de 2014.

NETO, Alfredo Colenci. Proposta de um Modelo de Referncia para Desenvolvimento de

Software com Foco na Certificao do MPS.BR. So Carlos, 2008.

OMG Object Managed Group. Business Process Model and Notation (BPMN).
Disponvel em: < http://www.bpmn.org/ > No dia 02 de Dezembro de 2014.

OTANI, Nilo; FIALHO, Francisco Antonio Pereira. TCC: Mtodos e Tcnicas.

Florianpolis: Visual Books, 2011, 2 Ed.

PFLEEGER, Shari Lawrence. Software Engineering Theory and Practice. So Paulo:

Prentice Hall, 2004. 2 Ed.

60

PRADO, Professor (ANO). Ciclo de Vida do Software. Disponvel em:

http://www2.dem.inpe.br/ijar/CicoloVidaSoftPrado.html No dia 27 de Outubro de 2014.

PRESSMAN, Roger S., Software Engineering. The McGraw-Hill Companies, Inc. So

Paulo, 2006, 6 Ed.

PRESSMAN, Roger S., Software Engineering: a Practitioners Approach. The McGraw-Hill

Companies, Inc., New York, EUA, 2011, 7 Ed.

PROTOCOLO TI (2012). Os modelos de Desenvolvimento de Software. Disponvel em:

http://protocoloti.blogspot.com.br/2012/03/os-modelos-de-desenvolvimento-de.html No dia
27 de Outubro de 2014.

QUITERIO, Ana Paula (2012); Anlise de Requisitos. Disponvel em: <

http://www.infoescola.com/engenharia-de-software/analise-de-requisitos/> No dia 07 de
Novembro de 2014.

RAMOS, Almir; CARLOS, Antonio; LEITO, Rafael Gonzaga; COSTA, Eryson Raphael
M.
(2011);
Modelo
Cascata
ou
Clssico.
Disponvel
em
http://modelocascata.blogspot.com.br/ No dia 27 de Outubro de 2014.

SGANDERLA, Kelly (2012). Um Guia para Iniciar Estudos em BPMN (I): Atividades e
Sequncia. Disponvel em: <http://blog.iprocess.com.br/2012/11/um-guia-para-iniciarestudos-em-bpmn-i-atividades-e-sequencia/ > No dia: 02 de Dezembro de 2014.

SOFTEX. 2013, MPS.BR Melhoria de Processo do Software Brasileiro, Guia de

Implementao Parte 1: Fundamentao para Implementao do Nvel G do MR-MPS.
Disponvel em: http://www.softex.br/mpsbr No dia 06 de Outubro de 2014.

SOFTEX. 2014, MPS-SV. Disponvel em: http://www.softex.br/mpsbr/mps/servicos/ No dia

03 de setembro de 2014.

SOMMERVILLE, Ian. Software engineering. So Paulo: Pearson Prentice Hall, 2011. 9 Ed.

61

SOUZA, Vincius Rodrigues De (2014). Prototipao no Desenvolvimento de Software.

Disponvel em: http://www.devmedia.com.br/artigo-engenharia-de-software-17-prototipacaono-desenvolvimento-de-software/14502 No dia 27 de Novembro de 2014.

THIVES JR., J. J. A Tecnologia de Workflow e a Transformao do Conhecimento. In:

ANGELONI, M.T (Org.). Organizaes do Conhecimento: infraestrutura, pessoas e
tecnologias. So Paulo, 2002.

VASCONCELOS, Alexandre Marcos Lins de; ROUILLER, Ana Cristina; MACHADO,

Cristina ngela Filipak; MEDEIROS, Tereza Maria Maciel de; Introduo Engenharia de
Software e qualidade de Software. Lavras: UFLA/FAEPE, 2006.

VOLPE, Renato Luiz Della; ZABEU, Ana Ceclia Peixoto (2004); Falando de Qualidade:
Gesto,
Processos
e
Meio
Ambiente.
Disponvel
em:
<
http://periodicos.anhembi.br/arquivos/hemeroteca/periodicos_vo/falando_de_qualidade/14200
8.pdf> No dia 08 de Novembro de 2014.

WHIRT, Niklaus (2012). Uma Breve Histria da Engenharia de Software. Disponvel em:
<http://marathoncode.blogspot.com.br/2012/07/uma-breve-historia-da-engenhariade_10.html> no dia 14 de outubro de 2014.