Pipelining Issues

Na literatura de sistemas de informação, o estudo pioneiro que introduziu a abordagem dos stakeholders foi o de Schonberger (1980) e incluiu a ideia de que o esforço de

design de um SI pode ser liderado pelo usuário e não apenas pelo analista. O autor propôs

seis abordagens para design de um SI variando de nenhum envolvimento do usuário a um envolvimento considerável. O modelo prevê que a liderança em design de um SI depende do tipo de tomada de decisão. Os executivos, usuários ou outros stakeholders podem assumir uma liderança ativa quando as circunstâncias a justifiquem.

Outras aplicações recentes avaliam o impacto dos stakeholders no planejamento de um SI, analisam o relacionamento dos stakeholders e a colaboração deles na prestação de serviços online, comunidades virtuais e abordam a teoria dos stakeholders para discutir questões éticas na gestão de SI (Freeman et al., 2010).

Um campo que tem utilizado essa teoria é o de engenharia de software. As pessoas e grupos que afetam o sistema e são afetadas por eles são os stakeholders com papel decisivo na definição e criação do software. Entender o papel dos stakeholders é fundamental para compreender o desenvolvimento do software pois eles tomam decisões fundamentais sobre o escopo, funcionalidade, características operacionais e estrutura de um sistema de software. Além disso, eles têm necessidades que precisam ser atingidas pelo software e preocupações sobre o sistema que será criado. Existem diversos stakeholders, tais quais: cliente, assessores, comunicadores, desenvolvedores, engenheiros de software, analistas, fornecedores, testadores e usuários (Rozanski & Woods, 2011).

O aspecto colaborativo é destacado pela literatura. O sucesso de um projeto de desenvolvimento de software é visto como resultado de atividades colaborativas entre diferentes stakeholders incluindo pessoas técnicas e todas as outras que tem riscos ou interesse no projeto com os clientes (Babar et al., 2014) .

Cada stakeholder desempenha um papel e leva para a interação seus interesses particulares o que gera uma negociação contínua sobre os objetivos e procedimentos do processo. A participação dos stakeholders no desenvolvimento de software tende a ser

descrita como um processo altamente complexo, entrópico (isto é, propenso a desordens) e idiossincrático (isto é, específico de caso e dependente do contexto). Em essência, a participação pode ser interpretada em três linhas gerais, são elas: participação como contribuição, que é voluntária ou outras formas de contribuição das pessoas para programas e projetos predeterminados; participação como organização, seja externamente concebida ou emergindo como resultado do processo; ou a participação como empoderamento, capacitando as pessoas a desenvolver habilidades para se tornarem mais autossuficientes, e para tomar decisões ações essenciais ao seu desenvolvimento (McManus, 2005).

Os estudos que analisam as abordagens de seleção e análise de stakeholders focam em diferentes domínios como abordagem da gestão estratégica, sistemas de informação, engenharia e de gestão (Babar et al., 2014). Diversos estudos adotam o conceito de

stakeholders na literatura de desenvolvimento de software. A fim de identificar aqueles que

que abordam os preceitos da teoria dos stakeholders e tem uma ligação com o campo da gestão foi feito uma revisão do tipo scoping conforme consta no apêndice III. A figura 30 apresenta os estudos identificados na literatura.

Ano Autores Título Principais resultados

2000 Ravichan dran e Rai Quality Management in Systems Development: An Organizational System Perspective

Os autores propõem o desenvolvimento de uma teoria de gerenciamento de qualidade de software que integra questões sócio-comportamentais, organizacionais e de desempenho. Um dos construtos do modelo é a participação dos stakeholders como clientes, fornecedores, programadores e analistas. Foi constatado que esse construto tem uma relação positiva com a eficácia do gerenciamento de processos de desenvolvimento. 2010 Power Stakeholder Identification in Agile Software Product Development Organizations

