• Nenhum resultado encontrado

Impacto da Maturidade da Função Sistema de Informação na Abordagem à Engenharia de Requisitos

N/A
N/A
Protected

Academic year: 2020

Share "Impacto da Maturidade da Função Sistema de Informação na Abordagem à Engenharia de Requisitos"

Copied!
14
0
0

Texto

(1)

Impacto da Maturidade da Função Sistema de Informação na

Abordagem à Engenharia de Requisitos

Álvaro Rocha

Universidade Fernando Pessoa, Departamento de Ciência e Tecnologia, Porto, Portugal

amrocha@ufp.pt

João Álvaro Carvalho

Universidade do Minho, Departamento de Sistemas de Informação, Guimarães, Portugal

amrocha@ufp.pt

Resumo

A engenharia de requisitos é, talvez, a actividade mais crítica do processo de desenvolvimento de sistemas de informação, sobretudo pelo facto de ser aí que se define o suporte que os sistemas de informação deverão dar ao trabalho realizado nas organizações. A experiência vem demonstrando que a engenharia de requisitos é conduzida na prática com uma abordagem de pendor tecnológico excessivo, negligenciando a dimensão social e organizacional do trabalho. Mas os principais modelos de maturidade para a função sistema de informação sugerem que, apesar de inicialmente as organizações só prestarem atenção a factores tecnológicos, alargam a sua atenção a factores sociais e organizacionais à medida que se tornam mais maduras. Este artigo apresenta um estudo que visou analisar o impacto da maturidade da função sistema de informação na abordagem seguida pelas organizações na condução da engenharia de requisitos.

Palavras chave: Maturidade, Função Sistema de Informação, Gestão de Sistemas de

Informação, Processo de Desenvolvimento de Software, Engenharia de Requisitos.

(2)

1 Introdução

A engenharia de requisitos (ER) é, talvez, a actividade mais crítica do processo de desenvolvimento de sistemas de informação, sobretudo pelo facto de ser aí que se define o suporte que os sistemas de informação (SI) deverão dar ao trabalho realizado nas organizações. A definição incorrecta dos requisitos levará à obtenção e disponibilização de sistemas inadequados ao sistema organizacional.

Diversos autores [e.g., Hanseth e Monteiro 1996, Hirschheim et al. 1996, Walsham 1996, Wastell e Newman 1996, Vidgen 1997, Bate 1998, Flynn e Jazi 1998, Hooks 1999a] têm vindo a referir que a engenharia de requisitos tem vindo a ser realizada nas organizações com uma abordagem de pendor tecnológico excessivo, sendo esta a principal causa do insucesso dos sistemas de informação, e que é necessário aumentar a atenção prestada a factores sociais e organizacionais para que o sucesso dos sistemas de informação possa aumentar.

Por sua vez, os principais modelos de maturidade para a função SI [e.g., Nolan 1979, Galliers e Sutherland 1991, Paulk et al. 1993] sugerem que as organizações deixem de prestar somente atenção a factores tecnológicos da área dos sistemas de informação, alargando cumulativamente a sua atenção a factores sociais e organizacionais à medida que se tornam mais maduras.

Sabendo-se que a ER geralmente é conduzida nas organizações com uma abordagem de pendor

tecnológico, quando também tem a possibilidade de seguir uma abordagem mista ou, ainda, de pendor sócio-organizacional (figura 1), levantou-se a seguinte questão de investigação: Que impacto tem a maturidade da função SI na abordagem seguida pelas organizações na condução da engenharia de requisitos?

Este artigo apresenta um estudo realizado no âmbito de um projecto de doutoramento [Rocha 2000] com o objectivo de ajudar a esclarecer esta questão. Inicialmente apresenta-se o modelo de investigação que suportou o estudo; depois a metodologia adoptada; posteriormente o estudo levado a cabo junto de organizações; e finalmente as conclusões mais relevantes do estudo.

Engenharia de Requisitos

Social e/ou Organizacional

(3)

Figura 1: Abordagens possíveis na engenharia de requisitos.

2 Modelo de Investigação

