Prova de Conceito (POC)

PREGÃO ELETRÔNICO Nº 34/2022

Processo Digital nº 398/2021

1. Introdução

A prova de conceito será aplicada para avaliar a proficiência das empresas

qualificadas e terá caráter eliminatório. As empresas qualificadas deverão executar
as atividades solicitadas, seguindo os parâmetros descritos no memorial descritivo.

Todas as atividades da POC deverão ser realizadas sob supervisão das equipes
técnicas do DITI, presencial ou remotamente. Caso a licitante opte por executar a
POC nas instalações da ALESP, esta fornecerá o espaço adequado, mesas, pontos
de energia e de rede. Os computadores e demais equipamentos necessários à
execução da POC ficarão a carga da empresa.

A equipe técnica responsável pela avaliação será a Divisão de Tecnologia da

Informação (DTI), juntamente com analistas indicados pelo Departamento de
Inovação e Tecnologia da Informação (DITI).

A ordem de avaliação da POC será a ordem de classificação das empresas

qualificadas respectivamente aos lotes "Lote 1 - Fábrica de Software" e "Lote 2 -
Fábrica de Métricas", ou seja, a primeira colocada no certame, em cada um dos
lotes licitados, terá suas entregas da POC avaliadas e, caso não seja aprovada, esta
será eliminada do processo licitatório, passando a avaliação da comissão à segunda
colocada em relação ao respectivo lote. Esse processo se repetirá até que uma das
empresas seja considerada habilitada pela equipe técnica que julgará a POC.

Não faz parte da POC o fornecimento de nenhuma ferramenta de apoio à

metodologia.

2. Cenário da Prova de Conceito

A Divisão de Tecnologia da Informação (DTI) necessita melhorar o seu processo de

recebimento e controle de demandas para desenvolvimento de sistemas para as
áreas de negócio da ALESP. Atualmente, essas demandas chegam à DTI por meio
de um formulário (ANEXO I - modelo) em papel preenchido e assinado pelo
responsável da área demandante.

Qualquer servidor da casa pode preencher o referido formulário, mas somente os

responsáveis pela UA de lotação do servidor podem assinar, autorizando e dando
ciência da demanda encaminhada.
 Depois de recebida a demanda em papel, a solicitação é encaminhada às equipes
técnicas da DTI para que seja elaborado um parecer técnico (modelo no ANEXO II)
no qual é realizada uma análise de viabilidade técnica e, em caso de viabilidade, um
planejamento com prazos e esforço é elaborado e respondido ao solicitante.

Com o objetivo melhorar o controle e digitalizar esse processo, a DTI irá desenvolver
um sistema que ficará disponível na intranet para as áreas registrarem e
encaminharem suas demandas de serviços de sistemas. As características macros
(requisitos) que tal sistema deverá atender estão descritos na Tabela 1.

# DESCRIÇÃO DO REQUISITO

01 O sistema deverá possuir acesso restrito mediante processo de login, com

fornecimento de usuário e senha.

02 O sistema deve permitir a qualquer usuário enviar uma solicitação de demanda

de desenvolvimento/manutenção de sistemas para a DTI mediante aprovação
do responsável pela UA do solicitante

03 O sistema deve permitir que os responsáveis das UAs autorizem (ou não) as
demandas registradas por servidores de suas UAs.

04 O sistema deve permitir ao responsável pela DTI receber a demanda

encaminhada pelas áreas da Alesp e distribuir para uma das equipes técnicas
elaborarem o parecer técnico. O responsável pela DTI também deve poder
devolver a solicitação ao solicitante para ajustes.

05 O sistema deve permitir aos líderes das equipes técnicas elaborarem o parecer
técnico e enviá-lo ao solicitante, após a aprovação pelo responsável da DTI.

06 O sistema deve permitir ao solicitante da demanda aprovar o parecer técnico

elaborado pelas equipes técnicas da DTI.

07 O sistema deve enviar email a cada nova ação/andamento da solicitação para o

solicitante e para o responsável pela DTI.

08 O sistema deve permitir que o solicitante exclua uma solicitação a qualquer

momento. A exclusão deverá ser lógica para efeito de histórico.

09 O sistema deve pode ser acessado pelos seguintes navegadores: Chrome e

Firefox nas versões mais recentes.

10 O sistema deve permitir imprimir tanto a solicitação de demanda quanto o

parecer técnico.

11 O sistema deve disponibilizar consulta das demandas registradas, bem como

 todo o histórico de andamentos.

12 As demandas registradas devem possuir um status com os seguintes possíveis

