• Nenhum resultado encontrado

Em continuidade as etapas anteriores, foi desenvolvida uma proposta de Guia de

Referência. Ele foi estruturado da seguinte forma:

• Apresentação dos dados da autora;

• Descrição das etapas realizadas para o desenvolvimento do Guia;

• Apresentação da lista dos requisitos e suas descrições;

• Apresentação dos processos relacionados a cada um dos requisitos, e em cada

processo, a sua melhor prática (de acordo com a norma ou modelo sugerida

no mapeamento).

O Guia de Referência encontra-se disponível na Internet através do link

http://www.gsigma.ufsc.br/~cancian/guide/, que possui, além da sua visualização on-line, a

opção de download. Esta opção gera o Guia no formato de uma apostila. O Guia proposto

completo é apresentado no Apêndice G deste documento.

O Guia foi criado em inglês por alguns motivos:

• Abrangência de sua utilização;

• Publicação do Guia em artigos científicos de eventos internacionais;

• Restrições, principalmente da norma ISO/IEC, da publicação da sua tradução.

Inicialmente, a página web apresenta informações Gerais sobre Guia e sobre a autora.

Apresenta também informações para a sua utilização conforme ilustra a Figura 31.

Figura 31. Página principal do Guia (na versão online).

A lista dos requisitos e suas descrições são apresenta a seguir.

Figura 32. Lista com os requisitos e suas descrições.

O Guia possui os requisitos de qualidade vinculados as práticas geradas no

Mapeamento, e para cada prática, o Guia apresenta um conjunto de práticas-base para o

processo, fornecendo uma definição das tarefas e atividades necessárias à realização do

processo e cumprir o objetivo processo resultados.

As fontes das práticas desta versão preliminar do Guia são as seguintes (conforme

especificado no Mapeamento):

• ISO/IEC 15504 (ISO/IEC, 2006);

• CMMI for Services (TEAM, 2008); e

• COBIT (ISACA, 2008).

Na descrição das práticas, é informado de qual dessas fontes a informação é

proveniente.

O Guia apresenta duas formas de navegação entre os dados:

Navegação pelos requisitos: escolhendo um requisitos, são listadas as práticas

relacionadas a ele juntamente com a sua importância; e a descrição das práticas. A Figura

33 apresenta um exemplo de requisitos com as práticas relacionadas. Neste exemplo, o

requisito “Acquisition” que foi classificado como “Quality requirements related to the

importância, conforme realizado com os especialistas no mapeamento. Clicando em cada

uma delas, é apresentada a descrição do item, de acordo com a sua fonte.

Figura 33. Apresentação das práticas de um requisito.

Navegação pelas práticas: escolhendo uma prática, são listados todos os requisitos

que estão relacionados a ele, com a sua importância. Neste caso, a prática também

apresenta a descrição para a implementação. A Figura 34 ilustra um exemplo deste caso.

Nesta navegação, escolhe-se a prática associada e verifica-se quais requisitos necessitam

da sua verificação. No exemplo, a prática “Acquisition preparation” é necessária para

satisfazer quatro requisitos: Reliability, Performance, Availability e Acquisition.

Figura 34. Navegação pelas práticas.

Na tabela a seguir é apresentada uma descrição completa de prática de um dos

processos. Este caso é o “Acquisition preparation”, onde as informações desta prática são

as seguintes:

• Process ID, Process Name, Process Purpose, Process Outcomes, Base

Practices e Work Products. Este exemplo foi extraído da fonte: ISO/IEC

15504.

The Acquisition Process Group (ACQ)

ACQ.1 Acquisition preparation

Process ID

ACQ.1

Process Name

Acquisition preparation

Process Purpose

The purpose of the Acquisition preparation process is to establish the needs and goals of

the

acquisition and to communicate these with the potential suppliers.

Process Outcomes

As a result of successful implementation of Acquisition preparation process:

1) the concept or the need for the acquisition, development, or enhancement is

established;

2) the needed acquisition requirements defining the project needs are defined and

validated;

3) the customer’s known requirements are defined and validated;

4) an acquisition strategy is developed; and