Uma revisão da literatura sobre modelos de maturidade para a função SI mostrou que não há um modelo capaz de cobrir razoavelmente toda a função SI, e que estes modelos de maturidade são passíveis de serem agrupados em dois tipos: i) os que se centram em tópicos de gestão e

planeamento de SI [e.g., Nolan 1979, Galliers e Sutherland 1991]; e ii) os que se focam no processo de desenvolvimento de software (PDS) [e.g., Paulk et al. 1993, Kuvaja et al. 1994].

Esta constatação influenciou o desenvolvimento do modelo de investigação que se apresenta na figura 2, pois é pouco aconselhável estudar o impacto da maturidade da função SI, como um todo, na abordagem seguida na condução da ER, dado que os modelos de maturidade disponíveis em cada um dos grupos têm estruturas, instrumentos e exigências de avaliação da maturidade bem diferentes. Assim, a maturidade da função SI é aqui constituída pela maturidade da gestão de SI mais a maturidade do processo de desenvolvimento de software.

Resultaram assim três variáveis principais: 1) maturidade da gestão de SI; 2) maturidade do

processo de desenvolvimento de software; e 3) abordagem à engenharia de requisitos.

As variáveis que não se encontram no modelo de investigação a "negrito" e os relacionamentos propostos a tracejado não foram tidos em consideração no estudo, por limitações do seu âmbito, tempo, teorias e, como já referido, modelos existentes. Porém aparecem no modelo para melhor contextuar o estudo. Maturidade da Gestão de SI Abordagem à Eng. de Requisitos Sucesso dos SI Maturidade da função SI H1 H2

(4)

Figura 2: Modelo de Investigação.

Com base no modelo de investigação levantaram-se para exploração as seguintes hipóteses:

Hipótese 1: A maturidade da gestão de SI tem impacto na abordagem seguida na condução da engenharia de requisitos.

Hipótese 2: A maturidade do PDS tem impacto na abordagem seguida na condução da engenharia de requisitos.

Esperava-se que a um aumento da maturidade, quer ao nível da gestão de SI, quer ao nível do processo de desenvolvimento de software, correspondesse uma diminuição do pendor tecnológico na abordagem seguida na condução da engenharia de requisitos. Ou seja, as organizações menos maduras teriam uma abordagem à ER com pendor tecnológico mais acentuado do que as mais maduras.

3 Metodologia

O estudo baseou-se na recolha de informação junto de organizações onde se aplicou um "pacote" de três questionários. Para aferição da maturidade da gestão de SI aplicou-se o questionário de Galliers (1995) subjacente ao "modelo revisto dos estádios de crescimento" de Galliers e Sutherland (1991). Para aferição da maturidade do processo de desenvolvimento de software aplicou-se o questionário de Zubrow et al. (1994) subjacente ao modelo SW-CMM1 1.1 de Paulk et al. (1993). E para identificação da abordagem seguida na condução da engenharia de requisitos aplicou-se o questionário de Rocha (2000) subjacente ao seu esquema de detecção dessa abordagem.

A abrangência dos assuntos estudados e a dimensão dos instrumentos usados na recolha de informação não "aconselharam" um estudo tipo "survey". Assim somente se realizou em

(5)

empresas onde havia a certeza de uma colaboração efectiva sobre a forma de resposta aos questionários, e que satisfizessem as exigências de selecção, i.e., que tivessem uma dimensão razoável, bem como uma função SI estabelecida e formalizada, e que realizasse as actividades relacionadas com as variáveis a serem medidas. O estudo poderá assim ser classificado como "estudo de casos".

Apesar da via adoptada não permitir generalizações por meio de testes estatísticos, considerou-se que permitia obter alguma confiança nas afirmações apreconsiderou-sentadas como hipóteconsiderou-ses, considerou-sendo um primeiro passo na explicação das associações entre as variáveis consideradas para estudo.

4 O Estudo

4.1 Organizações Estudadas e Respectivos Respondentes