valores:

 Nova
 Aprovada Solicitante
 Recebida pela DTI
 Devolvida para Solicitante
 Elaboração de Parecer Técnico
 Parecer Aprovado DTI
 Parecer Aprovado Solicitante
 Excluída

13 Os usuários poderão ter um dos seguintes perfis:

 Usuário comum: pode registrar uma solicitação e aprovar o parecer

técnico dela, além de excluir aquelas solicitações registradas por ele
 Responsável pela UA: pode aprovar as solicitações enviadas pelos
usuários da sua UA
 Responsável pela DTI: pode receber solicitações das áreas, encaminhar
para as equipes técnicas e aprovar os pareceres técnicos elaborados.
 Equipe técnica: elabora os pareceres técnicos de uma solicitação

Tabela 1 – Requisitos do sistema

2.1. Diretrizes técnicas

O sistema a ser desenvolvido deve conter dois módulos:

 Back end: API REST utilizando Spring Boot.
 Front end: Single page application utilizando Angular.

Diretivas Arquitetura:
 Java: versão LTS no momento do início da POC
 Angular: versão LTS no momento do início da POC
 Seguir as instruções para criação de aplicações descritas na documentação
de “Padrões para criação e configuração de aplicações no ambiente ALESP”
disponibilizada pela equipe de arquitetura.
 Conter documentação de métodos e funcionalidades no código fonte

3. Escopo, artefatos e prazos

3.1 Escopo da POC - "Lote 1 - Fábrica de Software"

As seguintes etapas deverão ser executadas:

A. Análise de Negócio
B. Requisitos
 C. Projeto
D. Codificação
E. Testes
F. Implantação

3.2 Artefatos da POC - "Lote 1 - Fábrica de Software"

Os seguintes artefatos deverão ser entregues pela empresa qualificada, no âmbito e

escopo da POC:

A. Análise de Negócio
 DMPN – Diagrama Macro dos Processos
B. Requisitos
 REQ – Documento de Especificação de Requisitos
 MCU – Modelo de Casos de Uso
 PRO – Protótipos de Telas
C. Projeto
 ARQ – Documento de Arquitetura
 MBDL – Modelo de Banco de Dados Físico
 DCLS – Diagrama de Classes
 EBD – Especificação de Banco de Dados
D. Codificação
 CFS – Código Fonte do Sistema
 PTU – Plano de Testes Unitários
 ETU – Evidência de Testes Unitários
E. Teste
 PTF – Plano de Testes Funcional
 CTF – Casos de Teste
 MDT – Massa de Dados para Testes
F. Implantação
 PIP – Plano de Implantação em Produção
 Sistema executando em ambiente próprio, configurado pela empresa
qualificada.
 Deverá ser executado em ambiente da ALESP, e seguir as diretivas da
equipe de arquitetura
G. Contagem estimada de tamanho funcional da solução desenvolvida na POC

3.3 Prazo para a execução da POC - "Lote 1 - Fábrica de Software"

15 dias úteis.

3.4 Escopo da POC - "Lote 2 - Fábrica de Métricas"

Contagem estimada de tamanho de software da proposta da POC, baseada no

cenário descrito. Serão disponibilizados pela ALESP à licitante os seguintes
artefatos e/ou informações para mensuração do tamanho funcional de solução.:
 DMPN – Diagrama Macro de Processos de Negócio
REQ – Documento de Especificação de Requisitos
MCU – Modelo de Casos de Uso
PRO – Protótipos de Tela
MBDF – Modelo de Banco de Dados Físico

3.5 Artefato da POC - "Lote 2 - Fábrica de Métricas"

 Documentação da Fronteira da Aplicação

 Documentação da Contagem com Rastreabilidade para Requisitos
 Documentação das Funcionalidades Identificadas
 Planilha de contagem de pontos de função da proposta da POC.

3.6 Prazo para a execução da POC - "Lote 2 - Fábrica de Métricas"

2 dias úteis.

4. Critérios de avaliação para o Lote 1

Serão avaliados os 16 artefatos entregues sobre os quais serão atribuídas as notas

de 0 (zero) a 5 (cinco). Cada artefato terá um peso cujo fator multiplicador está na
Tabela 2.

Artefato Peso Pontos

máximos
DMPN – Diagrama Macro dos Processos 1 5
REQ – Documento de Especificação de Requisitos 2 10
MCU – Modelo de Casos de Uso 3 15
PRO – Protótipos de Telas 1 10
ARQ – Documento de Arquitetura 2 10
MBDF – Modelo de Banco de Dados Físico 3 15
DCLS – Diagrama de Classes 1 5
EBD – Especificação de Banco de Dados 1 5
CFS – Código Fonte do Sistema 3 15
PTU – Plano de Testes Unitários 1 5
ETU – Evidência de Testes Unitários 1 5
PTF – Plano de Testes Funcional 2 10
CTF – Casos de Teste 2 10
MDT – Massa de Dados para Testes 1 5
PIP – Plano de Implantação em Produção 1 5
PLANILHA DE CONTAGEM - PONTOS DE FUNÇÃO 1 10
TOTAL - Entregáveis 140