Os conceitos de saliência, stakeholders primários e secundários são utilizados. O estudo de caso em uma organização de produtos de software classificou os stakeholders em seis categorias principais: a equipe do proprietário do produto; a equipe de entrega do produto; a equipe do patrocinador do programa; os consumidores de produtos; o Conselho do produto e a equipe principal do programa e fornece uma descrição das responsabilidades básicas dos membros do grupo.

2012 Pacheco e Garcia A systematic literature review of stakeholder identification methods in requirements elicitation

Foi realizada uma revisão sistematizada para investigar os métodos de elicitação de requisitos. Os métodos apresentados sugerem que a identificação de stakeholders relacionadas ao projeto será baseada em sua relevância para o projeto (interesses de prioridade), seus conhecimentos e habilidades, e na atitude adequada em relação ao processo. Todas as iniciativas de software referidas contribuem para a melhoria do processo de software. No entanto, os estudos não explicaram como desenvolver o sistema de informação.

2013 Bois, Els e Bart

Demonstration of software concepts to multiple stakeholders using modular abstract

prototyping

Os autores abordam a prototipagem para modelar a funcionalidade do sistema, aspectos visuais e interação nas fases iniciais, junto com os stakeholders. A metodologia de prototipagem desenvolvida tem as seguintes fases: 1) conceptualização; 2) design; 3) execução e 4)avaliação de dados.

2014 Babar, Ghazali, Jawawi e Elsafi Stakeholder management in value- based software development: systematic review

Os atributos enfatizados dos stakeholders nos estudos são poder, interesse, papel e urgência. A aplicação das diferentes abordagens de seleção e identificação de stakeholders não é uniforme e se concentram apenas em alguns domínios e diferentes metodologias são aplicadas. As questões relacionadas ao desenvolvimento de software baseada em valor são diversas, tais como: ideia inovadora, analise de riscos, comunicação, problemas de tomada de decisão e também nos stakeholders.

2015

Achimigu , Ibrahim e Selamat

Using the fuzzy multi- criteria decision making approach for software requirements

priorization

Propõe-se uma abordagem de decisão multicritérios pautada na lógica fuzzy para priorização de requisitos. Eles são definidos e etapas: 1)geração de requisitos, 2)requisitos de gravação, 3) discussão dos requisitos, 4) requisitos de classificação. Em seguida, são obtidos os pesos números, que são convertidos em uma matriz de decisão e alocados os pesos e gerada as classificação.

2016 Wurfel, Lutz e Diehl Grounded requirements Engineering: An approach to use case

driven requirements Engineering

Aplica-se a teoria fundamentada para coleta e análise de requisitos seguindo as fases: 1)coleta de dados, 2) transcrição de vídeos, 3) codificação aberta; 4) codificação axial; 5) codificação seletiva. Em seguida, os resultados da teoria fundamentada gerada foram transformados nos casos de uso seguindo três passagens: 1) transferência de estrutura; 2) transferência de conteúdo e 3)conclusão de detalhes. A nova abordagem permite passar das observações do mundo real aos requisitos na forma de casos de uso. Figura 30. Estudos sobre Teoria dos Stakeholders e desenvolvimento de software

Nota. Fonte: Elaboração própria, 2019

Foi gerada uma nuvem de palavras (figura 31) utilizando os resumos e palavras-chave desses estudos selecionados. Algumas regras de exclusão manual de palavras4 foram adotadas para melhor visualização da nuvem. As palavras que estão em destaque na nuvem refletem os principais aspectos estudados. A aplicação da teoria dos stakeholders no desenvolvimento de software se dá principalmente nas primeiras etapas de desenvolvimento do software que é a identificação dos stakeholders, elicitação dos requisitos e priorização

