francisco josé martins dias ferreira · 2018-01-22 · tencionam servir de guia para este...
TRANSCRIPT
Francisco José Martins Dias Ferreira
Desenvolvimento de uma escala de “agilidade”
para equipas de projetos TI, em ambientes ágeis
Projeto de Dissertação de Mestrado
Mestrado em Engenharia e Gestão de Sistemas de Informação
Trabalho efetuado sob a orientação do/da/de
Professor Doutor Pedro Miguel Gonzalez Abreu Ribeiro
Janeiro de 2018
ii
DECLARAÇÃO
Nome: Francisco José Martins Dias Ferreira
Endereço eletrónico: [email protected] Telefone: 960403498/telefone 2 (alternativo)
Bilhete de Identidade/Cartão do Cidadão: 123456789
Título da dissertação: Desenvolvimento de uma escala de “agilidade para equipas de projetos TI,
em ambientes ágeis
Orientador:
Professor Doutor Pedro Miguel Gonzalez Abreu Ribeiro
Ano de conclusão: 2018
Mestrado em Engenharia e Gestão de Sistemas de Informação
É AUTORIZADA A REPRODUÇÃO INTEGRAL DESTA DISSERTAÇÃO APENAS PARA EFEITOS DE
INVESTIGAÇÃO, MEDIANTE DECLARAÇÃO ESCRITA DO INTERESSADO, QUE A TAL SE
COMPROMETE.
Universidade do Minho, _____/_____/_________
Assinatura:
iii
AGRADECIMENTOS
É uma secção a escrever mais tarde que estará presente no relatório de dissertação final.
v
RESUMO
As tecnologias de informação são cada vez mais um fator distintivo do sucesso das organizações.
Inúmeras organizações têm equipas a desenvolver projetos de tecnologias de informação.
Para desenvolver estes projetos existe um grande número de modelos e abordagens que
tencionam servir de guia para este desenvolvimento. Este projeto de dissertação tem o objetivo de
recolher o estado da arte circundante ao tema desta dissertação. Tem a importância de criar os alicerces
necessários para a fase seguinte, que será a construção de um escala que possibilite medir a maturidade
ágil das equipas de projetos de TI, que é o grande objetivo final de todo este trabalho de dissertação.
Quando se elaboram projetos nesta área, deve ter-se em mente vários pressupostos e princípios,
que podem ou não ser aplicados. A área da engenharia de software aborda muitas áreas de
conhecimento e é preciso ter noção delas. Existem vários métodos tradicionais e ágeis que podem ser
aplicados em projetos de TI, dependendo do tipo de projeto, a organização e/ou equipa devem escolher
a metodologia mais indicada para o desenvolvimento do projeto. Dentro dos métodos tradicionais existem
modelos de processos e modelos de maturidade, dos quais alguns são descritos neste documento. Após
estes, também são descritas várias abordagens ágeis.
Ora, o objetivo desta dissertação é desenvolver uma escala de “agilidade” para equipas de TI,
em ambientes ágeis. Com “agilidade” a intenção é referir à maturidade ágil. Até à data, ainda não foram
descobertos quaisquer estudos relacionados com maturidade ágil.
Desta maneira, é necessário abordar modelos tradicionais de avaliação de maturidade, como o
CMMI, ISO 15504, o TSP, o PSP e o P-CMM. Após isto, faz-se a recolha e caracterização das práticas de
vários modelos ágeis. Após isto, já na fase posterior a este projeto de dissertação, será feito um estudo
da evolução das equipas em ambientes ágeis.
Com todas estas informações, tenciona-se conseguir então os fundamentos necessários para a
criação do artefacto final desta dissertação. Este trabalho será elaborado com recurso à metodologia
Design Science Research, que consiste na revisão de literatura dos conceitos mais relevantes para o
tema, seguidos de uma proposta de artefacto que possa contribuir para a ciência. Este modelo pressupõe
ainda que o artefacto desenvolvido seja avaliado num contexto real.
Palavras- Chave: Projetos de TI, Maturidade ágil, práticas, abordagens ágeis, modelos de maturidade.
vii
ABSTRACT
Information Technologies represents one distinctive success factor in nowadays organizations. A
tremendous number of organizations have teams to develop IT projects.
In order to develop this projects, there are a large number of approaches that are intended to
guide this development. This dissertation project aims to collect the state of the art surrounding the
theme. It is important to create the necessary foundations for the next phase, which will be the
construction of a scale that makes possible to measure the agile maturity of IT project teams, and that is
the great final goal of all this dissertation work.
When designing projects in this area, a number of assumptions and principals should be kept in
mind, although they can or not be applied. There are several traditional and agile approaches that can
be applied to IT projects, depending on the type of project, the organization can choose the most
appropriate methodology to the development of the project. Within the traditional methods there are
process models and maturity models, some of them are described in this document. Several agile
approaches are also described.
The purpose of this dissertation is to develop an "agility" scale for IT teams, in agile environments.
With "agility" the intention is to refer to agile maturity. No studies related to agile maturity have yet been
discovered.
So, it is necessary to approach traditional models of maturity evaluation, such as CMMI, ISO
15504, TSP, PSP and P-CMM. After this, the practices of several agile models are collected and
characterized. After this, in the subsequent phase to this dissertation project, will be made a study of the
evolution of the teams in agile environments.
With all this information, it is intended to obtain the necessary foundations for the creation of the
final artifact of this dissertation. This work will be elaborated using the methodology Design Science
Research, which consists in the literature review of the most relevant concepts for the theme, followed
by a proposal of artifact that can contribute to science. This model also assumes that the artifact
developed is evaluated in a real context.
Key words: IT projects, Agile maturity, practices, agile approaches, maturity models.
ix
ÍNDICE
Agradecimentos .................................................................................................................................. iii
Resumo............................................................................................................................................... v
Abstract............................................................................................................................................. vii
Lista de Figuras .................................................................................................................................. xi
Lista de Tabelas ............................................................................................................................... xiii
Lista de Abreviaturas, Siglas e Acrónimos .......................................................................................... xv
1. Introdução .................................................................................................................................. 1
1.1 Enquadramento .................................................................................................................. 1
1.2 Finalidade e Principais Objetivos da Dissertação .................................................................. 3
1.3 Organização da Dissertação ................................................................................................ 3
2. Revisão de Literatura .................................................................................................................. 5
2.1 Estratégia de Pesquisa ........................................................................................................ 5
2.1.1 Fontes de Dados e Estratégia de Pesquisa ................................................................... 5
2.1.2 Seleção dos Artigos ..................................................................................................... 7
2.1.3 Extração dos Dados e Síntese ...................................................................................... 7
2.2 Tecnologias de Informação e Sistemas de Informação ......................................................... 8
2.3 Métodos Tradicionais .......................................................................................................... 9
2.3.1 Engenharia de Software ............................................................................................... 9
SWEBOK .................................................................................................................................... 9
Quatro Atividades Fundamentais da Engenharia de Software ..................................................... 11
ISO 12207 ................................................................................................................................ 11
2.3.2 Modelos de Processo ................................................................................................. 12
Waterfall ................................................................................................................................... 12
V-Model .................................................................................................................................... 14
Rational Unified Process ........................................................................................................... 14
2.3.3 Modelos de Maturidade ............................................................................................. 16
CMMI ....................................................................................................................................... 17
Personal Software Process (PSP) ............................................................................................... 22
Team Software Process (TSP) ................................................................................................... 23
x
People Capability Maturity Model (P-CMM) ................................................................................ 23
ISO 15504 ................................................................................................................................ 24
2.4 Abordagens Ágeis .............................................................................................................. 25
2.4.1 Manifesto Ágil ............................................................................................................ 26
2.4.2 Chaos Report ............................................................................................................ 28
2.4.3 Métodos ágeis ........................................................................................................... 29
Extreme Programming (XP) ....................................................................................................... 30
Scrum ...................................................................................................................................... 35
OpenUP .................................................................................................................................... 43
Kanban ..................................................................................................................................... 47
Outros métodos existentes e conclusões gerais ......................................................................... 50
3. Caracterização do estudo .......................................................................................................... 51
3.1 Abordagem Metodológica .................................................................................................. 51
3.2 Plano de Atividades ........................................................................................................... 53
4. Conclusões ............................................................................................................................... 55
Bibliografia ....................................................................................................................................... 57
xi
LISTA DE FIGURAS
Figura 1- Tópicos para a área de conhecimento Engineering Process (retirado de (IEEE, 2014)) ........ 10
Figura 2- Passos para o desenvolvimento de um programa (retirado de Royce (1970)) ...................... 13
Figura 3- Diagrama representativo do V-Model (retirado de http://istqbexamcertification.com) ........... 14
Figura 4-Framework do RUP (retirado de https://www.pmi.org/learning/library/pmbok-rup-itil-software-
development-7573) .......................................................................................................................... 16
Figura 5- Os 5 níveiws de maturidade do P-CMM (Retirado de (Curtis, et al., 2009)) .......................... 24
Figura 6- Comparação da Chaos Resolution entre Agile e Waterfall (retirado de
https://www.infoq.com/articles/standish-chaos-2015) ..................................................................... 29
Figura 7-Ciclo de Vida do Processo em XP (retirado de Abrahamson, et al.,(2002))............................ 31
Figura 8 - Fluxo de trabalho do OpenUP (Retirado de http://epf.eclipse.org/wikis/openup/) ............. 44
Figura 9-Delivery Process do OpenUp (Retirado de Balduino (2007) .................................................. 45
Figura 10-Práticas do OpenUP (Adaptado de http://epf.eclipse.org/wikis/openup/) .......................... 47
Figura 11- Fases Constituintes da metodologia DSR .......................................................................... 52
Figura 12- Diagrama de Gantt ........................................................................................................... 53
xiii
LISTA DE TABELAS
Tabela 2- Organização dos Processos por Níveis de Maturidade (adaptado de SEI (2010)) ................. 19
Tabela 3- Descrição das fases do ciclo de vida do XP (adaptado de Beck (1999;2000) e Abrahamson, et
al.,(2002)) ........................................................................................................................................ 32
Tabela 4- Descrição dos papéis e responsabilidades do XP (adaptado de Beck (2000)) ...................... 33
Tabela 5- Práticas do XP (Adaptado de Beck (1999,2000), Abrahamsson, et al.,(2002), Sommerville
(2015a)) ........................................................................................................................................... 35
Tabela 6-Ciclo do Scrum (Retirado de Sutherland e schwaber, (2011)) .............................................. 43
Tabela 7- Mapeamento entre as iterações e respetivas atividades com os bojetivos de cada fase (Adaptado
de Balduino (2007) e de http://epf.eclipse.org/wikis/openup/) ........................................................ 44
Tabela 8-Papéis e respetivas responsabilidades da equipa em OpenUP (Adaptado de Balduino (2007) e
http://epf.eclipse.org/wikis/openup/) .............................................................................................. 45
Tabela 9- Mapeamento entre os princípios do Agile Manifesto e dos principios do OpenUP (Adaptado de
Balduino (2007) e http://epf.eclipse.org/wikis/openup/ .................................................................. 46
Tabela 10- Sumáio das práticas do Kanban e respetivas descrições (Adaptado de Anderson & Carmichael,
2016)). ............................................................................................................................................ 49
xv
LISTA DE ABREVIATURAS, SIGLAS E ACRÓNIMOS
CMMI Capability Maturity Model Integration
CMMI-DEV CMMI for development
CMM Capability Maturity Model
SCAMPI Standard CMMI Appraisal Method for Process Improvement
SPICE Software Process Improvement and Capability Determination
ISO International Organization of Standardization
PMBOK Project Management Body of Knowledge
TI Tecnologias de Informação
SI Sistemas de Informação
SWEBOK Software Engineering Body of Knowledge
RUP Rational Unified Process
P-CMM People Capability Maturity Model
UML Unified Modeling Language
TSP Team software process
PSP People software Process
DSR Design Science Research
1
1. INTRODUÇÃO
1.1 Enquadramento
Hoje em dia, no mundo atual, em que cada vez vivemos mais “inundados” de informação, os
sistemas de informação que são bem implementados representam uma grande arma para as empresas,
caso sejam utilizadas todas as suas capacidades. Têm grande importância pois processam os dados da
organização para gerar informação que é útil para gerir as suas operações.
Cada vez mais os clientes e utilizadores finais de projetos de tecnologias de informação requerem
mais qualidade e funcionalidades, com menos tempo, custos e recursos, desta maneira surge a
necessidade de utilizar certos mecanismos ou metodologias que permitam às empresas gerir as suas
atividades de desenvolvimento para atingir os seus objetivos de negócio (SEI, 2010). A engenharia de
software segue esta tendência, tendo atualmente uma fraca reputação no que diz respeito a falhas de
prazos, custos e muitas das vezes ao nível da qualidade do produto final que foi solicitado pelo cliente.
Uma maneira de contornar este problema é utilizando metodologias de desenvolvimento já bem
enraizadas no mercado. Estas metodologias servem para ajudar a organizar o trabalho de
desenvolvimento de software. Existem as metodologias tradicionais e as metodologias ágeis, que
apresentam algumas diferenças, mas podendo uma ou outra ser mais eficiente em diferentes tipos de
projetos, portanto não é possível saber qual a melhor entre as duas, sem saber o tipo do projeto que
certa equipa vai desenvolver. Existem até autores que falam na integração entre a metodologia
apresentada pelo CMMi e da Ágil.
Durante muitos anos as metodologias tradicionais eram mais conhecidas, apesar de existirem
também metodologias chamadas de lean methodologys, mas a partir do Agile Manifesto (2001) o termo
“ágil” ganhou popularidade e definindo alguns valores e princípios alternativos (Beck et al., 2001).
Existem vários métodos para o desenvolvimento ágil de software, e uma parte deste projeto de
dissertação vai ser o estudo desses métodos e modelos ágeis, após o estudo de modelos tradicionais,
como modelos de maturidade e modelos de processo, mas com foco na maturidade, para analisar a
evolução típica em equipas que trabalham em ambientes ágeis. Esta evolução poderá ser estudada
através de artigos que se consigam recolher. Mas também se pretende que exista o contacto com
empresas reais que aplicam metodologias ágeis e, através de entrevistas nessas empresas tentar
perceber o sucesso que têm vindo a obter, as práticas que aplicam, as abordagens que utilizam, entre
2
outros aspetos que na altura possam ser relevantes para servir de input ao desenvolvimento do artefacto
final.
O objetivo será a conseguir elaborar uma proposta de escala de agilidade, com os diversos níveis
de evolução. Os métodos tradicionais são pouco flexíveis o que contrasta com os ágeis que providenciam
um conjunto de práticas que permite adaptações rápidas a pedidos do cliente e que vão de encontro às
necessidades que o moderno desenvolvimento de produtos apresenta (Papadopoulos, 2014). Podem
ainda escolher entre utilizar as duas dependendo do tipo de projeto que têm em mãos ou tentam integrar
ambas a metodologias (Glazer et al., 2008).
Serão pesquisados estudos com algumas informações relativas à aplicação de metodologias Ágeis,
ou de métodos como o SCRUM, o XP, Kanban, OpenUP, por exemplo. Um dos exemplos é a utilização
de técnicas ágeis para a evolução da plataforma de Inteligência da Força Aérea dos Estados Unidos,
desta forma apresentam um trabalho incremental, abordagens iterativas para conseguir entregas de
grande capacidade mais frequentemente e de uma maneira mais gerida (Levinson, 2016). Outro exemplo
relevante de literatura entre muitos outros, será por exemplo o artigo publicado por Bradley de Souza em
2015, que diz que a Agilidade vem acompanhada da maturidade e explica que a abordagem Ágil é ideal
para projetos pequenos em organizações pequenas, mas quando é requerida uma escala maior, o
modelo precisa de ser ajustado para ser efetivo (Souza, 2015).
Em suma, a partir de um problema, que é o de medir a maturidade ágil das equipas de
desenvolvimento de Tecnologias de Informação, este trabalho visa desenvolver um artefacto, sendo neste
caso uma escala capaz de apresentar resposta ao problema referido previamente. Irão ser cobertos
vários modelos tradicionais e ágeis para ser possível, posteriormente, fazer a comparação entre eles e
definir quais as melhores práticas que devem ser incorporadas para tentar medir a maturidade ágil de
equipas de desenvolvimento de projetos TI. Isto será complementado com o estudo da evolução de
equipas ágeis, como por exemplo se usam métodos ágeis para todos os tipos de projetos, se antes
usavam métodos tradicionais e fizeram a mudança para ágeis, se tentam incorporar os dois, possíveis
aspetos positivos e/ou negativos com a adoção de algum dos métodos face a diferentes tipos de projeto
e possível perceção das áreas que algumas empresas cobrem com mais ou menos frequência tendo em
vista o sucesso. Para assim se tentar “medir” através de várias comparações e perceções, a maturidade
ágil, construindo posteriormente uma escala que possa medir a “agilidade” das equipas de
desenvolvimento de projetos de TI.
Visa-se chegar a este artefacto com o estudo de diversa literatura como contida neste documento,
através do estudo dos modelos tradicionais de avaliação de maturidade, após isto o estudo de modelos
3
ágeis e das principais práticas, da evolução das equipas em ambientes ágeis e da definição do conceito
de “Zero process” para assim ter ferramentas necessárias que permitam elaborar uma ferramenta que
neste caso vai conseguir escalar a agilidade das equipas. Esta será uma versão preliminar que vai ter
uma aplicação prática e a recolha de opinião de especialistas para assim conseguir elaborar uma nova
escala com base nos trabalhos de validação já referidos.
1.2 Finalidade e Principais Objetivos da Dissertação
Esta dissertação tem a finalidade de desenvolver uma escala de “agilidade” para equipas de
projetos TI, em ambientes ágeis, para assim ser possível medir a sua maturidade.
Desta forma, é necessário o estudo de modelos tradicionais e ágeis existentes e também de
entidades que fizeram a transição da utilização de modelos tradicionais para ágeis.
De seguida apresentam-se os principais objetivos propostos:
Estudar modelos tradicionais de avaliação de maturidade (CMMI, ISO 15504);
Caracterizar práticas ágeis dos modelos principais;
Definir o conceito de “zero process” ;
Definir uma escala para medir a maturidade ágil das equipas de desenvolvimento TIs;
Validar o modelo com casos práticos e opinião de especialistas
1.3 Organização da Dissertação
O primeiro capítulo desta dissertação contém a Introdução, onde está o enquadramento do
trabalho, onde é descrita a finalidade e quais os objetivos principais. Por fim apresenta a estrutura e
organização do documento de uma forma simples.
O segundo capítulo, Revisão de Literatura, é onde é feito o estudo de vários conceitos, métodos,
abordagens importantes relacionados com o tema, tais como a engenharia de software, modelos de
processo, modelos de maturidade e abordagens ágeis, para que se consiga obter todos os alicerces
necessários para avançar à próxima fase desta dissertação, que consiste em começar a construir o
artefacto.
O terceiro capítulo, caracterização do estudo, contem a abordagem metodológica, onde se refere
a forma como se vai realizar este trabalho de investigação e também o planeamento das tarefas que
fazem parte desta dissertação.
4
O quarto e último capítulo apresenta as conclusões e uma pequena síntese do trabalho que foi
realizado até à data.
5
2. REVISÃO DE LITERATURA
2.1 Estratégia de Pesquisa
2.1.1 Fontes de Dados e Estratégia de Pesquisa
Para a elaboração deste tópico, cujo objetivo é trabalhar e estudar o estado da arte, para realizar
uma revisão de literatura, inicialmente foram feitas algumas pesquisas para se verificar se existiam
estudos que cobrissem o tema desta dissertação, através de motores de busca como o Google Scholar,
a IEE Eletronic Xplore Digital Library e o presente no website da Carnegie Mellon University (CMU).
Não foram encontrados artigos que cobrissem totalmente o tema, ou seja, que o assunto fosse
escalas de maturidade ágil. Então, o passo seguinte foi começar por investigar várias abordagens
tradicionais e ágeis, ao mesmo tempo que se pesquisava se existiam propostas de maturidade para
alguma destas. A solução pensada foi então pesquisar por vários métodos tradicionais e ágeis e fazer
um estudo sobre estes e as práticas que os constituem. Algumas das abordagens não têm práticas
explícitas, mas podem ser importantes devido ao processo que têm associados e podem ser úteis na
conceção do artefacto desta dissertação, da escala de maturidade ágil.
Assim, ao pesquisar por artigos de assuntos mais específicos e restritos, foram encontrados
artigos com elevada relevância e muitos deles publicados em conferências (como a Agile conference, por
exemplo), revistas ou jornais científicos com boa reputação na área, como por exemplo o International
Journal of Information Technology and Business Management, The Journal of Systems and Software,
Information and Software Technology, Journal of Software Maintenance and Evolution: Research and
Practice, entre outros. Para além disto, foi feita a pesquisa de vários livros, que continham informações
bastante interessantes publicados por Ian Sommerville e Roger S. Pressman, alguns com excertos
disponíveis no Google Books, outros por autores pertencentes à Agile Alliance, como Kent Beck, Alistair
Cockburn, Mike Beedle, Ken Schwaber, Jeff Sutherland, assim como de documentos publicados por
entidades como o Software Engineering Institute, pelo Projeto Eclipse, pelo Project Management Institute
(PMI), pela IBM e pela IEEE Computer Society, por exemplo.
Apesar de toda a documentação importante encontrada acima, foram ainda utilizados outros
motores de busca para o acesso a mais informação que foi estudada e alguma dela utilizada já neste
projeto de dissertação. Os outros motores de busca que foram utilizados para obter mais documentação
6
das suas bases de dados e assim ter uma boa base de pesquisa, quer para o estado da arte incluído no
projeto de dissertação, quer para o arranque da fase seguinte, foram por exemplo: o ScienceDirect, o
ResearchGate, o Scopus, o RepositoriUM, o WebofScience e o Springer.
Assim, com esta documentação retirada de fontes concretas e com foco na área, acredita-se que
também as informações conseguidas para esta revisão de literatura possuem grande relevância no
ambiente que envolve o tema.
Várias expressões simples e compostas foram utilizadas para esta pesquisa, a lista que se segue,
contém apenas as mais relevantes de uma infinidade de combinações de palavras e conceitos utilizados:
“Software Engineering” e “SWEBOK”;
“Maturity Models” e “Modelos de Maturidade”;
“Process Models” e “Modelos de Processo”;
“Information Systems” e “Sistemas de Informação”;
“Information Technology” e “Tecnologias de Informação”;
“CMMI”;
“ISO 12207” e “ISO 15504”;
“Waterfall Model”;
“V-Model”;
“RUP”;
“Method Composer”;
“TSP”, “PSP” e “P-CMM”;
“Agile Manifesto”
“Agile Methods”
“Extreme Programming”, “Scrum”, “Kanban” e “OpenUP”;
“Best practices agile” e “Agile maturity levels”;
“Chaos Report”;
“Agile Scale” e “Escala ágil”;
“Agile proposals”, “CMU Agile” e “PMI Agile”.
7
2.1.2 Seleção dos Artigos
A seleção de artigos foi elaborada através do título destes, pois muitas das vezes o título fornecia
informação clara quanto ao seu conteúdo, outros foram escolhidos através de palavras-chave destacadas
que apareciam no excerto de texto por baixo do hyperlink quando é efetuada a pesquisa.
Outra forma foi ler o resumo do artigo, ou fazer uma leitura “cruzada” e perceber se este era
realmente relevante e passível de ser estudado com maior atenção através da compreensão do conteúdo
do mesmo.
Além disto, foram selecionados artigos que por vezes nem ao ler o resumo nem a introdução,
davam a perceber se este continha alguma informação sobre o assunto desejado, por isso era preciso
mais um bocado de esforço de leitura para se conseguir perceber se o artigo poderia servir o objetivo da
solução ou não.
Foram selecionados artigos que:
Abordassem e definissem metodologias tradicionais e/ou ágeis;
Abordassem as melhores práticas de determinada metodologia;
Abordassem níveis de maturidade, tanto para metodologias ágeis como tradicionais;
Abordassem o tema da engenharia de software;
Definissem o que se entende por SI e TI;
Abordassem o estudo de práticas comuns a vários métodos, principalmente se um
deles incluísse níveis de maturidade na sua abordagem.
Apesar de selecionados, alguns não foram referidos nesta revisão de literatura, mas vão servir
de arranque para a próxima fase desta dissertação.
2.1.3 Extração dos Dados e Síntese
Este tópico tem o objetivo de apresentar uma matriz de conceitos elaborada para se conseguir
uma melhor compreensão das afirmações e escolhas para cada tópico deste trabalho, nesta são
identificados os artigos abordados e faz-se o cruzamento com os conceitos que se relacionam.
Posto isto, documento ainda não vai conter esta matriz, a estrutura desta já foi pensada, mas vai
ser apenas inserida no documento final da dissertação, quando as referências tiverem todas acertadas.
Apesar disto, os conceitos com que as referências irão cruzar podem ficar já aqui enumerados e,
são os seguintes: Sistemas de Informação, Tecnologias de Informação, Modelos de Processo, Modelos
de Maturidade e Abordagens ágeis.
8
2.2 Tecnologias de Informação e Sistemas de Informação
Tecnologias de Informação (TI) e Sistemas de Informação (SI), são termos bastantes comuns no
dia a dia das pessoas pertencentes a este universo, apesar disto, não existe um consenso universal para
estes conceitos e vários autores influentes na área apresentam as suas próprias descrições do que serão
então os Sistemas de Informação, como por exemplo Alter (1992) e Buckingham (1987) (Amaral, 1994;
Carvalho, 2000; Laribee, 1991).
Um SI é uma entidade que recolhe, guarda, processa e dissemina informação relevante para uma
organização, com o objetivo de a tornar útil e acessível para quem a deseja e possa utilizar (Buckingham
et al. 1987; Varajão, 2002)
Outra definição de Sistemas de informação, disponibilizada por Oliveira e Amaral (1999), é que
estes estes são vistos como a junção da gestão de recursos humanos e materiais que executam
atividades para adquirir, armazenar, processar e difundir informação, que podem ter ou não o
envolvimento de computadores.
Uma outra possível descrição de SI é feita por Renkema e Berghout (1997) e referem que um SI
pode ser descrito como a integração de todos os componentes que fornecem informação necessária,
sendo eles: as pessoas, os procedimentos, o software, o hardware e os dados processados pelo sistema.
Os Sistemas de Informação são suportados pelas Tecnologias de Informação. Para definir a
maneira como as Tecnologias de Informação suportam os Sistemas de Informação, Amaral (1994)
propõe a atividade de Planeamento de Sistemas de Informação (PSI) e, os resultados desta atividade
com foco nas TI são: a identificação das grandes opções tecnológicas (configurações, equipamentos,
suportes lógicos, suportes metodológicos,…). Amaral (1994) defende que segundo McNurlin e Sprague
Jr. (1989), o SI deve assumir como missão própria a melhoria do desempenho das pessoas no que diz
respeito aos processos da organização, através da utilização da informação e das TI.
Alter (1992), numa perspetiva tecnológica, dá a entender que as TI são o conjunto de
equipamentos e suportes lógicos (hardware e software), que permitem executar tarefas de aquisição,
transmissão, armazenamento, recuperação e exposição de dados (Alter, 1992; Amaral, 1994).
Hoje, a importância das TI e dos SI nas organizações, é uma realidade bem conhecida (Earl, 1989;
Eason 1988; Amaral, 1994). Sá Soares (1998) vai ao encontro disto ao referir que a aposta nos SI e a
adoção de TI por parte das organizações contribui para que se consigam superar os desafios mais atuais.
A escala de “agilidade” é direcionada às equipas de projetos TI e como tal importa ter a noção do
conceito de projeto. Segundo o PMI (2013), um projeto representa um esforço temporário, com datas
de início e fim bem definidas, assim como os recursos presentes (humanos, materiais, monetários, …)
9
para utilização e, através de um conjunto de operações específicas, criar um novo produto, serviço ou
resultado. O PMI propõe ainda as seguintes fases para o ciclo de vida de um projeto: Iniciação,
Planeamento, Execução e Conclusão.
Segundo Fernandes e Abreu (2014), nas últimas décadas têm surgido uma série de referenciais
que abordam as melhores práticas de TI. Segundo Mahmood (2006) os referências que se aplicam nos
projetos, neste caso de TI, fornecem um conjunto de boas práticas, normas, modelos de maturidade,
que auxiliam o desenvolvimento do projeto.
Alguns destes referenciais são: o CMMI-DEV, P-CMM, RUP, SCRUM, entre outros, que no âmbito
deste projeto vão servir de base para o estudo e desenvolvimento deste projeto, pois será necessário
conhecimento de um leque alargado de referenciais e investigação de casos de empresas que apliquem
abordagens ágeis para conseguir criar um método ou agrupar as melhores práticas por níveis de
maturidade, com a finalidade de medir a “agilidade” das equipas de projetos TI.
2.3 Métodos Tradicionais
2.3.1 Engenharia de Software
SWEBOK
O SWEBOK é um guia que apresenta um corpo de conhecimento que tenta definir uma profissão,
neste caso a de engenharia de software e defende que todas as profissões são baseadas num corpo de
conhecimento, apesar de algumas não o terem definido de maneira concisa (IEEE,2014).
A última versão do SWEBok (v3.0) apresenta 15 áreas de conhecimento para a prática da
engenharia de software, sendo elas: Software Requirements, Software Design, Software Construction,
Software Testing, Software Maintenance, Software Configuration Management, Software Engineering
Management, Software Engineering Process, Software Quality, Software Engineering Models and
Methods, Software Engineering Professional Practice, Software Engineering Economics, Computing
Foundations, Mathematical Foundations e Engineering Foundations (IEEE, 2014).
Numa primeira visão sobre estas áreas e após uma breve compreensão de cada uma, importa
rever a área “Software Engineering Process” com maior atenção. Um processo é um conjunto de
atividades relacionadas entre si que transformam um ou mais inputs em outputs, através do consumo
de recursos. Mais detalhadamente, um processo, designa uma sequência de atividades, geralmente
agrupadas em fases, que são executadas de forma sistemática e uniformizada por intervenientes com
10
responsabilidades bem definidas e que, a partir de um conjunto de inputs, produzem um conjunto de
outputs, através do consumo de recursos (Pressman, 2009). Esta área de conhecimento preocupa-se
com as atividades relacionadas com o desenvolvimento, manutenção e operação de software feitas pelos
engenheiros de software. Um processo de software possibilita facilitar a compreensão, comunicação e
coordenação humana. Esta área de conhecimento embaraça a definição de processo de software, o ciclo
de vida do software, a avaliação e melhoria do(s) processo(s) de software, a medição do software e
ferramentas de processo da engenharia de software, como se pode ver na figura que se segue (Fairley,
Bourque, & Keppler, 2014).
Figura 1- Tópicos para a área de conhecimento Engineering Process (retirado de (IEEE, 2014))
Segundo o Swebok v3.0 (2014), o tópico Software Process Definition embaraça a definição de
processo de software, a gestão de processos de software e a infraestrutura dos processos de software.
Os modelos de ciclos de vida (BKCASE, 2017) de software servem de definição das fases que ocorrem
durante o desenvolvimento de software, definir as suas atividades e combiná-las com o processo de
software, para que sejam devidamente detalhadas e ordenadas. A avaliação dos processos de software
é geralmente feita através da utilização de modelos e de métodos, como o ITIL e o CMMI são exemplos
de modelos enquanto que os métodos fornecem informação quantitativa que caracteriza o nível de
11
capacidade do processo. A medição dos processos e do software deve ser feita com recurso às forças e
fraquezas ou mesmo pelo impacto que produz no resultado final, antes do processo corrente ser
modificado ou ser implementado um novo. As ferramentas de processo da engenharia de software são
utilizadas para auxiliarem as atividades da engenharia de software e suportam muitas notações para
definir, implementar e gerir processos de software e ciclos de vida. Estas ferramentas podem também
ser baseadas em computador, Computer-Assisted Software Engineering (CASE), que reforçamo uso de
processos integrados, suportam a execução da definição dos processos e disponibilizam guias para o
ser humano desenvolver processos bem definidos.
O SWEBOK tenta com estas áreas identificar o que constitui o núcleo da engenharia de software,
mas defende que para além disto, os engenheiros de software devem ainda ter conhecimento noutras
áreas, que por exemplo podem ser definidas ou sob a responsabilidade da organização ou iniciativa em
que estão envolvidos.
Quatro Atividades Fundamentais da Engenharia de Software
Sommerville (2015a), enuncia que existem muitos processos de software diferentes, mas todos
devem incluir as quatro seguintes atividades fundamentais à engenharia de software:
Software Specification- é a atividade onde os clientes e os engenheiros de software definem
o software a ser implementado, assim como os seus requisitos e restrições na sua operação;
Software Design and Implementation- é uma atividade também chamada de Software
Development e é onde se faz o design do software e a sua programação;
Software Validation- é a atividade onde o software é testado e avaliado para assegurar que é
o que o cliente quer;
Software Evolution- é a atividade onde o software é modificado e reflete os requisitos das
mudanças do cliente e do mercado.
ISO 12207
A ISO/IEC 12207 (2008) é uma norma internacional sobre a engenharia de software que define
os processos de engenharia de software, atividades e tarefas associadas com o ciclo de vida dos
processos de software desde a sua conceção até à sua retirada. O objetivo desta norma é ser “a” norma
que define todas as tarefas necessárias para o desenvolvimento e manutenção de software. Em
acréscimo, as atividades que esta norma apresenta, são transversais a todos os modelos de processo.
12
Estabelece que cada processo tem um conjunto de resultados associados e engloba 23
processos, 95 atividades, 325 tarefas e 224 resultados.
O conjunto de processos, atividades e tarefas pode ser adaptado de acordo com o projeto. A ISO
12207 classifica os processos em três tipos: básico, de suporte e organizacional. Os processos
organizacionais e de suporte devem existir independentemente da organização e do projeto que esta a
ser executado. Já os processos básicos, devem ser instanciados de acordo com a situação.
Após este estudo e recolha de informação sobre a profissão de engenharia de sofware, das
tarefas transversais a todos os modelos de processo (ISO/IEC/IEEE, 2008). Existem outros métodos
tradicionais que suportam o desenvolvimento de software que importam ter em atenção relevante para
a elaboração de uma possível primeira iteração do objetivo desta dissertação. No âmbito desta recolha
do estado da arte (da parte tradicional) irão ser estudados, nas secções seguintes, os modelos de
processo tradicionais como o modelo Waterfall, o V-model e o RUP. Após isto pretende-se que seja
recolhida informação sobre os modelos de maturidade como o CMMI e o P-CMM, passando por estudar
também o TSP e o PSP, que é a origem do PCMM.
2.3.2 Modelos de Processo
Waterfall
Bell e Thayer (1976), no seu paper, explicam que Royce (1970) introduziu o conceito de
“waterfall” para atividades de desenvolvimento. As fases do modelo original de Royce (1970) estão
representadas na figura 2. Nesta abordagem, o desenvolvimento de software é feito de uma maneira
sequencial, como demostra a figura atrás referida.
Assim, o modelo Waterfall aborda e propõe uma sequência temporal do trabalho (Pressman,
2009), ou seja, é um modelo de desenvolvimento sequencial, onde o desenvolvimento do projeto
pressupõe que cada passo é cuidadosamente executado na perfeição e não se volta atrás. Por isso, é
visto como uma cascata que segue constantemente para baixo através das fases: Requirements Analysis
(do sistema e do software), Design (conceção do programa), Implementation (codificação), Verification
(testes), Maintenance, como é demonstrado na figura que se segue (Balaji,2012).
13
Figura 2- Passos para o desenvolvimento de um programa (retirado de Royce (1970))
Neste modelo, os outputs de cada uma das fases anteriores serve de input para a fase seguinte
e a passagem de uma fase para a seguinte faz-se de forma sequencial. Por exemplo, neste caso, só
quando a análise de requisitos estiver concluída, ou seja, quando todos os requisitos tiverem sido
cumpridos, revistos e aprovados, é que a equipa de TI pode prosseguir para a fase de design, não é
possível avançar para a fase seguinte se a anterior não estiver devidamente concluída e como tal, não
pode haver sobreposição de fases (Balaji, 2012).
Os defeitos são encontrados muito tarde no ciclo de vida do desenvolvimento do software, porque
a equipa de testes não é envolvida desde o início do projeto, é apenas envolvida na fase de testes,
retardando assim a altura em que os defeitos e falhas são encontradas (Balaji, 2012).
Apesar disto, para a utilização deste modelo, os requisitos fornecidos pelo cliente devem ser
claros e bem definidos antes de começar a fase seguinte do ciclo de vida, pois no modelo Waterfall, por
exemplo, a fase de requisitos deve ficar “congelada” antes de se poder começar a fase seguinte (design),
Consequentemente, futuras mudanças de requisitos não podem ser consideradas.
14
V-Model
O V-Model é uma versão modificada do modelo em cascata (Waterfall) e, na sua estrutura, para
além do eixo linear semelhante ao do Waterfall, tem um eixo que volta para cima depois da fase de
desenvolvimento de código (Balaji, 2012).
É um modelo que depende da verificação das fases anteriores antes de poder prosseguir, ou
seja, o produto de cada uma das fases precisa de ser verificado e aprovado antes de se poder avançar
para a fase seguinte. A figura 3 ilustra esta situação.
Figura 3- Diagrama representativo do V-Model (retirado de http://istqbexamcertification.com)
Neste modelo, se o cliente precisar de mudar algum requisito é possível fazer a atualização dos
respetivos requisitos, mas toda a documentação previamente preparada das fases de requisitos e das
subsequentes têm de ser atualizados (Balaji, 2012).
Rational Unified Process
O Rational Unified Process (RUP) é um processo de engenharia de software e fornece uma
abordagem que permite atribuir tarefas e responsabilidades dentro de uma organização de
desenvolvimento, com o objetivo de assegurar a produção de software de alta qualidade que vai de
encontro às necessidades dos utilizadores dentro de prazos e orçamentos estipulados (Kruchten,2003;
ANWAR, 2014).
15
Este processo melhora a produtividade das equipas através do fornecimento de um fácil acesso
a uma base de conhecimento com várias orientações (guidelines), templates (modelos) e ferramentas
para atividades de desenvolvimento. Além disto, descreve as seis melhores práticas no desenvolvimento
de software, que se comprovam serem “melhores práticas” porque são comummente utilizadas na
indústria por organizações bem sucedidas (Rational Software White Paper, 2004) sendo elas: Develop
Software Iteratively, Manage Requirements, Use Component-based Architectures, Visually model
software, Verify software quality, Control Changes to Software. A descrição de cada uma destas práticas
é feita segundo Sommerville (2013):
Develop Software Iteratively- devem ser planeados incrementos do sistema baseados
nas prioridades do cliente e desenvolver as funcionalidades com maior prioridade no
processo de desenvolvimento;
Manage Requirements- os requisitos do cliente devem estar devidamente explícitos e
deve-se seguir as mudanças que possam ser feitas a esses requisitos e o impacto que
estas podem causar ao sistema antes de as aceitar;
Use Component-based Architectures- estruturar a arquitetura do sistema em
componentes
Visually model software- Usar gráficos de modelos UML para representar vistas estáticas
e dinâmicas do software;
Verify software quality- Assegurar que o software vai de encontro às normas de qualidade
da organização;
Control Changes to Software- Gerir as mudanças do software utilizando sistemas de
gestão de mudança, procedimentos de gestão de manutenção e ferramentas.
A figura 4 representa as fases constituintes da abordagem do RUP, que são a Inception,
Elaboration, Construction, Transition. De seguida apresenta-se uma breve descrição destas fases
segundo Anwar (2014):
Inception- prepara o lançamento do projeto. O projeto tem de ser validado para poder
ser aplicado um orçamento. Normalmente é produzido um business case, com todos os
detalhes necessários ao lançamento;
Elaboration- esta fase foca em perceber os maiores riscos técnicos do projeto. Nesta
fase elabora-se um sistema básico (a arquitetura do sistema) que poderá responder à
maioria das questões técnicas;
16
Construction- tem o foco em desenvolver um sistema operacional através da utilização
da arquitetura criada na fase anterior. O foco maior é no desenvolvimento de
componentes e funcionalidades;
Transition- foca na transição do sistema do estado de desenvolvimento para o estado de
produção. O sistema deve cumprir os requisitos e preencher as necessidades dos
utilizadores.
Figura 4-Framework do RUP (retirado de https://www.pmi.org/learning/library/pmbok-rup-itil-software-development-7573)
2.3.3 Modelos de Maturidade
Segundo Sommerville (2015a) De hoje em dia, existe cada vez uma demanda maior por parte da
indústria de software melhor e mais barato, que tem de ser entregue em tempos cada vez menores. A
noção de maturidade do processo foi introduzida no final da década de 80 quando o Software Engineering
Institute (SEI) propôs o seu modelo de capacidade e maturidade dos processos.
Após a análise dos modelos de processo tradicionais da secção anterior, importa analisar modelos
de maturidade, pois estão diretamente relacionados com o tema desta dissertação. Neste caso como já
referido acima, vai ser retirado o essencial dos seguintes modelos de maturidade: CMMI e P-CMM. Para
além destes também se espera uma recolha de informação sobre o TSP e o PSP, pois são modelos que
ajudam a atingir certos níveis de maturidade. Espera-se que com as seguintes secções fiquem claros os
aspetos mais importantes e que possam ser relevantes para o objetivo desta dissertação.
17
CMMI
Nos métodos tradicionais, um dos grandes referenciais é o CMMI. O CMMI é uma representação
simplificada do mundo e incorpora as melhores práticas para organizações de desenvolvimento de
produtos e serviços. Desta maneira as melhores práticas presentes no modelo CMMI focam nas
atividades para o desenvolvimento de produtos e serviços de qualidade que vão de encontro às
necessidades dos clientes e utilizadores finais.
Este documento está organizado em três partes principais. A primeira fornece informação
genérica sobre o modelo, a segunda contém os objetivos e práticas genéricas e as áreas de processo
que o utilizador do modelo deve ter atenção, a terceira inclui apêndices e o glossário necessário à
compreensão do modelo (SEI, 2010).
As organizações, cada vez mais precisam de entregar os seus produtos e serviços que são
gradualmente mais complexos de uma maneira melhor, mais rápida e de menor custo (SEI,2010;
Sommerville, 2015a). Como de hoje em dia, as organizações para desenvolverem um produto ou serviço
complexo não desenvolvem todos os componentes dentro da empresa, é comum que alguns sejam
adquiridos e finalmente integrados com os construídos dentro da empresa, ou não, para obter o produto
ou serviço final. Assim sendo, as organizações necessitam de conseguir gerir e controlar todo este
desenvolvimento complexo e processo de manutenção.
Para as organizações conseguirem melhorar a maneira de fazerem os seus negócios existem no
mercado, modelos de maturidade, normas, metodologias e guias. Contudo, muitas das abordagens
focam em partes específicas do negócio e não tomam uma abordagem sistémica aos problemas que
muitas organizações enfrentam.
O CMMI pode ser visto como uma coleção das melhores práticas relacionadas com a melhoria
dos processos nas organizações (SEI, 2010) e tem o objetivo fundametal que é avaliar a maturidade dos
processos da organização (Fernandes e Abreu, 2014; Jalote, 2002). A framework presente no CMMI, é
usada para gerar vários modelos e materiais de treino e avaliação. Os modelos são categorizados por
representações e pelos tipos de processos
O CMMI apresenta dois tipos de implementação que as organizações que aplicam este modelo
fazem: implementação por etapas (muitas vezes chamada de faseada) ou implementação contínua.
Para este trabalho, importa focar na implementação por etapas por ser o tipo de implementação
que divide as vinte e duas áreas de processo presentes no CMMI em níveis de maturidade.
Existem 5 níveis de maturidade diferentes na implementação por etapas do CMMI e para
alcançar estes níveis, cada um tem um determinado conjunto de áreas de processo que devem ser
18
atingidas. Cada um destes níveis vai ser descrito conforme a literatura de SEI (2010) e
(Sommerville,2015a).
O nível 1 é o nível inicial (denominado de Initial) e qualquer organização possui este nível 1 de
maturidade, é um nível que refere a processos imprevisíveis, controlados de forma pobre e pouco reativos
(ou seja, não são proativos).
O nível 2 de maturidade tem a designação de Managed, neste nível, os processos estão
caracterizados para projetos, tomam alguns inputs e geram alguns outputs, mas continuam a não ser
proativos, são reativos, quando algumas circunstâncias ocorrem, têm algumas soluções e respondem
de acordo. Cada projeto tem um conjunto de padrões, que estão implementados apenas ao nível do
projeto e as organizações que se encontram neste nível limitam-se a seguir estes padrões em todos os
projetos.
No nível 3 a designação para este nível de maturidade é Defined, todos os padrões que certo
projeto segue, é ao nível da organização e os processos estão descritos para a organização e deixam de
ser reativos e passam a ser proativos.
O nível 4, Quantitatively Managed, fala sobre números, sobre dados e estatísticas. Por exemplo,
a empresa tem de ter um certo lucro ou uma certa receita e por isso os seus processos são geridos e
controlados quantitativamente.
Finalmente, ao chegar ao nível 5, denominado de Optimizing. aqui os números que se trataram
no nível 4 precisam de ser otimizados, ou seja focar nos resultados e nos dados utilizados no nível 4 e
de alguma maneira otimizá-los e por isso as organizações que se encontram neste nível, focam na
melhoria continua dos processos (SEI, 2010; Sommerville,2015a).
A Tabela 2, agrupa as 22 áreas processos presentes no CMMI pelos respetivos níveis de
maturidade.
Nome da área de processo processo Tipo Abreviação
Nível de
maturidade
Configuration Management Suporte CM 2
Measurement and Analysis Suporte MA 2
Project Monitoring and Control Gestão de projetos PMC 2
Project Planning Gestão de projetos PP 2
Process and Product Quality Assurance Suporte PPQA 2
Requirements Management Gestão de projeto REQM 2
Supplier Agreement Management Gestão de Projeto SAM 2
19
Decision Analysis and Resolution Suporte DAR 3
Integrated Project Management Gestão de projeto IPM 3
Organizational Process Definition Gestão de processo OPD 3
Organizational Process Focus Gestão de processo OPF 3
Organizational Training Gestão de processo OT 3
Product Integration Engenharia PI 3
Requirements Development Engenharia RD 3
Risk Management Gestão de projeto RSKM 3
Technical Solution Engenharia TS 3
Validation Engenharia VAL 3
Verification Engenharia VER 3
Organizational Process Performance Gestão de processo OPP 4
Quantitative Project Management Gestão de projeto QPM 4
Causal Analysis and Resolution Suporte CAR 5
Organizational Performance Management Gestão de processo OPM 5
Tabela 1- Organização dos Processos por Níveis de Maturidade (adaptado de SEI (2010))
Utilizando este modelo de Maturidade, para se progredir de nível de maturidade, ou seja, para
passar ao nível seguinte, a organização deve ter incorporados todos os processos do nível de maturidade
anterior (SEI,2010). Em seguida será resumida, brevemente, cada uma das 22 áreas de processo, para
posteriormente, na fase de dissertação (pós projeto de dissertação) ser possível fazer mentalmente
comparações com outros modelos ou outras práticas caso seja necessário, para se perceber as bases
dos níveis de maturidade tradicionais propostos. E, se possível, através de relacionamentos e/ou práticas
parecidas começar a elaborar o escalonamento proposto pelo tema desta dissertação.
De acordo com o CMMI-DEV 1.3 (SEI, 2010) as áreas de processo são as seguintes:
CAUSAL ANALYSIS AND RESOLUTION (CAR)- Esta área de processo serve para
identificar as causas de resultados selecionados e planear medidas corretivas e
preventivas para melhorar o desempenho dos processos. Desta maneira é possível
melhora a qualidade e produtividade da organização.
CONFIGURATION MANAGEMENT (CM)- A CM ajuda a estabelecer e a manter a
integridade dos artefactos, através da utilização configuration identification, configuration
control, configuration status accounting, and configuration audits.
20
Decision Analysis and Resolution (DAR) - Ajuda a escolher a melhor alternativa através
análise de decisões possíveis e da utilização de um processo de avaliação formal que
avalie as alternativas indentificadas em contraste com as estabelecidas.
INTEGRATED PROJECT MANAGEMENT (IPM)- Esta área de processo ajuda a
estabelecer, gerir o projeto e o envolvimento de stakeholders relevantes e leva a criação
de um processo padrão para o desenvolvimento de processos do projeto definidos.
MEASUREMENT AND ANALYSIS (MA)- Esta área tem o propósito de desenvolver e
sustentar a capacidade de fazer medições em projetos ao nível da organização. Isto pode
ser usado para ajudar na tomada de decisão por parte da gestão de topo.
ORGANIZATION PROCESS DEFINITION (OPD)- Esta área de processo de estabelecer e
fazer a manutenção gradual necessária de um conjunto de processos ativos na
organização, de padrões de ambiente de trabalho, regras e orientações para equipas.
ORGANIZATION PROCESS FOCUS (OPF)- Esta área ajuda no planeamento,
implementação e implantação de melhorias de processos organizacionais. Tem como
base a compreensão dos pontos fortes e fracos atuais dos processos da organização.
ORGANIZATIONAL PERFORMANCE MANAGEMENT (OPM)- Tal como o nome sugere,
esta área foca na gestão proativa do desempenho da organização na medida em que
vai de encontro aos objetivos do negócio.
ORGANIZATIONAL PROCESS PERFORMANCE (OPP)- Esta área fornece ajuda às
atividades de melhoria de processos, na medida em que se estabelece e mantem uma
compreensão quantitativa do desempenho de um conjunto de processos padrão da
organização que dão o suporte necessário para alcançar objetivos de qualidade e de
desempenho de processos, fornecer dados sobre o desempenho de processos e
modelos que possibilitem a gestão quantitativa dos projetos da organização.
ORGANIZATIONAL TRAINING (OT)- O propósito desta área está associado ao
desenvolvimento dos skills e conhecimento das pessoas da organização para poderem
desempenhar as suas tarefas de maneira eficaz e eficiente.
PRODUCT INTEGRATION (PI)- Esta área de processo tem a função de conseguir reunir
os componentes do produto no produto final e, ainda, garantir que o produto depois da
integração se comporta como esperado e a sua entrega.
PROJECT MONITORING AND CONTROL (PMC)- Esta área de processo serve para se
garantir um conhecimento do progresso do projeto e consequentemente ser possível a
21
aplicação de medidas corretivas adequadas caso o desempenho do projeto se desvie
significativamente do plano.
PROJECT PLANNING (PP)- O propósito desta área de processo é estabelecer e fazer a
manutenção gradual dos planos que definem as atividades do projeto. Para isto, esta
área deve consistir nas melhores práticas de planeamento de projeto para ajudar a
concretizar um planeamento de projeto eficaz. Fazem parte desta área itens como
estimações, o preparação do plano de projeto que inclui o planeamento dos recursos, a
calendarização, o plano de riscos e contingências, etc
PROCESS AND PRODUCT QUALITY ASSURANCE (PPQA)- Esta área suporta a gestão da
qualidade dos processos e produtos através da utilização de atividades de garantia de
qualidade. Desta maneira, promove-se a entrega de produtos de alta qualidade, pois
todos o staff e gestores do projeto têm feedback e uma vista apropriada, a todos os
níveis, dos processos e produtos a serem desenvolvidos durante o tempo de vida do
projeto.
QUANTITATIVE PROJECT MANAGEMENT (QPM)- A área QPM tem o propósito de gerir e
controlar quantitativamente o projeto de forma a alcançar os objetivos de desempenho
de processos e qualidade estabelecida.
REQUIREMENTS DEVELOPMENT (RD)- O propósito desta área de processo é fazer a
coleta de requisitos, analisá-los e depois detalhá-los em diferentes tipos de requisitos,
tais como: requisitos do utilizador, do cliente, do produto e das componentes do produto.
REQUIREMENTS MANAGEMENT (REQM)- Esta área ajuda na gestão dos requisitos dos
produtos do projeto e das componentes do projeto. E, assegura que estes requisitos
estejam alinhados com o trabalho que é desenvolvido nos artefactos do projeto e com
os planos de projeto.
RISK MANAGEMENT (RSKM)- O propósito desta área é identificar possíveis problemas
antes que ocorram para que se possam planear atividades de tratamento de risco
(medidas atenuantes/corretivas/de prevenção/planear a sua mitigação) e executá-las
conforme necessário durante toda a vida do projeto ou produto para mitigar impactos
adversos à concretização dos objetivos.
SUPPLIER AGREEMENT MANAGEMENT (SAM)- A presente área ajuda na gestão da
aquisição de produtos e serviços de fornecedores.
22
TECHNICAL SOLUTION (TS)- O propósito desta área é ajudar na seleção, projeção e
implementação de soluções para os requisitos do projeto.
VALIDATION (VAL)- Esta área de processo tem o propósito de demonstrar que o produto
ou componente do produto funciona como desejado quando alocada no ambiente
pretendido.
VERIFICATION (VER)- O propósito desta área é assegurar que certos artefactos
selecionados vão de encontro aos seus requisitos específicos, verificando-os.
Personal Software Process (PSP)
Todos os desenvolvedores de software utilizam algum processo para o contruir. O Personal
Software Process enfatiza a medição pessoal de ambos o trabalho dos artefactos do produto a ser
realizado e a qualidade que resulta deste produto de trabalho. Este modelo define 5 atividades que cada
pessoa deve ter presente, de modo a torna-la ciente e responsável quanto ao plano de projeto e dar-lhe
a habilidade de controlar a qualidade de todos os produtos de trabalho de software que são desenvolvidos
(Pressman, 2009). O modelo PSP define cinco atividades, que são as seguintes: Planning, High-level
design, High-level design review, Development, Postmortem e, vão ser descritas brevemente segundo
Pressman (2009):
Planning- Esta atividade define os requisitos. Todas as métricas são redigidas e
guardadas. Após isto, as atividade de desenvolvimento são identificadas e o calendário
do projeto é criado.
High-level design- Especificações para cada componente a ser desenvolvida e é criado o
design do componente. São construídos protótipos quando existe incerteza. Todos os
problemas são seguidos e escritos em “relatórios” de forma a gravar os acontecimentos.
High-level design review- Verificação formal dos métodos para possibilitar descobrir erros
no design.
Development- O design ao nível da componente é refinado e revisto. É gerado código,
revisto, compilado e tewstado.
Postmortem- A eficácia do projeto é determinada através do uso das medidas e métricas
coletadas, que devem fornecer guias para a modificação do processo tendo em vista a
melhoria da eficácia.
23
Quando o PSP é devidamente introduzido aos engenheiros de software (Humphrey, 1997),
resulta numa melhoria da produtividade e qualidade na execução das tarefas e trabalhos relacionados
com a engenharia de software (Ferguson, 1997).
Team Software Process (TSP)
Muitos projetos de software são tidos por uma equipa de praticantes da profissão de engenharia
de software, por isto, Watts Humphrey extendeu o que se pôde aprender com a introdução do PSP e
propôs um Team Software Process (TSP). O objetivo do TSP é construir equipas de projeto que se auto
direcionam e se organizam de maneira a produzir software de alta qualidade (Humphrey, 2000).
Segundo Pressman (2009), uma equipa que se auto direciona compreende os objetivos e metas
globais, define papeis e responsabilidades para cada elemento da equipa, rastreia quantitativamente
dados do projeto, sobre a produtividade e qualidade, identifica um processo de equipa que é apropriado
para o projeto e a estratégia para a implementação do projeto, define normas aplicáveis ao trabalho da
equipa de engenharia de software, avalia continuamente o risco e reage conforme, segue, gere e reports
(cria relatórios) do estado do projeto.
As atividades que o modelo TSP define são as seguintes: project launch, high-level desing,
implementation, integration and test e postmortem. Estas atividades possibilitam que a equipa planeie,
faça o design e costrua o software de uma maneira disciplinada e ao mesmo tempo meça
quantitativamente o processo e o produto. A atividade postmortem serve para preparar uma etapa que
visa a melhoria de processos.
O TSP reconhece que as melhores equipas de software são auto-direcionadas. Os seus membros
definem objetivos para o projeto, adaptam o processo conforme as necessidades, controlam a
calendarização do projeto e através da medição e análise de métricas coletadas, trabalham
continuamente para melhorar a abordagem da equipa à engenharia de software (Pressman, 2009).
People Capability Maturity Model (P-CMM)
O People Capability Maturity Model (P-CMM) fornece um mapeamento para a transformação da
organização através da melhoria das práticas dos seus trabalhadores. Assim como o CMMI, o P-CM
também consiste em cinco níveis de maturidade, perante os quais as práticas dos trabalhadores da
organização evoluem (Curtis, Hefley, & Miller, 2009) e a imagem ilustra esta situação.
24
Figura 5- Os 5 níveiws de maturidade do P-CMM (Retirado de (Curtis, et al., 2009))
O P-CMM teve o PSP na sua origem e o SEI, desenvolveu o P-CMM pelo facto do fator das
pessoas ser deveras importante, ao mesmo tempo que reconhece que “toda a organização precisa de
melhorar continuamente a sua habilidade de atrair, desenvolver, motivar, organizar e reter a sua força
de trabalho necessária para cumprir os objetivos estratégicos do negócio” (Curtis, et al., 2009;
Pressman, 2009). Esta ferramenta reforça a necessidade de reconhecer a importância das pessoas
como indivíduos e de desenvolver as suas capacidades. O P-CM pode levar a melhorias significantes na
capacidade das organizações produzirem software de alta qualidade (Sommerville, 2015b).
Os objetivos estratégicos do P-CMM (Sommerville, 2015b) são:
Melhorar a capacidade das organizações que desenvolvem software, através do aumento da
sua força de trabalho;
Assegurar que a capacidade de desenvolvimento é um atributo da organização e não de
apenas alguns indivíduos;
Alinhar a motivação dos indivíduos com a da organização;
Reter pessoas que sejam valiosas (que tenham conhecimento crítico e habilidades) na
organização.
ISO 15504
A revisão desta norma vai ser feita através dos artigos de Pino, Baldassarre, Piattini, & Visaggio
(2009), Maheshkumar & Sukhbaatar, 2010 e, do livro de Loon(2007) que incluem várias informações
sobre a ISO/IEC 15504 e permite chegar às conclusões apresentadas nos próximos parágrafos.
25
A norma ISO/IEC 15504, também conhecida como SPICE, é uma framework para a avaliação
de processos. Com isto, é possível fazer uma revisão dos processos de software da organização, pois é
feita de maneira disciplinada uma análise dos processos de uma organização tendo em conta um
conjunto de critérios para se determinar a capacidade destes processos cumprirem com os objetivos de
qualidade, custo e calendarização. Assim, é de grande ajuda às melhorias da organização, já que permite
encontrar problemas críticos e estabelecer prioridades nas melhorias, isto leva à elaboração de um plano
de melhoria. Refere-se ainda que para se começar a fazer melhorias, é necessário saber o estado atual
dos processos de software da organização, os objetivos futuros e ainda se os objetivos foram atingidos
quando as atividades do plano de melhoria acabam.
A framework de avaliação SPICE, contém duas dimensões, a dimensão do Processo e a
dimensão da capacidade. Assim, cada processo recebe um certo nível de capacidade.
A escala de medida da capacidade do processo é definida desde o nível Incomplete Process,
que é o nível que representa menos capacidade e significa que o seu desempenho não é capaz de
preencher todos os objetivos, até ao nível Optimising Process, que por sua vez é o nível com mais
capacidade e significa que o seu desempenho é capaz de ir ao encontro dos objetivos e também sustentar
a melhoria contínua do processo. Os níveis intermédios são: Performed, Managed, Established,
Predictable.
2.4 Abordagens Ágeis
Esta secção serve para recolher informação do estado da arte sobre métodos ágeis, pois são os
que estão diretamente relacionados com o tema desta dissertação. Apesar disto, os métodos tradicionais
não podem ser negligenciados, pois ambos poderão ser necessários para o desenvolvimento da escala
de maturidade ágil. Correntemente não existe nenhuma maneira formulada de medir a maturidade ágil
de equipas TI. Portanto, é importante perceber os conceitos através do estado da arte relacionada com
o tema para na fase de dissertação ser possível tentar avançar com uma primeira iteração de uma
possível escala de maturidade ágil.
Apesar de todos os métodos tradicionais descritos acima, existe muita burocracia e sobrecarga
por parte destes métodos formais de melhoria de processos para pequenas empresas (Sommerville,
2015a).
26
Na década de 90 e mesmo antes já se falava de métodos “leves” que evoluíram através da reação
aos métodos mais “pesados” ou tradicionais, que foi quando várias metodologias até à data chamadas
“leves” começaram a aparecer, como por exemplo o Scrum, o Extreme Programming, o Crytal Clear,
entre outros. Só a partir do Manifesto Ágil é que métodos como os enumerados começaram a utilizar o
termo “ágil” para serem referidos.
2.4.1 Manifesto Ágil
A filosofia por trás dos métodos ágeis foi refletida no manifesto ágil em Fevereiro de 2001 e
assinado por todos os 17 participantes, que se nomearam de “The Agile Alliance”, os quais são
intervenientes e representantes de com métodos de desenvolvimento ágil (como é o exemplo de
representantes dos métodos XP, SCRUM, DSDM (Dynamic Systems Development Method), Adaptive
Software Development, Crystal, Feature-Driven Development, Pragmatic Programming) e também
simpatizantes com a necessidade da existência de uma alternativa para métodos mais “pesados” como
os tradicionais (Kent et al., 2001).
Desta reunião emergiu então o Manifesto for Agile Software Development (Manifesto para o
Desenvolvimento Ágil de Software), assinado por todos os participantes como referido acima, que
também por serem representantes de diferentes métodos, por vezes competem entre si. Todos em
acordo, como “The Agile Alliance”, criada na reunião, definiram um conjunto de valores e princípios do
desenvolvimento ágil de software.
Então, o Manifesto for Agile Software Development, cita: “Ao desenvolver e ao ajudar outros a
desenvolver software, temos vindo a descobrir melhores formas de o fazer. Através deste processo
começámos a valorizar:
Indivíduos e interações mais do que processos e ferramentas;
Software funcional mais do que documentação compreensiva;
Colaboração com o cliente mais do que negociações contratuais;
Responder à mudança mais do que seguir um plano.
Ou seja, apesar de reconhecermos valor nos itens à direita, valorizamos mais os itens à esquerda”(Kent,
et al., 2001).
Para além destes quatro valores, constataram-se ainda doze princípios que estão por trás do
Manifesto Agil (Kent et al., 2001) e, que por exemplo autores como Pressman (2009) e Cockburn (2002)
incluem-nos nos seus livros, sendo eles:
27
“A nossa maior prioridade é, desde as primeiras etapas do projeto, satisfazer o
cliente através da entrega rápida e contínua de software com valor.”
“Aceitar alterações de requisitos, mesmo numa fase tardia do ciclo de
desenvolvimento. Os processos ágeis potenciam a mudança em benefício da
vantagem competitiva do cliente.”
“Fornecer frequentemente software funcional. Os períodos de entrega devem
ser de poucas semanas a poucos meses, dando preferência a períodos mais
curtos.”
“O cliente e a equipa de desenvolvimento devem trabalhar juntos, diariamente,
durante o decorrer do projeto.”
“Desenvolver projetos com base em indivíduos motivados, dando-lhes o
ambiente e o apoio que necessitam, confiando que irão cumprir os objetivos.”
“O método mais eficiente e eficaz de passar informação para dentro e dentro
de uma equipa de desenvolvimento é através de conversa pessoal e direta.”
“A principal medida de progresso é a entrega de software funcional.”
“Os processos ágeis promovem o desenvolvimento sustentável. Os sponsors, a
equipa e os utilizadores deverão ser capazes de manter, indefinidamente um
ritmo constante.”
“A atenção permanente à excelência técnica e um bom design da solução
aumentam a agilidade.”
“Simplicidade- a arte de maximizar a quantidade de trabalho que não é feito- é
essencial.”
“As melhores arquiteturas, requisitos e desenhos surgem de equipas auto-
organizadas.”
“A equipa reflete regularmente sobre o modo de se tornar mais eficaz, fazendo
os ajustes e adaptações necessárias.”
Sommerville (2015a), com base na filosofia por trás do manifesto ágil e valores apresentados
pelos seus autores, apresenta uma visão sobre um conjunto de princípios comuns a vários métodos
ágeis e respetiva descrição. Este autor acrescenta que todos os métodos ágeis sugerem que o
desenvolvimento e entrega de software deve ser feito de maneira incremental. E, estes métodos são
baseados em diferentes processos ágeis mas partilham um conjunto de princípios, sendo eles
28
“Envolvimento com o cliente”, “Adotar a mudança”, “Entregas incrementais”, “Manter a simplicidade”,
“Pessoas, não processos”.
O princípio “Envolvimento com o cliente” avoga que os clientes devem ser envolvidos ao longo
do processo de desenvolvimento e o seu papel é fornecer, priorizar novos requisitos do sistema e avaliar
iterações do sistema. “Adotar a mudança” significa esperar e aceitar que os requisitos do sistema
mudem e como tal desenhar o sistema para alojar estas mudanças. O princípio “Entregas Incrementais”
provém do facto que nos métodos ágeis, o software é desenvolvido através de incrementos, com o cliente
a especificar os requisitos a serem incluídos em cada incremento. No princípio “Manter a simplicidade”
descreve que deve existir o foco na simplicidade tanto no software a ser desenvolvido como no processo
de desenvolvimento, seja onde for possível, deve-se trabalhar ativamente para que se possa eliminar o
máximo de complexidade possível do sistema. “Pessoas, não processos” é um princípio que refere que
as habilidades da equipa de desenvolvimento devem ser reconhecidas e exploradas. Os elementos da
equipa devem ser deixados para desenvolver as suas próprias maneiras de trabalhar sem processos
prescritos (Sommerville, 2015a).
2.4.2 Chaos Report
O Standish Group (2015) elaborou um relatório sobre o estado da indústria de desenvolvimento
de software, no qual abrangem 50000 projetos de todo o mundo, feitos numa vasta variedade de
indústrias, desde pequenas melhorias a implementações de reengenharia em sistemas muito complexos
(Hastie & Wojewoda, 2015).
Uma das grandes diferenças do relatório do ano de 2015 para os anos anteriores, foi que o
Standish Group redefiniu a sua definição de sucesso, como relata Jennifer na entrevista presente no
artigo de Hastie & Wojewoda (2015). Para o Standish Group, antes um projeto de sucesso era dentro do
tempo, do orçamento e do âmbito, mas em 2015, este último mudou para “com resultados satisfatórios.
Neste relatório podemos ver que em 2015, comparativamente aos 4 anos que lhe precedem, o
sucesso geral dos projetos aumentou, a percentagem dos projetos desafiadores e que falharam diminiu
(Hastie & Wojewoda, 2015).
É ainda referido neste relatório que a tendência dos projetos mais pequenos terem uma maior
probabilidade de sucesso continuou como no relatório do ano anterior. Sommerville (2015a), no seu livro
também acaba por confirmar este facto, ao referir que os métodos ágeis têm tido mais sucesso para
dois tipos de desenvolvimento de sistemas: quando o a organização desenvolve um produto de tamanho
médio ou pequeno para venda e quando existe um compromisso do cliente com o processo de
29
desenvolvimento, onde há poucas regulamentações e stakeholders externos que possam afetar o
software, sendo desta maneira mais fácil de alcançar resultados satisfatórios.
Com a inserção de métodos ágeis de desenvolvimento nos últimos anos, neste estudo é possível
comparar os resultados dos projetos entre os que utilizam uma metodologia ágil e projetos tradicionais,
como uma metodologia em waterfall, tendo ainda como outro fator de análise, o tamanho do projeto.
Como se pode ver na figura 6 presente neste estudo, em todos os tamanhos dos projetos, as abordagens
ágeis apresentam resultados que incluem uma maior probabilidade dos projetos serem bem sucedidos
e menor probabilidade de falhas completas (Hastie & Wojewoda, 2015).
Figura 6- Comparação da Chaos Resolution entre Agile e Waterfall (retirado de https://www.infoq.com/articles/standish-chaos-2015)
2.4.3 Métodos ágeis
As ideias subjacentes aos métodos ágeis foram desenvolvidas por volta do mesmo tempo por
um número diferente de pessoas na década de 1990 (Sommerville,2015a) e, como já referido no início
da secção 2.4, antes do Agile Manifesto, alguns dos métodos que aqui vão ser revistos ( como os que já
existiam antes de 2001), eram chamados de métodos “lean”, que era o termo utilizado na indústria
antes do termo “ágil” ganhar popularidade.
Cohn (2006), na sua obra e, a partir da compreensão dos quatro valores principais citados no
Manifesto Ágil, propõe que se pode virar a atenção para o que uma equipa ágil parece na prática. Os
30
quatro valores ao serem tidos em conta coletivamente, levam a processos de desenvolvimento de
software que são altamente iterativos e incrementais e, que levam à entrega de código e software testado
no final de cada iteração. Então, Cohn (2006) propõe que as maneiras principais em que as equipas
ágeis trabalham são:
Trabalhar como uma equipa;
Trabalhar em pequenas iterações;
Entregar algo em cada iteração;
Focar nas prioridades do negócio;
Inspecionar (perceber o que correu bem e o que correu mal) e adaptar;
Nesta secção é feita uma revisão descritiva e sucinta de vários abordagens para o
desenvolvimento ágil: Extreme Programming (XP), Scrum, Kanban e OpenUP com o objetivo de recolher
informação sobre ambos os métodos, assim como as melhores práticas propostas por estes, que serão
úteis para a formulação de uma primeira iteração da escala de maturidade ágil a ser proposta com esta
dissertação.
Os métodos Extreme Programming (XP) e o Scrum são dois métodos ágeis bastante conhecidos.
Muitas vezes, na prática, os métodos de gestão de projeto presentes no Scrum são combinados com as
técnicas mais práticas do XP, desta maneira as duas técnicas podem funcionar como complemento uma
da outra (Stellman & Greene, 2014).
Extreme Programming (XP)
Em 1999, Beck documentou a ideia do XP num livro chamado “Extreme programming Explained”,
este autor é um dos participantes de Agile Alliance e também foi um dos participantes do Agile Manifesto.
Em 2004 publicou a segunda versão do livro, com melhorias de cinco anos de experiência de trabalho
com o XP, incluindo feedback positivo e negativo.
O XP evoluiu de problemas causados devido aos longos ciclos de desenvolvimento dos modelos
de desenvolvimento tradicionais (Beck,1999) e surgiu primeiramente com práticas que foram vistas
como eficazes nos processos de desenvolvimento de software durante as décadas anteriores (Beck,
2000). É uma coleção de ideias e práticas retiradas de metodologias já existentes (Beck, 1999).
Beck (2000) explica que o termo “extreme” resulta de levar os princípios e práticas do senso
comum a um nível extremo e que apesar das práticas individuais presentes no XP não terem sido criadas
por ele e não serem novas, foram coletadas e alinhadas de maneira a poderem ser integradas entre si e
formar uma metodologia para o desenvolvimento de software.
31
O XP tem o objetivo de possibilitar o desenvolvimento de software com sucesso mesmo com
requisitos vagos ou em constante mudança em pequenas e médias equipas.
Em XP, os requisitos são chamados de “user stories”, que são implementados diretamente como
uma série de tarefas. Os programadores trabalham em pares, desenvolvem os testes para cada tarefa
antes de escreverem o código e todos os testes devem ser executados com sucesso quando o código é
integrado no sistema (Sommerville, 2015a).
Os principais valores do XP são a comunicação e feedback, simplicidade e coragem. A
comunicação frequente e cara a cara com o consumidor e também com os desenvolvedores do projeto,
que é vital para o sucesso do projeto em XP. O lançamento frequente de código funcional e consequente
receção de feedback por parte do cliente também representa uma parte crítica. Este método defende
que é mais rápido e mais eficiente desenvolver uma solução simples para as necessidades correntes do
software do que gastar demasiado tempo a desenhar uma solução flexível e reutilizável. Os
programadores em XP precisam de acreditar que com os valores e práticas presentes neste, serão
responsáveis por produzir código de alta qualidade para o software (Turk, et al., 2005).
Processo O ciclo de vida do XP consiste nas seguintes fases: Exploração, Planeamento, Iterações a serem
entregues, Produção, Manutenção e Morte (Beck,2000). A figura 7 esquematiza o ciclo de vida do processo em XP.
Figura 7-Ciclo de Vida do Processo em XP (retirado de Abrahamson, et al.,(2002))
32
A tabela seguinte descreve de forma sucinta as fases do ciclo de vida conforme a descrição de Beck (2000) no capítulo 21.
Fase Descrição
Exploração
Os clientes escrevem as user stories que desejam ver incluídas na primeira entrega. Cada story acrescenta uma funcionalidade a ser adicionada ao sistema. Enquanto isto, a equipa do projeto estuda as limitações, familiariza-se, testa a tecnologia a utilizar e explora diferentes possibilidades de arquitetura para o sistema através do desenvolvimento de um protótipo do sistema.
Planeamento
Define a prioridade de cada story e o acordo do conteúdo entre os programadores e o cliente que a primeira entrega deve ter, ou seja, quando um pequeno conjunto de stories estará completo. Para acordarem a calendarização das entregas, os programadores, fazem uma estimativa baseada no esforço que cada story requere
Iterações a serem entregues
Inclui varias iterações do sistema antes da primeira entrega. A calendarização da fase de planeamento é dividida pelo número de iterações (cada uma destas leva de uma a quatro semanas a ser implementada). O cliente é quem decide as stories que vão ser selecionadas para cada iteração e no final de cada uma cria os testes funcionais a serem executados. No final da última iteração o sistema está pronto para produção.
Produção
Requer a execução de mais testes e a avaliação do desempenho do sistema antes de ser entregue ao cliente. Nesta fase, novas mudanças podem ser requeridas e a decisão de serem incluídas na versão atual ou numa futura, tem de ser tomada. Conta também com feedback por parte do cliente. As novas ideias e sugestões são documentadas para serem implementadas durante a fase de manutenção.
Manutenção
Esta fase lida com a necessidade de manter o sistema da primeira entrega funcional enquanto que, ao mesmo tempo, se produzem novas funcionalidades. Importa notar que a equipa deve estar preparada para interromper o desenvolvimento caso ocorra algum problema na produção. Nesta fase também é aplicado esforço em tarefas que dizem respeito ao suporte ao cliente. Por estes factos, a velocidade de desenvolvimento pode diminuir depois do sistema estar em produção.
Morte
A aproximação desta fase dá-se quando o cliente não tem mais stories para serem implementadas, mas isto requer que o sistema satisfaça as necessidades do cliente. É o momento no qual se escreve a documentação necessária sobre o sistema, quando não existem mais mudanças na arquitetura, design, código do sistema. Apesar disto, pode ainda haver outro meio de chegar a esta fase, que é quando o sistema não entrega os resultados desejados, quando se torna muito dispendioso ou quando existe a inabilidade do sistema acomodar stories futuras.
Tabela 2- Descrição das fases do ciclo de vida do XP (adaptado de Beck (1999;2000) e Abrahamson, et al.,(2002))
33
Papéis e responsabilidades
No XP existem papéis diferentes para os vários integrantes da equipa do projeto que variam conforme as tarefas que cada um tem como responsabilidade. A tabela seguinte apresenta segundo o capítulo 22 de Beck (2000), os vários papéis e responsabilidades correspondentes.
Papel Responsabilidades
Programador
Escrever testes e manter o código o mais simples possível. Comunicar e existir coordenação com outros programadores e membros da equipa, pois um dos factores de sucesso do XP é conseguir com que exista esta comunicação e coordenação entre todos os integrantes do projeto.
Cliente Escrever as stories e os testes funcionais. Decidir quando um cada requisite é satisfeito. Definir a prioridade dos requisitos para a implementação.
Tester Ajudar o cliente a escrever testes funcionais. Executar regularmente estes testes, transmitir os seus resultados e ter a preocupação da manutenção das ferramentas de teste.
Tracker
Seguir as estimativas feitas pela equipa e dar feedback sobre o quão precisa foi a sua estimativa, com o objetivo de melhorar estimativas futuras. Traçar o progresso feito para cada iteração e avaliar se os objetivos são tangíveis conforme os recursos disponíveis e restrições de tempo ou se alguma mudança será necessária ao processo.
Coach
Ser responsável pelo processo como um todo. Notar quando existem desvios do que deve ser feito (do processo da equipa) e fazer com que a equipa tenha atenção a este aspeto, ou seja, servir de guia para os membros da equipa seguirem o processo.
Consultor
Membro externo à equipa que deve possuir o conhecimento técnico específico necessário. Estar atento ao que a equipa faz de uma maneira neutra. Guiar a equipa para perceberem o problema que necessitam de resolver de maneira clara. Providenciar testes específicos para mostrar exatamente quando o problema foi resolvido. Estar disponível para ensinar como resolver os seus problemas aos membros que necessitarem.
Big Boss ou Gestor
Tomar as decisões. Comunicar com a equipa para determinar a situação corrente e distinguir quaisquer dificuldades ou deficiências no processo.
Tabela 3- Descrição dos papéis e responsabilidades do XP (adaptado de Beck (2000))
Melhores práticas
Práticas são atividades concretas e artefactos que um método define como base a serem
utilizadas no processo (Abrahamsson, et al., 2002) e são as descrições das maneiras de atingir um objetivo (Sommerville, 2009).
Pequenas iterações e entregas com a obtenção de feedback rápido, a participação do cliente, a
comunicação e coordenação, a integração contínua e testes sucessivos, a posse coletiva do código, a
documentação limitada e a programação a pares são algumas das principais caraterísticas do XP.
As práticas presentes no XP são apresentadas na tabela 5 que está de acordo com Beck
(1999,2000).
34
Prática Descrição
Planning game
Deve existir uma interação próxima entre o cliente e os programadores. Os
programadores estimam o esforço necessário para implementar as “user
stories” e com base nestas estimativas, o cliente decide sobre o âmbito e o
tempo das iterações. Os programadores implementam apenas a
funcionalidade exigida nas stories da iteração presente.
Small releases
O sistema é colocado em produção em alguns meses, mesmo antes de
resolver o problema todo. Novas versões são feitas até diariamente e no
máximo mensalmente
Metaphor
A forma do sistema é definida por uma metaphor ou conjunto de metaphors
partilhadas entre o cliente e os programadores. Esta “storie partilhada” guia
todo o desenvolvimento ao descrever como o sistema funciona.
Simple design
Enfatiza que o design da solução seja o mais simples possível, que seja
implementável no momento. Complexidade desnecessária e código extra são
imediatamente removidos.
Tests
O desenvolvimento do software provém dos testes escritos pelos
programadores (test driven). Os testes são implementados antes do código e
são executados continuamente. O cliente escreve os testes funcionais para as
stories de uma iteração.
Refactoring
Re-estruturar o sistema com a remoção de duplicações, melhorar a
comunicação, simplificar e adicionar flexibilidade. Todos os programadores
são responsáveis por corrigir e melhorar o código o mais cedo possível cada
vez que uma possível melhoria é encontrada.
Pair Programming Toda a produção de código é feita por duas pessoas em apenas um
computador.
Continuous
Integration
Cada novo pedaço de código é integrado no código de base logo que esteja
pronto, por isto, o sistema é integrado a partir do zero várias vezes por dia e
todos os testes são feitos a cada mudança feita no código e devem apresentar
resultados positivos para ser aceite ou então, as mudanças são descartadas.
Collective ownership Todos os programadores devem melhorar o código em qualquer parte do
sistema, a qualquer momento, sempre que virem oportunidade para tal.
35
On-site customer O cliente deve estar presente e disponível a tempo inteiro para a equipa de
desenvolvimento
40-hour-weeks
Máximo de 40 horas de trabalho semanais. Não são permitidas mais que
duas semanas seguidas a ultrapassar este tempo e se tal acontecer, é tratado
como um problema a ser resolvido.
Open Workspace
A equipa trabalha numa sala ampla com pequenas “cabines” à volta da
periferia. Os pair programmers trabalham nos computadores alocados ao
centro.
Just rules
Uma equipa Extreme tem as suas próprias regras, que podem ser modificadas
a qualquer altura caso haja um consenso e o impacto desta mudança deve
ser avaliado.
Tabela 4- Práticas do XP (Adaptado de Beck (1999,2000), Abrahamsson, et al.,(2002), Sommerville (2015a))
Segundo Cockburn (2002), duas peculiaridades que devem ser ajustadas por serem
controversas: a ausência de documentação e a restrição a equipas pequenas. Muitas vezes os sponsors querem a entrega de alguma documentação para além do sistema a ser desenvolvido. Para além disto, se várias pessoas abandonarem o projeto sucessivamente, num curto espaço de tempo, os novos integrantes do projeto não vão ter tempo de absorver todos os detalhes do projeto adequadamente e, isto também se deve à inexistência de documentação. Sendo que a única documentação existente são as user stories, que apenas contêm as funcionalidades requeridas.
Scrum
O Scrum é uma abordagem criada por Ken Schwaber e Jeff Sutherland ao longo dos anos 90 e
finalmente formalizada em 1995 e deriva do trabalho presente no artigo de Takeuchi e Nonaka (1986).
Para além disto também foram Takeuchi e Nonaka que deram o nome “Scrum” a esta abordagem
(Sutherland, 2007).
O Scrum é uma framework com a qual as pessoas podem resolver problemas complexos, ao
mesmo tempo que conseguem entregar produtos do mais alto valor possível de maneira produtiva e
creativa. O Scrum é uma framework de processo utilizada para gerir projetos sobre produtos complexos.
Apesar de ser uma framework de processo, não é um processo, técnica, ou mesmo um método definitivo.
É uma estrutura (framework) na qual se podem empregar várias técnicas e processos (Schwaber &
Sutherland, 2017).
O Scrum baseia-se num processo empírico, iterativo e incremental. Ao ser uma metodologia que
se baseia num processo empírico tem em conta que o conhecimento vem da experiência e as decisões
36
são feitas baseadas no que é conhecido. Assim, os três pilares que suportam uma implementação de
um processo de controlo empírico e por consequência, do Scrum são: transparência, inspeção e
adaptação (Schwaber & Sutherland, 2017).
O Scrum é uma abordagem especialmente popular em em organizações que decidiram mudar
de abordagens tradicionais para uma metodologia ágil (Ashmore & Runyan, 2014). Assim, é um bom
ponto de partida para organizações que querem fazer a transição para o ágil, devido à sua simplicidade
na comunicação (Stellman & Greene, 2014), mas apesar de ser simples de compreender, é difícil de
dominar (Schwaber & Sutherland, 2017).
A abordagem que o Scrum apresenta para gerir projetos ágeis, provou a sua aptidão ao gerar
excelentes resultados. O Scrum lida com um projeto em iterações, ou seja, em curtos períodos de tempo
para atingir partes de um objetivo e então voltar a visitar os objetivos numa reunião. Uma iteração é
normalmente feita durante 30 dias e fornece a capacidade e flexibilidade de uma equipa fazer a sua
própria gestão, pois têm o foco em objetivos para trabalharem que são principalmente a prioridade dos
objetivos de negócio do cliente (Schwaber, 2004).
Assim, o foco principal do Scrum é fornecer uma forma de trabalho para que os elementos das
equipas de projetos que utilizem esta abordagem possam produzir software que oferece valor, de forma
flexível num ambiente em constante mudança (Lopes, 2014).
A framework apresentada pelo Scrum consiste nos papéis, eventos, artefactos e regras
associados à equipa Scrum (Scrum team). Cada componente da framework tem um propósito específico
e é essencial para que esta abordagem obtenha sucesso na sua utilização (Schwaber & Sutherland,
2017).
Papéis e Responsabilidades
Segundo a Scrum Guide que foi desenvolvida, atualizada e sustentada por mais de vinte anos
pelos autores do Scrum, Jeff Sutherland e Ken Schwaber (2017), no Scrum existem três papéis, sendo
eles o Product Owner, a equipa de desenvolvimento e um Scrum Master.
Para além destes papéis que dizem respeito à Scrum Team (Schwaber & Sutherland, 2017),
existem outros que fazem parte do ambiente desta abordagem e são referidos por estes dois autores do
Scrum noutros papers e por exemplo por Abrahamsson (2002). Estes papéis são: o cliente, o utilizador
e a própria gestão. Apesar disto, neste tópico e para este trabalho de dissertação, irão apenas ser
abordados os papéis referentes à equipa, neste caso a Scrum Team.
37
As Scrum Teams são capazes de se auto organizarem e são multifuncionais. Equipas auto
organizadas são capazes de escolher a melhor maneira de conseguir fazer o seu trabalho, em vez de
estarem a ser direcionadas por alguém de fora da equipa. Multifuncionais porque têm as competências
necessárias para cumprir o trabalho que têm a fazer sem depender de outros que não façam parte da
equipa. O modelo de equipa concebido pelo Scrum é feito de maneira a otimizar a flexibilidade,
criatividade e produtividade das esquipas. Como já foi referido, as Scrum teams entregam os produtos
de forma iterativa e incremental, de maneira a maximizar o feedback e as entregas incrementais de um
produto “acabado” asseguram que uma versão funcional do artefacto está sempre disponível (Schwaber
& Sutherland, 2017).
Então, os papéis presentes no Scrum são descritos em seguida de maneira sucinta:
Product Owner: é o “dono do produto” (Lopes, 2014), uma pessoa responsável por
maximizar o valor do produto que resulta do trabalho da equipa de desenvolvimento.
Toma as decisões do produto/projeto e as suas decisões são visíveis através do
conteúdo e da ordem dos itens do Backlog do produto e é o responsável por este
artefacto. Esta pessoa pode fazer este trabalho ou dar a alguém da equipa de
desenvolvimento para o fazer, mas apesar disto, continua a ser o responsável. A última
palavra no planeamento do Incremento/Sprint ou da prioridade dos itens do Backlog do
produto é sempre dele. Por isto, ninguém pode forçar a equipa de desenvolvimento a
trabalhar a partir de um conjunto diferente de requisitos.
Assim, o Product Owner ao ser a única pessoa responsável pela gestão do
Backlog do produto. Gerir este artefacto deve incluir a expressão clara os itens presentes
neste, a ordenação dos itens de maneira a atingir os objetivos, otimização do trabalho
que a equipa de desenvolvimento desempenha, assegurar que o Backlog do produto é
visível, transparente e claro para todos, mostrar no que a equipa deve trabalhar de
seguida e assegurar que esta percebe os itens do Backlog (Schwaber & Sutherland,
2017).
Equipa de desenvolvimento: é constituída pelos profissionais que elaboram uma versão
funcional que possibilita um potencial incremento do produto “acabado” ao fim de cada
Sprint. As equipas são auto organizam-se (ninguém lhes diz como tornar o Backlog do
produto em incrementos com potenciais funcionalidades para entrega) e devem ser
estáveis e dedicadas a 100% ao projeto, com um alto nível de autonomia, que apesar
38
de terem poder de decisão também têm de ter mais responsabilidade. As equipas são
multifuncionais e multidisciplinares, com todas as habilidades necessárias para criar um
incremento do produto. Não existe outros nomes ou diferença de papéis para os
membros das equipas de desenvolvimento, independentemente do tipo de trabalho que
qualquer pessoa esteja a desenvolver, são todos chamados de developer (Schwaber &
Sutherland, 2017). É a equipa de desenvolvimento que desenvolve as funcionalidades
do produto e como um todo, são responsáveis pelo sucesso de cada iteração
(Lopes,2014). Segundo Sutherland e Schwaber (2017) o número ideal de membros da
equipa de desenvolvimento deve estar entre os três e os nove elementos, mas
idealmente entre cinco e nove.
Scrum Master: é o líder da equipa (facilitador) e é responsável por transmitir os valores
do Scrum, tal é possível ao ajudar todos os elementos da equipa a compreender a teoria
do Scrum, as práticas, regras e valores. Garante que o processo é seguido e orienta e
distribui as tarefas pela equipa. É responsável pela gestão da equipa, incluindo
cumprimento de tarefas, objetivos, datas, bom funcionamento/ambiente do grupo e
ainda por resolver impedimentos que possam surgir e fazer mudanças no processo para
a equipa continuar a trabalhar o mais produtivamente possível. O Scrum Master serve o
Product Owner, a equipa de desenvolvimento e ainda a organização (Schwaber &
Sutherland, 2017).
Eventos do Scrum
Todos os eventos prescritos do Scrum são utilizados para criar regularidade e para minimizar a
necessidade de reuniões que não estejam definidas, para além disto, todos os eventos têm um tempo
limite.
Cada evento do Scrum representa uma oportunidade formal de inspecionar ou adaptar algo, pois
foram concebidos especialmente para possibilitar a transparência e a inspeção. A não inclusão de algum
destes eventos do Scrum resulta numa redução da transparência e na perda de uma oportunidade de
fazer inspeções e adaptar algo (Schwaber & Sutherland, 2017).
Em seguida são explicados cada um dos eventos do Scrum de forma descritiva e sucinta:
O Sprint: representa uma iteração do desenvolvimento do produto (Sommervile 2015a),
é o coração do Scrum, onde a equipa se organiza de modo a produzir um incremento
39
executável e funcional do produto que duração ronda os 30 dias ou menos. Quando um
Sprint é concluído, dá-se imediatamente o início de outro. Um Sprint contém e consiste
no Sprint Planning, Daily Scrums, trabalho de desenvolvimento, Sprint Review e na
Retrospetiva do Sprint (Schwaber & Sutherland, 2017).É o procedimento de adaptação
às variáveis em mudança do ambiente (requisitos, tempo, recursos, conhecimento,
tecnologia) (Abrahamsson, et al., 2002). Cada Sprint pode ser considerado como um
pequeno projeto com no máximo um mês de duração, porque tal como os projetos, os
Sprints são utilizados para conseguir/cumprir algo e têm um objetivo sobre o que se
precisa de construir, um respetivo design e um plano flexível que vai guiar a sua
construção, o trabalho e os resultados do incremento. Um Sprint pode vir a ser
cancelado se o seu objetivo se tornar obsoleto, mas devido à pequena duração de cada
Sprint, o seu cancelamento não costuma ocorrer (Schwaber & Sutherland, 2017).
Sprint Planning: o trabalho a ser feito no Sprint é planeado no Sprint Planning. Toda a
Scrum Team colabora na criação deste plano. Cada Sprint Planning demora no máximo
oito horas para cada Sprint de um mês e é realizada através de uma reunião. O Scrum
Master assegura que o evento acontece e que os participantes compreendem o seu
propósito. Este evento responde ainda às duas seguintes perguntas: “What can be
delivered in the Increment resulting from the upcoming Sprint?“ e “How will the work
needed to deliver the Increment be achieved?” (Schwaber & Sutherland, 2017). Para
responder à primeira pergunta a equipa de desenvolvimento tenta prever a
funcionalidade que vai ser desenvolvida durante o Sprint. O Product Owner leva para
esta reunião a Backlog devidamente priorizada e explica o objetivo a ser alcançado pelo
Sprint, através da clarificação dos itens do Backlog do produto que, se
completos/cumpridos, fazem com que o objetivo se concretize. A segunda pergunta,
depende da primeira, depois de se ter o objetivo do Sprint definido e selecionados os
itens do Backlog do produto para a Sprint daquele mês, a equipa de desenvolvimento
decide como vai construir estas funcionalidades num incremento “acabado” do produto.
Os itens do Backlog do produto selecionados para a corrente Sprint, mais o plano, são
denominados de Sprint Backlog (Schwaber & Sutherland, 2017).
Daily Scrum: é uma reunião diária a horas fixas (para diminuir a complexidade) que dura
no máximo quinze minutos e é onde a equipa de desenvolvimento planeia o trabalho
para o dia seguinte. Serve também para otimizar a colaboração entre a equipa e o
40
desempenho, ao inspecionar o trabalho feito desde a última Daily Scrum e ao tentar
prever o trabalho do próximo Sprint. Nesta reunião, cada membro deve dizer o que fez
no dia anterior, o que tem para fazer hoje e se existe algum impedimento que o possa
estar a impedir de concretizar os objetivos (Schwaber & Sutherland, 2017).
Sprint Review: é uma reunião com a duração máxima que ronda as quatro horas, que
acontece no final de cada Sprint para se poder inspecionar o incremento elaborado e
adaptar o Backlog do produto, caso necessário, baseado na discussão da equipa de
desenvolvimento com os stakeholders sobre o que correu bem durante a Sprint, os
problemas encontrados e os que foram resolvidos. A equipa de desenvolvimento mostra
o trabalho realizado e responde a perguntas sobre o incremento. O Product Owner
projeta datas para a conclusão do projeto baseadas no progresso até à data. Posto isto,
todos colaboram para decidir o que fazer a seguir, de modo a que a Sprint Review
forneça inputs valiosos para a Sprint Planning que se segue (Schwaber & Sutherland,
2017).
Sprint Retrospective: é uma reunião que representa uma oportunidade para a Scrum
Team de fazer uma inspeção sobre ela própria e criar um plano de melhorias para ser
aplicado na próxima Sprint. O seu propósito é inspecionar como a última Sprint correu
no que diz respeito às pessoas, relações entre elas, ao processo e às ferramentas,
identificar e ordenar os principais itens que correram bem e potenciais melhorias. Por
fim, criar um plano para implementar melhorais na forma como a Scrum Team faz o
seu trabalho (Schwaber & Sutherland, 2017).
Artefactos do Scrum
Os artefactos definidos pelo Scrum são especialmente concebidos para maximizar a
transparência da informação principal para que todos tenham a mesma compreensão do artefacto
(Schwaber & Sutherland, 2017). Os artefactos podem ser utilizados para guiar a maneira de pensar,
avaliar competências e criar algo passível de ser alvo de uma auditoria. Os artefactos consistem de
documentos, modelos, programas, casos de teste e outros deliverables criados antes da implementação
do sistema (Sutherland e Schwaber, 2011).
41
User stories: representam um objetivo a ser alcançado, ou seja, representam uma
funcionalidade, estas funcionalidades descritas nas User stories trazem valor quer para
o utilizador ou comprador do sistema ou software (Cohn, 2004). Por vezes quando chega
a altura de determinada story ser implementada, precisa de ser dividida em várias, em
partes mais pequenas. Isto acontece quando é uma story muito grande para se
conseguir alocar numa única iteração, ou mesmo pode acontecer de algumas vezes ser
“maior” do que a iteração inteira. E, como tal uma sotry nesta situação precisa de ser
dividida (Cohn, 2006).
Backlog do produto: é uma lista ordenada em termos de valor para o negócio de tudo
que é necessário estar no presente no produto, inclui as funcionalidades descritas nas
user stories, funções, requisitos, melhorias e ajustes que constituem as mudanças a ser
feitas no produto (Schwaber & Sutherland, 2017; Sommerville 2015a). O Product Owner
é o responsável pelo Backlog do produto, incluindo pelo seu conteúdo, disponibilidade e
ordenação. É um artefacto que nunca está completo, mas sim sempre em constante
evolução, é dinâmico, evolui à medida que o produto e respetivo ambiente evoluem,
muda constantemente com o objetivo de identificar o que o produto precisa para ser
apropriado, competitivo e útil (Schwaber & Sutherland, 2017).
Sprint Backlog: é o ponto de partida para cada Sprint. É uma lista do conjunto dos itens
selecionados do Backlog do produto selecionados para serem implementados no
próximo Sprint. Os itens são selecionados pela Scrum Team juntamente com o Scrum
Master e o Produtc Owner na Sprint Backlog Meeting. Contrasta com o Backlog do
produto, pois é estável até ao próprio Sprint estar completo. Quando todos os itens do
Sprint Backlog estão completos, uma nova iteração do sistema é entregue
(Abrahamsson, 2002; Schwaber & Beedle, 2001). Para além disto, é ainda um plano
para a entrega do incremento do produto e da realização do objetivo do Sprint, pois torna
visível todo o trabalho que a equipa de desenvolvimento identificou como necessário
para ir ao encontro dos objetivos do Sprint. Sendo assim, funciona como uma
visualização total, em tempo real do trabalho que a equipa de desenvolvimento planeou
cumprir durante o Sprint (Schwaber & Sutherland, 2017).
Existe um outro artefacto associado ao Sprint Backlog que são as Sprint
Burndown Charts. Este artefacto consiste num gráfico que serve como indicador de
42
progresso do Sprint e permite à equipa ver a evolução e, para caso seja necessário,
tomar medidas. Este artefacto é visualizado pela equipa nas Daily Scrum (Lopes, 2014).
Incremento: o incremento é a soma de todos os itens do Product Backlog desenvolvidos
durante a Sprint e é o artefacto que representa o valor dos incrementos dos Sprints
anteriores. No final de cada Sprint, um incremento deve estar “acabado”, o que significa
que se deve encontrar numa condição em que é útil e vai de encontro à definição que a
Scrum Team tem de “acabado” (Schwaber & Sutherland, 2017).
Ciclo do Scrum
Os projetos que utilizam a abordagem do Scrum são divididos em ciclos, pois o Scrum é uma
framework iterativa e incremental para o desenvolvimento de projetos. Esta abordagem estrutura o
desenvolvimento em ciclos chamados Sprints. Cada uma destas iterações não demora mais que um
mês e, a seguir a uma, logo outra toma lugar, sem parar. No início de cada Sprint, a equipa seleciona
os itens de uma lista ordenada (Backlog do Produto) e passa a ter o Sprint Backlog. A equipa
compromete-se a concluir o desenvolvimento dos itens até ao final do Sprint. Durante o Sprint, os itens
não mudam e todos os dias a equipa reúne (Daily Scrum) para inspecionar o seu progresso e, caso
necessário, ajustar os próximos passos necessários para completar o trabalho que falta. No fim do Sprint,
a equipa revê-o com os stakeholders (Sprint Review) e demonstra o que foi construído, aqui é obtido
feedback que pode ser introduzido no próximo Sprint. O Scrum dá ênfase ao produto “acabado” no fim
de cada Sprint, ou seja, que o incremento do produto está pronto para ser entregue de dar “pequenos
paços” no desenvolvimento, fazendo inspeções do produto que resultou do Sprint e da eficácia das
práticas correntes, após isto enfatiza a adaptação aos objetivos do produto e das práticas do processo
(Sutherland e schwaber, 2011).
A figura abaixo representa sumariamente o ciclo do Scrum, incluindo os principais papéis,
artefactos e eventos.
43
Tabela 5-Ciclo do Scrum (Retirado de Sutherland e schwaber, (2011))
OpenUP
O OpenUP é um método de desenvolvimento de software baseado no RUP mas com uma
estrutura simplificada.
Segundo Balduino (2007) contem apenas o conteúdo fundamental para o desenvolvimento de
software e portanto, não providencia guias em vários tópicos com que alguns projetos podem ter de lidar.
Contudo, é completo no sentido em que pode ser manifestado como um processo inteiro para construir
um sistema. Para cobrir necessidades de vários tópicos que não aborda, o OpenUp é extensível para ser
usado como base ao qual mais conteúdo do processo pode ser adicionado ou integrado conforme o
necessário.
O OpenUP é um processo ágil que aplica abordagens iterativas e incrementais num ciclo de vida
estruturado.
Processo A estrutura do ciclo de vida do projeto no método OpenUP apresenta quatro fases, sendo elas:
Inception, Elaboration, Contruction, Transition. (Balduino, 2007). A imagem seguinte representa o fluxo de trabalho estruturante deste ciclo de vida definido que suporta os princípios do OpenUP.
44
Figura 8 - Fluxo de trabalho do OpenUP (Retirado de http://epf.eclipse.org/wikis/openup/)
A tabela 7 faz o mapeamento entre as iterações de cada fase e respetivas atividades que lhe
dizem respeito, com os objetivos de cada fase, de modo a conseguirmos entender no que consiste cada fase que integra o processo de desenvolvimento em OpenUP. Nota-se também que, como este método é baseado no RUP, aplica fases do Unified Process, as quais já foram referidas acima.
Padrões das iterações Objetivos da fase Inception Phase Iteration
Iniciar o Projeto Planear e Gerir a Iteração Identificar e Aperfeiçoar os Requisitos Acordo sobre a Abordagem Técnica
Compreender o que se tem de construir Identificar as funcionalidades-chave do
sistema Determinar pelo menos uma solução
possível Compreender o custo, calendarização e
riscos associados ao projeto Elaboration Phase Iteration
Planear e gerir Iteração Identificar e Aperfeiçoar os Requisitos Definir a Arquitetura Desenvolver o Incremento da Solução Testar a Solução Tarefas Contínuas
Obter uma compreensão aprofundada dos requisitos
Elaborar o design, a implementação, a validação e linhas base da arquitetura
Mitigar os riscos, produzir um calendário preciso e estimar os custos
Construction Phase Iteration Planear e gerir Iteração Identificar e Aperfeiçoar os Requisitos Desenvolver o Incremento da Solução Testar a Solução Tarefas Contínuas
De maneira iterativa, desenvolver um produto completo que está pronto para a transição para a comunidade de utilizadores
Minimzar o custo de desenvolvimento e obter um grau de paralelismo
Transmition Phase Iteration Planear e gerir Iteração Desenvolver o Incremento da Solução Testar a Solução Tarefas Contínuas
Concretizar um Beta test para validar se as expetativas dos utilizadores são cumpridas
Alcançar a concordância dos stakeholders sobre o desenvolvimento estar completo
Tabela 6- Mapeamento entre as iterações e respetivas atividades com os bojetivos de cada fase (Adaptado de Balduino (2007) e de http://epf.eclipse.org/wikis/openup/)
Quando se elabora os diversos padrões dos templates das iterações (que ocorrem quantas vezes
for necessário), temos um delivery process – que é uma abordagem completa e integrada para
desenvolver um tipo especifico de projeto (figura abaixo). Um delivery process descreve o ciclo de vida
do projeto e é utilizado como referência para projetos similares (Banduino, 2007).
45
Figura 9-Delivery Process do OpenUp (Retirado de Balduino (2007)
O OpenUP apresenta assim um delivery process para o desenvolvimento iterativo através de
quatro fases. Os padrões dos templates das iterações são aplicados quantas vezes forem necessários e depende de quantas iterações a equipa decidir elaborar em cada fase. E, projetos com necessidades diferentes podem instanciar os pradrões dos templates das iterações de maneira diferente.
Papéis e Responsabilidades No OpenUP existem papéis diferentes que representam as habilidades requeridas dos vários
integrantes da equipa do projeto. A tabela seguinte apresenta os vários papéis e respetivas responsabilidades. Papel Responsabilidade Analista Representar os interesses e preocupações do cliente e utilizadores
finais através da informação fornecida pelos stakeholders para se compreender o problema a ser resolvido e ao mesmo tempo capturar e selecionar prioridades para os requisitos
Qualquer papel Ser capaz de desempenhar tarefas gerais Arquiteto Projetar a arquitetura de software, que inclui fazer as principais
decisões técnicas que limitam o design geral e implementação do projeto
Desenvolvedor Desenvolver uma parte do sistema, incluindo desenhá-la de maneira que vá ao encontro da arquitetura e depois implementar, fazer testes e integrar os componentes que são parte da solução
Gestor de Projeto Liderar o planeamento do projeto em colaboração com os stakeholders e a equipa, coordenar interações com os stakeholders e fazer com que a equipa do projeto continue motivada e focada em ir ao dos objetivos do projeto
Stakeholder Representa os grupos de interesse cujas necessidades devem ser satisfeitas pelo projeto. É um papel que pode ser representado por qualquer pessoa que é ou potencialmente vai ser, afetada pelo resultado do projeto
Tester Fazer as atividades fundamentais de testes, como a identificação, definição, implementação e gerir os testes necessários. Fazer ainda o registo dos resultados dos testes e analisar os resultados.
Tabela 7-Papéis e respetivas responsabilidades da equipa em OpenUP (Adaptado de Balduino (2007) e http://epf.eclipse.org/wikis/openup/)
46
Princípios e Práticas O OpenUP incorpora quatro princípios fundamentais que criam as bases para a interpretação
dos papéis, artefactos e para a realização de tarefas. Para além disto, estes princípios capturam os propósitos gerais que estão por trás de um processo (Balduino, 2007).
Estes princípios fundamentais em que o OpenUP se baseia suportam-se mutuamente. E, são os seguintes:
Colaborar para alinhar os interesses e compartilhar o entendimento- Boas práticas colaborativas alinham os interesses dos participantes do projeto. Assim, este princípio promove as práticas que alimentam um ambiente de equipa saudável, possibilita a colaboração e ajuda a desenvolver o espírito de partilha no que diz respeito à partilha da compreensão do projeto;
Ponderar as prioridades de competição de maneira a maximizar o valor para o stakeholder- Este princípio promove práticas que possibilitam que os participantes do projeto e os stakeholders desenvolvam uma solução que maximiza os benefícios para o último grupo referido e que esteja em conformidade com os requisitos e restrições alocadas no projeto;
Focar antecipadamente na arquitetura para minimizar os riscos e organizar o desenvolvimento- Este princípio promove práticas que possibilitam que a equipa se foque na arquitetura, com vista a minimizar/mitigar os riscos e organizar o desenvolvimento. Uma boa arquitetura evolutiva ajuda ainda a equipa a abordar a complexidade que possa existir.
Evoluir para obter feedback e melhorias continuamente- Este princípio promove práticas que possibilitam que a equipa obtenha feedback contínuo e desde cedo por parte dos stakeholders. Para além disto, possibilita ainda que a equipa lhes demonstre valor crescente a cada incremento.
Cada um dos quatro princípios do OpenUP suporta um dos valores declarados no Manifesto Ágil. A tabela que se segue ilustra o mapeamento entre estes princípios e valores.
Princípio do OpenUP Valor do Manifesto
Colaborar para alinhar os interesses e compartilhar o entendimento
Indivíduos e interações mais do que processos e ferramentas
Ponderar as prioridades de competição de maneira a maximizar o valor para o stakeholder
Software funcional mais do que documentação compreensiva
Focar antecipadamente na arquitetura para minimizar os riscos e organizar o desenvolvimento
Colaboração com o cliente mais do que negociações contratuais
Evoluir para obter feedback e melhorias continuamente
Responder à mudança mais do que seguir um plano
Tabela 8- Mapeamento entre os princípios do Agile Manifesto e dos principios do OpenUP (Adaptado de Balduino (2007) e http://epf.eclipse.org/wikis/openup/
Existem muitas boas práticas de desenvolvimento e o OpenUP é um Unified Process que contém
um conjunto mínimo de práticas beneficiam qualquer equipa de projeto e as ajudam a serem mais eficazes no desenvolvimento de software. Uma das práticas ágeis mais reconhecidas são as que têm a intenção de ajudar a equipa a comunicar de maneira a existir uma compreensão partilhada por todos os membros sobre o projeto (Balduino, 2007).
47
As práticas presentes no OpenUP estão esquematizadas na figura abaixo e são uma abordagem para se resolver um ou mais problemas. No Anexo I pode ser encontrada uma breve descrição de cada uma destas práticas.
Figura 10-Práticas do OpenUP (Adaptado de http://epf.eclipse.org/wikis/openup/)
Kanban
O método Kanban foi idealizado por Taiichi Ohno nos anos 40 (Sugimori, et al., 1977).O Kanban
não é uma metodologia do ciclo de vida do desenvolvimento de software ou sequer uma abordagem para
a gestão de projetos. O Kanban requer algum processo já definido para que possa ser aplicado para, de
maneira incremental, mudar o processo subjacente (Anderson & Carmichael, 2016).
No Kanban não existem papéis explícitos como nas abordagens anteriores, o Kanban é um
método utilizado por equipas ágeis para a melhoria de processos. Para as equipas usarem o Kanban
devem começar por compreender a maneira como constroem software correntemente e fazer melhorias
ao longo do tempo. O foco deste método é ajudar a equipa a melhorar a maneira de construir software.
Uma equipa que utiliza o Kanban tem uma ideia clara das ações que tomam para o desenvolvimento de
software, como interagem com o resto das pessoas da organização, onde começaram a desperdiçar
recursos por causa da ineficiência e desigualdade e, como melhorar ao longo do tempo através da
remoção da causa que está na raiz deste desperdício (Stellman & Greene, 2014). Este método utiliza
Práticas
Práticas de Gestão
Desenvolvimento Iterativo
Ciclo de vida do valor de risco
Lançamento do Plano
Toda a equipa
Gestão da Mudança da
equipa
Construção do Processo do
Projeto
Práticas Técnicas
Teste Concorrente
Integração Continua
Arquitetura Evolutiva
Design Evolutivo
Visão Partilhada
Desenvolvimento Orientado para o
Teste
Desenvolvimento Orientado para os
Casos de Uso
Práticas de Desenvolvimento
Documentação e Treino
Lançamento para a
Produção
48
um sistema de escalonamento para uma produção lean e Just-In-Time (JIT) (Carvalho, D., 2000). Tem o
objetivo de maximizar o valor para o cliente minimizando os desperdícios, como dito acima e, melhorar
continuamente o processo de produção.
O Kanban é dirigido por dez valores, sendo eles: a transparência, o balanço (a compreensão de
diferentes aspetos, pontos de vista, capacidades, tudo deve ser equilibrado para se atingir a eficácia), a
colaboração (trabalhar em equipa), o foco no cliente, o fluxo (perceber que o trabalho é um fluxo), a
liderança, a compreensão, a aceitação e o respeito. Estes valores incorporam as motivações da procura
de melhorias dos serviços que as equipas prestam (Anderson & Carmichael, 2016).
Princípios do Kanban
O Kanban apresenta seis princípios que estão na sua fundação e que se diviem em dois grupos:
os princípios que gerem a mudança e os princípios da entrega de serviços (Anderson & Carmichael,
2016).
Segundo (Stellman & Greene, 2014) e Anderson e Carmichael (2016) os princípios do primeiro
grupo, que se apresentam no enraizar do Kanban, são:
Começar com o que se faz no momento;
Aceitar perseguir a mudança incremental e evolucionária;
Inicialmente, respeitar os papéis correntes, responsabilidades e os títulos de profissão que
possam existir.
Os princípios da entrega de serviços, segundo Anderson e Carmichael (2016), são:
Comprender e focar nas necessidades e expetativas do cliente;
Gerir o trabalho, deixar que as pessoas se auto organizem à volta dele;
Desenvolver/evoluir políticas para melhorar os resultados dos clientes e dos negócios
Práticas do Kanban
Existem seis práticas gerais do Kanban e definem atividades essenciais para a gestão de sistemas
Kanban. As práticas são: visualizar o trabalho, limitar o WIP (work in progresso), gerir o fluxo, tornar as
políticas explícitas, implementar ciclos de feedback, melhorar coletivamente e evoluir experimentalmente
(Anderson & Carmichael, 2016). No início não é expectável que se adotem todas as seis práticas. A
aplicação deste método vai sendo aprofundada à medida que se começam a aplicar mais práticas
(Stellman & Greene, 2014).
49
A tabela 10 apresenta um sumário da práticas do Kanban e, as descrições feitas são baseadas
em (Anderson & Carmichael, 2016):
Prática Descrição
Visualizar o trabalho
Identificar o fluxo de trabalho e desenhar uma coluna para cada passo (por
exemplo: “propostas”, “para fazer”, “a ser feito”, ”testar”, “feito”). Após
isto escrever cada tarefa em post-it’s (não é obrigatório, mas a ideia de
visualizar é como se tivessem post-it´s colados num quadro divido em
várias colunas, neste caso, passos) separados e colocar as tarefas no
respetivo quadro.
Limitar o WIP
Em cada coluna, definir o limite. Introduzir limites faz com que exista um
sistema “pull”, no qual novos itens não são começados antes de se
terminar o trabalho anterior. Pretende-se um fluxo elevado mas suave e a
eliminação de desperdícios. Assim, é definida a quantidade ideal de
trabalho que a equipa consegue realizar com qualidade e dentro dos
requisitos.
Gerir o fluxo
O fluxo de trabalho de trabalho num sistema kanban deve maximizar a
entrega de valor, diminuir os tempos de espera. Um fluxo bem gerido,
diminui o custo dos tempos de espera de itens que estão a ser
desenvolvidos.
Tornar as políticas
explícitas
As políticas devem ser simples, bem definidas, visíveis, sempre aplicadas e
passíveis de serem mudadas. São um meio de articular e definir o processo
que vai para além da definição do fluxo de trabalho.
Implementar ciclos de
feedback
As equipas devem reunir-se frequentemente para discutir sobre diversas
áreas. Podem existir pedidos de mudança e, as reuniões e feedback obtido
podem facilitar a tomada de decisão a vários níveis.
Melhorar
coletivamente e
evoluir
experimentalmente
O Kanban é fundamentalmente um método de melhoria. O Kanban
começa pela organização e az com que esta, ao seguir o seu paradigma,
persiga a melhoria continua e incremental. Como é um método que foca
no coletivo, todos melhoram e, evoluem experimentalmente, porque se
existirem boas políticas, as pessoas da organização têm também a
oportunidade de desafiarem novos horizontes, mudar, ou mesmo passar
os limites por vezes impostos para perceberem se em diferentes
circunstâncias conseguiriam melhorar os resultados.
Tabela 9- Sumáio das práticas do Kanban e respetivas descrições (Adaptado de Anderson & Carmichael, 2016)).
50
Outros métodos existentes e conclusões gerais
Para além das abordagens atrás referidas nas secções anteriores, existem muitos outros
métodos e propostas passíveis de sofrerem uma análise do género da efetuda, vários destes métodos
foram criados ou formalizados por pessoas de nome relevante na área, como por exemplo:
Crystal;
Feature Driven Development (FDD);
Dynamic Systems Development Method (DSDM);
Adaptive Software Development (ASD);
Open Source Software Development;
Rapid Application Development;
Disciplined Agile Delivery (DAD);
Scrum ban;
EssUP (Essential Unified Process)
Lean Development;
Apesar desta lista extensa, existem ainda vários outros métodos. Neste projeto de dissertação
foram descritos o XP, o Scrum, o OpenUP e o Kanban como ponto de partida para o estudo e
compreensão de vários fundamentos de abordagens ágeis. Assim, a partir destes espera-se adquirir os
fundamentos que vão ser necessários para a definição da escala que vai ser proposta nesta dissertação.
E, apesar de terem sido descritas apenas quatro abordagens, não quer dizer que num futuro
próximo não seja necessário estudar outras mais exaustivamente.
51
3. CARACTERIZAÇÃO DO ESTUDO
3.1 Abordagem Metodológica
Design Science Research (DSR) é a abordagem metodológica que será utilizada para o
desenvolvimento desta dissertação. Este método foi desenvolvido com o objetivo de auxiliar a realização
de pesquisas na área de Sistemas de Informação e segundo Hevner (Hevner, March, Park, & Ram,
2004), esta abordagem permite criar e avaliar artefactos de TI em vez de resolver problemas
organizacionais identificados.
Como o objetivo desta dissertação é desenvolver um artefacto, que neste caso é uma escala, a
partir de um problema que é medir a maturidade ágil das equipas de projetos TI, esta metodologia é
ideal. O processo de obtenção de um artefacto através da investigação em sistemas de informação nesta
metodologia, faz-se utilizando um framework concetual e um total de 7 guidelines para entender,
executar e avaliar a pesquisa (Hevner et al., 2004).
Então, o processo de obtenção de um artefacto através desta metodologia, deve ter em conta as
7 guidelines propostas pois ajudam os investigadores a compreender os requisitos para uma design-
science research efetiva (Hevner et al., 2004):
1. Design as an Artifact: Nesta primeira orientação, é induzido que a metodologia Design-
Science Research deve produzir um artefacto, que pode ter várias formas e no caso
desta dissertação, vai ser uma escala.
2. Problem Relevance: O objetivo desta metodologia é desenvolver soluções baseadas em
tecnologia para solucionar alguns problemas de negócios e, neste caso o problema é
saber o nível de maturidade ágil em que se encontra certa equipa de desenvolvimento
de projetos de TI.
3. Design Evaluation: A qualidade e utilidade do artefacto deve ser bem demonstrada e por
isso, o produto final desta dissertação, vai ser testado com casos práticos e irá ter em
conta a opinião de especialistas.
4. Research Contributions: A metodologia deve contribuir para as áreas a que o artefacto
pertence e neste projeto, esta escala irá contribuir para que as organizações consigam
medir o nível de maturidade ágil das suas equipas de projetos de TI.
5. Research Rigor: Esta metodologia é suportada pela aplicação de métodos rigorosos tanto
na construção como na avaliação do artefacto, por isso é que esta tese vai ser bem
52
suportada por diversas referências, tanto de papers, como de revistas, jornais,
entrevistas, livros, etc… e irá ser avaliada em casos reais, por especialistas e através da
publicação de um artigo.
6. Design as a Search Process: A pesquisa para um artefacto eficaz requer que se utilize
os meios disponíveis para chegar aos resultados desejados ao mesmo tempo que se
respeitam e satisfazem as leis envolventes ao problema e, por isso, tudo que este
trabalho vai conter, irá ser baseado em literatura e devidamente referenciado, exceto as
minhas conclusões, deduções, explicações e processos criativos na construção do
artefacto que irão ser totalmente da minha autoria.
7. Communication of Research: O resultado desta metodologia deve ser comunicado e
apresentado a uma audiência, que pode dar dicas de melhoria sobre o produto, outra
que pode querer implementar o resultado e ainda que pode estudar se no contexto
valeria a pena aplicar o produto final na organização. Desta maneira, a escala produzida
por este trabalho de dissertação será apresentada a especialistas e através da
publicação de um artigo numa conferência.
Para além destas 7 guidelines, esta metodologia encontra-se ainda dividida em 5 fases sendo
elas as seguintes e por ordem: compreensão do problema, sugestão para a resolução do problema,
desenvolvimento, avaliação e conclusão (Vaishnavi &Kuechler, 2004):, como se pode ver na figura 11.
Figura 11- Fases Constituintes da metodologia DSR (retirado de Vaishnavi & Kuechler, (2004))
Na fase de compreensão do problema, este é descrito e justifica-se a importância da criação de
um documento que apresente uma proposta de resolução. A fase de sugesto de resolução do problema,
53
consiste em apresentar um conjunto de sugestões para a solução do problema. Na terceira fase
(desenvolvimento do problema) as propostas que foram apresentadas anteriormente são postas em
prática e cria-se o modelo da resolução proposto na fase prévia. A quarta fase é a avaliação, que serve
para avaliar o modelo e verificar se resolve mesmo o problema. A última fase (conclusão) é onde se
analisa os resultados obtidos aquando da aplicação do modelo (Vaishnavi &Kuechler, 2004).
3.2 Plano de Atividades
A imagem baixo representa o Diagrama de Gantt, que apresenta o planeamento de todo o projeto,
com as atividades e tarefas a alto nível a realizar, assim como o planeamento temporal para este projeto.
Como este projeto de dissertação é dinâmico e não estático, esta calendarização pode vir a sofrer
alterações aquando do desenvolvimento do projeto.
Figura 12- Diagrama de Gantt
Tarefa 1- Definição do tema de dissertação e elaboração do plano de trabalho;
Tarefa 2- Pesquisa de conceitos sobre o tema e de propostas ágeis por parte de várias entidades,
revisão de literatura;
Tarefa 3- Redação do Projeto de Dissertação;
Tarefa 4- Analisar e estabelecer padrões ágeis em diferentes organizações;
Tarefa 5- Elaborar um artigo para ser publicado numa conferência;
Tarefa 6- Avaliar os padrões e tendo em conta as várias propostas ágeis, elaborar uma escala com
vários níveis;
Tarefa 7- Aplicar a escala num projeto real;
54
Tarefa 8- Analisar e avaliar os resultados obtidos;
Tarefa 9- Aplicar as melhorias necessárias;
Tarefa 10- Redação da dissertação e divulgação dos resultados obtidos.
55
4. CONCLUSÕES
Este trabalho de pré dissertação, consistiu na recolha de informações científicas sobre áreas
relacionadas com o tema. Consistiu na pesquisa de literatura referente a sistemas e tecnologias de
informação. Após isto, fez-se a recolha do estado da arte sobre os métodos tradicionais, que contêm
conceitos como a engenharia de software, modelos de processo e modelos de maturidade.
De seguida foi dado mais um passo em direção ao tema da dissertação, que foi pesquisar sobre
abordagens ágeis e analisá-las profundamente tendo em conta as práticas caraterísticas de cada
abordagem.
Posto isto, espera-se que se tenha recolhido informação que irá ser útil para o objetivo final desta
dissertação que é ao desenvolvimento da escala de “agilidade”. E, para tal é necessário ter noção das
abordagens existentes tanto tradicionais como ágeis, principalmente no modo em que existem modelos
tradicionais de maturidade, que é o que a escala a ser elaborada pretende medir e das abordagens
ágeis, pois as práticas fundamentais destes modelos, deverão ser as que as equipas de TI, em ambientes
ágeis aplicam para desenvolver software.
Assim, com a junção destes temas pretende-se começar a elaborar o artefacto que constitui o
objetivo final desta dissertação.
57
BIBLIOGRAFIA
Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile software development methods: Review and analysis. VTT Publications.
Alter, S. (1992). Information Systems: A Management Perspective. In: Addison-Wesley. Amaral, L. (1994). PRAXIS: Um referencial para o Planeamento de Sistemas de Informação. Anderson, D. J., & Carmichael, A. (2016). Essential Kanban Condensed. Lean Kanban University.
Washington Anwar, A. (2014). A Review of RUP (Rational Unified Process). International Journal of Software
Engineering, 5(2), 8–24. Ashmore, S. & Runyan, K., (2014). Introduction to Agile Methods. Addison-Wesley Professional. Balaji, S. (2012). Waterfall vs v-model vs agile : A comparative study on SDLC. International Journal of
Information Technology and Business Management, 2(1), 26–30. Balduino, R. (2007). Introduction to OpenUP (Open Unified Process). Organization, 1–9. Retrieved from
https://eclipse.org/epf/general/OpenUP.pdf Beck, K. (1999a). “Embracing Change With Extreme Programming”. IEEE Computer 32(10): 70-77. Beck, K. (2000). Extreme Programming Explained: Embrace Change. Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J.,
Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J. & Thomas, D. (2001). Manifesto for Agile Software Development Manifesto for Agile Software Development. Retrieved October 29, 2017, from http://agilemanifesto.org/
Bell, T. E., & Thayer, T. A. (1976). Software Requirements : Are They Really a Problem ? International Conference on Software Engineering, 61–68.
Buckingham, R., Hirschheim, R., Land, F. and Tully, C. (1987). Information systems education: Recommendations and Implementation. Cambridge: Cambridge University Press.
BKCASE Governing Board. (2017). Guide to the Systems Engineering Body of Knowledge (SEBoK) v. 1.8, 945.
Carvalho, J. Á. (2000). Information System ? Which One Do You Mean ? Information Systems Concepts: An Integrated Discipline Emerging. Proceedings of the ISCO 4 Conference, (September 1999), 259–280.
Carvalho, D. (2000). Capítulo VIII Just In Time. Retrieved from http://pessoais.dps.uminho.pt/jdac/apontamentos/JustInTime.pdf
Cockburn, A. (2002). Agile Software Development. The agile Software Development Series. Addison-Wesley.
Cohn, M. (2004). User stories applied: For agile software development. AddisonWesley Longman. Cohn, M. (2006). Agile Estimating and Planning. Robert C. Martin Series. Prentice Hall. Curtis, B., Hefley, B., & Miller, S. (2009). People capability maturity model (P-CMM). Software Engineering
Institute, (July). Retrieved from https://www.sei.cmu.edu/reports/09tr003.pdf Earl, M. (1989). Management Strategies for Information Technology. Prentice-Hall. Cambridge Eason, K. (1988). Information Technology and Organizational Change. Taylor & Francis Fairley, R. E. D., Bourque, P., & Keppler, J. (2014). The impact of SWEBOK Version 3 on software
engineering education and training. In Software Engineering Education and Training (CSEE&T), 2014 IEEE 27th Conference on (pp. 192–200). https://doi.org/10.1109/CSEET.2014.6816804
Ferguson, P., Humphrey, W. S., Khajenoori, S., Macke, S., & Matvya, A. (1997). Results of applying the personal software process. IEEE Computer, 30(5), 24–31. https://doi.org/10.1109/2.589907
Fernandes, A. A., & Abreu, V. F. de. (2014). Implantando a governança de TI: da estratégia à gestão dos
58
processos e serviços (4ª edição.). Rio de Janeiro: Brasport. Glazer, H., Dalton, J., Anderson, D, Konrad , M., Shrum, S. (2008). CMMI or Agile: Why
Not Embrace Both! Hastie, S., & Wojewoda, S. (2015). Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch.
Retrieved from Http://Www.Infoq.Com/Articles/Standish-Chaos-2015. Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design Science in Information wSystems
Research. MIS Q., 28(1), 75–105. Humphrey, W. S. (1997). Introduction to the Personal Software Process. Addison-Wesley. Humphrey, W. S. (2000). Team Software Process (TSP). Software Engineering Institute.
https://doi.org/10.1002/0471028959.sof352 IEEE. (2014). SWEBOK v.3. IEEE Computer Society. https://doi.org/10.1234/12345678 ISSO/IEC/IEEE. (2008).12207:2008 - ISO/IEC/IEEE International Standard For Software and systems
engineering- Software life cycle processes. International Standard ISO/IEC 12207 (Vol.2). Jalote, P. (2002). Software Project Management in Practice. Addison Wesley. Pearson Education Kruchten, P. (2003). The rational unified process: an introduction. 3 ed. Addison Wesley. Laribee, J. F. (1991). Defining Information Resources: A Survey of the Literature. IDEA Group Publishing. Levinson, H. (Producer). (2016). Evolving Air Force Intelligence with Agile
Techniques.[Audio Podcast]. Retrieved from http://www.sei.cmu.edu/podcasts/ Loon, H. V. (2007). Process Assessment and ISO/IEC 15504. Springer US. Lopes, C. (2014). Universidade do Minho Escola de Engenharia Cristiana Sofia da Silva Lopes Scrum
para Ambientes de Software Distribuído : Análise Crítica e Estudo de Casos. MAHESHKUMAR, A., & Sukhbaatar, U. (2010). Complementing views in Software Process Improvement
An Assumption Analysis of SPICE from an Organizational Culture Perspective. Retrieved from https://gupea.ub.gu.se/bitstream/2077/23483/1/gupea_2077_23483_1.pdf
Mahmood, Z. (2006). Frameworks and tools for building enterprise information architectures. In Proc. of 6th Intl. IBIMA Conf on managing Information In Digital Society (pp. 216 – 226).
McNurlin, B., & Sprague, R. (1989). Information Systems Management in Practice. Prentice-Hall International. London
Oliveira, J. N., & Amaral, L. A. (1999). O papel da qualidade da informação nos sistemas de informação. In. Departamento de Sistemas de Informação.
Papadopoulos, G. (2014). Moving from traditional to agile software development methodologies also on large, distributed projects., 175(1),455-463.
Pino, F. J., Baldassarre, M. T., Piattini, M., & Visaggio, G. (2009). Harmonizing maturity levels from CMMI-DEV and ISO/IEC 15504. In Journal of Software Maintenance and Evolution (Vol. 22, pp. 279–296). https://doi.org/10.1002/spip.437
PMI, P. M. I. (2013). Project Management Body Of Knowledge Guide (fifth edition ed.): Project Management Institute.
Pressman, R. S. (2009). Software Engineering A Practitioner’s Approach 7th Ed . Rational Software White Paper. (2004). Rational Unified Process Best Practices for Software Development
Teams. Development, 1–21. Retrieved from https://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_best
practices_TP026B.pdf Renkema, T. J. W., & Berghout, E. W. (1997). Methodologies for information systems investment
evaluation at the proposal stage: a comparative review. Information and Software Technology, 39(1), 1-13.
Royce, W. W. (1970). Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, 26(8), 328–338.
Sá Soares, D. F. M. G. de. (1998). Planeamento de Sistemas de Informação Estudo das Variáveis que
59
Condicionam a sua Estratégia de Execução. Universidade do Minho. Schwaber, K., & Beedle, M. (2001). Agile Software Development with Scrum. cdswebcernch (Vol.18). Schwaber, K. (2004). Agile Project Management with Scrum. Microsoft Press (Vol.7). Schwaber, K., & Sutherland, J. (2017). The Scrum Guide. Scrum.Org and ScrumInc, (November), 17. Software Engineering Institute. (2010). CMMI for Development, Version 1.3. https://doi.org/CMU/SEI-
2010-TR-033 ESC-TR-2010-033 Sommerville, I. (2009). 26 Process Improvement. Retrieved from http://iansommerville.com/softwareengineeringbook/files/2014/07/Ch_26_ProcessImproveme
nt.pdf Sommerville, I. (2013). Software engineering. (Vol. 9th Ed). Pearson. Sommerville, I. (2015a). Software engineering. Global Edition (Vol. 10th Ed). Pearson. Sommerville, I. (2015b). People CMM. Retrieved January 3, 2018, from
http://iansommerville.com/software-engineering-book/web/people-cmm/ Souza, B. (2015). Agility comes with maturity. Retrieved from
https://www.cio.co.nz/article/589568/agility-comes-maturity/ Stellman, A. & Greene, J., (2014). Learning Agile: Understanding Scrum, XP, Lean, and Kanban. O'Reilly
Media, Inc. Sugimori, Y., Kusunoki, K., Cho, F., & Uchikawa,S. (1977): Toyota production system and Kanban system Materialization of just-in-time and respect-for-human system, International Journal of Production
Research, 15:6, 553-564 Sutherland, J. (2007). Origins of Scrum. Retrieved from https://www.scruminc.com/origins-of-scrum/ Sutherland, J., & Schwaber, K. (2011). The Scrum Papers : Nuts , Bolts , and Origins of an Agile Process.
Origins, (December), 1–224. Turk, D., France, R. & Rumpe, B., (2005). Assumptions Underlying Agile Software Development.
Database Management. Vaishnavi, V., & Kuechler, W. (2004). Design Science Research in Information Systems. Retrieved from
Association for Information Systems: http://www.desrist.org/design-research-in-informationsystems/
Varajão, J. (2002). Função de Sistemas de Informação: contributos para a melhoria do sucesso da adopção de tecnologias de informação e desenvolvimento de sistemas de informação nas organizações.