Tabela 2 - Pesos aplicados a cada um dos artefatos a serem entregues

Para a avaliação dos artefatos, serão considerados um ou mais dos seguintes

aspectos, de acordo com natureza do artefato:
  Adequação do artefato aos modelos e padrões mais utilizados na Engenharia de
Software pelo mercado
 Completude: o artefato deverá ser entregue o mais completo possível
 Organização e clareza
 Gramática/ortografia

Para a avaliação do código-fonte entregue, serão considerados os seguintes critérios:

 Tamanho (quantidade de linhas, de classes, de métodos, etc.)
 Organização (simplicidade, coesão, dependência, limpeza, redundância, etc.)
 Convenções adotadas para nomeação
 Documentação
 Padrões de projeto utilizados
 Manutenibilidade

Para avaliação da Planilha de Contagem dos Pontos de Função, serão verificadas se

foram seguidas as melhores práticas em contagem de pontos de função da página 88
do Roteiro de Métricas de Software do SISP – Versão 2.3

Importante: serão considerados os artefatos entregues e que serão

submetidos à avaliação e validação do DITI somente aqueles constantes no
repositório Git, em sua última versão submetida (“comittada”). Qualquer
outra forma de entrega (email, pasta na rede, pendrives etc.,) será
desconsiderada.

Juntamente com os artefatos entregues, será realizada também uma avaliação funcional
do sistema entregue que valerá 70 (setenta) pontos. Para a avaliação funcional do
sistema implantado no ambiente de testes, serão considerados os critérios – valendo 10
(dez) pontos cada – descritos na Tabela 3, juntamente com seus respectivos pesos:

Critério – avaliação funcional Peso Pontos

máximos
Usabilidade 1 10
Design 1 10
Atendimento aos requisitos especificados * 2 20
Quantidade de erros encontrados 2 20
Desempenho 1 10
TOTAL 70

Tabela 3 - Critérios e respectivos pesos da avaliação funcional

* Cada requisito constante da Tabela 1 que for atendido no sistema entregue valerá 1
(um ponto) para efeito da nota final deste critério. Serão descartadas as 3 (três)
menores notas, totalizando os 10 (dez) pontos máximos do critério.
 Para ser habilitada, a empresa deve obter 90 (noventa) ou mais pontos em
relação aos artefatos e 50 (cinquenta) ou mais pontos em relação ao sistema
entregue na avaliação funcional.

5. Critérios de avaliação para o Lote 2

A avaliação para o Lote 2 será na sua maior parte baseada nas considerações
encontradas no tópico “MELHORES PRÁTICAS EM CONTAGEM DE PONTOS DE
FUNÇÃO” do Anexo IV do Roteiro de Métricas de Software do SISP – Versão 2.3.

Serão avaliados 3 artefatos entregues sobre os quais serão atribuídas as notas de 0

(zero) a 5 (cinco). Cada artefato terá um peso cujo fator multiplicador está na Tabela
4. Os artefatos são:

 Documentação da Fronteira da Aplicação.

Texto com sua concepção da fronteira considerada nesta contagem de Pontos
de Função.

 Documentação da Contagem com Rastreabilidade para Requisitos.

Vide Anexo IV do Roteiro de Métricas de Software do SISP – Versão 2.3.

 Documentação das Funcionalidades Identificadas.

Vide Anexo IV do Roteiro de Métricas de Software do SISP – Versão 2.3.

ARTEFATO PESO PONTOS MÁXIMOS

Documentação da Fronteira da Aplicação 1 5
Documentação da Contagem com 5 25
Rastreabilidade para Requisitos
Documentação das Funcionalidades Identificadas 2 10

TOTAL - Entregáveis 40

Tabela 4 - Pesos aplicados a cada um dos artefatos a serem entregues

Para a avaliação dos artefatos, serão considerados um ou mais dos seguintes

aspectos, de acordo com natureza do artefato:

 Adequação do artefato ao Manual de Práticas de Contagem (CPM) versão

4.3.1 (ou superior) do IFPUG e ao Roteiro de Métricas do SISP.
 Completude: o artefato deverá ser entregue o mais completo possível
 Organização e clareza
 Gramática/ortografia
 Juntamente com os artefatos entregues, será realizada também uma avaliação do
