1
Universidade de Pernambuco
Faculdade de Ciência e Tecnologia de Caruaru
Bacharelado em Sistemas de Informação
UMA SOLUÇÃO ORIENTADA A PROCESSOS PARA AUXILIAR A
IMPLANTAÇÃO DO NIVEL G DO MPS.BR
Trabalho de Graduação
Sistemas de Informação
Ana Letícia Ferreira da Costa
Orientador: Prof. Msc. Rômulo César Dias de Andrade
2
ANA LETÍCIA FERREIRA DA COSTA
UMA SOLUÇÃO ORIENTADA A PROCESSOS PARA AUXILIAR A
IMPLANTAÇÃO DO NÍVEL G DO MPS.BR
Monografia
parcial
para
apresentada
obtenção
como
do
requisito
diploma
de
Bacharel em Sistemas de Informação pela
Faculdade de Ciência e Tecnologia de
Caruaru – Universidade de Pernambuco.
Caruaru, dezembro, 2014
3
Dedico este trabalho aos meus pais, Otávio
José
(in
memoriam)
e
Amparo,
pela
motivação aos estudos, amor e ensinamentos.
4
Agradecimentos
A Deus, por me dar perseverança, força, auxílio e fé para que esse trabalho pudesse ser
concluído.
A minha mãe, Amparo, por ser um verdadeiro amparo em minha vida, me orientando e
incentivando nos momentos de aflição.
Ao meu pai, Otávio José (in memoriam), que embora não esteja fisicamente comigo, seus
ensinamentos prevalecerão para sempre em minha vida.
As minhas avós, Valdeci (in memoriam), com seu modo simples de enxergar o mundo,
Marlene (in memoriam), que viu em mim aptidão para com os estudos e a minha bisavó Rosa,
com seu modo peculiar de apreciar o conhecimento.
A toda minha família pelo apoio incondicional, em especial aos tios: Zé Carlos, por ser um
exemplo de perseverança em relação 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 compreensão durante todos os momentos necessários para
elaboração deste trabalho.
Aos meus vizinhos, que indiretamente me forneceram internet.
Aos professores, que contribuíram com minha formação acadêmica, em particular ao meu
orientador, Rômulo César, pelo incentivo e força nos momentos de fraquejo.
Aos meus amigos pelo apoio dado durante toda a graduação, de modo notável, 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 contribuíram para que este trabalho acontecesse.
5
Resumo
Atualmente o cenário de competição e profissionalismo obriga organizações a buscarem
efetividades nos seus processos de desenvolvimento de software como uma forma de
aumentar a qualidade dos serviços 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 é inevitável, ocasionando requisitos de implementação
cada vez mais complexos, onde as fábricas de softwares utilizam modelos de referências para
guiar os seus processos. As empresas vêm melhorando os seus procedimentos de
especificação de requisitos, tendo em vista que as adoções de boas práticas trazem resultados
significativos para as mesmas. Diante desse cenário de processo e especificação de requisitos,
este trabalho apresenta um estudo sobre automação de processos com ênfase em BPMS
(Busines Process Management System) juntamente com a especificação de requisitos com
ênfase no Nível G do MPS.BR (Melhoria do Processo de Software Brasileiro). A finalidade
do trabalho proposto é de gerenciar a especificação de requisitos, controlando e dando
visibilidade de todas as etapas do processo e com isso melhorando a comunicação entre
empresas e clientes evitando assim interpretações 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 relatórios gerencias para as partes interessadas. Em virtude do uso de
um processo definido previamente, será possível identificar possíveis gargalos e trabalhar de
forma efetiva para corrigir eventuais problemas que possam existir na fase de especificação de
requisitos.
Palavras-chave: Qualidade de Software; Requisitos; BPMS; MPS.BR Nível G; Processo;
6
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;
7
INDICE DE FIGURAS
Figura 1 - Estrutura do Modelo de Prototipação ...................................................................... 21
Figura 2 - Correspondência 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 Elicitação dos Requisito ..................................... 46
Figura 9 - Modelagem de Dados na Ferramenta ...................................................................... 48
Figura 10 - Implementação da Fachada .................................................................................... 49
Figura 11 - Regra de Negócios ................................................................................................. 50
Figura 12 - Separação dos Grupos de Requisitos ..................................................................... 51
Figura 13 - Tela de login .......................................................................................................... 52
Figura 14 - Tela de Afazeres .................................................................................................... 52
Figura 15 - Gráfico para Acompanhamento de Projetos .......................................................... 53
Figura 16.1 - Criação e Definição do Papel de Analista .......................................................... 53
Figura 17 - Trabalhos em Andamento por Usuário .................................................................. 55
Figura 18 - Resumo do Tempo de Ciclo................................................................................... 55
8
INDICE DE TABELA
Tabela 1 - Fases da Ferramenta ................................................................................................ 46
9
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 Negócios
DSDM
Dynamic Systems Development Methodology
ISO
International Organization for Standardization
MCT
Ministério da Ciência e Tecnologia
MPS
Melhoria do Processo de Software
MPS.BR
Melhoria do Processo de Software Brasileiro
MR-MPS
Modelo de Referência do MPS.BR
PMBOK
Project Management Body of Knowledge
Sepin
Secretaria de Política de Informática
SEI
Software Engineering Institute
SWEBoK
Software Engineering Body of Knowledge
SW-CMM
Software Capability Maturity Model
TI
Tecnologia da Informação
UML
Linguagem de Modelagem Unificada
10
SUMÁRIO
1 INTRODUÇÃO ................................................................................................................... 11
1.1 CARACTERIZAÇÃO DO PROBLEMA .......................................................................... 12
1.2 OBJETIVOS ....................................................................................................................... 13
1.3 JUSTIFICATIVA ............................................................................................................... 13
1.4 METODOLOGIA DA PESQUISA .................................................................................... 14
1.5 ORGANIZAÇÃO DO TRABALHO ................................................................................. 16
2 REFERENCIAL TEÓRICO .............................................................................................. 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 GESTÃO 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 Nível G de Qualidade ...................................................................................................... 31
2.4 GERENCIAMENTO DE PROCESSOS DE NEGÓCIOS (BPM) .................................... 32
2.4.1 Tecnologia da Informação Aplicada à Gestão por Processos (BPMS) ........................... 35
2.5 CONSIDERAÇÕES FINAIS ............................................................................................. 39
3 RESULTADOS E DISCUSSÕES ...................................................................................... 41
4 CONCLUSÕES.................................................................................................................... 56
5. REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................. 57
11
1 INTRODUÇÃO
A invenção dos computadores foi algo que revolucionou a humanidade, pois, a partir do
surgimento e evolução destes objetos, Filho (2013), pessoas passaram a depender cada vez
mais da comodidade oferecida por estes. Para tanto, é necessário que os softwares
desenvolvidos atendam sempre aquilo que o usuário final anseie. É neste cenário que se
destaca a engenharia de software e todas as facilidades oferecidas por esta área tão promissora
Filho (2013).
Portanto, para que o produto de software desenvolvido tenha qualidade, seja entregue no
prazo definido, tenha um custo razoável e ainda atenda às necessidades dos usuários é
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 não se deve esquecer é que, softwares caóticos e ineficientes
levam organizações desenvolvedoras a perderem mercado, Filho (2013).
Motivar organizações às práticas proporcionadas pela qualidade é um desafio constante já
que muitas das organizações deixam esta prática como segundo plano; investir em qualidade é
algo que só traz benefícios, uma vez que serão observados os produtos de softwares
desenvolvidos assim como o grau de maturidade em que a empresa se encontra com a
finalidade de obter certificação de qualidade, Gomes (2000).
Presentemente existem alguns órgãos responsáveis 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 são 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 negócios (BPM) no desenvolvimento de
softwares é algo muito útil e quando agregado as práticas de qualidade transformam-se em
algo extraordinariamente proveitoso. Utilizar BPM em um processo de software possibilita a
transformação deste processo, BPM, CBOK (2013), pois é possível representa-lo
graficamente bem como automatiza-lo, não esquecendo de que também é possível fazer o
gerenciamento destes processos em desenvolvimento.
12
Antes de se pensar que é impossível fazer esta integração entre dois processos distintos,
sendo um voltado a qualidade e o outro à automação, lembremo-nos das oportunidades
oferecidas pelo Busines Process Management System (BPMS), como forma de automatizar a
gestão de processos de negócios.
Sendo assim, este projeto busca criar uma solução orientada a processos com o uso de
BPMS, o mesmo toma como ênfase o modelo de melhoria e avaliação do processo de
software MPS.BR nível G para que micro, pequenas e médias empresas possam adotar esta
ferramenta como metodologia de trabalho.
1.1 CARACTERIZAÇÃO DO PROBLEMA
Entende-se por engenharia de software o estabelecimento e uso de sólidos princípios
que integra métodos, ferramentas e procedimentos para o desenvolvimento de softwares.
Quanto à qualidade são todos os artefatos produzidos durante seu desenvolvimento, ou seja,
modelos, documentos, relatórios, código fonte, código executável, cronograma, etc., estes,
tem que satisfazer as necessidades dos clientes, colaboradores, acionistas e usuários finais.
Uma pesquisa realizada com organizações 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 são ocasionados quando o cliente, ou usuário final é
ignorado, pois, a falta de envolvimento desta parte, durante todo o desenvolvimento do
projeto, está diretamente relacionada ao fracasso.
Analisando tal cenário, em 2003 a Associação para Promoção da excelência do
Software Brasileiro (SOFTEX), que conta com o apoio de diversas empresas e ministérios
criou o MPS.BR (Melhoria de Processos do Software Brasileiro), este programa, busca
atender as necessidades do mercado e, ao mesmo tempo, manter os padrões de qualidade
exigidos por órgãos competentes, o MPS.BR subdivide-se em 7 níveis, que vão do G (sendo
este, o nível mínimo de qualificação) ao A (sendo este, o nível máximo de qualificação) .
Sabe-se, que o mercado de Tecnologia da Informação (TI), está cada vez mais
crescente e cada vez mais quebrando barreiras geográficas; é nesse cenário que, em
Pernambuco, destaca-se um grande polo de desenvolvimento e soluções inovadoras, o Porto
13
Digital, que age como uma “incubadora de empresas”, onde, para se desenvolver softwares, é
essencial que se tenha certificação nível G.
É diante desse cenário que surge a seguinte problemática: Como utilizar processos
automatizados para auxiliar na implantação do MPS.BR nível G?
De acordo com Sommerville (2011), um software além de corresponder às
expectativas do usuário, precisa ser confiável; e para ser confiável, precisa seguir padrões de
qualidade, tais padrões são ditados pelo MPS.BR, que segue modelos e normas internacionais
a fim de que a indústria de software nacional atenda cada vez mais as necessidades dos seus
clientes.
1.2 OBJETIVOS
Este trabalho tem como objetivo geral propor uma solução automatizada que guie as
empresas a partir dos processos Nível G do MPS.BR na implantação deste programa.
E como objetivos específicos:
o Compreender os processos do MPS.BR Nível G e relacionar suas boas práticas com
BPM.
o Definir um modelo de implantação do MPS.BR nível G orientada a processos através
de um BPMS(Tecnologia da Informação Aplicada a Gestão de Processos)
o Estimar o tempo para as atividades de implantação.
o Criar papéis e fases de implantação.
o Definir fluxos de trabalho.
1.3 JUSTIFICATIVA
Como já é costume, a maior parte de micro, pequenas e médias empresas utilizam
metodologias tradicionais para realizarem suas tarefas, porém nem sempre utiliza-las surte o
efeito esperado, Magalhães e Pinheiro (2007).
14
A pratica de Business Process Model and Notation (BPMN) contribui para um ambiente
de trabalho mais dinâmico, além de proporcionar maior comodidade quanto às atividades de
execução de estratégia de negócios que estas empresas estabelecem. Já as normas de
qualidade MPS.BR servem para atribuir métricas a fim de que estas empresas possuam
certificação 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 práticas no processo de
negócios e a outras voltada a qualidade, MPS.BR, como forma de melhorar gradativamente o
processo de software destas empresas, para tanto daremos ênfase ao Nível G de qualidade por
ser este o nível mínimo de qualificação que uma empresa deve ter.
A proposta de implantação do Nível G do MPS.BR através de uma ferramenta orientada a
processos, para micro, pequenas e médias empresas sobressai-se por ser dinâmica, ágil e
intuitiva assim como é proposto pelo BPMN. Porém, de acordo com Magalhães e Pinheiro
(2007) mudar a cultura organizacional de empresas é uma tarefa árdua, mesmo que o objetivo
seja aumentar a produção e a qualidade dos produtos e serviços pois os gestores estão
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 propõe às empresas automação 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 responsável por uma fase, ou seja, a ferramenta indica
a definição do fluxo dos trabalhos correntes na empresa.
1.4 METODOLOGIA DA PESQUISA
Entende-se por metodologia, um conjunto de regras e métodos, ou seja, procedimentos
organizados que conduzem a certo resultado. De acordo com Cervo, Bervian e Da Silva
(2006), nos estudos científicos, os métodos são conjuntos de processos utilizados para
investigar a demonstração da verdade. Sendo assim, como forma de validar esta pesquisa,
algumas etapas consideradas cruciais foram abordadas.
15
A presente pesquisa caracteriza-se por ser exploratória, pois, segundo Cervo, Bervian e Da
Silva (2006), este tipo de pesquisa realiza descrições precisas e quer descobrir as relações
existentes entre seus elementos componentes. Para tanto será desenvolvida uma ferramenta
orientada a processos; esta auxiliará a implantação do nível G em empresas desenvolvedoras
de software, seguindo as normas estabelecidas pelo MPS.BR.
Ainda de acordo com Cervo, Bervian e Da Silva (2006) qualquer espécie de pesquisa e em
qualquer área de estudo, é primórdio que seja feita uma pesquisa bibliográfica; seguindo este
pensamento, um estudo bibliográfico detalhado sobre engenharia e modelagem de software,
gestão de qualidade com base no MPS.BR nível G e Busines Process Management Suite
(BPMS) foi realizado, tendo como objetivo criar embasamento teórico para esta pesquisa.
Para que pudesse ser feito o acompanhamento do desenvolvimento da ferramenta, foi adotado
o modelo de prototipagem de software, este, gera versões 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 satisfatória ao desenvolvimento desta ferramenta,
uma maior explanação acerca do assunto será exibido no capítulo 2.
Ao ser efetivada a revisão da literatura, descrita no capítulo 2 observou-se a importância
de conectar gerenciamento de processos à qualidade de software, tendo em vista viabilizar o
desenvolvimento de softwares realizado por micro, pequenas e médias empresas.
Para finalizar foi realizada uma pesquisa qualitativa, que, de acordo com Otani e Fialho
(2011), são levados em conta a relação diligente entre objetividade e subjetividade o qual não
pode ser traduzido em números; para Flick (2009) este tipo de pesquisa consiste na relevância
e análise de diferentes perspectivas para o pesquisador, já que são levadas em conta variedade
das abordagens bem como os métodos reflexivos no que diz respeito ao processo de produção
do conhecimento. Uma pesquisa qualitativa “não requer o uso de métodos e técnicas
estatísticas” (OTANI, FIALHO, 2011, p. 38) já que, ainda de acordo com Otani e Fialho
(2011) os dados necessários para realização da coleta estão disponíveis 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 são os focos principais da
abordagem.” (OTANI, FIALHO, 2011, p. 38).
16
1.5 ORGANIZAÇÃO DO TRABALHO
O conteúdo deste trabalho está estruturado em cinco capítulos:
o No capítulo 1 foi feita uma breve introdução acerca dos principais motivos que
levaram a realização deste trabalho, seus objetivos e metodologia utilizada;
o No capítulo 2 foi feita a revisão da literatura que aborda assuntos como engenharia de
software e o modelo de prototipagem de desenvolvimento, modelagem e gestão da
qualidade de software e para finalizar, foi tratado do tema BPM;
o Capítulo 3 apresenta os resultados, assim como as discussões acerca do estudo
realizado;
o E para finalizar, o capítulo 4 aborda as conclusões deste trabalho.
2 REFERENCIAL TEÓRICO
Como forma de embasar a pesquisa aqui apresentada, foi-se analisado o estudo da arte
referente à engenharia de software. O presente referencial teórico traz como peças chave, a
modelagem de software, que de acordo com Pfleeger (2004), modelar softwares é analisar os
procedimentos necessários para que ações possam ser acompanhadas e tomadas de forma
correta; gestão da qualidade de software, que, segundo Pressman (2011) é o processo onde se
verifica os requisitos existentes no projeto, bem como o grau de satisfação do cliente;
MPS.BR com ênfase no nível G de qualidade, de acordo com o guia de implementação
desenvolvido pela SOFTEX tal programa busca atender as necessidades do mercado ao
mesmo tempo que mantém os padrões de qualidade exigidos por órgãos 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 funções que tem por objetivo modelar processos de negócios de maneira
padronizada.
17
2.1 ENGENHARIA DE SOFTWARE
Assim como aconteceu à humanidade, com o software não foi diferente; ambos
sofreram intensas evoluções, cada uma ao seu tempo e com sua importância.
O software passou a fazer parte da vida das pessoas de tal forma que não conseguimos
imaginar o mundo sem as facilidades oferecidas a nós por eles. Mas nem sempre foi assim,
segundo Wirth (2012), no princípio havia muitas limitações 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 programação baixo nível; foi apenas nos 60,
quando os computadores ganharam características multiprogramação que houve a
popularização destes, porém, tal popularização trouxe consigo a necessidade de se
desenvolver programas e aplicativos cada vez mais robustos; para tanto, era necessária a
contínua evolução do hardware agregada à experiência dos programadores, na prática, as
coisas não funcionavam desta forma, as melhorias no hardware, prometidas pelas grandes
empresas que fabricavam os computadores não eram cumpridas, nem tão pouco, os
programadores eram dotados de experiência nesta “nova área”.
Em 1968, uma conferência patrocinada pela NATO, foi dedicada ao tema (1968 em
Garmisch-Partenkirchen, Alemanha). Apesar de críticas terem ocasionalmente sido
expressas anteriormente, só após a conferência 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 mudanças expressivas ao longo dos últimos cinquenta anos. Algumas dessas
mudanças foram,
Aperfeiçoamento significativo no desempenho do hardware, mudanças profundas nas
arquiteturas computacionais, vasto aumento na capacidade de memória e armazenamento, e
uma ampla variedade de exóticas opções de entrada e saída, tudo isso resultou em sistemas
computacionais mais sofisticados e complexos. (Pressman, 2011, p.31).
18
Para Falbo (2005) desenvolver softwares não deve ser confundido com programar
softwares. Estas são 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, através de métodos, técnicas, ferramentas, dentre outros”
(FALBO, 2005, Introdução), a este conjunto de métodos atribuímos o nome de engenharia de
software. Para França (2012), programar softwares é escrever códigos a partir de uma
linguagem de programação existente, revisar e realizar testes de modo que haja uma interação
entre o hardware, o sistema operacional e o usuário final.
Ambos os processos são estritamente parecidos, porém, para Sommerville (2011) a
engenharia de software foca todas as metodologias de desenvolvimento, desde o estágio
inicial, onde são obtidas as especificações necessárias do sistema até sua manutenção, 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 são
comuns a todos os projetos, por exemplo: elicitação dos requisitos, onde os clientes e
engenheiros se reúnem a fim de definir o software a ser produzido, bem como suas restrições;
desenvolvimento do software, ou seja, fase onde os requisitos definidos são programados e é
feita uma projeção; validação do software, nesta etapa, é feita uma análise do software
produzido, para garantir que o mesmo está de acordo com as especificações do cliente;
evolução do software, isto acontece quando há necessidade de modificação, ou seja, quando
há uma atualização da versão 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 versão operacional do sistema.
(DevMedia 36, 2012, p.1).
Pode-se dizer que os modelos de ciclo de vida funcionam como a estrutura onde serão
ajustadas as fases do projeto para que assim, este vá tomando forma; outro ponto de
notoriedade nesta etapa é a detecção de erros; pois bem, o erro, quanto mais cedo for
descoberto, mais vantajoso o é, pois assim evita-se o retrabalho, além 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 DevMédia (2014), não existe um modelo de ciclo de vida específico
para cada projeto, a escolha de um ou mais modelos vai depender da complexidade do
negócio do cliente, bem como nível de confiabilidade, ambiente operacional, custos, equipe
de desenvolvimento, dentre outros fatores.
Para que haja acompanhamento dos desenvolvedores e da empresa contratante e uma
documentação atualizada para assim haver validação de cada uma das etapas, os projetos
fazem uso de modelos de software, alguns desses modelos são:
o Modelo Cascata: Este modelo tem como finalidade de “estabelecer ordem no
desenvolvimento de grandes produtos de software.” (RAMOS, CARLOS,
LEITÃO, COSTA, 2010, Introdução); 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 criação de testes de dados e cenários
de teste durante o ciclo de desenvolvimento do software, e trabalha com
diferentes níveis de testes como: unidade, integração, sistema e aceitação.”
(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 são incrementadas até sua versão final, daí o
nome “modelo incremental”. Neste tipo de modelo, o cliente acompanha
diretamente cada fase de desenvolvimento do projeto, além de poder opinar se
tudo está saindo como o esperado.
o Modelo Evolutivo: Este tipo de modelo tem como desígnio “apresentar
características que possibilitem desenvolver versões 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 “junção” dos
modelos cascata, prototipação e também o modelo interativo.
o Rational Unifield Process (RUP): O RUP é um processo bem estruturado
para que o desenvolvimento de softwares seja uma tarefa previsível e repetível
possui alta qualidade além de levar em conta a acuidade da comunicação com
20
os clientes, é “iterativo e incremental, proporcionando a sensação
evolucionária que é essencial no desenvolvimento de software moderno.”
(PRESSMAN, 2011, p. 72).
2.1.1 Prototipagem de Software
“Prototipação, é a montagem de protótipos, ela pode ser classificada de acordo com
uma variedade de dimensões.” (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, documentação, codificação, testes, entre outros, são
considerados, porém, não necessariamente estas etapas precisam ser seguidas de modo
formal.
Este tipo de modelo de desenvolvimento oferece vantagens, como por exemplo:
o Requisitos necessários não precisam ser totalmente declarados no início de um
projeto, e, podem ainda ser editados caso haja essa necessidade.
o A entrega do protótipo é feita ao cliente assim como as especificações e definições
para que o usuário final saiba utilizar o software; a satisfação e entendimento destes
usuários são levados em conta.
Estas vantagens oferecidas servem para certificar que o ambiente de desenvolvimento
destes softwares está sendo funcional, Lessa, Júnior (2009), pois, o principal objetivo da
prototipagem é que a construção total ou parcial de um produto de software seja feita de
forma rápida para que assim a equipe desenvolvedora bem como os usuários finais cheguem a
um consenso do que realmente é necessário para a construção de um software, Pfleeger
(2004).
O modelo de prototipagem, tem como intuito revelar ao cliente uma versão inicial do
sistema, esta primeira versão serve para “testar” possibilidades, ou seja, “mostrar conceitos,
experimentar opções do projeto e, em geral, para conhecer mais sobre os problemas e suas
possíveis soluções.” (BATISTA; SANTOS; 2012, p.1), evitando-se assim, gastos com futuras
correções de erros. A figura 1 mostra a estrutura do modelo de prototipação.
21
Figura 1 Estrutura do Modelo de Prototipação.
Fonte: Pfleeger (2004).
Protótipos de software, servem para auxiliar diligências no processo de engenharia de
requisitos, já que, na maioria dos projetos, a versão beta serve apenas de orientação quanto ao
bom funcionamento, rapidez na execução entre outros fatores que dizem respeito à qualidade.
Esta prototipação pode ser mostrada aos usuários de diversas formas, modelo executável, bem
como, projeções, protótipos de papel, protótipos existentes, etc.
2.2 MODELAGEM DE SOFTWARE
“Modelagem abrange tanto análise quanto projeto, descrevendo representações do
software que se tornam progressivamente mais detalhadas.” (Pressman, 2011, p. 123).
Para Castilho (2008), modelar software é algo parecido à planta de uma casa, é a
representação simplificada de algo real. Tais representações 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 usuário final almeje. De
acordo com Sommerville (2011), atualmente os modelos de software são, na maioria das
vezes representados por algum tipo de notação gráfica baseadas em notação UML (linguagem
de modelagem unificada), porém, também é possível que tal representação seja feita por
modelos matemáticos como forma de se especificar detalhes do sistema.
Desse modo, este trabalho aborda as técnicas utilizadas a partir das notações UML sob
uma perspectiva estrutural, já que será criada uma modelagem a fim de exemplificar os
requisitos que comporão a ferramenta orientada a processos. Neste novo modelo de sistema os
requisitos estarão documentados a fim de facilitar o entendimento e também, para seguir
normas de qualidade ditadas pelo MPS.BR.
“Os modelos estruturais podem ser modelos estáticos, que mostram a estrutura do
sistema, ou dinâmicos, que mostram a organização do sistema quando ele está em execução.”
(SOMMERVILLE, 2011, p. 89). Como será desenvolvida uma ferramenta orientada a
processos, está será estruturada de modo estático e dinâmico, pois, após finalizar a
modelagem, está será automatizada.
Para tanto, no momento da modelagem, serão utilizados diagramas de classes para que
se tornem mais claras as associações existentes entre elas; além disso, também será detalhado
nessa modelagem, modelos semânticos de dados, “eles mostram as entidades dos dados, seus
atributos associados, e as relações entre essas entidades.” (SOMMERVILLE, 2011, p. 90),
funcionam como uma espécie de banco de dados, já que, os diagramas UML não os possui;
muitas vezes, os dados podem ter características em comum, e, quando isto acontece, a UML
dispõe de um tipo especial de associação entre as classes, conhecida por agregação 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 diversão.” (PRESSMAN,
2011, p. 127). Bem, a tarefa de desenvolver softwares é sim empolgante, e, por tal motivo,
muitos desenvolvedores esquecem de levantar os requisitos necessários para o sucesso do
projeto.
23
Apesar de parecer desnecessário que haja documentação e acompanhamento do
projeto que está sendo desenvolvido, erros graves podem vir a surgir caso não haja
planejamento das ações que deverão ser tomadas; por tudo isso, criou-se o termo engenharia
de requisitos, esta, serve como referência para as atividades de desenvolvimento e
acompanhamento de projetos de software, pois,
Na perspectiva do processo de software, a engenharia de requisitos é uma ação de
engenharia de software importante que se inicia durante a atividade de comunicação e
contínua na de modelagem. Ela deve ser adaptada às necessidades do processo, do projeto,
do produto e das pessoas que estão realizando o trabalho. (Pressman, 2011, p. 127).
É a partir da engenharia de requisitos que são analisadas as propostas dos clientes, que,
de acordo com Pressman (2011), seguem sete tarefas distintas onde algumas ocorrem em
paralelo, e ambas são utilizadas de acordo com as necessidades de cada projeto; estas tarefas
são:
o Concepção: Nesta fase os clientes formalizam os requisitos fundamentais,
determinam as restrições primordiais dos projetos e abordam as principais
características e desempenhos que devem estar presentes para que o sistema atenda às
necessidades dos clientes ou usuários finais.
o Levantamento: Na fase de levantamento dos requisitos é importante que sejam
realizadas reuniões com a presença da equipe desenvolvedora bem como dos clientes,
para que sejam definidas as necessidades bem como as funcionalidades do software
desenvolvido.
o Elaboração: A fase de elaboração é responsável por expandir as necessidades
identificadas nas fases de concepção e levantamento, por meio de conjuntos de
elementos comportamentais, orientados a fluxos e baseados em cenários e classes, este
modelo, faz ainda alusões a padrões de análises, e soluções para problemas recorrentes
em distintas aplicações, Presman (2011).
o Negociação: Fase em que a prioridade dos requisitos bem como a disponibilidade e os
custos relativos são analisados e negociados pela equipe desenvolvedora e também
pelos interessados no projeto.
o Especificação: “Descrição sistemática e abstrata do que o software deve fazer, a partir
daquilo que foi analisado.” (LEITE, 2000, p.1). Após esta análise, são levantados
24
possíveis problemas no software que será implementado, e, soluções são mostradas
para que tais problemas sejam efetuados de forma segura; tem uma visão voltada para
a comunicação sistemática entre as classes, pois assim, indica quais das propriedades
funcionais são mais diligentes para resolver o problema de domínio.
o Validação: Como certificação que foi feito aquilo que o cliente ou usuário final
deseja, esta responsabilidade recai sobre a validação dos requisitos. Além disso, esta
fase também é responsável por corrigir possíveis erros no projeto como um todo,
evitando que sejam necessários retrabalhos após a entrega da versão final ao cliente.
o Gestão: Fase de extrema importância para a engenharia de requisitos já que nesta fase
a equipe de desenvolvimento consegue controlar, identificar e acompanhar as
mudanças feitas ao longo do desenvolvimento do projeto.
Para o Institute of Eletricaland Eletronics Engineers (IEEE, 1990), analisar requisitos
de software é uma cadeia onde são ponderadas as necessidades dos clientes, e, a partir delas
são determinados “o sucesso ou fracasso do projeto” (QUITERIO, 2012). É primordial que os
requisitos que foram levantados, sejam relevantes para o projeto,
Pois, eles fornecerão a referência para validar o produto final, estabelecerão o acordo entre
cliente e fornecedor sobre o que o software fará, e consequentemente reduzirão os custos de
desenvolvimento, pois requisitos mal definidos implicam num retrabalho. (QUITERIO,
2012, p.1).
2.3 GESTÃO DE QUALIDADE
Na engenharia de software estabelecer metas e cumprir prazos é de suma importância
para que se obtenha excelência no produto produzido. Com a evolução constante deste
mercado, empresas desenvolvedoras de software estão mais conscientes que nunca de que
qualidade e produtividade andam juntas, e, para que haja eficiência nestas tarefas, o processo
de produção de softwares deve ser eficiente.
Ao pensarmos em qualidade, imaginamos algo livre de erros ou defeitos, e em
excelentes condições, 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 especificação,
conhecimento do processo para melhora-lo, efetividade e usabilidade.” (VASCONCELOS et
al., 2006, p. 73).
Como visto, definir qualidade não é uma tarefa fácil, já que esta pode ser vista de
vários ângulos; no campo da engenharia de software este é um termo a ser tratado com
delicadeza já que softwares são bens intangíveis além de que podemos estar nos referindo a
qualquer etapa do processo de software, que vai desde uma visão transcendental até uma visão
de mercado. Garvin (1984) comenta detalhadamente quais são as perspectivas de qualidade e
o que elas significam:
o
Visão Transcendental: Onde a qualidade é algo que podemos
reconhecer, mas não podemos definir.
o
Visão do Usuário: Onde a qualidade é adequação ao propósito
pretendido.
o
Visão do Fabricante: Onde a qualidade é a conformidade com a
especificação.
o
Visão do Produto: Onde a qualidade está relacionada às
características inerentes ao produto.
o
Visão do Mercado: Onde a qualidade depende do valor que os
consumidores
estão
dispostos
a
pagar
pelo
produto.
(GARVIN, 1984, p. 25-45).
De acordo com Pfleeger (2004), devemos considerar a qualidade de software a partir
de três ângulos:
o Qualidade do Produto: Esta característica deve ser analisada sob dois pontos de
vista; do usuário, estes vão analisar se o software desenvolvido corresponde a suas
expectativas, ou seja, se ele faz aquilo que foi projetado para fazer, o usuário analisa
ainda se o software é intuitivo, fácil de ser utilizado e possui alguma falha; e dos
desenvolvedores do produto, estes tem a função de considerar todas as características
do produto antes deste ser entregue ao usuário, por exemplo, defeitos, qualidades, etc.
26
o Qualidade do Processo: O processo de análise da qualidade do software
desenvolvido é considerado por muitos engenheiros como sendo de vital importância
para um bom funcionamento do projeto, pois, projetos passam por muitas fases e
etapas, e caso em alguma destas não for bem realizada, a qualidade pode sofrer algum
tipo de consequência; por isso deve-se dar ênfase ao processo de desenvolvimento, e
este deve ser melhorado constantemente para que hajam evoluções na qualidade,
assim como nos produtos resultantes.
o Qualidade no Contexto do Ambiente de Negócios: Aqui o enfoque da observação
está voltado para uma perspectiva de negócios, ou seja, a qualidade é mensurada a
partir de produtos e serviços que dão suporte ao desenvolvimento de softwares; a
partir de pesquisas foi analisado que, ao se melhorar a qualidade do software seu valor
comercial também aumenta.
Com os constantes avanços tecnológicos, com o crescimento do mercado de Tecnologia
da Informação (TI), e com um público alvo cada vez mais exigente, a Organização
Internacional de Padronização (ISO) foi criada, esta tinha o intuito de realizar auditorias
internas para verificar o funcionamento do sistema de gestão de qualidade (ISO 9000). Pois
bem, controlar a qualidade é uma ação que demanda muita responsabilidade, pois, fazer este
controle total implica em uma representação de um sistema funcional, onde são integradas
atividades como qualidade de desenvolvimento, manutenção além de esforços de melhoria da
qualidade.
2.3.1 Qualidade de Software
Como foi visto, o mercado de TI está em constante crescimento e evolução, e, a busca
por produtos que ofereçam qualidade é algo cada vez mais almejado pelos usuários; investir
na qualidade desses softwares é uma tarefa que está “diretamente relacionada a um
gerenciamento rigoroso de requisitos, uma gerência efetiva de projetos e um processo de
desenvolvimento bem definido, gerenciado e em melhoria contínua.” (VASCONCELOS et
al., 2006, p. 81).
27
No sentido mais geral a qualidade de software deve ser definida como: uma gestão de
qualidade efetiva aplicada de modo a criar produto útil que forneça valor mensurável por
aqueles que o produzem e para aqueles que o utilizam. (Pressman, 2011, p. 360).
Devemos lembrar que os softwares são desenvolvidos por pessoas, e, muitas vezes as
limitações humanas fazem com que erros de lógica ou erros de interpretação influenciem no
cumprimento das metas estabelecidas; investir na qualidade dos softwares desenvolvidos só
traz benefícios as empresas, pois, são evitados retrabalhos e correções de defeitos após o
software ser entregue ao usuário, sem contar que há um aumento na produtividade assim
como um melhor relacionamento com os clientes ou usuários finais já que há um melhor
planejamento e gestão por parte da empresa.
Segundo Pressman (2011), existem três definições importantes para medir a qualidade
dos softwares:
o Gestão da Qualidade: Aqui são estabelecidas informações e metas que darão
suporte ao processo de criação do software.
o Produto Útil: Caracteriza-se como tal um produto de software, porém, este
deve atender as necessidades dos clientes, devem ser isentos de erros além de
fornecer confiabilidade.
o Agregue Valor tanto para o Fabricante quanto para o Usuário: A empresa
desenvolvedora deve disponibilizar o mínimo de atualizações possíveis, ou esta
vai perder credibilidade junto ao mercado consumidor de softwares.
Para Volpe et al. (2004), desde 1993 a Secretaria de Política de Informática (Sepin)
que faz parte do Ministério da Ciência 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 contínua da qualidade nos
processos de desenvolvimento dos softwares brasileiros.
Adotar um modelo de qualidade traz benefícios em todos os sentidos para uma
organização, por exemplo,
Aumento de produtividade, redução no número de defeitos em produtos, maior
previsibilidade e visibilidade dos processos, além do atendimento das metas de custo,
prazo, funcionalidade e qualidade do produto desenvolvido, além de aumentar a motivação
da equipe. (VOLPE et al. 2004, p. 48).
28
Atualmente existem diferentes modelos de qualidade que podem ser seguidas por
organizações que desenvolvem de software, são elas (Volpe 2004):
o Capability
Maturity
Model
(CMM):
Desenvolvido
pelo
Software
Engineering Institute (SEI), este modelo descreve um caminho evolucionário
no que diz respeito a maturidade; possui cinco níveis de qualidade, sendo
assim, quanto maior o nível, maior a maturidade nos processos de
desenvolvimento de software de uma empresa.
o Capability Maturity Model Integration (CMMI): Também desenvolvido
pelo SEI, porém 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 práticas em gerencia de projetos; este guia traduz os
conhecimentos mais atuais da prática de gerenciar projetos no mundo inteiro.
o Software Engineering Body of Knowledge (SWEBoK): Guia de uso
contendo as melhores práticas da engenharia de software.
o ISO 9001 – Sistema de qualidade: Modelo para garantia da qualidade em
projetos, desenvolvimento, produção, instalação e serviços associados:
“Esta norma é baseada em uma série de princípios de gestão da qualidade,
incluindo um forte foco no cliente, a motivação e o envolvimento da gestão,
abordagem de processo e melhoria contínua.” (ISO 9001: 2008).
o ISO 12207 – Tecnologia da Informação: Avaliação 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 nível
G de qualidade; a próxima seção detalhará melhor as funcionalidades deste método.
2.3.2 Melhoria do Processo de Software Brasileiro (MPS.BR)
O MPS.BR foi criado em dezembro de 2003 pela Associação Para Promoção do
Software Brasileiro (SOFTEX), esta conta com o apoio do Ministério de Ciência e Tecnologia
29
(MCT), Financiadora de Estudos e Projetos (FINEP), Serviço 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 Serviços no Brasil,
porém, com um atendimento voltado às empresas de pequeno e médio porte. Esta
metodologia busca satisfazer as necessidades deste mercado que se encontra em constante
expansão; tal programa busca ainda reconhecimento nacional bem como internacional por ser
um modelo eficaz e que presta serviço às comunidades desenvolvedoras de software.
Como forma de averiguar se este processo está sendo empregado da forma correta, o
MPS.BR dispõe de processos e métodos para que sejam realizadas avaliações. Agindo deste
modo, embora pareça bobagem, o MPS.BR está contribuindo para que os softwares nacionais
possuam certificação de qualidade.
O modelo de qualidade MPS.BR, teve sua inspiração em padrões 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 referência para desenvolvimento de software, define sete níveis 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, métodos, práticas e
mudanças, e, as organizações desenvolvedoras são as responsáveis por manter e desenvolver
produtos de software baseados nestas atividades. A figura 2, mostra a correspondência entre o
CMMI e o MPS.BR.
30
Figura 2 Correspondência entre o CMMI e o MPS.BR
Fonte: Carvalho (2005).
Estes níveis de maturidade determinam uma escala para medir o quão madura uma
organização o é, e foram inspirados nos cinco níveis de desenvolvimento criados pelo CMMI.
Apesar do padrão proposto pelo CMMI começar pelo nível inicial (1), depois passar para os
níveis de repetível (2), definido (3), gerenciado (4) e otimizado (5), este ainda era um padrão
muito alto para as micro, pequenas e médias empresas brasileiras, justamente por este motivo,
o MPS.BR desenvolveu sete níveis que atendem ao mercado nacional, são eles:
o Nível A: Em Otimização;
o Nível B: Gerenciado Quantitativamente;
o Nível C: Definido;
o Nível D: Largamente Definido;
o Nível E: Parcialmente Definido;
o Nível F: Gerenciado;
o Nível G: Parcialmente Gerenciado;
Segundo Neto (2008, apud Couto 2007), o MPS.BR possui uma série de vantagens se
tomarmos outros métodos de processo como modelo; alguns desses diferenciais são:
31
o Os níveis de maturidade propostos pelo MPS.BR, permitem uma implantação mais
gradual, mais de acordo com a realidade de micro, pequenas e médias empresas
brasileiras que desenvolvem software, além de ser possível 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
médio porte;
o Custo acessível;
o Estas qualificações são avaliadas a cada dois anos;
Cabe lembrar, que não há critérios contraditórios nos diferentes métodos de processo,
apenas foram feitas adaptações que se adequaram melhor a realidade do mercado
brasileiro.
2.3.3 Nível G de Qualidade
“O nível G é o primeiro nível de maturidade do MR-MPS-SW” (SOFTEX, 2013, p. 7).
Este deve ser implantado com precaução já que é o início da implantação de melhorias dos
processos de software.
Mudar a cultura de uma organização é 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 nível de qualidade, o nível G;
em seguida, a empresa deve esclarecer se possui padrões organizacionais.
Na maioria dos casos, empresas que desenvolvem software precisam adequar suas
metodologias de trabalho para se tornarem organizações orientadas a projetos, e isto ocorre
com a evolução dos produtos de software, “ser orientado a projetos significa redefinir
algumas operações (atividades de rotina) já em andamento, como projeto, estabelecendo
objetivos, prazos e escopo para sua execução.”
Este nível subdivide-se em:
o Gerência de Projetos: Tem como propósito estabelecer e manter planos para
definição de atividades, recursos e responsabilidades acerca do projeto além de
32
corrigir desvios significativos no desenvolvimento do projeto, quando houver;
com o crescimento da maturidade da organização, este propósito evolui junto.
o Gerência de Requisitos: Tem como propósito gerenciar os requisitos do
produto bem como dos componentes do projeto, além disso, é responsável
ainda por identificar inconsistências entre estes requisitos, os planos de projeto
e os produtos de trabalho. Esta gerência é responsável por controlar os
requisitos.
2.4 GERENCIAMENTO DE PROCESSOS DE NEGÓCIOS (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 usuários; para que isto possa se concretizar, é importante que um modelo de processo de
negócios seja seguido, sendo assim, o BPMN (Business Process Moddel and Notation)
sobressai-se por “prover uma gramática de símbolos, para mapear de maneira padrão todos os
processos de negócio de uma organização” (SGANDERLA, 2012, p.1) buscando com isto
gerar a capacidade de entendimento de todas as partes interessadas no projeto, ou seja,
analistas, desenvolvedores e também os usuários do sistema, OMG (2014).
De acordo com Sganderla (2012), desde o seu lançamento, o que ocorreu em 2004,
organizações do mundo inteiro passaram a utilizar BPMN em seus processos de negócios, e
isto fez com que fossem disseminados conceitos a respeito de processos de negócios,
atualmente, esta é considerada uma “característica chave de qualquer iniciativa BPM”
(SGANDERLA, 2012, p.1). De acodo com o Guia para Gerenciamento de Processos de
Negócios, 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 transformação de processos. Isto porque a transformação vai além da
melhoria, transformação implica repensar inovar e mudar paradigmas. Transformar é
liderar e construir novas formas de geração de valor para os clientes e para a sociedade.
(BPM, CBOK, 2013, p. 1).
33
Utilizar-se de processos para a realização 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, práticas, técnicas e ferramentas para
processos, já que estes muitas vezes são 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 negócios muda a forma
tradicional em que as empresas estão acostumadas a gerenciar seus fluxos de trabalho, este
novo meio, proporciona mudanças rápidas e inovações para otimizar o trabalho, o
relacionamento com os clientes, fornecedores e colaboradores, BPM, CBOK (2013).
A ABPMP tem sua atenção voltada para os profissionais que adotem este tipo de
processo, a fim de que transformem seus ambientes de trabalho, quer sejam estes públicos ou
privados, para oferecer produtos e serviços mais eficientes e que possuam menos defeitos,
para que assim, os softwares produzidos forneçam maior valor para o usuário.
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 prática de BPM torna-se mais comum na organização, além de
agregar mais valor.
Com a implantação e prática de ferramentas orientas a processos novas estruturas,
assim como papéis organizacionais para oferecer suporte às novas práticas tendem a surgir
junto; o BPM, arremete duas principais abordagens, as que são mais orientadas a projetos de
processo e a outra que vê BPM como esforço de transformação de processos, figura 3. Ainda
que ambas as áreas tenham foco no gerenciamento de processos, tais abordagens geram
papéis e responsabilidades distintos.
Embora adotar a prática de BPM traga tantos benefícios às organizações, infelizmente
existe um grave problema a cerca deste processo; “não há pessoas qualificadas e com
conhecimento” (BPM CBOK, 2013, p. 13) suficiente nesta área para atender as necessidades
de empresas e organizações. De acordo com Brett Champlin, fundador da ABPMP
Internacional, (BPM CBOK (2013)), uma saída 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
Estão construindo seus próprios currículos e programas de treinamento e incorporando
pessoas iniciantes para trabalhar junto com os poucos profissionais talentosos de BPM que
possuem. Outras estão enviando gestores e analistas para treinamento, para começaram a
adquirir conhecimentos e habilidades necessários. (BPM CBOK, 2013, p. 13).
Vale enaltecer que hoje, a prática de BPM é uma atividade de negócios que só tende a
crescer, esta é uma prática estimulante e que vem conquistando o mercado por oferecer
soluções rápidas e inovadoras. Como crédito 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 práticas no futuro,
como é apresentado na figura 3.
Figura 3 Áreas de Conhecimento em BPM
Fonte: BPM, CBoK (2013).
35
2.4.1 Tecnologia da Informação Aplicada à Gestão por Processos (BPMS)
A mudança do foco de função para processo por parte de empresas e organizações fez
com que a procura por sistemas de informações 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 comunicação entre as pessoas envolvidas no desenvolvimento de softwares
tornaram-se mais eficazes.
Davenport et al. (2004) nos afirmam o quão importante é ajustar sistemas de
informação a processos de negócios, uma vez que as organizações devem buscar melhorias
contínuas; estas empresas devem melhorar o suporte informacional além de reavaliarem e
reajustarem outros fatores que contribuam para o sucesso de uma gestão orientada a
processos.
Em certos casos, automatizar os processos organizacionais não surte o efeito esperado
“pois a automação foi usualmente aplicada aos processos de retaguarda (back office) e às
funções administrativas” (GONÇALVES, 2000, p. 6-19).
Fazer uso de tecnologias wokrflow (conjunto de ferramentas) no ambiente
organizacional possibilita que haja integração entre a automação de processos nas
organizações, Thives Jr. (2002). Alguns autores consideram BPM como sendo uma evolução
da tecnologia workflow, já que BPM é um processo de transformação de processos e integra
várias áreas de atuação de uma organização pela lógica de fluxos de trabalho.
A tecnologia BPMS deve fornecer suporte a modelagem dos processos de software,
como se pode ver na figura 4, além de integração entre os atores (regra de negócios),
automatização dos processos e administração destes, uma vez que os processos desenvolvidos
necessitam de execução, monitoração e também de análise, 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 básicas:
o Definição de Processos;
o Execução de Processos;
o Modelagem Gráfica de Processos;
o Controle de Atividades;
o Interface do Usuário;
e, durante sua execução, os dados obtidos devem ser adquiridos, usados, reutilizados e criados
constantemente.
Visando automatizar a gestão do processo de negócio, foi proposto neste projeto a
integração entre a ferramenta BPMS e o modelo de qualidade MPS.BR nível G, como forma
de deliberar a criação de uma ferramenta que auxilie organizações 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 gráfica intuitiva e versátil, facilitando
a automação de processos. Tem como objetivo proporcionar resultados imediatos a partir de
suas ferramentas, estas dão suporte a modelagem de processos BPMN, regras de negócios,
definição de interface com o usuário, portal web de trabalho, além de dar suporte a gerência
com ferramentas de otimização 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, é possível fazer a
edição destes de forma prática; isto é bastante útil para as empresas, pois, caso haja a
necessidade de modificação, os processos são rapidamente alterados sem gerar danos
comerciais, BizAgi (2014).
A seguir, será detalhado as funcionalidades desta plataforma de automação de
processos, BizAgi (2014):
o Curso BPMN Embutido: Model Process é a ferramenta de modelagem de processos
oferecida pelo BizAgi, nela é possível 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, além disso, ao ser finalizada a modelagem, o
BizAgi também permite “exportar os gráficos 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 Aplicação: Com esta plataforma não é necessário desenvolver
códigos, pois, a mesma oferece um ambiente para desenvolvimento totalmente gráfico
e ainda dispõe de funções como if, else, for, etc.
o Acompanhamento Gráfico e online: Para auxiliar as tarefas dos gestores, o BizAgi
disponibiliza graficamente da rota pela qual o processo seguiu, qual o responsável por
aquela etapa do projeto e em que ponto o projeto se encontra.
o Ambiente Web Customizável: Aqui, pode-se ter um acompanhamento completo da
situação em que as tarefas se encontram, pode-se ainda interagir diretamente com
estas. Diz-se que a visualização do ambiente é customizável pois pode-se utilizar a
apresentação 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 Integração Sharepoint | Web: Possui fácil integração com páginas como HTML,
Java, páginas Wiki, Sharepoint, para publicação das mesmas; isto é importante pois a
colaboração na geração de modelos torna o processo mais ágil.
2.5 CONSIDERAÇÕES FINAIS
40
Neste capítulo foi apresentada uma visão geral sobre engenharia e modelagem de
software, gestão de qualidade e gerenciamento de processos de software.
Foi dado ênfase a assuntos como MPS.BR Nível 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 DISCUSSÕES
Como já foi apresentado em capítulos anteriores, para desenvolver um sistema ou
ferramenta de software algumas etapas devem ser seguidas, e, para o desenvolvimento deste
projeto não foi diferente.
A princípio foi analisado minuciosamente o guia de implementação MPS.BR nível G,
desenvolvido pela SOFTEX para que os requisitos pudessem ser levantados. Com base neste
guia, foi escolhida a gerência 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 serão
os meios de comunicação pelos quais ambas
se comunicarão durante o desenvolvimento
do projeto. Estas comunicações devem ser
registradas formalmente em atas, e-mails,
ferramentas de comunicação 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
e
definidos
aprovação da empresa contratante.
têm
42
Fase_05: Avaliar Requisitos
É feita uma avaliação dos requisitos a fim de
garantir que os requisitos propostos atendam
às necessidades e expectativas da empresa
contratante.
Fase_06: Registrar Reprovação
Caso os requisitos sejam reprovados, um
registro de reprovação 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 aprovação deve ser obtido pelos
fornecedores de requisitos. Este registro deve
ser tratado como um marco do projeto.
Fase_08: Avaliar Qualidade Técnica
A avaliação e aprovação por parte do cliente
após o entendimento dos requisitos por si só
não é suficiente para que os requisitos sejam
refinados e refletidos em modelos de análise
e projeto para a codificação. A avaliação dos
requisitos deve envolver, além do cliente,
também a equipe técnica da organização. Em
geral é aconselhável que os requisitos sejam
avaliados pela equipe técnica antes de serem
submetidos para aprovação pelo cliente para
evitar retrabalho ou a apresentação de um
documento sem qualidade técnica adequada
para o cliente.
Fase_09: Usar Checklist
É interessante que a empresa desenvolvedora
faça uso de Checklist em suas atividades para
que problemas frequentes sejam percebidos.
Fase_10: Realizar Reuniões
Realizar reuniões possibilita que as diversas
partes envolvidas no desenvolvimento do
43
projeto
possam
opinar,
aprovar
e
se
comprometer em relação aos requisitos do
projeto.
Fase_11: Reavaliar Qualidades Técnicas
Caso haja necessidade de modificar algum
requisito, a equipe técnica deverá reavalialos.
Logo
após,
são
submetidos
para
aprovação da empresa contratante.
Fase_12: Documentar Novos Requisitos
Após a reavaliação dos requisitos editados
por parte da empresa contratante, um registro
de
aprovação
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, transformação
em modelos, a codificação, o planejamento e
a execução de testes são estruturados para
garantir a correta execução do projeto, tendo
tarefas
previstas
discriminadas
em
um
cronograma ou conforme previsto pelo
processo Gerência de Projetos - GP (Se
houver).
Fase_14: Rastrear Dependências
A criação de um sistema de rastreabilidade
tanto pode ser vertical como horizontal;
pressupõe-se que diferentes abstrações dos
requisitos, documentos relacionados e o
código fonte sejam rastreáveis entre si.
Fase_15: Verificar Itens Implementados
Os requisitos, dentro do ciclo de vida do
projeto, são posteriormente derivados em
elementos de análise e projeto e então,
44
transformados em código fonte, para só
depois serem testados.
Fase_16: Avaliar Artefatos
Avaliação da consistência entre os requisitos
e os produtos de trabalho do projeto.
Fase_17: Identificar Possíveis
É importante que revisões sejam realizadas a
Inconsistências
fim de identificar possíveis inconsistências
entre os requisitos e os demais elementos do
projeto (planos, atividades e produtos de
trabalho).
Fase_18: Registrar Aceite
Após
passar
por
todas
as
fases
de
desenvolvimento, e a empresa contratante
decidir que não há inconsistências e nem há a
necessidade de realizarem-se mudanças, um
registro de aprovação deve ser obtido pelos
fornecedores de requisitos. Este registro deve
ser
tratado
como
um
marco
no
desenvolvimento do projeto.
Fase_19: Resolver Possíveis Inconsistências
Caso haja inconsistências, estas devem ser
registradas e ações corretivas executadas a
fim de resolvê-las.
Fase_20: Examinar Possíveis Mudanças
No caso de haver mudanças, é importante
examinar se há consistência em todos os
artefatos modificados.
Fase_21: Adequar Mudanças ao Escopo
Mudanças
documentadas
realizadas
juntamente
devem
aos
ser
outros
requisitos.
Fase_22: Revisar Requisitos
Durante o desenvolvimento do projeto, os
requisitos podem mudar por uma série de
motivos. Desta forma, requisitos adicionais
45
podem
ser
incorporados
no
projeto,
requisitos podem ser retirados ou ainda
podem ser editados.
Fase_23: Analisar Possíveis Mudanças
Caso haja necessidade de realizarem-se
mudanças nos requisitos, estas devem ser
registradas e um histórico das decisões
acerca dos requisitos deve estar disponível.
Fase_24: Analisar Impacto
São analisados aspectos como:
*Influência de outros requisitos;
*Expectativa dos interessados;
*Esforço;
*Cronograma;
*Riscos;
*Custos;
Vale
ressaltar
que
o
mecanismo
de
rastreabilidade bidirecional é de fundamental
importância.
Fase_25: Editar Requisitos
Elaboração de um documento onde sejam
declarados os requisitos modificados.
Fase_26: Registrar Reprovação
Caso o cliente ou empresa contratante
aprovem os requisitos editados, esta ação é
encaminhada para o nível de mudança a fim
de resolver este problema. É realizado um
registro de reprovação. Este registro deve ser
tratado como um marco do projeto.
Fase_27: Registrar Aceite
Quando há aceitação do cliente ou empresa
contratante, é realizado um registro de
aprovação. Este registro deve ser tratado
46
como um marco do projeto.
Fase_28: Realizar Histórico das Decisões
São registras as necessidades de mudanças
(se
houver),
informações
assim
como
tomadas
todas
durante
as
o
desenvolvimento do projeto.
Tabela 1 Fases da Ferramenta.
Fonte: Softex (2013), adaptado.
Após ter sido feito o levantamento dos requisitos foi realizada a modelagem da
ferramenta utilizando notações BPMN no software BizAgi, como serão mostradas nas figuras
8.1 à 8.7;
Figura 8.1 Fases da Modelagem, Etapa de Elicitação dos Requisitos.
Fonte: O Autor.
Figura 8.2 Fases da Modelagem, Etapa de Avaliação 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 Revisão.
Fonte: O Autor.
Figura 8.5 Fases da Modelagem, Etapa de Mudança.
Fonte: O Autor.
48
Figura 8.6 Fases da Modelagem, Etapa de Avaliação por parte do Cliente.
Fonte: O Autor.
Figura 8.7 Modelagem Completa da Ferramenta.
Fonte: O Autor.
Ao ser concluída 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, além de possibilitar que
a interface com o usuário (fachada) também seja implementada, como se percebe na figura
10:
Figura 10 Implementação da Fachada.
Fonte: O Autor.
Não diferente de outras plataformas para desenvolvimento de softwares, o BizAgi
também dá suporte a implementação da regra de negócios (algo extremamente importante),
como mostra a figura 11:
50
Figura 11 Regra de Negócios.
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
específicos, como mostra a figura 12:
51
Figura 12 Separação dos Grupos de Requisitos.
Fonte: O Autor.
Tomando como base o modelo de prototipagem de software, o próximo passo tomado
foi o teste da ferramenta, mas, antes que se possa acessar o sistema, é preciso logar em uma
área de atuação específica de acordo com a função de cada desenvolvedor, o que pode ser
observado na figura 13:
52
Figura 13 Tela de login.
Fonte: O Autor.
Após 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 são realizados como uma forma de revisar os requisitos
implementados para que erros e/ou inconsistências possam ser resolvidos. Mudanças
realizadas foram documentadas como forma de manter controle do desenvolvimento desta
ferramenta.
Por fim, a ferramenta proposta neste projeto tem fortes indícios que atenderá aos
objetivos geral e específicos, uma vez que esta foi modelada e automatizada tendo como base
os princípios do MPS.BR nível G.
Como se pode perceber, a ferramenta desenvolvida relacionou Tecnologia da
Informação Aplicada ao Processo de Negócios (BPMS) com as boas práticas do MPS.BR
nível G, e, definiu um modelo de implantação com tempo específico para cada tarefa, como
mostra a figura 15:
53
Figura 15 Gráfico para Acompanhamento de Projetos.
Fonte: O Autor.
Com definição dos fluxos de trabalho e criação de papéis para cada fase da
implementação do software, como está explicito nas figuras 16.1 à 16.3:
Figura 16.1 Criação e Definição do Papel de Analista.
Fonte: O Autor.
54
Figura 16.2 Criação e Definição do Papel de Equipe Técnica.
Fonte: O Autor.
Figura 16.3 Criação e Definição do Papel de Gerência.
Fonte: O Autor.
Para que possa ser feito o acompanhamento da evolução dos processos, o bizagi gera
gráficos onde são descriminadas as tarefas por usuários, além de mostrar quantas tarefas estão
em dia bem como as atrasadas e informa quem deve faze-las, como mostra a figura 17:
55
Figura 17 Trabalhos em Andamento por Usuário.
Fonte: O Autor.
Para que possa ser acompanhado o tempo total de um ciclo de um processo uma tabela
com tais informações é gerada, como mostra a figura 18:
Figura 18 Resumo do Tempo de Ciclo.
Fonte: O Autor.
56
4 CONCLUSÕES
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 necessário que normas
de qualidade surgissem para que houvesse certificação que os softwares produzidos
atenderiam as necessidades dos usuários, 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 médias
empresas a desenvolverem softwares de maneira eficiente, SOFTEX (2013), é necessário que
alguns níveis de maturidade sejam seguidos, inicialmente o MPS.BR sugere que seja adotado
o Nível G em qualidade, por ser este o nível mínimo para certificação 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 Nível G em qualidade proposto pelo
MPS.BR e a partir dele a modelagem foi montada com base em gerência de requisitos. Vale
ressaltar que a principal proposta deste trabalho é fazer com que a gerência bem como as
especificações dos requisitos possam ser controlados e acompanhados tanto pela empresa
desenvolvedora quanto pela empresa contratante, evitando-se possíveis retrabalhos.
Para que o trabalho de desenvolvimento destes softwares seja uma atividade mais
efetiva, a ferramenta dispõe de uma plataforma onde é possível controlar o tempo das
atividades além de gerar gráficos discriminatórios dos processos, útil para correção de
gargalos identificados e eventuais problemas.
57
5 REFERÊNCIAS BIBLIOGRÁFICAS
ANJOS, Lúcio André Mendonça; MOURA, Hermano Perreli de; Um Modelo Para
Avaliação de Produtos de Software. Centro de Informática - Universidade Federal de
Pernambuco (UFPE), 2014.
ATALLA, Fabiano (2012). Por que os Projetos de TI Fracassam? Disponível 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
Prototipação.
Disponível
em:
http://engenhariadesoftwareuesb.blogspot.com.br/2012/12/blog-post.html No dia 28 de
Outubro de 2014.
BARRIOS,
Bruno
(2012).
O
que
é
BPM?
Disponível
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.
Disponível
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 Científica.
São Paulo: Pearson Prentice Hall, 2007. 6ª Ed.
DA SILVA, Fernando Rodrigues (2011). Testes de Software – Níveis de Testes. Disponível
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 Gestão da Informação. Porto
Alegre, Bookman, 2004.
DEVMEDIA, Equipe de Moderação (2012). Ciclos de Vida do Software: Conhecendo os
Bastidores. Disponível 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 Espírito Santo – UFES, 2005.
FACCIO, Letícia Juciara. Qualidade de Software Aplicando Business Process Model and
Notation 2.0. Paraná, 2011.
FERREIRA, Décio; COSTA, Felipe; ALONSO, Filipe; ALVES, Pedro; NUNES, Tiago
(2005); SCRUM: Um Modelo Ágil para Gestão de Projetos de Software. Disponível em: <
http://www.emprel.gov.br/files/es_final_19.pdf> No dia 30 de Outubro de 2014.
FILHO, Gilson Teixeira de Almeida (2013). Introdução a Engenharia de Software. Notas
de Aula.
FLICK, Uwe; Introdução a Pesquisa Qualitativa. Porto Alegre: Artmed 2009, 3ª Ed.
FRANÇA, Renato (2014). Diferenças entre Programador e Desenvolvedor de Software.
Disponível
em:
<renato-franca.com/diferenças-entre-programador-desenvolvedor-desoftware/> No dia 21 de outubro de 2014.
FURTADO, André, Pontas de Iceberg do Caos no Desenvolvimento de Software.
Disponível
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); Métodos Ágeis Para
Desenvolvimento de Software. Disponível em: < http://livrometodosageis.com.br/ > No dia
01 de Novembro de 2014.
ISO – International Organization for Standardization, ISSO 9000: Gestão de Qualidade.
Disponível
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); Análise e Especificação de Requisitos. Disponível 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 Esboço Sobre o Processo de Testes de Software.
Disponível em http://www.macoratti.net/08/08/tst_sw2.htm No dia 28 de Outubro de 2014.
MAGALHÃES, I. L. E PINHEIRO W. B. (2007). Gerenciamento de Serviços de TI na
Prática: Uma abordagem com base na ITIL – Editora Novatec – 1ª edição, ISBN: 978-857522-106-8.
MASTERHAUSE. O que é BPM? Disponível em: <http://www.masterhouse.com.br/sobrebpm/> No dia 14 de outubro de 2014.
NETO, Alfredo Colenci. Proposta de um Modelo de Referência para Desenvolvimento de
Software com Foco na Certificação do MPS.BR. São Carlos, 2008.
OMG – Object Managed Group. Business Process Model and Notation (BPMN).
Disponível em: < http://www.bpmn.org/ > No dia 02 de Dezembro de 2014.
OTANI, Nilo; FIALHO, Francisco Antonio Pereira. TCC: Métodos e Técnicas.
Florianópolis: Visual Books, 2011, 2ª Ed.
PFLEEGER, Shari Lawrence. Software Engineering – Theory and Practice. São Paulo:
Prentice Hall, 2004. 2ª Ed.
60
PRADO, Professor (ANO). Ciclo de Vida do Software. Disponível 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. São
Paulo, 2006, 6ª Ed.
PRESSMAN, Roger S., Software Engineering: a Practitioner’s Approach. The McGraw-Hill
Companies, Inc., New York, EUA, 2011, 7ª Ed.
PROTOCOLO TI (2012). Os modelos de Desenvolvimento de Software. Disponível 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); Análise de Requisitos. Disponível em: <
http://www.infoescola.com/engenharia-de-software/analise-de-requisitos/> No dia 07 de
Novembro de 2014.
RAMOS, Almir; CARLOS, Antonio; LEITÃO, Rafael Gonzaga; COSTA, Eryson Raphael
M.
(2011);
Modelo
Cascata
ou
Clássico.
Disponível
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
Sequência. Disponível 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
Implementação – Parte 1: Fundamentação para Implementação do Nível G do MR-MPS.
Disponível em: http://www.softex.br/mpsbr No dia 06 de Outubro de 2014.
SOFTEX. 2014, MPS-SV. Disponível em: http://www.softex.br/mpsbr/mps/servicos/ No dia
03 de setembro de 2014.
SOMMERVILLE, Ian. Software engineering. São Paulo: Pearson Prentice Hall, 2011. 9ª Ed.
61
SOUZA, Vinícius Rodrigues De (2014). Prototipação no Desenvolvimento de Software.
Disponível 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 Transformação do Conhecimento. In:
ANGELONI, M.T (Org.). Organizações do Conhecimento: infraestrutura, pessoas e
tecnologias. São Paulo, 2002.
VASCONCELOS, Alexandre Marcos Lins de; ROUILLER, Ana Cristina; MACHADO,
Cristina Ângela Filipak; MEDEIROS, Tereza Maria Maciel de; Introdução à Engenharia de
Software e à qualidade de Software. Lavras: UFLA/FAEPE, 2006.
VOLPE, Renato Luiz Della; ZABEU, Ana Cecília Peixoto (2004); Falando de Qualidade:
Gestão,
Processos
e
Meio
Ambiente.
Disponível
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 História da Engenharia de Software. Disponível em:
<http://marathoncode.blogspot.com.br/2012/07/uma-breve-historia-da-engenhariade_10.html> no dia 14 de outubro de 2014.