O estudo foi realizado junto de cinco organizações pertencentes a áreas de negócio distintas, a saber: banca e seguros, governo, alimentação, comércio electrónico e ensino. O número total de colaboradores, bem como os que constituem a função SI, também é diversificado entre elas. A tabela 1 apresenta estruturada e resumidamente as organizações estudadas.

Tabela 1: Organizações estudadas.

Emp. Negócio Colaboradores Função SI Descrição

A Banca e seguros 12691 400 Um dos principais grupos financeiros e seguradores do país

B Governo 260 150 Instituto de informática e finanças de um dos maiores ministérios do governo português

C Alimentação 1286 33 Uma das maiores empresas de bebidas do país

D Comércio electrónico

32 24 Uma das primeiras e das maiores empresas de comércio electrónico do país

E Ensino 296 7 Universidade privada

Os respondentes são engenheiros de requisitos com formação superior mas com experiências e funções já desempenhadas multi-variadas, como mostra a tabela 2.

Tabela 2: Características dos respondentes.

Empresa Formação Funções já desempenhadas Experiência

A Licenciatura em Eng.

Programador; 20 anos

1

(6)

Electrotécnica;

Pós-graduação em Gestão

Financeira.

Engenheiro de Sistemas/Negócio;

Gestor de Departamento de Migração e Desenvolvimento.

B Licenciatura em Matemáticas e Ciências dos Computadores

Gestor de Redes/Sistemas Informáticos;

Formador; Programador; Engenheiro de Software; Gestor de Dados. 7 anos C Licenciatura em Informática de Gestão Programador; Engenheiro de Software. 4 anos D Licenciatura em Eng. Sistemas e Informática; Mestrado em Informática de Gestão. Programador; Engenheiro de Software;

Gestor de Redes/Sistemas Informáticos.

10 anos E Licenciatura em Informática de Gestão. Técnico de Hardware; Programador; Engenheiro de Software. 4 anos 4.2 Maturidade da Gestão de SI

A figura 3 apresenta a síntese dos resultados obtidos para a maturidade da gestão de SI, mostrando na forma de matriz os estádios de maturidade em que as empresas se encontram para cada uma das dimensões de maturidade propostas pelo "modelo revisto dos estádios de crescimento" [Galliers e Sutherland 1991], destacando graficamente o estádio de maturidade médio de cada uma das empresas estudadas.

As empresas estudadas situam-se próximo do Estádio 4 de maturidade (Cooperação e Diálogo Democrático). Calculando a diferença entre a mais madura e a menos madura chega-se apenas a um valor próximo de um estádio de maturidade (4,7 - 3,4 = 1,3).

As empresas que apresentam melhores resultados são a B e a C. Poder-se-á então concluir que, apesar de haver um certo equilíbrio entre as empresas estudadas, as empresas B e C são, apesar de tudo, as mais avançadas relativamente à gestão de SI.

0 1 2 3 4 5 6

(7)

Factor de influência Emp. A Emp. B Emp. C Emp. D Emp. E Estratégia 3 4 5 2 5 Estrutura 5 6 4 4 4 Sistemas 3 2 5 4 6 Pessoal 3 5 5 3 5 Estilo 4 6 5 4 2 Aptidões 4 4 4 5 3 Valores partilhados 5 6 4 2 3 Estádio Médio 3,9 4,7 4,6 3,4 4,0

Figura 3: Estádios de maturidade da gestão de SI.

Cabe dizer que se sentiram algumas dificuldades na aplicação do questionário de Galliers (1995), nomeadamente: algumas das afirmações que caracterizam os estádios são muito subjectivas; existem algumas afirmações muito similares; e a ordem por qual aparecem afirmações relacionadas, por vezes, promove ambiguidade nas respostas.

4.3 Maturidade do Processo de Desenvolvimento de Software

A tabela 3 sintetiza os resultados conseguidos para a maturidade do processo de desenvolvimento de software pelas 18 áreas-chave do processo consideradas no modelo SW-CMM 1.1.

Pelos resultados obtidos, e sendo rigoroso na aplicação dos critérios de cálculo de maturidade subjacentes ao modelo SW-CMM 1.1, todas as empresas estudadas seriam caracterizadas como residindo no Nível 1 de maturidade (Inicial). O resultado não é de estranhar uma vez que diversos autores [e.g., Vicente et al. 1996, Soares 1997] referem o elevado grau de exigência deste modelo.