valor final da contagem dos Pontos de Função realizada pela licitante, que deverá
ser entregue formalmente documentada pelo seguinte artefato:

 Planilha de contagem de pontos de função

Planilha contendo a estimativa de contagem de pontos de função do software
descrito e especificado no cenário da POC

A nota para a contagem da licitante seguirá a seguinte regra, onde CL é a contagem

da licitante e CA é a contagem a ser realizada pela ALESP:

Contagem de Nota para contagem

Pontos de Função da licitante
CL < CA 50 * (CL / CA)
CL = CA 50
CL > CA 50 * [2 - (CL / CA)]

Tabela 5 – Cálculo da nota da planilha de contagem de PFs

Obs.: No caso de uma contagem da licitante maior que o dobro da contagem da

ALESP, a nota da contagem da licitante será zero.

Para ser habilitada, a empresa deve obter 30 (trinta) ou mais pontos em relação
aos artefatos e 35 (trinta e cinco) ou mais pontos em relação à contagem dos
Pontos de Função.

OBSERVAÇÕES:

Para registro da contagem de Pontos de Função, a planilha a ser utilizada deverá

conter MINIMAMENTE as seguintes colunas:
 Função (de dados ou de transação)
 Tipo da função (ALI, AIE, EE, SE, CE)
 Complexidade
 Número de pontos da função

Outras colunas, bem como outros objetos que agreguem valor à documentação da
contagem serão benvindos.

6. Ambiente tecnológico

As tecnologias e ferramentas a serem utilizadas são as seguintes:

 Linguagem de programação: Java, TypeScript e Angular;
 Servidor de aplicação: Tomcat - embeded do SpringBoot;
 Servidor HTTP: NGINX para aplicações angular;
 Banco de Dados: Oracle 11;
  Frameworks de programação: SpringBoot, Hibernate, e Bootstrap (versão latest);
 Ferramentas DevOps: Docker, Docker Swarm e Maven;
 Ferramentas de versionamento: Git / Gitlab;
 Ferramentas de desenvolvimento: Eclipse STS e/ou VSCode.

Serão disponibilizados os seguintes ambientes para a equipe da empresa que irá

executar a POC:

 Schema de banco de dados Oracle 11g – ambiente de desenvolvimento;

 Docker Swarm;
 Ambiente / projeto no servidor Gitlab (repositório de artefatos e código).

Observações:

1) A instalação e configuração do container Docker no ambiente disponibilizado

pela Alesp é de responsabilidade da empresa;
2) A Alesp disponibilizará equipe técnica para eventuais consultas e mitigação de
dúvidas – técnicas e de negócio – por parte da empresa durante o período da
POC diariamente das 13h00 as 19h00.
3) O horário de execução da POC nas instalações da Alesp será das 09h00 as
19h00.
4) A equipe da empresa ficará alocada exclusivamente em sala indicada pelo
DITI e ficará responsável, durante o período e horário de execução da POC,
pelos eventuais equipamentos que trouxerem para a Alesp. Um dos
colaboradores ficará com 1 (uma) cópia das chaves das portas que dão
acesso à referida sala e responderá por qualquer dano causado à Alesp por
qualquer membro da equipe da empresa.
5) Contatos no DITI para dúvidas ou problemas:
a. Gestão: Kasuo (DTI), ramal 6685 kaoyanagi@al.sp.gov.br
b. Negócio: Frederico (DITI), ramal 6448 fbortolato@al.sp.gov.br
c. Banco de Dados: Claudio Duarte (DAI), ramal 6675
cduarte@al.sp.gov.br
d. Gitlab e Docker Swarm: Fernando Crespo (DTI), ramal 6685
arquitetura@al.sp.gov.br
 ANEXO I

Formulário de Solicitação de Sistemas e Serviços

Nome do sistema

1. Identificação do solicitante

UA Ramal

Responsável Mat.

2. Assinale com X o tipo de solicitação:

 Alteração/Melhoria em sistema já existente

 Desenvolvimento de novo sistema
Descreva, de forma detalhada, qual a alteração/melhoria desejada para o sistema já existente
ou descreva, de forma detalhada, o que o sistema precisa ou deve fazer.

Justificativa: Cite os principais benefícios a serem atingidos com este sistema / serviço.

São Paulo, de de .

__________________________________________________
Nome / Assinatura do responsável pela Unidade Administrativa
 ANEXO II

Parecer Técnico
Nome do sistema

1. Identificação do solicitante

UA Ramal

Responsável Mat.

No. Protocolo Data

2. Identificação da solicitação

3. Análise da solicitação

4. Estimativas de Esforço e Prazo