5) supplier selection criteria are defined.

Base Practices

ACQ.1.BP1: Establish the need. Establish a need to acquire, develop, or enhance a

system,

software product or service. [Outcome: 1]

ACQ.1.BP2: Define the requirements. Identify the customer / stakeholder

requirements,

including acceptance criteria, for a system and/or software product or service. [Outcome:

2, 3]

ACQ.1.BP3: Review requirements. Analyze and validate the defined requirements

against the

identified needs. Validate the requirements to reduce risk of misunderstanding by the

potential

suppliers. [Outcome: 3]

ACQ.1.BP4: Develop acquisition strategy. Develop a strategy for the acquisition of the

product according to the acquisition needs. [Outcome: 4]

NOTE: The strategy may include reference to the life cycle model, schedule, budget and

selection criteria.

ACQ.1.BP5: Define selection criteria. Establish and agree on supplier selection criteria

and the

means of evaluation to be used. [Outcome: 4, 5]

ACQ.1.BP6 Communicate the need. Communicate the need for acquisition to

interested

parties through the identified channels. [Purpose; Outcome: 1]

Work Products

Inputs

Outputs

05-02 Business Goals [Outcome: 1]

08-02 Acquisition plan [Outcome: 4]

12-01 Request for proposal [Outcome: 4, 5]

13-19 Review record [Outcome: 3]

15-01 Analysis report [Outcome: 1, 2]

15-04 Market analysis report [Outcome: 2]

15-19 Product needs assessment [Outcome: 1, 3, 4]

15-19 Product needs assessment [Outcome: 2, 3]

17-03 Customer requirements [Outcome: 3]

17-09 Product requirements [Outcome: 3]

17-10 Service requirements [Outcome: 3]

18-01 Acceptance criteria [Outcome: 2, 4]

18-08 Supplier selection criteria [Outcome: 5]

Source: ISO/IEC 15504

(ISO/IEC. International Organization for Standardization and International Electrotechnical Commission,

ISO/IEC 15504-5: Information Technology - Process Assessment. Genebra. 2006)

Tabela 9. Descrição completa da ACQ.1 Acquisition preparation

Fonte: (ISO/IEC, 2006)

O Guia pode ser usado para avaliar o processo de desenvolvimento de software de

qualquer empresa que venha prover serviços no modelo SaaS. Um exemplo são os

provedores de serviços para as Federações de Serviços de Software, ambiente este que foi

descrito neste trabalho.

5 Conclusões

O objetivo principal desse trabalho foi desenvolver uma proposta de Guia de

Referência para avaliação do processo de desenvolvimento de software de provedores de

serviços no modelo SaaS. Uma aplicação sugerida neste trabalho para aplicação deste Guia

foi a Federação de Serviços de Software.

Para a realização desse objetivo foi realizada uma revisão da literatura para dar o

embasamento dos assuntos que envolvem o cenário deste trabalho e um levantamento dos

trabalhos correlatos. Essa pesquisa, além de definir os conceitos relevantes a este trabalho,

apresentou alguns dos trabalhos que estão sendo desenvolvidos, expondo o que é

atualmente feito neste campo. Esta etapa também possibilitou a criação de um modelo

genérico de SLA para auxiliar os usuários em sua utilização.

Uma pesquisa com uma série de profissionais foi realizada para levantamento dos

Requisitos de Qualidade a serem verificados de possíveis provedores no modelo SaaS, e

nessas entrevistas o conceito de Federações de Serviços de Software foi introduzido. Aqui

já foi possível vislumbrar os principais requisitos a serem verificados dos provedores.

Para aumentar a abrangência desses Requisitos elicitados, uma pesquisa foi realizada

com participantes do Brasil e do exterior, visando a complementação e priorização dessa

lista de requisitos. Além disso, opiniões dos participantes da pesquisas foram coletadas e

contribuíram para o andamento deste trabalho.

Um Mapeamento desses requisitos frente a normas e modelos existentes foi realizado

com especialistas para a verificação de cobertura desses requisitos. Nesta etapa uma série

de necessidades foi identificada, como a de aprofundar o estudo de diversos requisitos e

