Pregão Eletrônico nº 18/2014
Ferramenta de Apoio ao Núcleo de Métricas de Software
PoC – Prova de Conceito
Ferramenta: APFBR
1
CRITÉRIOS EDITALÍCIOS PARA A REALIZAÇÃO DA PROVA DE CONCEITO (CÓPIA DO
TERMO DE REFERÊNCIA):
10.2 DA VERIFICAÇÃO DE CONFORMIDADE (AMOSTRAS)
10.2.1. Para esta aquisição, será necessária a verificação de conformidades da ferramenta
proposta por meio de realização de uma PoC;
10.2.2. Caberá à empresa primeira colocada, no prazo de 5 (cinco) dias úteis após a
convocação do BRB, demonstrar todas as funcionalidades exigidas para o software por meio de
uma Prova de Conceito (PoC) a ser realizada no ambiente do BRB, sendo homologada como
vencedora caso o resultado da PoC seja satisfatório, ou seja, demonstre que todos os
requisitos do software definidos na especificação foram atendidos e funcionalmente
demonstrados;
10.2.3. Prevê-se que a PoC será realizada em um único dia, iniciando às 14 horas. Caso não
seja possível, a PoC será retomada no próximo dia útil ao início e assim, sucessivamente, até a
conclusão;
10.2.4. Deverão participar da PoC recurso(s) técnico(s) da empresa, com total domínio técnico
e conceitual da ferramenta e um representante legal que deverá assinar, em nome da
empresa, o Relatório da Prova de Conceito e, pelo BRB, servidor(es) técnico(s) da Diretoria de
Tecnologia que será(ão) responsável(is) pela análise do software e pelo ateste de atendimento
aos requisitos definidos neste termo;
10.2.5. Todos os requisitos técnicos e funcionais definidos neste Termo de Referência serão
objeto de avaliação desta PoC e deverão ser demonstrados e executados satisfatoriamente;
10.2.6. Caso algum requisito não seja devidamente demonstrado e comprovado, a empresa
terá o prazo de um dia útil para adequação da ferramenta. Este prazo será dado por uma única
vez e não poderá ser estendido. A PoC será retomada às 09 horas do dia útil subsequente, e
caso algum requisito
não seja devidamente demostrado e comprovado caracterizará a
incompatibilidade do produto com as exigências deste Termo de Referência;
10.2.7. A presença de falhas cosméticas, ou seja, falhas que não comprometem os requisitos
técnicos e funcionais do sistema não caracterizam a incompatibilidade do produto. Como
exemplos podemos citar: labels ou mensagens com erros de grafia; falhas de
formatação/máscara de campos;
10.2.8. A presença de bug/defeito em funcionalidade que, teoricamente, atenda a determinado
requisito funcional caracteriza que o requisito não foi atendido e, consequentemente, a
incompatibilidade do produto;
10.2.9. Caso a licitante classificada não comprove a compatibilidade do produto com as
exigências especificadas, a empresa classificada imediatamente após será convocada para,
sucessivamente e em igual prazo, realizar a PoC, obedecendo aos mesmos critérios de
avaliação e homologação.
2
REQUISITOS, ORIENTAÇÕES E DADOS PARA TESTES
Caso não concordem com a data sugerida para realização da PoC, favor informar-nos para o
reagendamento.
Como foi esclarecido nos questionamentos que não há necessidade de uma instalação
completa da ferramenta no ambiente do BRB, admitiremos a PoC por meio de equipamentos
da licitante ou do BRB, sem haver prejuízo nas verificações exigidas no edital.
Para tanto, a empresa deverá informar com a maior brevidade possível em qual ambiente
deseja executar a PoC.
Caso a opção seja instalar a ferramenta no ambiente do BRB, deverão ser respeitadas as
regras abaixo:
•
Será disponibilizado um ponto de acesso à Internet para as funcionalidades que
necessitem de conexão.
•
Fica a cargo da empresa instalar a ferramenta no ambiente do BRB, que já se
encontra disponível, no prazo compreendido entre a convocação e o início da
PoC.
•
Caso a PoC se estenda por mais de um dia, ou seja necessário um dia útil para
adequação de alguma funcionalidade, o ambiente escolhido deverá ser mantido.
•
No caso de necessidade de utilização do dia útil para adequação da ferramenta,
a empresa deverá retornar com a versão adequada no horário previsto em
edital, e será disponibilizado o tempo necessário para a reinstalação da
ferramenta.
Caso a opção seja executar a PoC em um equipamento da licitante (notebook), deverão ser
respeitadas as regras abaixo:
•
Será disponibilizado um ponto de acesso à Internet para as funcionalidades que
necessitem de conexão.
•
Fica a cargo da empresa chegar ao início da PoC com a ferramenta devidamente
instalada no notebook. Será disponibilizado um datashow com entrada VGA.
•
Caso a PoC se estenda por mais de um dia, ou seja necessário um dia útil para
adequação de alguma funcionalidade, o ambiente escolhido deverá ser mantido.
•
No caso de necessidade de utilização do dia útil para adequação da ferramenta,
a empresa deverá retornar com a versão adequada no horário previsto em
edital, e será disponibilizado o tempo necessário para a reinstalação da
ferramenta.
Para atender às necessidades de negócio apontadas faz-se necessária uma ferramenta que
contemple:
1 - REQUISITOS DE NEGÓCIO:
3
Características funcionais:
Para atender às necessidades de negócio apontadas faz-se necessária uma Ferramenta de
Apoio à Métrica de Software que contemple os seguintes requisitos:
1.1 A ferramenta deverá permitir o controle de acesso (login) de usuários através de perfis
para se prover níveis de acesso diferenciados às funcionalidades da plataforma, sendo possível
a divisão em equipes.
Dados para teste e validação:
1. Cadastrar equipe “NUMEP”;
2. Criar um perfil “gerente” com nível de acesso gerencial e alocar na equipe “NUMEP”;
3. Criar um perfil “analista” de acesso comum e alocar na equipe “NUMEP”.
1.2 Cadastro de linguagens/tecnologias – A ferramenta deve possibilitar o cadastro de
linguagens/tecnologias de desenvolvimento com sua respectiva taxa de entrega para
associação às contagens.
Dados para teste e validação:
1. Cadastrar linguagem “JAVA” com taxa de entrega para projeto de desenvolvimento de
10 horas/PF e para projeto de melhoria de 5 horas/PF;
2. Cadastrar linguagem “COBOL” com taxa de entrega para projeto de desenvolvimento de
12 horas/PF e para projeto de melhoria de 10 horas/PF.
1.3 Cadastro de aplicações/baselines/fronteiras - A ferramenta deve possibilitar o cadastro de
aplicações (sistemas)/baselines/fronteiras.
Dados para teste e validação:
1. Cadastrar o sistema BKT com a linguagem “JAVA”;
2. Cadastrar o sistema COC com a linguagem “COBOL”.
1.4 Deverá permitir o cadastro de fases do projeto.
Dados para teste e validação:
1. Cadastrar a fase “Definição do sistema”;
2. Cadastrar a fase “Implantação”.
1.5 Deflator em Projetos de Melhoria - A ferramenta deve permitir o cadastramento de
deflatores a serem aplicados em Projetos de Melhoria para funcionalidades incluídas, alteradas
e excluídas.
Dados para teste e validação:
1. Cadastrar o deflator de Inclusão como 100%;
2. Cadastrar o deflator de Alteração como 50%;
3. Cadastrar o deflator de Exclusão como 20%.
1.6 Fator de Ajuste padrão (=1) - A ferramenta deve permitir definir o valor padrão do fator de
ajuste para todas as contagens.
4
1.
2.
3.
4.
5.
6.
7.
Dados para teste e validação:
Definir o Fator de Ajuste Padrão com o valor de “1,1”;
Criar uma nova contagem estimada do sistema BankNet do tipo “Aplicação”;
Não indicar a opção de “Atualizar o baseline”;
Inserir um Arquivo Lógico Interno;
Inserir uma Saída Externa;
Verificar se o valor da contagem foi de 13,2PF;
Definir o Fator de Ajuste Padrão com o valor de “1”.
1.7 Itens não mensuráveis (INM) - A ferramenta deve permitir o cadastramento customizável
de itens não mensuráveis padrão com respectivos pesos em PF para posterior uso e referência
em contagens de PF (Pontos de Função).
Dados para teste e validação:
1. Incluir o INM “Programas auxiliares” 0,40PF;
2. Incluir o INM “Camada de apresentação” 15% do total da demanda;
3. Incluir o INM “Code Table – Inclusão de tabela” 1PF.
1.8 - Contagem de Aplicação - A ferramenta deve possuir funcionalidade para contagem de
Aplicação segundo o IFPUG.
Dados para teste e validação:
1. Criar uma nova contagem do tipo Aplicação para o sistema COC;
2. Indicar a fase “Definição do Sistema”;
3. Inserir o número da demanda de acordo com a planilha COC 201401;
4. Indicar a opção de “Atualizar o baseline”;
5. Preencher as informações básicas da contagem APF;
6. Cadastrar contagem definida na planilha: Detalhada Aplicação COC 201401;
7. Cadastrar os Arquivos Lógicos antes das Funções de Transação, para utilizar os
Arquivos Lógicos que já estiverem cadastrados na contagem como AR's nas Funções
de Transação;
8. Resultado da contagem: 45PF.
1.9 - Contagem de Projetos de Melhoria - A ferramenta deve possuir funcionalidade para
contagem de Projetos de Melhoria segundo o IFPUG. Contagens de melhoria a partir da
baseline (aplicação) - A ferramenta deve possibilitar a realização de contagens de projeto de
melhoria a partir de uma contagem de aplicação (baseline), com o aproveitamento das funções
de dados e funções de transação já incorporadas pela baseline. Ao selecionar a inclusão de
uma nova análise de um sistema que já possua um baseline, a ferramenta deverá permitir a
recuperação destas funcionalidades de forma que todas as funcionalidades do baseline sirvam
de subsídio para a nova contagem, carregando automaticamente os campos de ALI, AIE, EE,
SE, CE, TD, TR e AR, evitando preencher manualmente dados já carregados/contados
anteriormente. Para cada contagem deve ser dada a opção de atualizar ou não o baseline da
aplicação. Integridade entre funções - A ferramenta deve permitir relacionar funções de
transação e arquivos de dados (arquivos referenciados, neste caso), bem como, os TD entre
funções de dado e de transação, possibilitando, ainda, a identificação deste relacionamento em
caso de tentativa de exclusão de algum TD de um arquivo referenciado em qualquer transação.
Em caso de tentativa de exclusão ou modificação de uma Função de Dados deverão ser
listadas todas as funções impactadas.
Dados para teste e validação:
1. Criar uma nova contagem do tipo Projeto de Melhoria para o sistema COC;
2. Indicar fase “Implantação”;
5
3.
4.
5.
6.
Inserir o mesmo número da demanda do item 1.8;
Preencher as informações básicas de uma contagem APF;
Cadastrar contagem definida na planilha: Detalhada Melhoria COC 201402;
Tentar excluir um ALI previamente cadastrado, que possua vínculo com pelo
menos uma função transacional para verificar se há a mensagem de alerta com
as transações impactadas;
7. Tentar alterar um ALI previamente cadastrado, que possua vínculo com pelo
menos uma função transacional para verificar se há a mensagem de alerta com
as transações impactadas;
8. Aproveitar uma função contada na contagem COC 201401, já incorporada ao
baseline, cadastrando-a com o impacto de ALTERAÇÃO;
9. Incluir funções de transacionais relacionando com arquivos de dados contados
na contagem COC 201401;
10. Indicar a opção de “Atualizar o baseline”;
11. Resultado da contagem: 9,5PF;
12. Verificar o baseline atualizado, inclusive se as funções, que foram adicionadas
com deflator, possuem seu valor bruto (Conferir com Planilha COC 201403).
1.10 – Estimativa NESMA - A ferramenta deve possibilitar a realização de uma contagem
ESTIMATIVA de acordo com a NESMA.
Dados para teste e validação:
1. Criar uma nova contagem do tipo Projeto de Desenvolvimento para o sistema
COC;
2. Indicar que se trata de uma estimativa NESMA;
3. Não indicar a opção de “Atualizar o baseline”;
4. Indicar fase “Definição do sistema”;
5. Cadastrar contagem definida na planilha: COC 201404
6. Resultado da contagem: 24,9PF.
1.11 - Contagem de Projetos de Desenvolvimento - A ferramenta deve possuir funcionalidade
para contagem de Projetos de Desenvolvimento segundo o IFPUG.
1.
2.
3.
4.
5.
6.
Dados para teste e validação:
Criar uma nova contagem do tipo Projeto de Desenvolvimento para o sistema
BKT;
Indicar fase “Implantação”;
Não indicar a opção de “Atualizar o baseline”;
Preencher as informações básicas de uma contagem APF;
Cadastrar contagem definida na planilha: BKT 201401, utilizando os itens não
mensuráveis previamente cadastrados;
Resultado da contagem: 24,4PF.
1.12 - Indicativa NESMA - A ferramenta deve possibilitar a realização de uma contagem
INDICATIVA de acordo com a NESMA.
Dados para teste e validação:
1. Criar uma nova contagem do tipo Projeto de Desenvolvimento para o sistema
BKT;
2. Indicar que se trata de uma indicativa NESMA;
3. Não indicar a opção de “Atualizar o baseline”;
6
4. Indicar fase “Definição do sistema”;
5. Cadastrar contagem definida na planilha: BKT 201402;
6. Resultado da contagem: 115PF.
1.13 - Contagem por fase do projeto - A ferramenta deve possibilitar a realização de contagens
por Fase do andamento do projeto (exemplo: pré-projeto, iniciação, elaboração, construção,
transição) e possibilitar a análise comparativa entre contagens.
•
Dados para teste e validação:
Realizar uma análise comparativa entre as contagens feitas nos itens 1.8 e 1.9;
1.14 - Detalhamento da contagem - A ferramenta deve permitir realizar o detalhamento da
contagem, identificando/descrevendo todos os TD (Tipos de Dados), TR (Tipos de Registro) e
AR (Arquivos Referenciados) apurados em cada função de dado ou transação.
•
Dados para teste e validação:
Na contagem do item 1.11, relacionar para cada função todos os TD, TR ou AR.
1.15 - Relatórios - A ferramenta deve possuir módulo para emissão de relatórios, tanto em tela
quanto impressos, sendo obrigatórios: um Relatório de Contagem (dados de uma contagem e
lista de funções com classificação e tamanho funcional de cada uma e o totalizador de PF); um
Relatório de contagens realizadas (identificação da contagem, do sistema, data, tipo da
contagem, quantidade de pontos de função, …)
1.16 - Estimativa de prazo e esforço – A ferramenta deve possuir mecanismo que permita a
estimativa de prazo e esforço baseada no volume de Pontos de Função estimados/contados em
determinada contagem, possibilitando, ainda, o cadastramento e parametrização de taxas de
entrega (horas/PF) por tecnologia e por tipo de contagem (desenvolvimento e melhoria).
Dados para teste e validação:
• Verificar a estimativa de prazo para a contagem realizada no item 1.9 (segunda
contagem), de acordo com a produtividade cadastrada para a linguagem do
sistema
1.17 - Assistente de identificação e classificação de funções de dado e transação – A
ferramenta deve possuir mecanismo que auxilie o contador, opcionalmente, a identificar e
classificar, de forma dirigida, as funções de dado e transação por meio da aplicação dos
conceitos, regras e questões definidos pelo IFPUG, no Manual de Práticas e Contagem, em
mecanismo dirigido, por exemplo: do tipo passo a passo/wizard. Exemplo: questões para
identificação de uma Entrada Externa:
I. O dado é recebido de fora da fronteira da aplicação?
II. O processo é a menor unidade de atividade na perspectiva do usuário?
III. O processo é autocontido e deixa o negócio em um estado consistente?
IV. Tem a intenção primária de manter um ou mais ALI?
1.18 - A ferramenta deve permitir a busca das contagens por aplicação, por tipo ou por
identificador da demanda.
1.19 - A ferramenta deve permitir a apresentação executiva (resumida) dos resultados da
7
contagem realizada, ou existente no sistema.
* Informações básicas de uma contagem APF: propósito da contagem, escopo da contagem,
fronteira, tipo de contagem (projeto de desenvolvimento, projeto de melhoria, ou contagem de
aplicação), método de contagem (detalhada segundo o IFPUG, estimativa NESMA, ou
indicativa NESMA), versão do CPM, código identificador da demanda e documentação utilizada
na análise (permitindo adicionar ou eliminar as referências das documentações utilizadas na
contagem).
2 - REQUISITOS DE SEGURANÇA:
2.1 - Geração de Informações para Auditoria
A solução deverá ser capaz de gerar uma trilha de auditoria, com pelo menos os seguintes
eventos: início e finalização da própria solução, históricos de acessos, eventos de negócio da
solução. A solução deverá armazenar no mínimo as seguintes informações na trilha de
auditoria: data e hora do evento, tipo do evento, identidade do usuário, resultado (sucesso ou
falha). Informações relevantes para o negócio.
Dados para teste e validação:
1. Adicionar uma função transacional qualquer à contagem do item 1.11 e verificar no LOG
se as ações realizadas estão presentes.
2. Verificar se a mudança no valor do Fator de Ajuste Padrão realizada no item 1.6 está
presente no LOG;
3. Verificar no LOG se o cadastro de deflatores realizado no item 1.5 está presente.
2.2 - A solução deverá prover ao administrador (ou outros usuários autorizados) a capacidade
de ler todas as informações das trilhas de auditoria. A solução deverá apresentar a trilha de
auditoria de modo que seja compreensível para o usuário.
Dados para teste e validação:
1. Logar com perfil de analista e verificar se é possível ler as informações de auditoria.
3 - REQUISITOS DE ARQUITETURA
3.1 - Hardware
Conforme especificado no item 4.1.3 - Plataforma Tecnológica Aberta INTEL/AMD
Modo de validação: Verificação se o processador utilizado é Intel ou AMD
3.2 - Software Básico Plataforma Software Livre
Servidor de Aplicações JBoss/Tomcat
Modo de validação: Verificação se o Servidor WEB é JBoss ou Apache/Tomcat
3.3 - Estações de Trabalho (No cliente)
Software Básico
a) Sistema Operacional : Windows XP Professional SP3 ou superior
Modo de validação: Verificação da versão do sistema operacional do cliente
3.4 - Navegador: Microsoft Internet Explorer 8.0, Mozilla Firefox 5.0 ou superior
Modo de validação: verificação do navegador web e sua versão
8
3.5 - Requisitos Adicionais
Todas as funcionalidades do software devem ser executadas via navegador web Internet
Explorer 8 e superior e Mozilla Firefox 20 e superior, sem a necessidade de instalação de
softwares na estação do usuário
Modo de validação: verificação do navegador web e sua versão
3.6 - Possuir interface gráfica em idioma português do Brasil para usuário final e para o
usuário administrador
Modo de validação: verificação da interface do sistema através do navegador web
RELATÓRIO DA PROVA DE CONCEITO
Produto avaliado: APFBR
Nome da Empresa classificada:
Data de realização da PoC: __/__/____
AVALIAÇÃO
REQUISITO (item)
APROVADO
Sim
Observação
Não
Funcionalidades
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
1.14
1.15
1.16
1.17
1.18
1.19
9
Segurança
2.1
2.2
Arquitetura
3.1
3.2
3.3
3.4
3.5
3.6
10