ANEXO VI - DESCRIÇÃO DOS SERVIÇOS
ANEXO VI - DESCRIÇÃO DOS SERVIÇOS
ANEXO 01 – OBJETO
CONTRATAÇÃO DE PRESTAÇÃO DE SERVIÇOS TÉCNICOS DE DESENVOLVIMENTO DE NOVOS SISTEMAS E MANUTENÇÃO DE SISTEMAS DE INFORMAÇÃO DA CESAN, UTILIZANDO PRÁTICAS ÁGEIS.
ANEXO 02 - DESCRIÇÃO DOS SERVIÇOS
1. A contratação tem como objeto a “PRESTAÇÃO DE SERVIÇOS TÉCNICOS DE DESENVOLVIMENTO DE NOVOS SISTEMAS E MANUTENÇÃO DE SISTEMAS DE INFORMAÇÃO DA CESAN, UTILIZANDO PRÁTICAS ÁGEIS”.
2. A contratação terá vigência de 12 (doze) meses, prorrogáveis até que se atinja o limite legal de 05 (cinco) anos de contrato.
3. A contratação será consumida mediante Ordem de Serviço (OS), que será aberta sob demanda, com antecedência mínima de 30 (trinta) dias e contará com datas de início e término pré-definidas, e com o tipo de alocação dos postos de trabalho, que será preferencialmente a alocação remota. A OS será composta por postos de trabalho que formarão uma Equipe Técnica Dedicada (ETD). A ETD poderá ser composta por no mínimo dois e no máximo quatro postos de trabalho, com atuação dentro do horário convencional da CESAN, com produtividade mínima definida em Ponto de Função por posto de trabalho e remuneração por custo mensal de cada posto de trabalho que formará a ETD alocada na OS – podendo acontecer a medição a cada 30 (trinta) ou 60 (sessenta) dias, a critério da CESAN, conforme apuração dos níveis de serviço e também da frequência de cada posto de trabalho alocado na ETD.
3.1. A relação de entregáveis da OS será composta dos artefatos contidos no item 4 do ANEXO 02 - DESCRIÇÃO DOS SERVIÇOS.
4. A relação de entregáveis de cada OS será a composição abaixo:
4.1. Código fonte atualizado em repositório definido pela CESAN;
4.2. Funcionalidades do módulo em ambiente operacional;
4.3. Documentação conforme estabelecido pelo ANEXO 04 - PROCESSO DE DESENVOLVIMENTO DE PROJETO E DE MANUTENÇÃO DE SOFTWARE.
ANEXO 03 - ESPECIFICAÇÃO TÉCNICA DOS SERVIÇOS
1. METODOLOGIA E QUALIFICAÇÃO
1.1. Os serviços a serem contratados possuem natureza técnica e deverão ser prestados de forma continuada, segundo metodologia e abertura de ordem de serviços (conforme prazos estabelecidos).
1.2. A decisão pelo uso de metodologias ágeis no desenvolvimento de software se deve aos frequentes ciclos de planejamento, execução e entrega, com facilidade de adaptação e/ou mudança de requisitos, de forma que os produtos finais sejam o mais aderente às necessidades das áreas usuárias, mitigando riscos à finalização do projeto proposto que não possam ser contornados com a antecedência e agilidade necessária, se mostrando vantajoso em relação ao modelo de desenvolvimento tradicional.
1.3. Todos os artefatos gerados na prestação desse serviço serão de propriedade exclusiva da CESAN.
1.4. A CONTRATADA deverá prestar serviço de mão de obra especializada para desenvolvimento de software seguindo o processo definido no ANEXO 04 - PROCESSO DE DESENVOLVIMENTO DE PROJETO E DE MANUTENÇÃO DE SOFTWARE, que contempla a adoção de metodologias ágeis, com suas práticas e papéis de atuação, a exemplo de Extreme Programming (XP), Kanban e Scrum, respeitando o padrão definido pela CESAN.
1.4.1. Cada posto de trabalho que formará a equipe técnica da CONTRATADA deverá seguir a qualificação mínima dos profissionais especificada no item 2.3 do ANEXO 03 - ESPECIFICAÇÃO TÉCNICA DOS SERVIÇOS.
1.4.2. Os postos de trabalho que formarão equipe técnica da CONTRATADA deverão ser disponibilizados exclusivamente para atendimento da CESAN. A equipe técnica atuará nos papéis de desenvolvimento previstos nas metodologias dispostas no ANEXO 04 - PROCESSO DE DESENVOLVIMENTO DE PROJETO E DE MANUTENÇÃO DE SOFTWARE, enquanto os demais papéis serão desempenhados por empregados da CESAN.
1.4.2.1. Uma equipe técnica padrão corresponde a um conjunto de formado por 3 (três) postos de trabalho. Na abertura da Ordem de Serviço ou durante a execução dos serviços, a equipe técnica da empresa contratada poderá ser:
a. Reduzida até ficar com o limite mínimo de 2 (dois) profissionais; ou
b. Aumentada até ficar com o limite máximo de 4 (quatro) profissionais.
1.4.3. A disponibilização de nova equipe na composição solicitada, considerando a composição das equipes no âmbito de outras Ordens de Serviço abertas simultaneamente, não poderá resultar em quantitativo de profissionais superior ao quantitativo máximo de postos de trabalho previstos no contrato. A disponibilização de novos postos de trabalho para formação de nova equipe não poderá, ainda, implicar na extrapolação do orçamento total da contratação.
1.5. O pagamento das ordens de serviço estará vinculado ao atendimento dos níveis de serviço mínimos, conforme regras descritas no ANEXO 05 - NÍVEIS MÍNIMOS DE SERVIÇO E CÁLCULO DE PAGAMENTO.
2. DA PRESTAÇÃO DO SERVIÇO
2.1. Requisitos tecnológicos
2.1.1. A contratação deverá englobar a utilização e administração das ferramentas utilizadas pela CESAN, sejam em suas versões atualmente utilizadas, seja em futuras atualizações, conforme objeto da contratação.
2.1.2. Segue lista das principais ferramentas/tecnologias em uso na CESAN de forma não exaustiva:
a. Python
i. Plataforma 2.7.8
b. PhP
i. Plataforma 5.2 e 7.0
c. Banco de Dados:
i. Microsoft Report Services 2017
ii. Microsoft SQL 2017
iii. Microsoft SQL 2008 R2
iv. Microsoft SQL 2008
v. MariaDB
vi. PostgreSQL + extensão PostGIS
d. Java
i. Plataforma 1.5, 1.6
ii. Open JDK 11
iii. JSF 2.1.9
e. Business Intelligence:
i. Business Intelligence Development Studio 2008
ii. IBM Cognos 10.2
f. XSeed:
i. Plataforma 8.1.19
g. Docker CE
i. Plataforma 19.03.6 e 19.03.13
h. Servidores de Aplicação
i. Tomcat 5.5.28 e 5.0.28
ii. Glassfish 9.1-02
iii. Microsoft IIS 7.0, 7.5, 10 iv. JBoss 4.0.5, 7.1.1
2.2. Preparação para início do contrato e da prestação de serviços
2.2.1. Antes do início efetivo da prestação de serviços relativo à OS, a CONTRATADA deverá apresentar a relação de seus profissionais, com nome completo, cargo/função, valor do salário, número de registro de identidade (RG), número do Cadastro de Pessoa Física (CPF), número da Carteira de Trabalho e Previdência Social (CTPS) ou a cópia do contrato de prestação de serviços. Essa relação de profissionais deverá ser mantida atualizada pela CESAN no caso de entrada e saída de profissionais atuantes no contrato, respeitadas as disposições encontradas no item 2.3 do ANEXO 03 - ESPECIFICAÇÃO TÉCNICA DOS SERVIÇOS.
2.2.2. Qualquer descumprimento de direito aos profissionais da CONTRATADA deverá ser comunicado a CESAN imediatamente, podendo ser realizada pelos próprios profissionais alocados para prestação de serviços.
2.2.3. Para cada profissional apresentado pela empresa, a CESAN conferirá a adequação do currículo apresentado em relação aos requisitos de qualificação técnica exigidos, sem prejuízo da avaliação destes requisitos durante a efetiva prestação do serviço.
2.3. Qualificação técnica dos profissionais e as atividades a serem executadas pela CONTRATADA constam no anexo ANEXO 08 – QUALIFICAÇÃO TÉCNICA E ATIVIDADES A SEREM EXECUTADAS.
2.3.1. A qualificação técnica dos profissionais estará sujeita a diligência conforme descrito no ANEXO 09 - DILIGÊNCIA PRÉVIA DE CAPACIDADE TÉCNICA.
2.3.2. Caso a CESAN opte pela adoção e uso de ferramentas de apoio ao desenvolvimento como frameworks, bibliotecas e boas práticas, entre alternativas, os profissionais da CONTRATADA terão o prazo de até 22 (vinte e dois) dias úteis para estudo e adaptação do uso.
2.3.3. A comprovação de vínculo trabalhista e de qualificação técnica dos profissionais da equipe técnica da contratada deverá ocorrer em até 5 (cinco) dias úteis anteriores ao início de execução da OS, dentro do horário de expediente da CONTRATANTE.
2.4. Modelo de Execução
2.4.1. A disponibilização dos postos de trabalho para formação das equipes técnicas da CONTRATADA para prestação do serviço será formalizada mediante abertura de Ordem de Serviço (OS), sob demanda da CESAN, conforme item 3 do ANEXO 02 - DESCRIÇÃO DOS SERVIÇOS.
2.4.1.1. A CESAN abrirá OS quando houver projeto ou manutenção de software a ser executado pela empresa CONTRATADA. A OS permanecerá aberta, em regra, até o término do projeto ou manutenção, observada a vigência do contrato.
2.4.1.2. Na OS será informado pela CESAN à quantidade de postos de trabalho, e deverão ser informados também o “nível profissional” e o respectivo “papel de atuação” requerido para prestação do serviço, conforme detalhado no item 2.3 do ANEXO 03 - ESPECIFICAÇÃO TÉCNICA DOS SERVIÇOS.
2.4.2. Após a abertura da Ordem de Serviço, a CONTRATADA terá o prazo de até 30 (trinta) dias para disponibilizar os postos de trabalho, que formarão uma equipe, para prestação de serviço.
2.4.3. A CESAN poderá, a seu critério, prorrogar o prazo da OS por menor ou igual período, desde que haja justificativa formal da CONTRATADA e a mesma seja acatada. Extrapolado o prazo previsto para disponibilização ou não cumprimentos dos requisitos de qualificação e experiência, ficará caracterizada inexecução total se for a primeira Ordem de Serviço no âmbito do contrato, ou inexecução parcial para as demais.
2.4.4. Cada OS estará relacionada a uma e somente uma equipe técnica da CONTRATADA para prestação do serviço. A quantidade máxima de Ordens de Serviço abertas simultaneamente ficará limitada ao quantitativo máximo de postos de trabalho previstos no contrato.
2.4.5. O mesmo profissional não pode ser membro de mais de uma equipe técnica ao mesmo tempo, ou seja, não pode prestar serviço em ordens de serviço distintas para o mesmo período, exceto quando houver necessidade de correção de erros identificados até o aceite definitivo ou em período de garantia.
2.4.6. A equipe técnica da CONTRATADA prestará o serviço até que Ordem de Serviço seja finalizada, mediante validação e aceite. A CONTRATADA será remunerada de acordo com os postos de trabalho ocupados efetivamente no período, observando os níveis mínimos de serviço definidos no ANEXO 05
- NÍVEIS MÍNIMOS DE SERVIÇO E CÁLCULO DE PAGAMENTO.
2.4.7. A eventual não-ocupação de posto de trabalho durante a prestação de serviço incorrerá em desconto conforme ANEXO 05 - NÍVEIS MÍNIMOS DE SERVIÇO E CÁLCULO DE PAGAMENTO.
2.5. Medição do Tamanho Funcional do Projeto e Manutenção de Software
2.5.1. A medição do tamanho funcional do software desenvolvido para fins de aferição do cumprimento dos itens dispostos no ANEXO 05 - NÍVEIS MÍNIMOS DE SERVIÇO E CÁLCULO DE PAGAMENTO será de responsabilidade da CONTRATADA.
2.5.2. A medição deve ser realizada por um funcionário da empresa CONTRATADA certificado em Ponto de Função (Certified Function Point Specialist – CPFS) pelo International Function Point User’s Group (IFPUG) ou experiência mínima de 3 (três) anos em atividades de medição de tamanho funcional de software, na unidade de pontos de função devidamente comprovados por declaração expedida por pessoa jurídica de direito público ou privado, sendo posteriormente validada pela CESAN. Não é obrigatório que o funcionário que realizará a contagem seja um dos membros da equipe de desenvolvimento.
2.5.3. A realização dessa atividade não reduzirá a produtividade esperada nem os demais níveis mínimos de serviço exigidos (ANEXO 05 - NÍVEIS MÍNIMOS DE SERVIÇO E CÁLCULO DE PAGAMENTO), devendo seu custo ser incluído pela CONTRATADA na proposta de preços.
2.5.4. A equipe técnica da CONTRATADA que estiver desenvolvendo o software deverá repassar as informações necessárias ao funcionário que realizará a medição do seu tamanho funcional e à equipe da CESAN que fará sua validação.
2.5.5. As medições realizadas pela CONTRATADA deverão ser registradas no relatório de contagem.
2.5.6. A CESAN indicará empregados responsáveis pela aplicação de métricas de software que serão responsáveis pela validação e auditoria das medições de ponto de função.
2.5.7. Na ocorrência de problemas no relatório de contagem, este será retornado à CONTRATADA para os devidos ajustes.
2.5.8. Divergências técnicas acerca das contagens realizadas deverão ser sanadas diretamente entre os empregados responsáveis da CESAN e o funcionário responsável da CONTRATADA. Cabe aos primeiros o posicionamento técnico final sobre o tema. A cada aplicação correta dos conceitos divergentes, a decisão tomada será registrada em documentação apropriada, sendo esta um Guia de Melhores Práticas de Contagem de Pontos de Função para futura referência, se necessário for.
2.5.9. A medição de pontos de função pode sofrer atualização em decorrência da evolução do Roteiro de Métricas de Software– versão 2.3 (ou superior), e subsidiariamente, no Function Point Counting Practices Manual (CPM), versão 4.3 (ou superior), publicado pelo IFPUG – International Function Point Users Group (xxxx://xxx.xxxxx.xxx).
2.5.10. Fronteiras de aplicações para utilização sob a contagem de pontos de função serão definidas pela CESAN. Alterações podem ocorrer com a mudança de requisitos dos usuários, evolução ou entrada de novas aplicações podem alterar fronteiras, sendo comunicado previamente a CONTRATADA.
2.6. Ordens de Serviços e Acompanhamento
2.6.1. A CESAN abrirá Ordem de Serviço para a CONTRATADA informando acerca dos postos de trabalho para formação da equipe técnica para prestação do serviço contratado, conforme definido no item 2.3 do ANEXO 03 - ESPECIFICAÇÃO TÉCNICA DOS SERVIÇOS.
2.6.2. Na Ordem de Serviço aberta, a CESAN informará data prevista de término do serviço bem como a composição desejada para a equipe técnica da CONTRATADA, limitado ao orçamento e ao tamanho máximo da equipe. Conforme definido no item 2.3 do ANEXO 03 - ESPECIFICAÇÃO TÉCNICA DOS SERVIÇOS.
2.6.3. A ausência da maior parte da equipe técnica da CONTRATADA em reunião de planejamento, revisão e/ou definição de Sprint acarretará em inexecução parcial do contrato.
2.6.4. A prestação de serviço será feita de acordo com o processo de desenvolvimento de software, descrito no ANEXO 04 - PROCESSO DE DESENVOLVIMENTO DE PROJETO E DE MANUTENÇÃO DE SOFTWARE.
2.6.5. A equipe da CONTRATADA também executará processos previstos no processo de desenvolvimento descrito no ANEXO 04 - PROCESSO DE DESENVOLVIMENTO DE PROJETO E DE MANUTENÇÃO DE SOFTWARE, além de fiscalizar a execução do contrato, e ainda demais atividades que sejam necessárias e vitais para sustentabilidade dos serviços entregues.
2.6.6. Caso um profissional da equipe técnica da CONTRATADA não atenda aos requisitos estipulados de qualificação, este não será mais aceito pela CESAN para prestação de serviço, sendo a CONTRATADA notificada formalmente.
2.6.7. A inclusão de profissional na equipe técnica da CONTRATADA que não atenda aos requisitos de qualificação técnica exigidos por 3 (três) vezes dentro da mesma Ordem de Serviço, ou por 6 (seis) vezes alternadas no período de 8 (oito) meses, caracterizará inexecução parcial do contrato.
2.6.8. A CESAN, em virtude de prazo ou volume de demandas, poderá solicitar redução ou aumento da equipe técnica da CONTRATADA, por meio de comunicação e aditivo à Ordem de Serviço, respeitando os limites máximos e mínimos contratados. O prazo para alocação/retirada de parte da equipe técnica será o mesmo previsto para alocação inicial quando da abertura de Ordem de Serviço.
2.6.9. Em caso de substituição de profissional da equipe técnica da CONTRATADA alocada, é de obrigação dos demais membros da mesma o repasse das informações necessárias ao novo membro.
2.6.10. Caso não seja estabelecido prazo específico distinto dependendo da situação particular, a empresa CONTRATADA deverá resolver impropriedade identificada na execução do serviço contratado no prazo de 10 (dez) dias úteis.
2.6.11. A taxa mínima exigida de ocupação dos postos de trabalho e sua relação com os níveis mínimos de serviço estão dispostos no ANEXO 05 - NÍVEIS MÍNIMOS DE SERVIÇO E CÁLCULO DE PAGAMENTO.
2.6.12. Caso seja de interesse da CESAN a interrupção, término antecipado ou prorrogado da Ordem de Serviço, a mesma deverá comunicar a CONTRATADA com antecedência mínima de 22 (vinte e dois) dias úteis.
2.6.13. No caso de interrupção, término antecipado ou prorrogado da Ordem de Serviço conforme descrito no item anterior, a CONTRATADA deverá continuar a prestação de serviços regularmente, atendendo demais demandas restantes e efetuando a transferência de conhecimento à CESAN.
ANEXO 04 - PROCESSO DE DESENVOLVIMENTO DE PROJETO E DE MANUTENÇÃO DE SOFTWARE
1. INTRODUÇÃO
1.1. O processo de desenvolvimento de software que será utilizado no âmbito deste contrato é baseado no
Scrum e no Kanban e contém práticas de Extreme Programming (XP).
1.2. Considerando que estes modelos e práticas são de amplo conhecimento e se encontram descritos em vasta literatura, trataremos neste documento das particularidades do processo adotado na CESAN.
2. PAPÉIS E RESPONSABILIDADES
2.1. Product Owner (PO)
2.1.1. O papel de Product Owner (PO) será exercido, em regra, por representante da unidade gestora da solução de TI a ser desenvolvida ou empregado da A-DDS.
2.2. ScrumMaster
2.2.1. O papel de ScrumMaster será exercido por empregado da CESAN, lotado na Divisão de Desenvolvimento de Sistemas - A-DDS.
2.3. Equipe de desenvolvimento
2.3.1. O papel de equipe de desenvolvimento será exercido pela equipe técnica da empresa
CONTRATADA, ficando a critério da CESAN incluir profissionais próprios nesta equipe.
2.3.2. A equipe de desenvolvimento será responsável por executar as tarefas do backlog do produto respeitando a priorização definida pelo Product Owner (PO).
2.3.3. A distribuição de tarefas priorizadas do backlog do produto entre os seus membros é responsabilidade da própria equipe de desenvolvimento, e deverá ser feita no momento de planejamento da Sprint (sprint planning).
2.3.4. A equipe de desenvolvimento deve entrar em contato com a equipe da CESAN sempre que houver dúvidas acerca de tarefas a serem executadas e que for necessário obter feedback para produto de software desenvolvido.
2.3.5. Durante todo o projeto, a equipe de desenvolvimento deverá transferir continuamente conhecimentos acerca do sistema em construção para a equipe da CESAN.
2.4. Equipe técnica de apoio ao projeto
2.4.1. O ScrumMaster contará com equipe técnica da CESAN para apoiá-lo na condução do projeto, para absorver o conhecimento acerca do sistema e para executar outras tarefas que visem ao sucesso do projeto e a sustentabilidade do sistema produzido após o término do contrato.
2.4.2. O tamanho da equipe de apoio deverá ser dimensionada considerando fatores como as características técnicas e de negócio do projeto, o tamanho da equipe técnica da empresa CONTRATADA, o ritmo do projeto, entre outros.
2.4.3. A equipe técnica de apoio ao projeto será responsável também por exigir respeito aos padrões técnicos de desenvolvimento de software adotados na CESAN e adotar as providências cabíveis em caso de descumprimento.
2.4.4. A equipe técnica de apoio ao projeto poderá realizar reunião diária (daily meeting) e acompanhamento de progresso do trabalho com ferramentas sugeridas pela própria metodologia ágil, como o Burndown Chart.
3. DEFINIÇÃO DE BACKLOG DO PRODUTO
3.1. Cada módulo (agrupamento de processos para um mesmo domínio de negócio) será identificado como um Epic, segundo o conceito do Scrum. Cada Epic é decomposto em Features, que representam os requisitos de softwares identificados a partir de histórias de usuários (user stories).
3.2. User stories serão subdivididas em partes menores, conhecidas como tarefas (tasks). Este refinamento será feito no decorrer do projeto, de acordo com a prioridade dos requisitos do software.
3.3. Os requisitos do software (features), as histórias de usuários (user stories) e as tarefas (tasks) compõem o backlog do produto.
3.4. Também são incluídas no backlog do produto eventuais manutenções corretivas e adaptativas que venham a ser necessárias no software, como também o tratamento de débitos técnicos, e obrigatoriamente correções dos produtos gerados em cada sprint.
3.4.1. Os defeitos que não impeçam a validação do produto poderão ser incluídos como itens do backlog e serão tratados como débitos técnicos. A execução dos débitos técnicos não contará no indicador de produtividade da sprint quando da sua execução. A priorização dessas atividades ficará a critério da CONTRATANTE, no planejamento das próximas sprints. Na reunião de planejamento, a CONTRATANTE poderá solicitar que até 20% da sprint seja utilizado para entrega de atividades de débito técnico. Essa reserva se dará na forma de até 20% dos DIAS-DESENVOLVEDOR (conforme item 9.2.26 do ANEXO I - Termo de Referência) previstos na sprint.
3.5. O backlog do produto será priorizado pelo Product Owner (PO).
4. SPRINTS
4.1. As sprints terão duração entre 1 a 4 semanas, de acordo com as características do projeto específico.
4.2. A duração das sprints e o dia e a duração das reuniões de planejamento, revisão e retrospectiva das sprints serão definidas pela CESAN no início do projeto. Estas definições poderão ser alteradas posteriormente, a critério da CESAN, mediante comunicação prévia à equipe de desenvolvimento da CONTRATADA.
4.3. O critério para aceitar cada tarefa como “pronta” será definido para cada história e, quando necessário, de forma particular para cada tarefa.
5. ENTREGA E HOMOLOGAÇÃO CONTÍNUAS
5.1. Software
5.1.1. Seguindo a prática de entrega contínua (continuous delivery), incrementos ao software serão constantemente entregues para homologação da CESAN.
5.1.2. Os incrementos aceitos comporão a versão homologada do software, enquanto os incrementos rejeitados retornarão para o backlog do produto.
5.1.3. O código fonte deverá ser entregue versionado em repositório definido pela CESAN, de onde serão geradas as versões de homologação. O versionamento de cada artefato deve identificar qual(is) task(s) deu(deram) originou/alterou o mesmo, em comentário na ferramenta. Juntamente com o fonte, quando necessário, deverá ser atualizado o Modelo de Dados e versionados os scripts, devidamente identificados pela(s) task(s) que deu(deram) origem ao mesmo.
5.2. Documentação
5.2.1. A documentação apresentada no final de cada Sprint deverá conter:
• Checklist de implementação: roteiro com verificações de implementação para atender aos padrões da CESAN: padrão de nomenclatura de pacotes, classes, métodos, variáveis e serviços, uso de identidade visual da empresa, ortografia, comportamento de componentes, máscaras de formatação, campos obrigatórios, acessibilidade, execução de testes em navegadores distintos, entre outros itens pertinentes a forma como as funcionalidades foram implementadas, conforme modelo disposto no ANEXO VI - CHECKLIST DE VERIFICAÇÃO DE IMPLEMENTAÇÃO.
• Documentação básica da funcionalidade: história(s) do(s) usuário(s) que deu(deram) início ao desenvolvimento da funcionalidade, tarefas executadas para atender a(s) história(s) e Cenários de testes: fluxos normal e alternativos de cada tarefa, possibilitando testar os comportamentos de cada funcionalidade/componente e sua aderência ao requisito de backlog apontado, conforme modelo disposto no ANEXO VII - DOCUMENTAÇÃO DA FUNCIONALIDADE.
ANEXO 05 - NÍVEIS MÍNIMOS DE SERVIÇO E CÁLCULO DE PAGAMENTO
1. NÍVEIS DE SERVIÇO
1.1 Índice de Evolução do Sistema (IES)
1.1.1 Os níveis de serviço de OS do tipo PROJETO serão representados por indicadores de desempenho denominados Índice de Evolução do Sistema (IES), que será a média ponderada de três componentes:
Componentes do IES | Peso |
Índice de Produtividade (IP) | 0,60 |
Índice de Qualidade (IQ) | 0,20 |
Avaliação do Product Owner (APO) | 0,20 |
1.1.2 O Índice de Evolução do Sistema (IES) será aferido em períodos de 1 a 2 meses, em momento escolhido pela CESAN, e obrigatoriamente ao término da Ordem de Serviço.
1.1.3 Adicionalmente, há níveis mínimos de serviço exigidos para alguns componentes do IES isoladamente, conforme item “1.1.8 Descontos a serem aplicados de acordo com o índice de cumprimento dos níveis de serviço”.
1.1.4 O IES e as aferições acontecerão para cada Serviço de Desenvolvimento Web e Mobile.
1.1.5 Índice de Produtividade (IP)
1.1.5.1 O Índice de Produtividade (IP) é aferido comparando a produtividade no período de aferição com a produtividade-base estabelecida no item “1.1.10 - Produtividade-base”.
1.1.5.2 A produtividade será estabelecida em termos de dias de efetiva prestação de serviço de membro da equipe técnica da CONTRATADA, unidade esta que será identificada por DIAS- DESENVOLVEDOR.
a) Por exemplo, se em um dado período de aferição tivermos 40 (quarenta) dias de serviço prestado por equipe de 4 membros, haverá neste período 160 (cento e sessenta) DIAS- DESENVOLVEDOR.
b) Não serão considerados aqueles dias em que não houver efetiva prestação do serviço, como finais de semana e feriados, em regra.
1.1.5.3 Para calcular o Índice de Produtividade (IP) deverá ser medido primeiro o Tamanho da Evolução Funcional (TEF), que é o quantitativo de pontos de função correspondente aos aprimoramentos realizados na versão atual do software em relação à versão anterior.
a) Por versão atual considera-se aquela versão do software que contiver os aprimoramentos entregues no período escolhido pela CESAN para aferição do Índice de Evolução do Sistema (IES). Para finalizar a aferição do cálculo do Índice de Evolução do Sistema (IES) os aprimoramentos precisam estar homologados/aceitos pelo Product Onwer(PO), a homologação/aceitação poderá acontecer em até 10 dias úteis após o período de aferição escolhido pela CESAN.
b) Por versão anterior do sistema entende-se aquela analisada e medida na aferição imediatamente anterior do IES.
c) Eventuais aprimoramentos no software, como inclusões, alterações ou exclusões de funcionalidades, que forem realizadas em versões intermediárias do software e que não sejam identificáveis ao se comparar a versão atual com a versão anterior do sistema não serão consideradas no cálculo do TEF e, consequentemente, do IP.
1.1.5.4 Para calcular o Tamanho da Evolução Funcional (TEF), deve ser feita, em princípio, a medição detalhada em pontos de função de cada demanda de manutenção atendida e homologada no período, de acordo com o no Roteiro de Métricas de Software do SISP, versão
2.3 ou superior e na ausência de regra nestes Roteiro/Guia, o Manual de Práticas e Contagens (CPM, sigla para “Counting Practices Manual”) versão 4.3 ou superior, publicado pelo IFPUG (Sigla para “International Function Point Users Group”).
Para ilustrar esta regra, consideremos o seguinte cenário:
a) A CESAN realizou a primeira aferição do IES;
b) Na próxima sprint foi acrescentado o campo C1-A na tela T1, os campos C2-A e C2-B na tela T2 e o campo C3-A na tela T3:
Tela | Campo(s) acrescentado(s) em relação à versão anterior da tela |
T1 | X0-X |
X0 | X0-X / X0-X |
X0 | X0-X |
c) O Product Owner (PO) homologou as alterações realizadas na sprint;
d) Na próxima sprint, o campo C2-B da tela T2 foi excluído, foi acrescentado o campo C3- B na tela T3 e não houve alteração na tela T1;
Tela | Campo(s) acrescentado(s) em relação à versão anterior da tela |
T1 | X0-X |
X0 | X0-X / |
X0 | X0-X / X0-X |
e) O PO novamente homologou estas alterações;
f) A CESAN decidiu aferir o IES novamente;
g) Nesta nova aferição serão consideradas somente a inclusão do campo C1-A na tela T1, a inclusão do campo C2-A na tela T2 e a inclusão dos campos C3-A e C3-B na tela T3 para efeito do cálculo do TEF. Ou seja, nem a inclusão do campo C2-B na tela T2 e nem a sua posterior exclusão serão consideradas para fins de apuração da produtividade em tamanho funcional.
Tela | Campo(s) acrescentado(s) em relação À versão anterior da tela |
T1 | X0-X |
X0 | X0-X |
X0 | X0-X / X0-X |
1.1.5.5 A Produtividade no Período em Tamanho Funcional (PPTF) será obtida dividindo o Tamanho da Evolução Funcional (TEF) do sistema pela quantidade de DIAS-DESENVOLVEDOR do período de aferição.
1.1.5.6 O Índice de Produtividade (IP) será calculado dividindo a PPTF pela produtividade-base estabelecida no item “1.1.10 Produtividade-base”.
1.1.5.7 Caso o resultado do cálculo do IP seja maior que 100%, será adotado 100% para o valor deste Item de Controle.
1.1.5.8 A expectativa de cumprimento mínimo ou máximo do IP no próximo período de aferição não desonera a CONTRATADA de progredir na atividade de desenvolvimento da OS em andamento.
1.1.6 Índice de Qualidade (IQ)
1.1.6.1 O Índice de Qualidade será medido conforme a aderência às boas práticas definidas pela CESAN na reunião de abertura da OS.
Item | Avaliação |
1 – Estrutura de tabelas | Seguem as boas práticas definidas: [ ] 4 – Todas [ ] 3 – Maioria [ ] 2 – Metade [ ] 1 – Minoria [ ] 0 – Nenhuma |
2 – Classes correspondentes aos Modelos, Repositórios, Serviços, Controllers e ViewModels | Seguem as boas práticas definidas: [ ] 4 – Todas [ ] 3 – Maioria [ ] 2 – Metade [ ] 1 – Minoria [ ] 0 – Nenhuma |
3 – Camada de apresentação | Procurou manter consistência com o restante do sistema: [ ] 4 – Sempre [ ] 3 – Maioria [ ] 2 – Metade [ ] 1 – Minoria [ ] 0 – Nunca |
4 – Reuso de componentes e integração com outras bibliotecas do projeto | Sempre que possível utilizou os componentes já desenvolvidos ou fez uso das bibliotecas disponíveis: [ ] 4 – Sempre [ ] 3 – Maioria [ ] 2 – Metade [ ] 1 – Minoria [ ] 0 – Nunca |
Comentários adicionais (optativo) | |
1.1.6.2 O valor final do Índice de Qualidade (IQ) será obtido da seguinte forma:
1.1.7 Avaliação do Product Owner (APO)
1.1.7.1 Considerando os princípios e valores do desenvolvimento ágil, o Product Owner (PO) do projeto deverá avaliar os seguintes aspectos da prestação do serviço e justificar os valores atribuídos.
Item | Avaliação |
1 - Periodicidade de entrega de software para homologação (preferência por períodos entre 1 a 4 semanas) | Entregas realizadas em período igual ou menor a 4 semanas: [ ] 4 – Todas [ ] 3 – Maioria [ ] 2 – Metade [ ] 1 – Minoria [ ] 0 – Nenhuma |
2 - Receptividade da equipe de desenvolvimento à mudança de requisitos, mesmo em estágio avançado de desenvolvimento | [ ] 4 – Não houve resistência à nenhuma solicitação de mudança de requisitos [ ] 3 – Não houve resistência à maioria das solicitações de mudança de requisitos [ ] 2 – Não houve resistência à metade das solicitações de mudança de requisitos [ ] 1 – Não houve resistência à minoria das solicitações de mudança de requisitos [ ] 0 – Houve resistência a todas às solicitações de mudança de requisitos |
3 - Manutenção pela equipe de desenvolvimento de diálogo contínuo e eficiente com o Product Owner para esclarecer dúvidas e obter feedback | Eventual falta de comunicação da equipe de desenvolvimento com o PO ocasionou: [ ] 4 – nenhuma falha ou desvio [ ] 3 – falha ou desvio na minoria das entregas [ ] 2 – falha ou desvio na metade das entregas [ ] 1 – falha ou desvio na maioria das entregas [ ] 0 – falha ou desvio em todas as entregas |
omentários adicionais (optativo) | |
1.1.7.2 O valor final da Avaliação do Product Owner (APO) será obtido da seguinte forma:
1.1.8 Descontos a serem aplicados de acordo com o índice de cumprimento dos níveis de serviço
1.1.8.1 O quadro a seguir mostra o desconto a ser aplicado no faturamento da Ordem de Serviço (OS) de acordo com o Índice de Evolução do Sistema (IES):
Índice de Evolução do Sistema (IES) | Desconto sobre o valor de faturamento da OS |
Igual ou superior a 80% | 0% |
Igual ou superior a 70% e inferior a 80% | 10% |
Igual ou superior a 60% e inferior a 70% | 20% |
Igual ou superior a 50% e inferior a 60% | 30% |
Inferior a 50% | 40% |
1.1.8.2 O quadro a seguir mostra o desconto a ser aplicado no faturamento da OS de acordo com níveis mínimos de serviço de componentes do IES, sem prejuízo a outros eventuais descontos previstos neste Edital:
Componente do IES | Nível de Serviço | Desconto sobre o valor de faturamento da OS |
Índice de Produtividade (IP) | Igual ou superior a 50% | 0% |
Igual ou superior a 25% e inferior a 50% | 5% | |
Inferior a 25% | 10% | |
Índice de Qualidade (IQ) | Igual ou superior a 50% | 0% |
Igual ou superior a 25% e inferior a 50% | 5% | |
Inferior a 25% | 10% | |
Avaliação do Product Owner (APO) | Igual ou superior a 50% | 0% |
Igual ou superior a 25% e inferior a 50% | 5% | |
Inferior a 25% | 10% |
1.1.9 Descontos a serem aplicados na primeira aferição do Índice de Evolução do Sistema (IES)
1.1.9.1 Excepcionalmente, na primeira aferição do Índice de Evolução do Sistema (IES) da Ordem de Serviço (OS), caso o período considerado não ultrapasse mais que um terço do período total da OS, os descontos a serem aplicados no faturamento da Ordem de Serviço considerarão os dos quadros a seguir:
Índice de Evolução do Sistema (IES) | Desconto sobre o valor de faturamento da OS |
Igual ou superior a 60% | 0% |
Igual ou superior a 50% e inferior a 60% | 10% |
Igual ou superior a 40% e inferior a 50% | 20% |
Inferior a 40% | 30% |
Componente do IES | Nível de Serviço | Desconto sobre o valor de faturamento da OS |
Índice de Produtividade (IP) | Igual ou superior a 40% | 0% |
Igual ou superior a 20% e inferior a 40% | 5% | |
Inferior a 20% | 10% | |
Índice de Qualidade (IQ) | Igual ou superior a 50% | 0% |
Igual ou superior a 25% e inferior a 50% | 5% | |
Inferior a 25% | 10% | |
Avaliação do Product Owner (APO) | Igual ou superior a 50% | 0% |
Igual ou superior a 25% e inferior a 50% | 5% | |
Inferior a 25% | 10% |
1.1.10 Produtividade-base
1.1.10.1 No quadro a seguir temos a produtividade-base em tamanho funcional que será utilizada na aferição do cumprimento dos níveis mínimos de serviço:
Lote | Produtividade-base em Tamanho Funcional |
Lote 01 | 0,80 |
1.2 Índice de Manutenção do Sistema (IMS)
1.2.1 Os níveis de serviço de OS do tipo MANUTENÇÃO serão representados por indicador de desempenho denominado Índice de Manutenção de Sistema (IMS), que será a média ponderada de três componentes:
Componente do IMS | Peso |
Índice de Produtividade de Manutenção (IPM) | 0,50 |
Índice de Qualidade de Manutenção (IQM) | 0,30 |
Avaliação do Product Owner – Manutenção (APO-M) | 0,20 |
1.2.2 O IMS será aferido em períodos de um a dois meses, em momento escolhido pela CESAN, e obrigatoriamente ao término da Ordem de Serviço. Adicionalmente, há níveis mínimos de serviço exigidos para alguns componentes do IMS isoladamente, conforme item “1.2.6 Descontos a serem aplicados de acordo com o índice de cumprimento dos níveis de serviço”.
1.2.3 Índice de Produtividade de Manutenção (IPM)
1.2.3.1 A produtividade será estabelecida em DIA-DESENVOLVEDOR como no caso do Índice de Evolução do Sistema - IES.
1.2.3.2 Para calcular o Tamanho Funcional de Manutenção (TFM), deve ser feita, em princípio, a medição detalhada em pontos de função de cada demanda de manutenção atendida e homologada no período escolhido pela Cesan para aferição, de acordo com o no Roteiro de Métricas de Software do SISP, versão 2.3 ou superior e na ausência de regra nestes Roteiro/Guia, o Manual de Práticas e Contagens (CPM, sigla para “Counting Practices Manual”) versão 4.3 ou superior, publicado pelo IFPUG (Sigla para “International Function Point Users Group”).
1.2.3.2.1 Para finalizar a aferição do cálculo do Índice de Manutenção do Sistema (IMS) as demandas precisam estar homologadas/aceitas pelo Product Onwer(PO), a homologação/aceitação poderá acontecer em até 10 dias úteis após o período de aferição escolhido pela CESAN.
1.2.3.3 O Índice de Produtividade de Manutenção (IPM) será calculado dividindo a produtividade no período em tamanho funcional de manutenção (TFM) pela produtividade-base estabelecida “1.2.8 Produtividade Base Manutenção”.
1.2.3.4 Caso o resultado do cálculo do IPM seja maior que 100%, será adotado 100% para o valor deste Item de Controle.
1.2.3.5 Entretanto, considerando o custo da medição detalhada em pontos de função de grande volume de demandas de manutenção, esta medição somente será realizada em caráter excepcional, a pedido de uma das partes contratuais para defesa de seus interesses.
1.2.3.6 Por exemplo, a CESAN poderá exigir a medição detalhada caso haja indícios de que a produtividade da CONTRATADA esteja abaixo do exigido neste Edital. Por outro lado, a CONTRATADA poderá exigir a medição detalhada caso a CESAN reclame do desempenho do serviço prestado no âmbito de uma Ordem de Serviço.
1.2.4 Índice de Qualidade de Manutenção (IQM)
1.2.4.1 Idem ao “item 1.1.6 Índice de Qualidade (IQ)”.
1.2.5 Avaliação do Product Owner – Manutenção (APO-M)
1.2.5.1 Idem ao “1.1.7 Avaliação do Product Owner (APO)”.
1.2.6 Descontos a serem aplicados de acordo com o índice de cumprimento dos níveis de serviço
1.2.6.1 O quadro a seguir mostra o desconto a ser aplicado no faturamento da Ordem de Serviço (OS) de acordo com o Índice de Manutenção do Sistema (IMS):
Índice de Manutenção do Sistema (IMS) | Desconto sobre o valor de faturamento da OS |
Igual ou superior a 80% | 0% |
Igual ou superior a 70% e inferior a 80% | 10% |
Igual ou superior a 60% e inferior a 70% | 20% |
Igual ou superior a 50% e inferior a 60% | 30% |
Inferior a 50% | 40% |
1.2.6.2 O quadro a seguir mostra o desconto a ser aplicado no faturamento da OS de acordo com níveis mínimos de serviço de componentes do IMS, sem prejuízo a outros eventuais descontos previstos neste Edital:
Componente do IMS | Nível de serviço | Desconto sobre o valor de faturamento da OS |
Avaliação do Product Owner - Manutenção (APO-M) | Igual ou superior a 50% | 0% |
Igual ou superior a 25% e inferior a 50% | 5% | |
Inferior a 25% | 10% |
1.2.7 Descontos a serem aplicados na primeira aferição do Índice de Manutenção do Sistema (IMS)
1.2.7.1 Excepcionalmente, na primeira aferição do Índice de Manutenção do Sistema (IMS) da Ordem de Serviço (OS), caso o período considerado não ultrapasse mais que um terço do período total da OS, os descontos a serem aplicados no faturamento da Ordem de Serviço considerarão os do quadro a seguir:
Índice de Manutenção do Sistema (IMS) | Desconto sobre o valor de faturamento da OS |
Igual ou superior a 60% | 0% |
Igual ou superior a 50% e inferior a 60% | 10% |
Igual ou superior a 40% e inferior a 50% | 20% |
Inferior a 40% | 30% |
Componente do IMS | Nível de serviço | Desconto sobre o valor de faturamento da OS |
Avaliação do Product Owner - Manutenção (APO-M) | Igual ou superior a 50% | 0% |
Igual ou superior a 25% e inferior a 50% | 5% | |
Inferior a 25% | 10% |
1.2.8 Produtividade Base Manutenção
1.2.8.1 Nos quadros a seguir temos a produtividade-base em tamanho funcional e em linhas de código que serão utilizadas na aferição do cumprimento do Índice de Manutenção do Sistema (IMS):
Lote | Produtividade-base em Tamanho Funcional |
LOTE 01 | 0,80 |
1.3 Taxa Efetiva de Ocupação dos Postos de Trabalho da Ordem de Serviço (TEOPT)
1.3.1 Juntamente com a aferição do Índice de Evolução do Sistema (IES) e Índice de Manutenção do Sistema (IMS) será verificada a Taxa Efetiva de Ocupação dos Postos de Trabalho – TEOPT (quantidade de membros da equipe técnica da CONTRATADA) previstos na Ordem de Serviço.
1.3.2 A TEOPT será a calculada dividindo a ocupação efetiva dos postos de trabalho (em DIAS- DESENVOLVEDOR) pela ocupação total prevista para este período (também em dias-desenvolvedor).
1.3.3 O quadro a seguir mostra o desconto adicional a ser aplicado no faturamento mensal da Ordem de Serviço de acordo com a TEOPT, sem prejuízo do desconto a ser aplicado por dia de não ocupação de posto de trabalho, conforme previsto no item 9 do Termo de Referência “CRITÉRIOS DE ACEITABILIDADE, MEDIÇÃO DO(S) SERVIÇO(S) E FORMA DE PAGAMENTO”:
Taxa Efetiva de Ocupação dos Postos de Trabalho previstos na OS (TEOPT) | Desconto sobre o valor do faturamento mensal da OS |
Igual ou superior a 80% | 0% |
Igual ou superior a 50% e inferior a 80% | 80% - TEOPT |
Inferior a 50% | 40% |
1.3.4 Excepcionalmente, caso os resultados obtidos no período de aferição do Índice de Evolução do Sistema corresponderem a, no mínimo, 80% do IES ou IMS considerando 100% de TEOPT, serão desconsideradas eventuais ausências de membros da equipe técnica da CONTRATADA até o limite de 5% da ocupação total de postos de trabalho prevista para o período para efeito de desconto por não preenchimento do posto de trabalho e para efeito do cálculo do TEOPT.
1.4 Inexecução parcial do contrato por descumprimento de nível de serviço
1.4.1 Poderá caracterizar inexecução parcial do contrato:
1.4.1.1 Descumprimentos de níveis mínimos de serviço no âmbito da mesma Ordem de Serviço que tenham ensejado desconto total igual ou superior a 20% (vinte por cento) do valor de faturamento da OS em dois faturamentos consecutivos ou por três faturamentos em seis faturamentos consecutivos dessa OS.
1.4.1.2 Não alcance de meta do mesmo indicador de qualidade no âmbito da mesma Ordem de Serviço, em três faturamentos consecutivos ou por quatro faturamentos em seis faturamentos consecutivos dessa OS.
1.4.1.3 Descumprimentos de níveis mínimos de serviço que tenham ensejado desconto total igual ou superior a 20% (vinte por cento) do valor de faturamento da OS em três faturamentos dessa OS ou de OS distintas no período de 6 (seis) meses no âmbito do contrato.
1.4.1.4 Tentativa de burla de mecanismos de aferição dos níveis de serviço previstos neste Edital.
ANEXO 06 - CHECKLIST DE VERIFICAÇÃO DE IMPLEMENTAÇÃO
Item a ser verificado | Sim | Não | N/A |
A ortografia das palavras exibidas ao usuário está correta (labels, botões, componentes, listagens, relatórios, outros) | |||
As máscaras de formatação foram aplicadas nos padrões brasileiros (data, documento, matrícula, moeda, outros) | |||
O tipo de entrada permitida no campo corresponde ao tipo que está registrado na base de dados | |||
Os campos que tem valores que podem ser verificados através de fórmulas estão permitindo somente valores validados (exemplo: CPF) | |||
Todos os campos são acessíveis via teclado, e na ordem em que se apresentam na tela | |||
A informação apresentada na tela não depende de cores | |||
Imagens e/ou textos e fundos utilizadas apresentam contraste suficiente para pessoas com deficiência na visão de cores | |||
As cores utilizadas seguem o manual de identidade visual da empresa | |||
O tamanho da fonte é maior ou igual a 12 pixels | |||
Tabelas de dados mostram separação entre colunas e linhas | |||
Campos obrigatórios estão marcados como tal | |||
Não há botões ou links inoperantes |
É exibido no topo da tela o caminho que o usuário navegou até chegar a funcionalidade atual (exemplo: Cadastro > Consultar > Dados do Imóvel) | |||
Textos, campos de formulário, botões, componentes e listagens estão alinhados | |||
Não há textos sendo exibidos como imagens | |||
Xxxxxx obrigatórios estão sendo exigidos no momento de salvar, e xxxxxx não obrigatórios não são exigidos | |||
Checkboxes podem ser marcados e desmarcados | |||
Radiobuttons em lista permitem e exigem somente uma marcação, e sempre vem com um valor padrão marcado | |||
Combos não obrigatórios vem com um valor padrão na primeira posição da listagem, que não altera filtros ou dados e pode ser utilizado a qualquer momento | |||
Textos são iniciados sempre com letra maiúscula | |||
Testes foram realizados nos principais navegadores (Internet Explorer, Firefox, Chrome) | |||
Documentação e comentários entregues em língua portuguesa (Brasil) | |||
Padrão de codificação Frontend e Backend | Sim | Não | N/A |
Classes: • Nome inicia com letra maiúscula e segue por minúsculas; exceto nos casos que a sua abreviação seja mais sugestiva que o nome completo • Devem ser nomeadas como substantivos e sempre no singular; • Quando a palavra for composta, a separação entre elas é feita por uma letra maiúscula • Não há uso de artigos, preposições para conectar substantivos e adjetivos, nem caracteres específicos de uma língua como é o caso do “ç” e os acentos da língua portuguesa Ordem de declaração: o Constantes; o Variáveis de classe (estáticas); o Variáveis de instância; o Construtores; o Métodos de classe (estáticos); o Métodos de instância; | |||
Modificadores de acesso: primeiro declaram-se públicos, depois protegidos, sem modificadores, e, por último, privados; | |||
Interfaces: • Constantes nomeadas com todas as letras maiúsculas (quando compostas por duas ou mais palavras a separação é feita por underscore (_), na ordem de declaração públicas, protegidas, sem modificadores (pacote), privadas • Métodos devem ser agrupados por funcionalidade • Variáveis devem ser escritas com letras minúsculas, e quando for composta, a separação entre elas é feita por uma letra maiúscula |
Métodos: • Métodos construtores devem ser listados antes de métodos estáticos e de instâncias • Na assinatura dos métodos não deve haver espaços entre o nome do método e o parêntese de abertura “(“ • A chave de abertura “{” deve aparecer na mesma linha da declaração do método; • Os métodos são agrupados por funcionalidade e não pela forma de acesso ou sua condição de estático ou de instância • Métodos de acesso a atributos iniciam com get ou set e finalizam com o nome da variável tendo a primeira letra da variável maiúscula • Métodos devem ser escritos com letras minúsculas, e quando for nome composto, a separação entre palavras é feita por uma letra maiúscula • Normalmente são verbos no infinitivo representando a utilidade do método, com exceção dos métodos que retornam um boolean, que devem começar com um verbo no presente; • Não se utiliza nenhum caractere especial (ç, é, ã, …); • Os nomes não devem ser abreviados (torna o código mais fácil de compreender) |
Obs.: poderá ser verificado se os artefatos entregues estão em consonância com outros itens não listados constantes nas referências oficiais de cada tecnologia / framework utilizados.
ANEXO 07 - DOCUMENTAÇÃO DA FUNCIONALIDADE
Epic | |||||
Módulo de ... | |||||
Feature | |||||
Product Owner | |||||
User Story | |||||
Pré-Requisitos | |||||
Tasks | Esforço | DoD | Entregue? | Homologado pelo SM? | Homologado pelo PO? |
Cenários | de Testes | ||||
Teste | Resultado | ||||
ANEXO 08 - QUALIFICAÇÃO TÉCNICA E ATIVIDADES A SEREM EXECUTADAS (Serviços de
desenvolvimento Web e Mobile)
1. QUALIFICAÇÃO TÉCNICA POR NÍVEL PROFISSIONAL
1.1. Formação acadêmica requerida:
1.1.1. Graduação de nível superior na área de Tecnologia da Informação, ou conclusão de qualquer curso de nível superior acompanhado de certificado de curso de pós-graduação (especialização, mestrado ou doutorado) na área de Tecnologia da Informação de, no mínimo, 360 horas de carga horária.
1.2. Conhecimentos técnicos requeridos
1.2.1. Princípios e práticas de desenvolvimento de software ágil, incluindo o Manifesto Ágil, Scrum, Extreme Programming (XP) e Kanban;
1.2.2. Análise de requisitos funcionais e não-funcionais, padrões de projeto (enterprise integration patterns, design patterns, microservices patterns);
1.2.3. Modelagem de dados relacional;
1.2.4. Arquitetura de aplicações para ambiente web, arquitetura em três camadas, modelo MVC;
1.2.5. Mapeamento ORM;
1.2.6. Integrações e comunicação síncrona/assíncrona entre sistemas, uso de Mensageria e APIs (RabbitMQ, REST, Web Services);
1.2.7. Domain-driven design (DDD);
1.2.8. Javascript, Typescript, JSON, JWT, Jquery
1.2.9. NodeJS e NestJS
1.2.10. Angular 2 ou superior e Ionic;
1.2.11. HTML 5, ECMAScript 6 ou superior, CSS 3 ou superior, Bootstrap;
1.2.12. User Experience (UX) e conceitos de usabilidade;
1.2.13. Interfaces responsivas;
1.2.14. Banco de dados relacional;
1.2.15. Linguagem para consultas, manipulações e definições de dados SQL;
1.2.16. Conhecimento na utilização de ambiente de desenvolvimento, como Visual Studio Code, Eclipse;
1.2.17. Integração contínua (continuous integration), test-driven development (TDD), acceptance test driven development (ATDD), especificação por exemplo, refactoring, entrega contínua (continuous delivery);
1.2.18. Testes de software: teste de unidade, integração, sistema/funcional, aceitação, carga, desempenho, vulnerabilidade, usabilidade, acessibilidade. Automatização de testes funcionais, de unidade e de carga com ferramentas de software.
1.2.19. Construção de consultas a bancos de dados em linguagem SQL 2008 ou superior;
1.2.20. Conceitos e práticas de controle de versão (centralizado/descentralizado) de código fonte e uso da ferramenta Git;
1.2.21. Arquitetura de microsserviços;
1.2.22. Docker e noções de DevOps
1.2.23. Microsoft Reporting Services
1.2.24. Spring Boot, Spring Data, Hibernate e JPA;
1.2.25. IDEs: Eclipse e VSCode.
1.3. Atividades a serem executadas
1.3.1. Codificação de software;
1.3.2. Teste de software;
1.3.3. Análise e projeto de software;
1.3.4. Modelagem de dados (modelos físico e lógico);
1.3.5. Versionamento de artefatos e gerações de versões (builds);
1.3.6. Documentação, instalação e configuração de servidores de aplicações e recursos inerentes ao funcionamento dos mesmos, em qualquer ambiente (desenvolvimento, homologação ou produtivo);
1.3.7. Publicação (deploy) de versões geradas do sistema ou de algum de seus módulos;
1.3.8. Apoio ao Product Owner na definição e especificação de requisitos;
1.3.9. Participação nas reuniões e demais práticas estabelecidas para os padrões de desenvolvimento ágil;
1.3.10. Medição do software produzido, conforme especificações presentes neste termo de referência;
1.3.11. Transferência de conhecimento a equipe da CESAN;
1.3.12. Cada profissional fará o papel de membro de equipe de desenvolvimento previsto no Scrum.
1.4. Competências comportamentais requeridas
1.4.1. Proatividade, capacidade de trabalho em equipe, capacidade de iniciava e autogerenciamento, capacidade de comunicação (capacidade de se expressar oralmente e por escrito com precisão e clareza e de compreender com facilidade mensagens escritas e faladas).
1.5. Experiência comprovada
1.5.1. Analista Full Stack Web e Mobile Pleno
1.5.1.1. Quando for atuar no papel de Analista Desenvolvedor Java, necessário experiência de 2 ANOS
relativos à execução de atividade ligada ao conhecimento técnico abaixo:
a) Java 6 ou superior.
1.5.1.2. Quando for atuar no papel de Analista Desenvolvedor PHP, necessário experiência de 2 ANOS
relativos à execução de atividades ligada ao conhecimento técnico abaixo:
a) PHP 5 ou superior.
1.5.1.3. Quando for atuar no papel de Analista Desenvolvedor .Net, necessário experiência de 2 ANOS
relativos à execução de atividades ligadas aos conhecimentos técnicos abaixo:
a) NET 3.5 superior C# ou superior;
b) EntityFramework 6 ou superior.
1.5.2. Analista Full Stack Web e Mobile Sênior
1.5.2.1. Quando for atuar no papel de Analista Desenvolvedor Java, necessário experiência de 5 ANOS
relativos à execução de atividade ligadas ao conhecimento técnico abaixo:
a) Java 6 ou superior.
1.5.2.2. Quando for atuar no papel de Analista Desenvolvedor PHP, necessário experiência de 5 ANOS
relativos à execução de atividade ligada ao conhecimento técnico abaixo:
b) PHP 5 ou superior;
1.5.2.3. Quando for atuar no papel de Analista Desenvolvedor .Net, necessário experiência de 5 ANOS
relativos à execução de atividades ligadas aos conhecimentos técnicos abaixo:
a) NET 3.5 superior C# ou superior;
b) EntityFramework 6 ou superior;
ANEXO 09 – DILIGÊNCIA PRÉVIA DE CAPACIDADE TÉCNICA
1. DILIGÊNCIA PRÉVIA DE CAPACIDADE TÉCNICA PARA PERFIS PROFISSIONAIS (DPC)
1.1. Cada profissional indicado pela CONTRATADA deverá entregar o currículo atualizado e poderá passar por uma Diligência Prévia de Capacidade técnica (DPC). A DPC visa garantir que o funcionário indicado pela CONTRATADA possua a capacidade técnica e a experiência para o desempenho das atividades contratuais previstas.
1.2. O resultado da DPC será “satisfatório” ou “insatisfatório”. Apenas os profissionais que obtiverem grau “satisfatório” serão considerados aptos a serem alocados em contrato.
1.3. A comprovação de experiência profissional poderá ser realizada por meio de:
1.3.1. Currículo;
1.3.2. Cópias de registros em Carteira de Trabalho e Previdência Social (CTPS);
1.3.3. Contratos de trabalho assinados;
1.3.4. Declaração assinada e carimbada do empregador indicando o período e função/atividades executadas;
1.3.5. Entrevista com equipe técnica do CONTRATANTE.
1.4. A comprovação de experiência profissional realizada não elimina o pedido de substituição do profissional posteriormente, a qualquer tempo, no caso de desempenho insatisfatório ou comportamento inadequado na execução do serviço.
1.5. A CESAN se reserva o direito de realizar auditorias a qualquer tempo para verificar se as competências mínimas solicitadas são atendidas pela CONTRATADA. Desta forma, quando solicitado, a CONTRATADA deverá apresentar os currículos dos profissionais alocados ao contrato, assinados pelo profissional, bem como as devidas certificações.
1.6. A CESAN possui um ambiente computacional heterogêneo e, não raramente, precisa atender com celeridade a necessidades urgentes das áreas de negócio. Portanto, a CONTRATADA precisa dispor de uma equipe técnica experiente e competente, detentora dos requisitos elencados neste documento.
ANEXO 10 – MODELO DE ORDEM DE SERVIÇO
Companhia Espírito Santense de Saneamento – CESAN | Nº da OS 00 Data DD/MM/AAAA | |
Ordem de Serviço | ||
Contrato | ||
Tipo da Ordem de Serviço | ( ) MANUTENÇÃO | ( ) PROJETO - Desenvolvimento de novos sistemas ou ( ) PROJETO - Desenvolvimento de novos sistemas referente ao empreendimento nº I.VIT.TI.13.01 |
Nome do Projeto / Sistema(s) | ||
Data da Abertura | ||
Data Prevista de Término | ||
Alocação | ( ) Alocação Remota ( ) In Loco. Ver item 5.4 do ANEXO I – Termo de Referência | |
Quantitativo de Posto de Trabalho | SERVIÇO DE DESENVOLVIMENTO WEB E MOBILE ANALISTA FULL STACK WEB E MOBILE Papel: Analista Desenvolvedor Java – Pleno – Qtd ( ) Analista Desenvolvedor PHP – Pleno – Qtd ( ) Analista Desenvolvedor .NET – Pleno – Qtd ( ) Analista Desenvolvedor Java – Sênior – Qtd ( ) Analista Desenvolvedor PHP – Sênior – Qtd ( ) Analista Desenvolvedor .NET – Sênior – Qtd ( ) | |
Representantes da CESAN | NOME – MATRÍCULA (Gestor ou Fiscal do Contrato) | |
Ciência do representante da CONTRATADA | NOME – CPF – Cargo na empresa | |
ANEXO 11 – MODELO DE ADITIVO EM ORDEM DE SERVIÇO
Companhia Espírito Santense de Saneamento – CESAN | Nº da OS 00 Nº do Aditivo 00 | |
Aditivo à Ordem de Serviço | ||
Contrato | ||
Nome do Projeto / Sistema(s) | ||
Data do Aditivo | ||
Tipo | ( ) Alocação Fora da Cesan ( ) Alocação dentro da Cesan ( ) Aumento de posto(s) de trabalho: ( ) Redução de posto(s) de trabalho: SERVIÇO DE DESENVOLVIMENTO WEB E MOBILE ANALISTA FULL STACK WEB E MOBILE Papel: Analista Desenvolvedor Java – Pleno – Qtd ( ) Analista Desenvolvedor PHP – Pleno – Qtd ( ) Analista Desenvolvedor .NET – Pleno – Qtd ( ) Analista Desenvolvedor Java – Sênior – Qtd ( ) Analista Desenvolvedor PHP – Sênior – Qtd ( ) Analista Desenvolvedor .NET – Sênior – Qtd ( ) ( ) Prorrogação do Término da OS para: DD/MM/AAAA ( ) Antecipação da OS para: DD/MM/AAAA | |
Representantes da CESAN | NOME – MATRÍCULA (Gestor ou Fiscal do Contrato) | |
Ciência do representante da CONTRATADA | NOME – CPF – Cargo na empresa | |