4_{Regras adotadas: 1) exclusão de palavras que tiveram frequência de ocorrência igual a 1 e 2; 2) exclusão das palavras que} representam as temáticas da revisão, tais como “stakeholders”, “stakeholder”, “software”, “system”, “Systems”, “development”, “Software”; “management”, “organization” 3) exclusão de adjetivos como “different”, “specific”, “important”, “current” 4) exclusão de verbos como “can”, “presentes”, “using”, “demonstrate”, “according”, “developed”, “reported”, “improved”, “existing”, “may”, “used”, “need”, “understanding”, 6) exclusão de palavras que remetem a estrutura do resumo dos artigos como “theory”, “paper”, “approaches” e “approach”, “abstract”, “methods”, “review”, “Theory”, “model”, “literature”, “systematic”, “method”; 7) siglas de tecnologias “VBS”, “GRE” e “MAP e 8) exclusão de outras palavras que não são significantes para a nuvem como “suggest”, “atributes”, “demonstration”, “group”, “order” e “evidence”.

deles, conforme destacado pelas palavras “identification”, “elicitation”, “requirements” e “priorization”.

Figura 31. Nuvem de palavras teoria dos stakeholders e desenvolvimento de software Nota. Fonte: Elaboração própria (2019)

Babar et al. (2014) realizaram uma revisão sistemática e constataram que o modelo de Mitchell (1997) é um dos modelos mais adotados, os atributos de poder, legitimidade e urgência são usados para identificar e quantificar as stakeholders. O atributo de poder é o foco de 46,6% das técnicas; o de interesse é o foco de 40% das técnicas; o do papel está focado em 33,3% das técnicas; o da urgência é focado em 20% das técnicas e os atributos de atividade e relacionamento estão focados em 13,3%.

Nesse sentido, o estudo de Power (2010) enfatizou os papéis dos stakeholders e apresenta um mapa dos stakeholders e seus papéis no desenvolvimento de software sob o paradigma dos métodos ágeis. Entretanto, o estudo não descreve detalhadamente como foi feita essa identificação e análise. Babar et al. (2014) observaram isso na revisão e concluíram que o foco deles está em um nível mais genérico e não há quantificação e categorização dos

stakeholders em forma de um quadro ou em processo refinado de análise.

Rozanski e Woods (2005) corroboram com a constatação de Babar et al. (2014) e elucidam que não existem critérios objetivos para determinar se a identificação dos

stakeholders foi feita corretamente. Essa seleção depende de um conjunto de fatores,

incluindo os objetivos do sistema, as considerações políticas e organizacionais, a disponibilidade de recursos, o custo e as restrições de tempo. É indicada a elaboração de uma lista de stakeholders e a avaliação deles com base nos seguintes critérios: 1) informado – O

certas? 2) comprometido – O stakeholder está habilitado e disponível para participar do processo e enfrentar algumas decisões difíceis? 3) autorizado – Tem certeza de que a decisão feita agora pelo stakeholder não será revertida mais tarde? 4) representativo – O stakeholder é um grupo e não uma pessoa, tem representantes adequados que foram selecionados do grupo? Os autores apresentam uma lista (figura 32) dos principais stakeholders que atuam no desenvolvimento de software.

Stakeholder Descrição Preocupações

Comprador Supervisionam a aquisição do sistema. Geralmente são os gestores sêniores.

Alinhamento aos objetivos estratégicos, retorno do investimento, custo, planos e recursos envolvidos

Assessor

Supervisiona a conformidade dos sistemas com os padrões e regulação legal

Conformidade com os requisitos e compliance

Comunicador

Explica o sistema para outros stakeholders via documentação e materiais de

treinamento

Qualidade da comunicação

Desenvolvedor

Constroem o sistema com base nas especificações

Padrões de desenvolvimento, escolha da plataforma, linguagem, ferramentas, manutenção, flexibilidade e preservação do conhecimento ao longo do tempo

Mantenedores Gerencia a evolução do sistema

Documentação, instrumentação e preservação do conhecimento do time

Fornecedores

Constrói ou fornece o hardware, software ou infra para o sistema funcionar

Não estão envolvidos na construção e uso do sistema mas podem impor limitações Suporte

Fornece suporte para os usuários do sistema.