Numa tentativa de diferenciação entre as várias empresas, experimentou-se aplicar uma tolerância ao critério de cálculo do SW-CMM 1.1. A tabela 4 apresenta os níveis de maturidade em que se encontra cada empresa em função de valores de tolerância diferentes.

(8)

As empresas que apresentam melhores resultados são a A e a B. Poder-se-á afirmar que, apesar de todas as organizações serem pouco maduras face aos critérios de cálculo sugeridos pelo SW-CMM, as empresas A e B são, apesar de tudo, as mais avançadas em termos do processo de desenvolvimento de software.

Tabela 3: Síntese dos resultados da maturidade do processo de software.

Áreas Chave Emp. A Emp. B Emp. C Emp. D Emp. E

Gestão de Requisitos 50% 66,7% 0% 33,3% 0% Planeamento de Projectos de Software 28,6% 57,1% 28,6% 14,3% 71,4% Vigilância Acompanhamento Projectos de Software 28,6% 71,4% 14,3% 0% 71,4% Gestão da Sub-contratação de Software 37,5% 37,5% 0% 0% 0% Verificação da Qualidade de Software 50% 37,5% 0% 0% 75% Gestão de Configurações 0% 62,5% 25% 0% 62,5%

32,4% 55,5% 11,3% 7,9% 46,7%

Concentração no Processo Organizacional 57,1% 85,7% 0% 14,3% 42,9% Definição do Processo Organizacional 0% 83,3% 0% 16,7% 0% Programas de Treino 100% 42,9% 57,1% 0% 71,4% Gestão da Integração de Software 0% 66,7% 0% 0% 0% Engenharia do Produto de Software 50% 50% 0% 16,7% 0% Coordenação Inter-Grupos 0% 71,4% 0% 0% 0% Revisões por Pares 0% 16,7% 33,3% 0% 0%

29,6% 59,5% 12,9% 6,8% 16,3%

Gestão Quantitativa do Processo 0% 28,6% 0% 0% 0% Gestão da Qualidade de Software 0% 71,4% 0% 0% 0%

0% 50% 0% 0% 0%

Prevenção de Defeitos 0% 71,4% 28,6% 14,3% 0% Gestão da Mudança da Tecnologia 42,9% 57,1% 14,3% 0% 28,6% Gestão da Mudança do Processo 14,3% 28,6% 0% 14,3% 0%

19% 52,4% 14,3% 9,5% 9,5%

Tabela 4: Níveis de maturidade para valores de tolerância diferentes.

Tolerância Emp. A Emp. B Emp. C Emp. D Emp. E

0% 1 1 1 1 1

25% 1 1 1 1 1

50% 1 5 1 1 1

75% 3 5 1 1 2

A figura 4 mostra os estádios de maturidade do processo de desenvolvimento de software conseguidos, por empresa, admitindo tolerância de 75%.

2 3 4 5

(9)

Figura 4: Estádios de maturidade do processo de software, admitindo tolerância de 75%

Cabe acrescentar que a aplicação do questionário de Zubrow et al. (1994) não apresentou dificuldades, pois mostrou-se um instrumento de levantamento de informação regido por um bom grau de clareza e objectividade.

4.4 Abordagem Seguida na Condução da Engenharia de Requisitos

Os resultados obtidos para a variável abordagem à engenharia de requisitos mostram que, na globalidade das organizações estudadas, a abordagem seguida na condução da engenharia de requisitos é predominantemente de pendor tecnológico, como ilustra a figura 5.

A abordagem de pendor tecnológico atinge uma frequência média superior à frequência média da soma da abordagem mista com a abordagem social e/ou organizacional. Este indicador vai de encontro aos autores [e.g., Hanseth e Monteiro 1996, Bate 1998] que afirmam que a engenharia de requisitos é realizada na prática com pendor tecnológico.

