=Paper=
{{Paper
|id=Vol-1135/paper17
|storemode=property
|title=Modelos de Maturidade para SI/TI de Pequenas e Média Dimensão
|pdfUrl=https://ceur-ws.org/Vol-1135/paper17.pdf
|volume=Vol-1135
|dblpUrl=https://dblp.org/rec/conf/quatic/SimoesS04
}}
==Modelos de Maturidade para SI/TI de Pequenas e Média Dimensão==
https://ceur-ws.org/Vol-1135/paper17.pdf
1
Modelos de Maturidade para SI/TI de
Pequenas e Média Dimensão
Fernando Simões, Pedro Sousa
Abstract — Hoje em dia os modelos de maturidade são globalmente aceites como guias para aumentar os níveis de qualidade nas
organizações. No entanto, considera-se que estes são demasiado complexos para serem implementados em organizações de
pequena e média dimensão (PME). Este artigo centra-se essencialmente nas PME de SI/TI (Sistemas de Informação/Tecnologia de
Informação) que, devido ao seu Core Bussiness, nos leva imediatamente a focar duas grandes áreas: Engenharia de Software e
Gestão de Projectos. Efectuou-se um estudo comparativo de dois modelos de maturidade, analisando as sinergias de
implementação dos mesmos. Os modelos que entraram para este estudo foram o Capability Maturity Model do Software
Engineering Institute (CMM / SEI) e o Project Management Maturity Model (PMMM) do Harold Kerzner, para Engenharia de
Software e Gestão de Projectos respectivamente. Finalmente efectuou-se o cruzamento dos modelos de maturidade com os
processos do Project management Body of Knowledge (PMBOK) e o Software Engineering Body of Knowledge (SWEBOK) para
uma análise mais refinada a nível das sinergias.
Palavras Chave — CMM, PMBOK, PME, PMMM, SWEBOK.
—————————— ——————————
1 INTRODUÇÃO
N as últimas décadas, as empresas têm-se deparado com
o grave problema de conseguirem realizar os
projectos de Engenharia de Software com eficiência e
Para a identificação dos processos de engenharia de
software, teve-se por base o SWEBOK[6] visto este definir
as áreas de conhecimento e consequentemente os processos
dentro dos prazos previstos. Para além de outras razões fundamentais de suporte à engenharia de software. Este
possíveis, este problema tem essencialmente a ver com o guia é considerado um documento de referência do SEI
facto de essas empresas não se basearem na repetição de (Software Engineer Institute) e reúne os pontos de vista de
métodos provados com um processo de engenharia de cerca de 500 engenheiros de software de 42 países,
software maduro. Os modelos de maturidade são um guia apresentando consenso relativamente a esta questãoe.
para as organizações obterem o controlo dos seus processos Optou-se por utilizar o SWEBOK[6] em alternativa ao RUP
e obterem uma excelência de gestão, no caminho de uma (Rational Unified Process) devido ao facto de aquele ser um
cultura de Engenharia de Software. No entanto, a guia para as melhores práticas da engenharia de software e
implementação de modelos de maturidade não é simples e não uma metodologia, já que o que se pretende é que as
envolve um enorme esforço por parte das organizações. organizações efectuem as devidas adaptações e consigam
O primeiro passo deste trabalho é analisar os modelos de adequar os processos à sua realidade.
maturidade para as duas principais áreas com impacto Ao nível dos processos de gestão de projectos, seguiu-se o
directo no negócio, a saber: a gestão de projectos e a PMBOK[3] do PMI (Project Management Institute) por ser a
engenharia de software. É assim efectuado um estudo referência mundial no mercado da gestão de projectos.
comparativo entre os dois modelos, para identificar as Finalmente, efectua-se uma análise das características das
semelhanças entre eles e respectivas sinergias, pelo facto de PME identificando alguns pontos fortes e pontos fracos da
estes modelos terem por objectivo a melhoria contínua dos implementação dos modelos de maturidade nesse tipo de
processos das organizações. empresas.
Em segundo lugar, pretende-se identificar e integrar os
diversos processos de negócio, baseando-se nas referências
2 MODELO DE MATURIDADE DE ENGENHARIA DE
de mercado: o SWEBOK[6] (Software Engineering body of
knowledge) e o PMBOK (Project Management body of SOFTWARE
knowledge), tendo sempre por contexto os modelos de 2.1 Modelo CMM do SEI
maturidade. Esta análise tem por objectivo clarificar o A inexistência de um processo de Software maduro obriga
âmbito e identificar os processos que são potencialmente a que uma equipa se dedique aos projectos, com esforços
comuns. individuais e insustentáveis, para que produzam bons
resultados, mesmo sem a infra-estrutura e o suporte (de
———————————————— gestão) necessários para os apoiar. Isso faz com que a
• Fernando Simões Consultor Senior na PT Sistemas de Informação . E-mail: repetição do sucesso de um determinado projecto dependa
Fernando-a-simoes@telecom.pt.
única e exclusivamente da equipa envolvida. O SEI estudou
• Pedro Sousa, Professor Associado no instituto Superior Técnico. E-mail: o processo de desenvolvimento de software e respectivo
pedro.sousa@link.pt modelo de maturidade, indicando quais as áreas chave para
. uma determinada organização atingir um determinado
2 MODELOS DE MATURIDADE PARA SI/TI DE PEQUENAS E MÉDIA DIMENSÃO
nível de maturidade. Em conformidade com este estudo, os Nível 3 – Definido: O processo de software para as
melhoramentos contínuos só podem ocorrer através de actividades de gestão e engenharia é documentado,
esforços sustentados e focados na construção de uma infra- padronizado e integrado num processo de software padrão
estrutura de processo de desenvolvimento de software e em para a organização. Todos os projectos utilizam uma versão
práticas de gestão efectivas. aprovada do processo de software padrão para o
O SEI efectou a evolução do modelo de maturidade de desenvolvimento e manutenção de software.
engenharia de Software, integrando-o comos restantes
modelos de maturidade do SEI: Systems Engineering, Nível 4 – Gerido: São realizadas medidas detalhadas de
Software Engineering, Integrated Product and Process indicadores do processo de software e da qualidade do
Development, and Supplier Sourcing (CMMI-SE/SW/IPPD/SS, produto. O processo e os produtos de software são
V1.1), no entanto este artigo focou-se sobre SW–CMM, quantitativamente compreendidos e controlados.
dado este estar centrado na Engenharia de Software.
O CMM está organizado em 5 níveis de maturidade desde Nível 5 – Em Optimização: A melhoria contínua do
o nível Inicial (Ad-Hoc) até o nível Optimizado (melhoria processo é propiciada pelo feedback quantitativo do
contínua de processos). [1] processo e pelas ideias e tecnologias inovadoras.
2.2 Processos de Engenharia de Software
2.1.1 Níveis de maturidade do modelo CMM (SWEBOK)
O conceito de nível de maturidade é um estágio O SWEBOK é um guia das melhores práticas para a
evolutivo bem definido em busca de um processo de engenharia de software e tem como principais objectivos
software maduro. Cada nível de maturidade fornece uma [6]:
gama de fundamentos para a melhoria contínua do • Promover, de um ponto de vista consistente, a
processo e compreende um conjunto de objectivos que, engenharia de software ao nível mundial.
quando satisfeitos, estabilizam uma componente • Clarificar a área da engenharia de software e definir as
importante do processo de software. Alcançando cada nível suas fronteiras relativamente a outras áreas tais como:
da estrutura de maturidade, estabelecem-se diferentes ciência da computação, gestão de projectos, engenharia
componentes no processo de software, resultando num de computadores e matemática.
crescimento da capacidade de processo da organização. [1] • Caracterizar os conteúdos da Engenharia de Software.
• Fornecer um acesso facilitado ao conhecimento das
melhores práticas da Engenharia de software.
• Facultar os meios para o desenvolvimento profissional,
tanto ao nível da certificação como a material licenciado.
Para um melhor entendimento da área de engenharia de
software, o SWEBOK está organizado em áreas de
conhecimento (KA – Knowledge Areas), mais precisamente
em 10 áreas de conhecimento:
• Requisitos de Software (Software Requirement – SR)
• Desenho de Software (Software Design – SD)
• Desenvolvimento de Software (Software Construction –
SC)
• Testes de Software (Software Testing – ST)
• Manutenção de Software (Software Maintenance – SM)
• Gestão de Configurações de Software (Software
Configuration Management – SCM)
• Gestão de Engenharia de Software (Software
Engineering Management – SEM)
Figura 1 – Áreas chave por nível de maturidade. • Processo de Engenharia de Software (Software
Engineering Process – SEP)
Nível 1 – Inicial: O processo de software é caracterizado • Ferramentas e Métodos de Engenharia de Software
como “ad hoc” e até mesmo ocasionalmente caótico. Os (Software Engineering Tools and Methods – SETM)
produtos são obtidos de forma imprevisível e pouco • Qualidade de Software (Software Quality – SQA)
controlada. Poucos processos estão definidos e o sucesso Cada área supra referida é constituída por processos que
depende do esforço individual dos colaboradores. serão utilizados no estudo apresentado adiante.
Nível 2 – Repetitivo: Os processos básicos de gestão de
projecto são estabelecidos para acompanharem o custo, o
planeamento, a funcionalidade e a qualidade do produto. A
disciplina necessária ao processo existe para repetir
sucessos anteriores em projectos com aplicações similares.
FERNANDO SIMOES, PEDRO SOUSA: MODELOS DE MATURIDADE PARA SI/TI DE PEQUENAS E MÉDIA DIMENSÃO
3
3 MODELO DE MATURIDADE DE GESTÃO DE
PROJECTOS Nível 4 – Benchmarking: No nível Benchmarking a
organização reconhece que a melhoria do processo é
3.1 Modelo PMMM necessária para manter a vantagem competitiva. Os testes
de desempenho devem ser efectuados continuamente, a
Quanto maior for o nível de maturidade de uma
organização deve decidir quem os deve efectuar e que
determinada organização, menor será a margem de erro a
testes devem ser efectuados.
nível da previsão de esforço e tempo, no desenvolvimento
de um determinado produto de software. Visto isto, uma Nível 5 – Melhoria Contínua: No nível Melhoria Contínua,
organização tem toda a vantagem em investir no aumento a organização avalia a informação obtida com base nos
da sua maturidade em gestão de projectos, pois a relação testes de desempenho efectuados, e toma acções
custo/beneficio é claramente positiva. Isto deve-se ao facto correctivas, caso seja necessário, quer sobre a metodologia
de, com uma gestão de projectos madura, se conseguir única, quer sobre os testes de desempenho, definido nos
praticamente eliminar as derrapagens em termos de níveis 3 e 4.
planeamento/execução. [2]
3.2 Processos de gestão de projectos (PMBOK)
3.1.1 Níveis de Maturidade de Gestão de Projecto O “Project Management Boby of Knowledge” (PMBOK) é
Para apoio às organizações no sentido de obtenção da um guia para as melhores práticas da gestão de projectos e
excelência em gestão de projectos, foi desenvolvido o está organizado matricialmente por agrupamentos de
modelo de maturidade de gestão de projectos que é processos e por áreas de conhecimento que identificamos
composto por 5 níveis de maturidade tal como ilustrado na sumariamente de seguida.
figura seguinte. Cada nível de maturidade representa um
estágio diferente na maturidade de gestão de projectos.
Figura 3 - Agrupamento de processos(PMBOK).
Processo de Iniciação: reconhecimento de que um projecto
Figura 2 - Níveis de maturidade do PMMM. ou fase deve iniciar-se e comprometer-se a executá-lo(a).
Nível 1 – Linguagem Comum: No nível Linguagem
Comum, a organização reconhece a importância da gestão Processo de Planeamento: planear e manter um esquema
de projecto e a necessidade do entendimento acerca do de trabalho viável para se atingir os objectivos de negócio
assunto entre as diversas equipas dentro da organização. que determinaram a existência do projecto.
Neste nível é definida a linguagem/ terminologia.
Processo de Execução: coordenar pessoas e outros recursos
Nível 2 – Processos Comuns: No nível Processos Comuns, para a realização do plano.
a organização reconhece a necessidade de definição e
desenvolvimento de processos comuns, de tal forma que o Processo de Controlo: assegurar que os objectivos do
sucesso na execução dum determinado projecto possa ser projecto estão a ser atingidos, através de monitorização e da
repetido nos projectos seguintes. Neste nível também é avaliação do seu progresso, tomando acções correctivas
reconhecida a aplicação da gestão de projectos nas mais quando necessárias.
diversas áreas da organização.
Processo de Encerramento: formalização da aceitação do
Nível 3 – Metodologia Única: No nível Metodologia Única projecto ou fase, e encerrá-lo(a) de uma forma organizada.
a organização reconhece os efeitos das sinergias que advêm
da convergência das diversas metodologias existentes na Para além dos cinco agrupamentos de processos
organização para uma única que se impõe como sendo a identificados anteriormente, o PMBOK também está
metodologia principal para a gestão de projectos. O efeito organizado em nove áreas de conhecimento de gestão de
da sinergia também é notado no controlo do processo que projectos que passamos a descrever:
se torna mais simples, visto basear-se exclusivamente numa • Gestão de Âmbito de Projecto: processos necessários
única metodologia. para assegurar que o projecto contempla todo o trabalho
requerido, e nada mais do que o que foi requerido, para
4 MODELOS DE MATURIDADE PARA SI/TI DE PEQUENAS E MÉDIA DIMENSÃO
completar o projecto com sucesso. 4 CMM VS. PMMM
• Gestão do Tempo: processos para assegurar que um
Neste capítulo, comparam-se as características entre os dois
projecto termina dentro do prazo previsto.
modelos de maturidade apresentados inicialmente, com o
• Gestão de Custos: processos necessários para assegurar
objectivo de verificar quais as características comuns. Esta
que o projecto termina dentro do orçamento aprovado.
análise é feita recorrendo a uma tabela, identificando as
• Gestão da Qualidade: processos necessários para
características de ambos os modelos e efectuando uma
assegurar que as necessidades que originaram o
breve análise comparativa.
desenvolvimento do projecto são atendidas.
• Gestão de Recursos Humanos: processos necessários
para proporcionar uma utilização mais eficiente das TABELA 2 – ANÁLISE COMPARATIVA ENTRE CMM E PMMM
pessoas envolvidas no projecto.
• Gestão da Comunicação: processos necessários para
assegurar que a geração, recolha, distribuição e
armazenamento de documentos é efectuada de forma
adequada e a tempo.
• Gestão de Riscos: processos necessários para a
identificação, análise e resposta a riscos do projecto.
• Gestão de Contratações (procurement): processos
necessários para aquisição de produtos e serviços fora
da organização que desenvolve o projecto.
• Gestão de Integração de projecto: processos necessários
para assegurar que os diversos elementos do projecto
são adequadamente coordenados.
De seguida, apresenta-se uma tabela com a organização
dos processos das diversas áreas de conhecimento
(Integração, Âmbito, Tempo, Custo, Qualidade, Recursos
humanos, Comunicações, Riscos, Contratações),
organizados pelos agrupamentos de processos (Iniciação,
Planeamento, Execução, Controlo, Encerramento) definidos
pelo PMBOK. [3]
TABELA 1 – PROCESSOS DAS ÁREAS DE CONHECIMENTO POR
AGRUPAMENTO DE PROCESSOS, SEGUNDO O PMBOK
Após uma análise da Tabela 2, podemos verificar que a
natureza de cada um dos níveis, na sua génese, é
semelhante em ambos os modelos. Fazendo uma análise
mais detalhada, podemos verificar que, do ponto de vista
de uma organização de SI/TI, o CMM é mais abrangente do
que o PMMM, visto que, para além dos processos de gestão
de projectos (básicos), abrange os processos de engenharia
de software. No entanto, o PMMM leva a uma optimização
e um controlo mais refinado da gestão de projecto, ao nível
da organização.
Do ponto de vista da gestão organizacional, a aplicação de
ambos os modelos poderá conduzir a uma melhor
performance, não só financeira como de processo, visto que
o CMM está mais voltado para a engenharia de software e o
PMMM está voltado para a excelência da gestão de
projecto. Conclui-se portanto que os modelos são
complementares e existe vantagem clara na sua
implementação conjunta.
Conclui-se ainda que o CMM está mais voltado para gestão
da qualidade de produto enquanto que o PMMM está
claramente mais voltado para a qualidade do processo,
garantido indirectamente a qualidade do produto.
Para uma análise mais clara e para a identificação das
FERNANDO SIMOES, PEDRO SOUSA: MODELOS DE MATURIDADE PARA SI/TI DE PEQUENAS E MÉDIA DIMENSÃO
5
sinergias, ainda é necessário efectuar uma análise ao nível com os processos do PMBOK e SWEBOK respectivamente.
dos processos propriamente ditos, que iremos efectuar de Com base na análise da tabela 3, podemos retirar as
seguida. seguintes conclusões:
• Existem processos comuns nos dois modelos no nível 2.
5 MODELOS DE MATURIDADE VS. PMBOK VS.
Isto acontece devido ao facto de o PMBOK ser
SWEBOK completamente implementado no nível 2 do PMMM.
Neste capítulo, é efectuada uma análise mais refinada com base
no cruzamento dos modelos de maturidade PMMM e CMM, • Verifica-se que algumas áreas chave de processos do
nível 2 do CMM correspondem a alguns agrupamentos
TABELA 3 – DISTRIBUIÇÃO DOS RESPECTIVOS PROCESSOS
do PMBOK, a saber:
PELOS DIVERSOS NÍVEIS DE MATURIDADE
– Planeamento de Projecto de Software versus
Planeamento
– Acompanhamento e Supervisão de Projecto de
Software versus Controlo
• CMM no nível 3 exige que haja uma metodologia única
de processos que é comum a toda a organização,
levando-nos à conclusão que dentro dessa metodologia
estejam incluídos os processos da gestão de projectos.
Quando se atinge o nível 3 do CMM, parte dos
objectivos do nível 3 do PMMM também foram
atingidos, pois o objectivo deste nível também é obter
uma metodologia única, embora esta possa ser mais
abrangente ao nível de áreas de conhecimento.
• Nos níveis 3, 4 e 5 deixamos de ter processos do
PMBOK, visto já estarem contemplados nos níveis 1 e 2,
pelo que o PMBOK não traz um contributo directo para
atingir um nível
• No PMBOK não se define forma de extrair indicadores
de processo (nível 4). É necessário que as organizações
efectuem um trabalho a posteriori, com vista à
optimização dos processos (nível 5).
• Os processos de comunicação e integração (PMBOK)
não estão previstos nos modelos de maturidade.
Figura 4 – sobreposição de modelos.
Na figura 4, é apresentada de uma forma gráfica o que se
pode subentender do trabalho efectuado neste capítulo,
para além das conclusões retiradas anteriormente. Como se
pode constar, existem intersecções não só ao nível dos
modelos de maturidade (CMM e SWEBOK) como ao nível
dos processos dos “Body of Knowledge“ (SWEBOK e
PMBOK).
Em conclusão, caso as metodologias sejam implementadas
independentemente, poderão verificar-se perdas de
eficiência devido ao facto de existirem processos comuns,
como acima referido. Um factor a reter, após esta análise, é
que as metodologias são complementares e daí se obterem
sinergias na implementação de ambas.
6 MODELOS DE MATURIDADE PARA SI/TI DE PEQUENAS E MÉDIA DIMENSÃO
6 CARACTERÍSTICAS DAS PME
Os reais problemas que se passam hoje em dia nas
No contexto da Engenharia de Software, o conceito de PME
organizações, quer sejam PME quer sejam grandes
não é consensual, e tem sido largamente discutido no âmbito
organizações, passam por requisitos não documentados,
do CMM. Pode-se considerar que PME são empresas com um
erros por inexperiência dos gestores, alocação de recursos,
número de colaboradores inferior a 50 [5] [9], com recursos
formação contínua, revisão por pares e documentação do
financeiros limitados e com uma carteira de projectos
produto.
essencialmente constituída por pequenos projectos com
equipas de menos de 20 colaboradores [5]. Para além disso, as
Outro problema que por vezes ocorre com a implementação
PME têm como principal objectivo a sua sobrevivência, o que
dos modelos de maturidade é o excessivo números de
faz com que foquem todo o seu esforço em tarefas de negócio
funções que devem estar presentes na organização. Este
ignorando a optimização dos seus processos e
problema deve ser endereçado com vista a um colaborador
consequentemente o aumento do seu nível de maturidade.
acumular diversos papéis de uma forma coerente e
Apresentamos de seguida algumas características das PME.
suficientemente independente. [9]
TABELA 4 – CARACTERÍSTICAS POSITIVAS E NEGATIVAS DAS PME Ex: Um colaborador pode assumir o papel de
gestor de projecto em simultâneo com o papel de
Engenheiro de software (Responsável técnico) mas
não de responsável pelos testes [9]. Por definição,
as pessoas responsáveis por esta área não devem
ser as que efectuam desenvolvimento de Software,
por não terem a distanciação necessária à detecção
de erros.
A visão que deve ser abordada para a implementação dos
modelos de maturidade passa por encarar estes problemas
de uma forma diferente. A complexidade do modelo deixa
de ser impeditiva se ele for dividido em pequenas partes
possíveis de serem geridas. A dificuldade de adaptação não
se coloca, caso se utilize apenas o conhecimento e
experiência disponível para começar com processos
simples. Os modelos muito estruturados/rígidos não se
colocam pois devem ser interpretados como um guia e não
para serem seguidos à letra. A ideia de documentação
exagerada não existe pois deverá sempre existir a
documentação necessária para manter o processo
controlado.
Os Clientes das PME conseguem efectuar maior pressão
sobre as empresas, obrigando-as por vezes a alteração de A necessidade de um grande investimento inicial (recursos,
processos e metodologias instituídas nas organizações, tempo e aspecto financeiro) pode ser colmatada iniciando
devido ao seu poder negocial, enquanto nas grandes com um investimento razoável, que faça sentido.
organizações, essa pressão é praticamente impossível e as O retorno do investimento não é imediato mas é visível
metodologias devem ser seguidas. caso se comece com as áreas que possam gerar maior
retorno e com o retorno visível a nível da qualidade e da
produtividade, o que irá aumentar a moral organizacional.
7 MODELOS DE MATURIDADE NAS PME
A implementação dos modelos de maturidade nas PME é Finalmente, a implementação e a adaptação dos modelos de
um trabalho que deve ser abordado com serenidade e com maturidade devem ser abordadas com bom senso, e com
o apoio da gestão a todos os níveis, não podendo ser visto adaptação às realidades organizacionais, com o principal
de uma forma leviana. objectivo de potenciar o negócio e não de o prejudicar [5]. A
“If the CMM is simply the flavor of the month, then you implementação/optimização dos processos com base nos
have a prescrition for disaster [1]” [5] modelos de maturidade para uma PME é possível, quando
interpretada de uma forma apropriada. No caso do CMM,
Os argumentos que muitas vezes são utilizados pelas este está já está a ser usado por empresas com menos de 15
diversas organizações são: os processos são demasiado pessoas e em projectos com apenas 2 pessoas: inclusive o
complexos, modelos difíceis de adaptar, os modelos são SEI’s em Dezembro de 1998 tinha 27 organizações com
muito estruturados/rígidos, a documentação é exagerada, menos de 25 colaboradores, que tinham realizado a
requer um grande investimento inicial (recursos, tempo e auditoria (CBA-IPI - CMM-based appraisal for Internal
ao nível financeiro) e o retorno do investimento não é Process Improvement). [4].
imediato.
FERNANDO SIMOES, PEDRO SOUSA: MODELOS DE MATURIDADE PARA SI/TI DE PEQUENAS E MÉDIA DIMENSÃO
7
8 CONCLUSÕES UMINF 00.12, 2000.
[8] Orci, T, Capability Maturity Model for Extra Small Organizations,
Os dois modelos de maturidade aqui apresentados, vindos
Level 2. Umeå University, Dept of Computing Sciences, UMINF
de duas escolas diferentes, Engenharia de Software e
00.13, 2000.
Gestão de Projectos, tal como se pode constatar, são
[9] Terttu Orci, Capability Maturity Model for Small Organizations,
complementares, tendo sinergias interessantes. Devido ao
Level 2. Umeå University, Dept of Computing Sciences, UMINF
facto de existirem processos comuns aos dois modelos ,
00.14, 2000.
uma organização que pretenda atingir um determinado
[10] Terttu Orci, Astrid Laryd CMModel for Small Organizations, Level
nível de maturidade de ambos os modelos tem toda a
2. Umeå University, Dept of Computing Sciences, UMINF 00.20,
vantagem em implementá-los em conjunto devido às
2000
sinergias que daí advêm.
[11] Kaisu Sammalisto, “Developing Total Quality Environmental
Management in SMEs Management Systems Approach”,
Por outro lado, as PME, apesar de todos os problemas
February 2001
apresentados, têm vantagens em relação às grandes [12] Phillipe Kruchten, “The Rational Unified Process, an
empresas, pois podem tirar partido da sua dimensão. Esta Introduction”, 1998
facilita claramente a implementação dos processos, sendo a
comunicação interna muito facilitada e tirando partindo Fernando Simões, Licenciado em Engenharia Informatica; Consultor
das relações inter-pessoais. na Novabase SA., Consultor especialista na Link SA, consultor Sénior
na Portugal Telecom Sistemas de Informação; Pesquisa em Modelos
de qualidade nas organizações de SI/TI.
Para que a implementação dos modelos de maturidade
numa organização seja efectuada com sucesso, deverá Pedro Sousa, Administrador Link Consulting, Professor Associado do
existir, ao nível da gestão, um apoio total para a Instituto Superior Técnico, Investigador no Centro de Engenharia
implementação dos modelos na organização. Para além Organizacional do INESC.
disso, ao nível da organização dever-se-á trabalhar numa
possível mudança cultural, para que a transição seja
efectuada sem grandes problemas.
9 PRÓXIMOS PASSOS.
Ao nível de próximos passos, um dos caminhos possíveis
será a definição de uma arquitectura de sistemas de
informação de referência, pela qual as organizações se
possam eventualmente orientar. Esta arquitectura deverá
ter por base todos os processos definidos neste trabalho,
assim como os processos base de suporte ao negócio. A
implementação desta tem por objectivo a automatização
dos processos de negócio de forma a diminuir o esforço de
implementação, utilização e manutenção, facilitando desta
forma o alcance de um determinado nível de maturidade
REFERENCES
[1] M. C. Paulk, Charles V. Weber, Suzanne M. Garcia, M. B.Chrisis, Marilyn
Bush, "Key Practices of the Capability Maturity ModelSM, Version 1.1"
Software Engineering Institute Technical Report, CMU/SEI-93-TR-25,
Fevereiro 1993.
[2] Kerzner, Harold, “Strategic Planning for project management using a
Project Management Maturity Model”, John Wiley and Sons, 2000.
[3] PMI Standards Committee, Wiliam R. Duncan, “A Guide to project
management Body of Knowledge”, 1996.
[4] M. C. Paulk, "Using the software CMM® With Good Judgment",
ASQ Software Quality Professional, Vol. 1, No. 3, Junho 1999.
[5] Paulk M. C.: Using the Software CMM in Small Organizations,
Carnegie Mellon University, 1998.
[6] Abran, A. and J. W. Moore, Eds. (2001). Guide to the Software
Engineering Body of Knowledge - Trial Version v 1.0 - SWEBOK .
Los Alamitos, California, U.S., IEEE Computer Society
[7] Terttu Orci, Capability Maturity Model for Extra Extra Small
Organizations, Level 2. Umeå University, Dept of Computing Sciences,