Possuir a informação requerida para resolver o problema dos usuários que se comunica via telefone, e-mail ou internet

Administração do sistema

Rodam o sistema desenvolvido

Monitoração do sistema, continuidade do negócio, disponibilidade, resiliência, escalabilidade

Testadores Testam o sistema para garantir o uso

Estabelecimento dos requisitos e design de teste

Usuários

Definem a funcionalidade do sistema e o utilizam

Escopo, funcionalidade, performance, segurança.

Figura 32. Principais stakeholders no desenvolvimento de software Nota. Fonte: Rozanski e Woods (2005)

McManus (2005) também apresentam uma lista completa dos stakeholders de um projeto de software específico na área de saúde conforme pode ser visto na figura 33. A equipe típica de stakeholders de um projeto de software consiste em um gerente de projeto, analistas, designers, desenvolvedores, testadores e pessoal de garantia de qualidade. A equipe também pode incluir usuários ou seus representantes.

Ciclo de vida do projeto de software Stakeholders primários, secundários, externos 1. Análise dos requisitos do sistema • Membro do conselho do projeto • Analistas de negócios 2. Design da arquitetura do sistema • Administradores não executivos • Arquiteto técnico 3. Análise dos requisitos do software • Gerente / diretor

• Arquiteto de banco de dados

4. Design arquitetura do software • Gerente de departamento

• Analista de banco de dados

5. Design detalhado do software • Gerentes de conta • Desenvolvedores 6. Teste e codificação do software • Patrocinador do projeto • Gerente de integração 7. Integração de software • Usuário campeão • Gerente de configuração 8. Teste de qualificação do software • Gerente de recursos humanos

• Gerente de controle de mudanças

9. Integração do sistema • Usuários do departamento

• Gerente de controle de qualidade

10. Teste de sistema • Gerente de programa • Gerente de teste 11. Instalação do software • Gerente de projetos • Testadores 12. Apoio a aceitação • Arquiteto de negócios

• Equipes de suporte de infraestrutura

• Ministro do governo • Agências governamentais • Autoridades locais • Órgãos estatutários e voluntários • Agências do setor privado • Regulamentação de categorias profissionais • Instituições financeiras • Grupos de interesse local • Público geral • Consultores

• Relações Públicas • Pacientes Figura 33. Stakeholders de software na área de saúde

Nota. Fonte: McManus (2005)

Outro aspecto abordado nos estudos é a atuação dos stakeholders na elicitação e priorização de requisitos. Pacheco e Garcia (2012) realizaram uma revisão sistemática e constataram que a identificação dos stakeholders na fase de elicitação recebeu pouca atenção das diferentes iniciativas existentes no desenvolvimento de software, por exemplo, CMMi, SWEBOK, BABOK e ISO / IEC 12207. Os métodos apresentados sugerem que a identificação dos stakeholders seja baseada em sua relevância para o projeto (interesses de prioridade), seus conhecimentos e habilidades, e em uma atitude adequada em relação ao processo. Wurfel et al. (2016) desenvolveram um método baseado em teoria fundamentada para coletar os requisitos do software, que seguiu as fases: 1) coleta de dados, 2) transcrição de vídeos, 3) codificação aberta; 4) codificação axial; 5) codificação seletiva. Em seguida, os resultados foram transformados nos casos de uso seguindo três passagens: 1) transferência de estrutura; 2) transferência de conteúdo e 3) conclusão de detalhes.

A literatura recomenda algumas práticas para o desenvolvimento de um SI: 1) Atribuir papéis apropriados aos stakeholders por meio de uma análise de habilidades, comportamento em dinâmicas de grupo e testes de personalidade; aspectos que tornariam o SI repetível e verificável; 2) Estabelecer uma interação construtiva entre eles durante o processo de coleta de requisitos para evitar conflitos e problemas de comunicação decorrentes de diferentes pontos de vista; 3) Classificar os requisitos obtidos dos stakeholders