após isso, rever o seu mapeamento. Nesta etapa também foi verificado que os processos da

norma ISO/IEC 15504 abrangem grande parte dos requisitos elicitados, porém, este estudo

possibilitou a visualização dos processos realmente necessários e a relevância de cada um

deles no modelo SaaS.

Com isso, uma proposta de Guia de Referência preliminar foi elaborado para ser

utilizado na verificação de possíveis fornecedores de serviços no cenário SaaS, conforme

objetivo principal deste trabalho. Além do documento textual, uma versão web do Guia foi

disponibilizado para facilitar o acesso.

Como a pesquisa apresentada nesta dissertação é exploratória, e o Guia apresentado

neste trabalho ainda é uma versão preliminar, não foi possível realizar uma validação

formal ou mesmo avaliação científica. Neste caso, esta autora contactou os seis

entrevistados inicialmente neste trabalho, com o objetivo de obter informações sobre as

expectativas dos entrevistados, para utilizarmos essa informação na continuidade deste

trabalho. Esta autora fez contato via e-mail e telefone com os seis entrevistados, que então

acessaram a versão online o Guia na Internet. Algumas perguntas foram realizadas, mas a

de maior importância era a pergunta de pesquisa deste trabalho: “O Guia de Referência

proposto para a avaliação do processo de desenvolvimento de software de provedores de

serviços pode trazer maior confiabilidade na contratação de seus serviços?”. Quatro

pessoas responderam as perguntas. Das quatro respostas, três confirmaram a pergunta de

pesquisa e um entrevistado optou em “parcialmente sim, na maioria dos casos”.

Todas as perguntas e respostas desse contato com os entrevistados estão descritos no

Apêndice H.

A oferta de serviços com qualidade assegurada no âmbito do modelo SaaS pode

impulsionar a sua aceitação e aprovação numa escala maior, e a procura de serviços com

qualidade tende a aumentar ainda mais. Este Guia pode ser visto como uma contribuição

para alavancar a criação e sustentabilidade de inúmeras empresas. Desta forma, em

seguida, pode-se expandir seus mercados e, ao mesmo tempo os clientes SaaS podem

ganhar mais confiança na seleção dos fornecedores, utilizando o levantamento de

requisitos realizado neste trabalho.

O Guia elaborado neste trabalho pode ser utilizado para avaliação do processo de

desenvolvimento de software dos provedores no contexto de uma Federação de Serviços de

Software como também pode ser utilizado para avaliação de um provedor por um cliente-

final.

No decorrer das etapas deste trabalho, notou-se a complexidade de alguns passos, em

nível de importância, quantidade de material disponível e informações para serem

avaliadas. Foi o caso do Mapeamento dos Requisitos e da necessidade de criação e

adaptação da melhores práticas.

Para a continuidade do trabalho aqui proposto e cumprimentos dos objetivos

principais, essas necessidades foram registradas e são apresentadas na seção de trabalhos

futuros. Isso fez com que o presente trabalho apresentasse uma versão ainda preliminar do

Guia de Referência, mas nos deu subsídios para identificar os pontos fracos e faltantes e

programar a continuidade deste trabalho em pesquisas futuras.

O Guia de Referencia desenvolvido neste trabalho apesar de ser uma versão

preliminar, possui uma estrutura que permite a sua pronta implementação, e isso pode

servir como um instrumento de ajuda aos clientes em termos de confiança quando do uso

dos serviços de provedores diversos e desconhecidos. Seu desenvolvimento seguiu uma

metodologia bem definida, conforme descrito neste texto. Pretende-se em breve validar o

Guia nos moldes da IEEE (IEEE 1998), avaliando, por exemplo, sua corretude,

completude e consistência. Mas antes disso, pretende-se disponibilizar uma versão do

Guia mais avançada, principalmente com as necessidades identificadas na etapa do

Mapeamento (explicitadas nas sugestões de trabalhos futuros).

Os resultados apresentados neste documento representam um passo importante na

customização de um guia de referência de processo de software para provedores de

serviços identificando os requisitos de qualidade a serem atendidos num cenário SaaS.

Documentos relacionados