Pregão Eletrônico nº 18/2014

(1)

Pregão Eletrônico nº 18/2014

Ferramenta de Apoio ao Núcleo de Métricas de Software PoC – Prova de Conceito

Ferramenta: APFBR

(2)

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.

(3)

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:

(4)

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.

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.

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.

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.

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.

(5)

1. Definir o Fator de Ajuste Padrão com o valor de “1,1”;

2. Criar uma nova contagem estimada do sistema BankNet do tipo “Aplicação”;

3. Não indicar a opção de “Atualizar o baseline”;

4. Inserir um Arquivo Lógico Interno;

5. Inserir uma Saída Externa;

6. Verificar se o valor da contagem foi de 13,2PF;

7. 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).

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.

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.

1. Criar uma nova contagem do tipo Projeto de Melhoria para o sistema COC;

(6)

3. Inserir o mesmo número da demanda do item 1.8;

4. Preencher as informações básicas de uma contagem APF;

5. Cadastrar contagem definida na planilha: Detalhada Melhoria COC 201402;

6. 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.

1. Criar uma nova contagem do tipo Projeto de Desenvolvimento para o sistema COC;

2. Indicar que se trata de uma estimativa NESMA;

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. Criar uma nova contagem do tipo Projeto de Desenvolvimento para o sistema BKT;

2. Indicar fase “Implantação”;

4. Preencher as informações básicas de uma contagem APF;

5. Cadastrar contagem definida na planilha: BKT 201401, utilizando os itens não mensuráveis previamente cadastrados;

6. 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.

1. Criar uma nova contagem do tipo Projeto de Desenvolvimento para o sistema BKT;

2. Indicar que se trata de uma indicativa NESMA;

(7)

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.

• 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.

• 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).

• 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

(8)

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.

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.

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

(9)

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 Observação

Sim 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

(10)

Segurança 2.1

2.2

Arquitetura 3.1

3.2 3.3 3.4 3.5 3.6