de acordo com uma avaliação de suas prioridades em relação ao objetivo do projeto (Pacheco & Garcia, 2012).

Após a seleção dos requisitos, o conceito de stakeholders aparece na priorização dos requisitos que é o ato de classificá-los de acordo com sua importância relativa pelos

stakeholders do projeto a fim de planejar as fases de liberação do software. Muitas técnicas

têm sido propostas na literatura por profissionais e acadêmicos. No entanto, qualquer que seja a técnica de priorização proposta, sua essência é gerar uma lista ordenada de requisitos com base nos pesos relativos ou nas pontuações fornecidas pelos stakeholders relevantes do projeto (Achimugu, Selamat, & Ibrahim, 2015).

Achimugu et al. (2015) utilizaram uma técnica quantitativa pautada na abordagem de decisão multicritério com o aporte da lógica fuzzy. Os requisitos são definidos em quatro etapas: 2) geração de requisitos, 2) requisitos de gravação, 3) discussão dos requisitos, 4) requisitos de classificação. Em seguida, são obtidos os pesos, números, que são convertidos em uma matriz de decisão e alocados para gerar a classificação.

As palavras “prototyping” e “design” representam a atuação dos stakeholders na fase de construção do software. Bois e Gerritsen (2013) desenvolveram uma metodologia para prototipagem de software que combina módulos genéricos e específicos de acordo com o foco dos stakeholders, ou seja, de acordo com seus pontos de vistas, demandas, habilidades e modalidade de apresentação. A metodologia desenvolvida tem as seguintes fases: 1) conceitualização, que envolve o perfil e agrupamento dos stakeholders, a definição do conceito de software, design do conteúdo de demonstração; 2) design que inclui a modularização, implementação, questões de discussão, planejamento de sessão, convocação e pré-avaliação e 3) execução, que inclui a participação dos stakeholders na criação e 4) avaliação de dados.

A palavra “quality” remete a atuação dos stakeholders no gerenciamento da qualidade do software. Ravichandran e Rai (2000) construíram um modelo para analisar os determinantes da qualidade do software e constataram que a participação dos principais

stakeholders, como clientes, fornecedores, programadores e analistas, tem uma relação

positiva com a eficácia do gerenciamento de processos de desenvolvimento de software. A figura 34 apresenta esses conceitos que são abordados pelos estudos e estão na interseção do campo da teoria dos stakeholders e desenvolvimento de software.

Figura 34. Interseção dos conceitos teoria dos stakeholders e desenvolvimento de software Nota. Fonte: Elaboração própria, 2019.

Após o entendimento, reflexão e discussão dos principais conceitos que permeiam essa pesquisa, é estabelecido um framework que especifica as relações que serão analisadas no estudo de campo. A pesquisa empírica que será desenvolvida objetiva entender e ampliar o conhecimento teórico discutido e apresentado na revisão de literatura.

2.4 SÍNTESE DA LITERATURA E CONFIGURAÇÃO TEÓRICA DA PESQUISA

Em resumo, as lacunas de pesquisa em relação à temática estudada dizem respeito principalmente a duas áreas. Primeiro, a forma como a cocriação acontece no desenvolvimento de software ainda é pouco conhecida. Sabe-se que é um processo dinâmico, cíclico e interativo, todavia as peculiaridades do processo ainda são pouco conhecidas. Em especial, são necessárias pesquisas sobre as formas específicas da cocriação e os seus resultados subsequentes (Oertzen et al., 2018).

A literatura relata aspectos que podem ajudar a explicar a cocriação, tais como, o lócus de interação que explica como se dá a interação com os stakeholders; o padrão de interação se é ativo ou passivo, iniciado pela organização ou pelos próprios stakeholders; a qualidade da interação e a existência de impedimentos ou incentivos no processo de cocriação (Hoyer et al., 2010; Prahalad & Ramaswamy, 2004a; Zwass, 2010). A literatura ainda explana que a cocriação acontece por meio de interações dinâmicas entre ações, recursos e um grupo de atores conforme foi exposto na figura 7 (Russo‐Spena & Mele, 2012).