Um olhar mais atento aos resultados, mostra que nas empresas A e B, apesar da abordagem de pendor tecnológico ainda predominar, as abordagens mista e social e/ou organizacional já começam a receber uma atenção significativa, o que sugere que estas organizações darão, face às outras, uma atenção mais equilibrada a factores técnicos, sociais e organizacionais.

Acresce dizer que a aplicação do questionário de Rocha (2000) não apresentou dificuldades.

0,0% 10,0% 20,0% 30,0% 40,0% 50,0% 60,0% 70,0% 80,0% Social e/ou Organizacional Mista Tecnológica

(10)

Emp. A Emp. B Emp. C Emp. D Emp. E Média

Social e/ou Organizacional 40,5% 37,7% 11,3% 14,0% 26,3% 26,0% Mista 32,3% 38,5% 23,0% 31,0% 35,0% 32,0% Tecnológica 63,8% 57,2% 73,2% 75,2% 67,5% 67,4%

Figura 5: Abordagem à engenharia de requisitos

4.5 Impacto da Maturidade da Função SI na Engenharia de Requisitos

Vai-se agora analisar o impacto das variáveis maturidade da gestão de SI e maturidade do

processo de desenvolvimento de software na variável abordagem à engenharia de requisitos,

tendo por base a síntese estruturada de resultados apresentada na tabela 5.

Tabela 5: Síntese estruturada dos resultados.

Empresas Maturidade GSI Maturidade PDS Pendor tecnológico ER A B C D E 3,9 4,7 4,6 3,4 4,0 3 5 1 1 2 63,8% 57,2% 73,2% 75,2% 67,5%

A metodologia a seguir consistirá em ordenar as organizações desde as mais maduras até as menos maduras relativamente à gestão de SI e do processo de desenvolvimento de software, e desde aquelas que reflectem um menor pendor tecnológico até as que reflectem um maior pendor tecnológico na abordagem seguida na condução da engenharia de requisitos, analisando-se posteriormente as associações propostas no modelo de investigação e nas hipóteanalisando-ses levantadas.

Impacto da maturidade da gestão de SI

A hipótese 1, apresentada inicialmente, sugere que a maturidade da gestão de SI tem impacto na abordagem seguida na condução da engenharia de requisitos.

Esperava-se que uma gestão de SI pouco madura implicasse uma abordagem à engenharia de requisitos com pendor tecnológico, por outro lado, esperava-se que uma maior maturidade da

(11)

gestão de SI implicasse uma diminuição desse pendor, em favor do aumento da atenção dada as aspectos sociais e/ou organizacionais.

Ordenando as organizações desde as mais maduras até as menos maduras (figura 6), no que diz respeito à gestão de SI, encontra-se a seguinte lista: B=4,7; C=4,6; E=4,0; A=3,9; e D=3,4.

Maturidade Gestão SI Abordagem ER

+ maduras B C B A - tecnológicas - maduras E A D E C D + tecnológicas

Figura 6: Maturidade da gestão de SI versus abordagem à ER.

Fazendo um exercício similar sobre os resultados da abordagem à engenharia de requisitos, ou seja, ordenando as empresas desde as que indiciam um menor pendor tecnológico até as que evidenciam um maior pendor tecnológico, obtém-se a seguinte lista B=57,2%; A=63,8%; E=67,5%; C=73,2%; D=75,2%.

As listas encontradas para cada uma das duas variáveis em comparação não permitem consolidar na totalidade a hipótese 1 e, consequentemente, o relacionamento proposto, porque somente se verifica em três das empresas estudadas: B, D e E.

Em suma, poderá dizer-se que, apesar de na maioria das situações estudadas se verificar o relacionamento proposto inicialmente entre a maturidade da gestão de SI e a abordagem seguida na condução da engenharia de requisitos (3 para 5), o estudo presente não reforçou completamente a hipótese 1, contudo também não a contrariou. Os resultados obtidos indicam assim no sentido de ganhar confiança na hipótese levantada, mas julga-se necessário um outro estudo com um maior número de organizações para que algo mais de concreto possa ser acrescentado.

Impacto da maturidade do processo de desenvolvimento de software

A hipótese 2, apresentada inicialmente, sugere que a maturidade do processo de desenvolvimento de software tem impacto na abordagem seguida na condução da engenharia de requisitos.

(12)

Esperava-se que um processo de software menos maduro implicasse uma abordagem à engenharia de requisitos com pendor tecnológico, por outro lado, esperava-se que uma maior maturidade do processo de desenvolvimento de software implicasse uma diminuição desse pendor, em favor do aumento da atenção dada aos aspectos sociais e/ou organizacionais.

Ordenando as organizações desde as mais maduras até as menos maduras (figura 7), no que diz respeito ao processo de desenvolvimento de software, encontra-se a seguinte lista: B=5; A=3; E=2; C=1; e D=1. Maturidade PDS Abordagem ER + maduras B A B A - tecnológicas - maduras E C D E C D + tecnológicas

Figura 7: Maturidade PDS versus abordagem da ER.

Como vimos anteriormente, fazendo um exercício idêntico sobre os resultados da abordagem à engenharia de requisitos, ou seja, ordenando as empresas desde as que indiciam um menor

pendor tecnológico até as que evidenciam um maior pendor tecnológico, obtém-se a seguinte

lista: B=57,2%; A=63,8%; E=67,5%; C=73,2%; D=75,2%.

Neste caso, como ilustra a figura 7, as listas encontradas para as variáveis em comparação reforçam na totalidade a hipótese 2, e consequentemente o relacionamento proposto.

Em suma, poderá dizer-se que o relacionamento proposto inicialmente, entre a maturidade do processo de desenvolvimento de software e a abordagem seguida na condução da engenharia de requisitos (hipótese 2), se verifica em todas as organizações estudadas. Esta constatação é um bom prenúncio para a realização de um estudo com uma amostra representativa de organizações, onde seja aconselhável/permitido realizar testes estatísticos, possibilitando, dessa forma, validar a generalização deste relacionamento, por exemplo, a nível nacional.

(13)

5 Conclusões

Pretendeu-se com este artigo apresentar um estudo realizado com o objectivo de analisar o impacto da maturidade da função SI na abordagem seguida pelas organizações na condução da actividade engenharia de requisitos.

Os resultados vieram a consolidar as opiniões que apontavam no sentido de que a engenharia de requisitos é conduzida na prática com pendor tecnológico, bem como as hipóteses e relacionamentos propostos no modelo de investigação.

A abordagem à engenharia de requisitos com pendor tecnológico predomina em todas as organizações estudadas, apesar de se verificar que perde sempre força para as abordagens mista e social e/ou organizacional naquelas empresas cujo processo de desenvolvimento de software é mais maduro.

Este impacto da maturidade do processo de desenvolvimento de software na abordagem seguida na condução da engenharia de requisitos consolidou na totalidade a hipótese 2 e o relacionamento proposto para estas variáveis, ou seja, a maturidade do processo de desenvolvimento de software influi, de facto, em todas as organizações estudadas, na atenção prestada durante a engenharia de requisitos a aspectos tecnológicos e sociais e/ou organizacionais.

Já o relacionamento entre a maturidade da gestão de SI e a abordagem seguida na condução da engenharia de requisitos, sugerido na hipótese 1, não se verificou tão forte como o esperado. Apesar de ocorrer na maioria das organizações, somente foi registado em três das cinco empresas estudadas.

Uma justificação para isto acontecer talvez possa ser o facto da maturidade da gestão de SI se basear em filosofias e princípios estratégicos e de gestão, situando-se o seu foco, portanto, num nível hierárquico da organização elevado. Ao passo que a maturidade do processo de software se baseia em princípios e formas de execução/desenvolvimento de uma actividade, situando-se, portanto, a um nível de operacionalização/desenvolvimento, tal como a actividade engenharia de requisitos. Em suma, isto sugere a existência de lacunas na ligação entre o nível de gestão e planeamento de SI e o nível onde se enquadra a actividade engenharia de requisitos.

Referências

Bate, R., "Do systems engineering? Who, me?", IEEE Software, Julho/Agosto (1998), pp. 65-66.