Além disso, estudos posteriores associam o elemento papéis à cocriação. Cada

stakeholder pode desempenhar papéis específicos os quais estão vinculados às suas ações no

processo de cocriação, bem como o uso de recursos ao longo do processo (Breidbach & Maglio, 2016; Goodman et al., 2017). Sabe-se que alguns stakeholders podem ter um papel mais proativo na cocriação. Em vez de reagir às solicitações da organização, esses

stakeholders proativos tomam a iniciativa de contribuir para o processo. Enquanto outros

podem ter um papel mais reativo (Goodman et al., 2017).

Todavia, ainda não está muito claro quais papéis e atividades os atores desempenham em conjunto na cocriação. Esse elemento parece ser importante para explicar o fenômeno uma vez que os papéis podem combinar-se com os recursos por meio de tarefas independentes, facilitar a troca de recursos ou efetivar atividades conjuntas. Assim, conceituar processos de cocriação de valor como sequências de interação entre papéis interdependentes de atores fornece uma nova compreensão da natureza da cocriação (Breidbach & Maglio, 2016).

A segunda lacuna refere-se à atuação dos stakeholders. Sabe-se que eles atuam de maneira colaborativa e interativa no desenvolvimento do software. Entretanto, os aspectos que impulsionam e caracterizam essa atuação ainda são pouco explorados e as ações deles nas atividades de cocriação também são pouco conhecidas. A literatura indica a realização de estudos que consideram a perspectiva de redes e de stakeholders na cocriação, ao invés de perspectivas diádicas (Agrawal et al., 2015; Agrawal & Rahman, 2015; Oertzen et al., 2018)

Assim, esse fenômeno da cocriação pode ser explicado pela ótica da teoria dos

stakeholders, conforme abordado na revisão de literatura. Os construtos dessa teoria podem

explicar as ações e reivindicações dos stakeholders nas atividades e decisões de cocriação. Esses construtos representam a saliência dos stakeholders, tais como o poder, a urgência e a legitimidade (Mitchell et al., 1997). Estudos enfatizados acima mostram que stakeholders que têm mais poder têm uma maior atuação na cocriação e tendem a tomar decisões mais estruturadas durante o processo de cocriação (Iivari, 2010; Nakki et al., 2011; Power, 2010).

Diante disso, o framework teórico-conceitual da pesquisa (figura 35) apresenta uma representação esquemática das categorias que serão analisadas, bem como uma visão integradora sobre o fenômeno estudado, utilizado como um guia para a realização da pesquisa de campo (Miles, Huberman, & Saldana, 2014) .

Figura 35. Framework teórico-conceitual da pesquisa Nota. Fonte: Elaboração própria, 2019

A seguir será o apresentado o delineamento e o percurso metodológico aplicado na pesquisa de campo.

COCRIAÇÃO

PODER URGÊNCIA LEGITIMIDADE

Russo-Spena e Mele (2015) Goodman et al. (2011) Breidbach e Maglio (2016) Prahalad e Ramaswamy (2009) Zwass et al. (2010) Hoyer et al. (2010) Boaventura (2017) Aaltonen et al. (2008) Parent e Deephouse (2007) Lócus de Interação Padrão de Interação Qualidade de Interação Cond. Facilitadoras ou Limitadoras Saliência ATORES/ STAKEHOLDERS AÇÕES RECURSOS PAPÉIS

3 PROCEDIMENTOS METODOLÓGICOS

A construção do percurso metodológico desta pesquisa consiste num encadeamento entre a filosofia da pesquisa e o desenvolvimento do método para operacionalização da pesquisa de campo. Ao construir o desenho da pesquisa, é aconselhável começar refletindo sobre as crenças e pressupostos que geram a filosofia adotada pela pesquisadora. Em seguida