(14)

Flynn, D. e Jazi, D., "Constructing user requirements: a social process for a social context", Information Systems Journal, 8 (1998), pp. 53-83.

Galliers, R., Stages of Growth Model: Data Collection Forms, Warwick Business School ou PI Business Consultants Ltd, 1995.

Galliers, R. e Sutherland, A., "Information systems management and strategy formulation: the ´stages of growth´ model revisited", Journal of Information Systems, 1, 2 (1991), pp. 89-94.

Hanseth, O. e Monteiro, E., "Navigation future research: judging the relevance of information systems development research", Accounting, Management and Information Technologies, 6, 1-2 (1996), pp. 77-85.

Hirschheim, R., Klein, H. e Lyytinen, K., "Exploring intellectual structures of information systems development: a social action theoretic analysis", Accounting, Management and Information Technologies, 6, 1-2 (1996), pp. 1-64.

Hooks, Ivy., Writing good requirements, artigo apresentado ao Fourth INCOSE Symposium, 1999.

Kuvaja, P. et al., Software process Assessment & Improvement: The Bootstrap Approach, Blackwell Business, 1994.

Nolan, R., "Managing the crisis in data processing", Harvard Business Review, 57, 2 (1979), pp. 115-126.

Paulk, M., Curtis, B., Chrissis, M. e Weber, C., Capability Maturity Model for Software, Version 1.1, Software Engineering Institute, Carnegie Mellon University, CMU/SEI-93-TR-024, 1993.

Rocha, A., Influência da Maturidade da Função Sistema de Informação na Abordagem à Engenharia de Requisitos, Tese de Doutoramento (versão rascunho), Universidade do Minho, 2000.

Soares, N., Avaliação da Maturidade do Processo de Software, Dissertação de Mestrado, Universidade do Minho, 1997.

Vicente, B., António, C. e Barreira, J., Qualidade no Software, Projecto Aquis, Instituto Português da Qualidade, 1996.

Vidgen, R., "Stakeholders, soft systems and technology: separation and mediation in the analysis of information systems requirements", Information Systems Journal, 7, 1 (1997), pp. 21-46.

Walsham, G., "Exploring the intellectual structures of information systems development: a short critique", Accounting, Management and Information Technologies, 6, 1-2 (1996), pp. 133-138.

Wastell, D. e Newman, M., "Information system design, stress and organizational change in the ambulance services: a tale of two cities", Accounting, Management and Information Technologies, 6, 4 (1996), pp. 283-300.

Zubrow, D. et al., Maturity Questionnaire, Special Report, CMU/SEI-94-SR-07, Software Engineering Institute, 1994.

Imagem

Figura 1: Abordagens possíveis na engenharia de requisitos.
Figura 2: Modelo de Investigação.
Tabela 1: Organizações estudadas.
Figura 3: Estádios de maturidade da gestão de SI.
+6

Referências

Documentos relacionados

O objetivo do curso foi oportunizar aos participantes, um contato direto com as plantas nativas do Cerrado para identificação de espécies com potencial

Os alunos que concluam com aproveitamento este curso, ficam habilitados com o 9.º ano de escolaridade e certificação profissional, podem prosseguir estudos em cursos vocacionais

Mais
 ainda,
 numa
 perspectiva
 didáctica,
 bastante
 pertinente
 para
 este
 projecto,
 a


• The definition of the concept of the project’s area of indirect influence should consider the area affected by changes in economic, social and environmental dynamics induced

Para atingir este fim, foram adotados diversos métodos: busca bibliográfica sobre os conceitos envolvidos na relação do desenvolvimento de software com

Objetivo: Garantir estimativas mais realistas e precisas para o projeto, ao considerar nesta estimativa o esforço necessário (em horas ou percentual do projeto) para

One of the main strengths in this library is that the system designer has a great flexibility to specify the controller architecture that best fits the design goals, ranging from

Both the distribution of toxin concentrations and toxin quota were defined by epilimnetic temperature (T_Epi), surface temperature (T_Surf), buoyancy frequency (BuoyFreq) and