MSTECH wiki - Contribuições do usuário [pt-br]

Diretrizes de Gestão de Configuração

2017-03-21T14:56:25Z

Lucimara.maiorali:

== Objetivo ==
Esta página descreve como estão definidos os níveis de controle, itens de configuração, ''baselines'' nos projetos e processos organizacionais de Gestão de Portfólio de Projetos e Medição.

== Níveis de Controle ==

Os documentos e artefatos gerados pelos projetos e processos organizacionais são considerados itens de configuração e são classificados entre:

* Formal
Itens controlados com histórico de alterações e recuperação de versões anteriores. São artefatos que definem os requisitos e que contenham informações para a produção do produto a ser entregue (Exemplos: códigos fonte, documento de arquitetura, documentos técnicos enviados pelo cliente, outros documentos técnicos).
As modificações em artefatos formais são vinculadas a tasks no Youtrack, por meio da referência do ''commit'' realizado para alteração do documento na tarefa de alteração.

* Versionado
Itens controlados com histórico de alterações e recuperação de versões anteriores, sem a necessidade de solicitação formal para a realização de alterações. São artefatos de gestão (por exemplo: atas, relatórios gerenciais, coleta de indicadores) e demais artefatos que não se encaixem como “Formal”.

'''Controle de Acessos'''

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" rowspan=2 |Papeis
! scope="col" colspan=8 |Repositórios
|-
! scope="col"| Gestão de Projetos (Redmine)
! scope="col"| Gestão de Produtos (GitLab)
! scope="col"| Gestão de Produtos (Youtrack)
! scope="col"| Garantia de Qualidade (Redmine)
! scope="col"| Gestão de Portfólio de Projetos (Redmine)
! scope="col"| Gestão de Portfólio de Projetos (Sharepoint)
! scope="col"| Medição (Redmine)
! scope="col"| Diretrizes (Processo)
|-
|Analista de Controladoria
|Não se aplica
|Não se aplica
|Leitura
|Não se aplica
|Não se aplica
|Colaboração
|Não se aplica
|Leitura
|-
|Analista de PCP
|Colaboração
|Não se aplica
|Colaboração
|Leitura
|Colaboração
|Colaboração
|Colaboração
|Colaboração
|-
|Analista de Operações
|Leitura
|Colaboração
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Analistas de QA
|Leitura
|Leitura
|Leitura
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Analistas de Testes
|Colaboração
|Colaboração
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Arquiteto de Software
|Colaboração
|Colaboração
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Auditor Técnico de Baseline
|Colaboração
|Colaboração
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Desenvolvedores
|Colaboração
|Colaboração
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Designer
|Colaboração
|Colaboração
|Colaboração
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Product Owner
|Colaboração
|Não se aplica
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Responsável pela Oportunidade
|Leitura
|Não se aplica
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Responsável por GPP
|Colaboração
|Não se aplica
|Leitura
|Leitura
|Colaboração
|Colaboração
|Leitura
|Leitura
|-
|Scrum Master
|Colaboração
|Colaboração
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|-
|}

Para cada célula, haverá um membro da equipe (Scrum Master) com acesso suficiente para administrar as permissões dos repositórios técnicos de produtos atendidos pela célula. Na falta desse integrante, deve ser nomeado um substituto para assumir a responsabilidade de manter as permissões dos repositórios devidamente atribuídas.

== Itens de configuração por repositório ==

Os projetos utilizam pelo menos dois repositórios distintos: um para os artefatos de gestão (nomeado nesse documento como repositório de gestão) e outro para os artefatos que compõem o produto a ser produzido ou mantido (nomeado nesse documento como repositório de produto).

Os projetos devem indicar os repositórios a serem utilizados, podendo utilizar mais de um repositório de produto. Os processos organizacionais possuem pelo menos um repositório para armazenamento de artefatos e registros de ações de acompanhamento.

As tabelas abaixo mostram a identificação dos itens de configuração e as seguintes informações: identificação do item, regra de nomenclatura, local para armazenamento, nível de controle, obrigatoriedade de ser gerado, necessidade de aprovação pelo cliente e ''baseline'' onde é incorporado.

* '''Repositórios de gestão do projeto'''
O repositório de gestão utiliza a ferramenta Redmine e esse ambiente é administrado pela MSTECH. A utilização desse repositório é obrigatória para todos os projetos de desenvolvimento de software.
Além disso, é utilizado um repositório na ferramenta Sharepoint, com a finalidade de armazenar informações contábeis dos projetos. A utilização deste repositório é obrigatória a todos os projetos e o ambiente é administrado pela MSTECH.

''http://redmine.mstech.com.br/ > Projetos > Nome do Projeto''

''http://portal.mstech.com.br/epcp/Lists/Projetos%20e%20prprojetos/AllItems.aspx''

Redmine:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Necessidades do cliente*
|(Nome do projeto)-NecessidadesCliente
|Documentos do pré-projeto no Redmine
|Versionado
|Sim
|Sim
|Entrega
|-
|Plano de projeto inicial
|(Nome do projeto)-PlanoProjetoInicial
|Documentos do pré-projeto no Redmine
|Versionado
|Sim
|Não
|Não íntegra
|-
|Checklist de auditoria de iniciação
|(Nome do projeto)-ChecklistIniciação
|Tarefa de auditoria de iniciação no Redmine do pré-projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Plano de projeto
|Não se aplica
|Wiki do Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Cronograma do projeto
|Não se aplica
|Gantt/ Calendário do Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Riscos do projeto
|Não se aplica
|Tarefa de risco no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Análise de viabilidade inicial
|Não se aplica
|Tarefa de análise de viabilidade inicial no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de comprometimento da equipe
|Não se aplica
|Tarefa de registro de validação de planejamento no Redmine no projeto + apontamento de horas do ''planning'', no ''Youtrack''
|Versionado
|Sim
|Não
|Não íntegra
|-
|Checklist de auditoria de planejamento
|(Nome do projeto)-ChecklistPlanejamento
|Tarefa de auditoria de planejamento no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Termo de aceite
|(Nome do projeto)-TermoAceite
|Documentos no no Redmine do projeto
|Versionado
|Sim
|Sim
|Não íntegra
|-
|Revisão de resultados do projeto
|Não se aplica
|Tarefa de revisão de resultados no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de problema do projeto
|Não se aplica
|Tarefa de problema no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Checklist de auditoria de encerramento
|(Nome do projeto)-ChecklistEncerramento
|Tarefa de auditoria de encerramento no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de ponto de controle
|Não se aplica
|Tarefa de ponto de controle no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de revisão de marco
|Não se aplica
|Tarefa de ponto de controle indicando revisão de marco no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de mudança
|Não se aplica
|Tarefa de registro de mudança no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Análise de viabilidade periódica
|Não se aplica
|Informação na tarefa de ponto de controle no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de lição aprendida do projeto
|Não se aplica
|Tarefa de lição aprendida no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de não conformidade de projeto
|Não se aplica
|Tarefa de não conformidade no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de cancelamento/ suspensão do projeto
|Não se aplica
|Tarefa de cancelamento/ suspensão do projeto no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Relatório de entrega
|(Nome do projeto)-RelatorioEntrega
|Documentos no Redmine do projeto
|Versionado
|Sim
|Sim
|Não íntegra
|-
|Checklist de auditoria de entrega
|(Nome do projeto)-ChecklistEntrega
|Anexo na tarefa de auditoria de entrega no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|}

''* O documento é inserido no repositório técnico na fase de execução do projeto para que integre a baseline.''

SharePoint:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Ordem de serviço interna (pré-projeto)
|(Nome do pré-projeto)-OrdemServiço_(AAAAXXXXXX)
|Registro do projeto do Sharepoint
|Versionado
|Sim
|Não
|Não íntegra
|-
|Ordem de serviço interna (projeto)
|(Nome do projeto)-OrdemServiço_(AAAAXXXXXX)
|Registro do projeto do Sharepoint
|Versionado
|Sim
|Não
|Não íntegra
|}

* '''Repositórios de Produto'''
O repositório de artefatos técnicos do produto utiliza a ferramenta GitLab. O ambiente é administrado pela MSTECH e cada registro de projeto (na ferramenta SharePoint) possui a informação do nome do grupo do respectivo repositório. A utilização desses repositórios é obrigatória para todos os projetos.
Além disso, a ferramenta Youtrack deve ser utilizada para gestão do backlog dos produtos e apontamento de horas.

''http://gitlab.mstech.com.br/ > Projects > Groups > Grupo de Repositórios > Repositórios''

''https://youtrack.mstech.com.br/ > Projects > Container do produto''

GitLab:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Código-fonte
|Não se aplica
|Pasta “src” no repositório do produto
|Formal
|Sim
|Não
|Entrega
|-
|Manual de instalação e atualização
|Manual de instalação e atualização
|Wiki no repositório do produto/ Wiki do repositório "docs"
|Formal
|Não
|Não
|Entrega
|-
|Documento de arquitetura
|Arquitetura do Produto
|Wiki no repositório do produto/ Wiki do repositório "docs"
|Formal
|Sim
|Não
|Não íntegra
|-
|Necessidades do cliente
|(Nome do projeto)-NecessidadesCliente
|Repositório “docs” no(s) grupo(s) do produto
|Formal
|Sim
|Sim
|Entrega
|}

Youtrack:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Backlog da sprint
|Não se aplica
|Container do projeto no Youtrack
|Versionado
|Sim
|Não
|Não íntegra
|-
|Caso de teste
|Não se aplica
|Comentários nas tarefas de teste no container do projeto no Youtrack
|Formal
|Sim
|Não
|Não íntegra
|-
|Registro do sprint planning
|Planning - Sprint (nome da sprint)
|Comentário na tarefa de planning no container do projeto no Youtrack
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro do sprint review
|Review - Sprint (nome da sprint)
|Comentário na tarefa de review no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Tarefa de publicação em homologação
|Publicação em Homologação - v(número da versão)
|Container do projeto no Youtrack
|Versionado
|Sim
|Não
|Não íntegra
|-
|Tarefa de publicação em produção
|Publicação em Produção - v(número da versão)
|Container do projeto no Youtrack
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro da retrospectiva
|Retrospectiva - Sprint (nome da sprint)
|Comentário na tarefa de retrospectiva no container do projeto no Youtrack
|Versionado
|Sim
|Não
|Não íntegra
|}

* '''Repositório de Garantia da Qualidade'''
O repositório oficial de Garantia da Qualidade utiliza a ferramenta Redmine com o nome “Garantia da Qualidade”. O ambiente é administrado pela MSTECH e sua utilização é obrigatória.

''http://redmine.mstech.com.br/ > Projetos > Garantia da Qualidade''

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Cronograma de auditorias do QA
|Não se aplica
|Gantt/ Calendário do Redmine do QA
|Versionado
|Sim
|Não
|Não íntegra
|-
|Plano de Garantia da Qualidade
|Plano de Garantia da Qualidade
|Wiki no Redmine do QA
|Formal
|Sim
|Não
|Não íntegra
|-
|Relatório Gerencial QA
|RelatórioGerencialQA_DD_MM_AAAA
|Documentos no Redmine do QA
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de lição aprendida do QA
|Não se aplica
|Tarefa de lição aprendida no Redmine do QA
|Versionado
|Sim
|Não
|Não íntegra
|}

* '''Repositório de Gestão de Portfólio de Projetos'''
O repositório de uso do processo de Gestão de Portfólio de Projetos encontra-se na ferramenta Redmine com o nome “Gestão de Portfólio de Projetos”. O ambiente é mantido pela MSTECH e sua utilização é obrigatória.

''http://redmine.mstech.com.br/ > Projetos > Gestão de Portfólio de Projetos''

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Registro de não conformidade de GPP
|Não se aplica
|Tarefa de não conformidade no Redmine de GPP
|Versionado
|Não
|Não
|Não íntegra
|-
|Registro de lição aprendida de GPP
|Não se aplica
|Tarefa de lição aprendida no Redmine de GPP
|Versionado
|Sim
|Não
|Não íntegra
|-
|Objetivos estratégicos de GPP
|Objetivos Estratégicos
|Documentos no Redmine de GPP
|Formal
|Sim
|Não
|Não íntegra
|-
|Checklist de auditoria de execução de GPP
|GPP-ChecklistExecução
|Anexo na tarefa de auditoria de execução de GPP no Redmine de GPP
|Versionado
|Sim
|Não
|Não íntegra
|-
|Checklist de auditoria de planejamento anual de GPP
|GPP-ChecklistPlanejamentoAnual
|Anexo na tarefa de auditoria de planejamento anual de GPP no Redmine de GPP
|Versionado
|Sim
|Não
|Não íntegra
|-
|Análise de Viabilidade dos projetos
|Não se aplica
|Confirmação da viabilidade no Redmine de GPP
|Versionado
|Sim
|Não
|Não íntegra
|-
|Análise de cancelamento
|Não se aplica
|Tarefa de análise de cancelamento no Redmine de GPP
|Versionado
|Sim
|Não
|Não íntegra
|-
|Priorização de projetos
|Não se aplica
|Registro da priorização na lista de priorização de demandas, no Sharepoint
|Versionado
|Sim
|Não
|Não íntegra
|-
|Planos de ação
|Não se aplica
|Tarefas do tipo problema no Redmine de Gestão de Portfólio
|Versionado
|Sim
|Não
|Não íntegra
|-
|Planilhas de coleta de indicadores
|Global_MED_DD.MM.AAAA
|Documentos no Redmine de Gestão de Portfólio
|Versionado
|Sim
|Não
|Não íntegra
|-
|Reporte Mensal da Situação do Portfólio
|Global_MED_DD.MM.AAAA
|Documentos no Redmine de Gestão de Portfólio
|Versionado
|Sim
|Não
|Não íntegra
|-
|Critérios de aceite
|(Nome da oportunidade)-CriteriosAceite_AAAA
|Anexo ao registro da oportunidade de negócios
|Versionado
|Sim
|Não
|Não íntegra
|-
|Planejamento Anual
|PlanejamentoAnual_GPP_AAAA
|Documentos no projeto de Gestão de Portfólio de Projetos no Redmine
|Versionado
|Sim
|Não
|Não íntegra
|}

* '''Repositório de Medição'''
O repositório para armazenamento de artefatos concluídos de medição (com exceção de artefatos gerados pela coleta de indicadores de projetos) e análises de indicadores utiliza a ferramenta Redmine com o nome “Medição”. O ambiente é administrado pela MSTECH e sua utilização é obrigatória.

''http://redmine.mstech.com.br/ > Projetos > Medição''

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Planilha de coleta de indicadores globais
|Global_MED_DD-MM-AAAA
|Anexo na tarefa de coleta no Redmine de Medição
|Versionado
|Sim
|Não
|Não íntegra
|-
|Planilha de coleta de indicadores de projetos
|(Nome do projeto)_MED_DD-MM-AAAA
|Anexo na tarefa de coleta no Redmine de Medição
|Versionado
|Sim
|Não
|Não íntegra
|-
|Diretrizes de Medição
|MED_Diretrizes_AAAA
|Documentos no Redmine de Medição
|Versionado
|Sim
|Não
|Não íntegra
|}

* '''Repositório de Diretrizes'''
Todas as diretrizes existentes são mantidas na wiki corporativa da MSTECH, com exceção das diretrizes de Medição, que pode ser encontrada na página de processos, em "Medição".

''https://wiki.mstech.com.br/ > Padrões de Desenvolvimento MSTECH > Diretrizes''

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Diretrizes de Comunicação
|Diretrizes de Comunicação
|Página de padrões de desenvolvimento da MSTECH na Wiki corporativa
|Versionado
|Sim
|Não
|Não íntegra
|-
|Diretrizes de Gestão de Configuração
|Diretrizes de Gestão de Configuração
|Página de padrões de desenvolvimento da MSTECH na Wiki corporativa
|Versionado
|Sim
|Não
|Não íntegra
|-
|Diretrizes de Medição
|Diretrizes de Medição
|Página de processos
|Versionado
|Sim
|Não
|Não íntegra
|}

== ''Baseline'' de Produto ==

A ''baseline'' de cada entrega do produto é composta pela ''baseline'' de cada um dos repositórios alterados na entrega. As ''baselines'' são identificadas por ''tags'' no GitLab e deverão ser nomeadas de acordo com a regra abaixo, sendo que, os valores correspondem à versão do produto ou do documento.

'''v<X.X.X>'''

'''Exemplo:''' v1.2.1

A composição das ''baselines'' deve estar descrita no diário de bordo de cada projeto, localizado na wiki do Redmine.

Diretrizes de Gestão de Configuração

2017-03-21T14:46:36Z

Lucimara.maiorali:

== Objetivo ==
Esta página descreve como estão definidos os níveis de controle, itens de configuração, ''baselines'' nos projetos e processos organizacionais de Gestão de Portfólio de Projetos e Medição.

== Níveis de Controle ==

Os documentos e artefatos gerados pelos projetos e processos organizacionais são considerados itens de configuração e são classificados entre:

* Formal
Itens controlados com histórico de alterações e recuperação de versões anteriores. São artefatos que definem os requisitos e que contenham informações para a produção do produto a ser entregue (Exemplos: códigos fonte, documento de arquitetura, documentos técnicos enviados pelo cliente, outros documentos técnicos).
As modificações em artefatos formais são vinculadas a tasks no Youtrack, por meio da referência do ''commit'' realizado para alteração do documento na tarefa de alteração.

* Versionado
Itens controlados com histórico de alterações e recuperação de versões anteriores, sem a necessidade de solicitação formal para a realização de alterações. São artefatos de gestão (por exemplo: atas, relatórios gerenciais, coleta de indicadores) e demais artefatos que não se encaixem como “Formal”.

'''Controle de Acessos'''

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" rowspan=2 |Papeis
! scope="col" colspan=8 |Repositórios
|-
! scope="col"| Gestão de Projetos (Redmine)
! scope="col"| Gestão de Produtos (GitLab)
! scope="col"| Gestão de Produtos (Youtrack)
! scope="col"| Garantia de Qualidade (Redmine)
! scope="col"| Gestão de Portfólio de Projetos (Redmine)
! scope="col"| Gestão de Portfólio de Projetos (Sharepoint)
! scope="col"| Medição (Redmine)
! scope="col"| Diretrizes (Processo)
|-
|Analista de Controladoria
|Não se aplica
|Não se aplica
|Leitura
|Não se aplica
|Não se aplica
|Colaboração
|Não se aplica
|Leitura
|-
|Analista de PCP
|Colaboração
|Não se aplica
|Colaboração
|Leitura
|Colaboração
|Colaboração
|Colaboração
|Colaboração
|-
|Analista de Operações
|Leitura
|Colaboração
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Analistas de QA
|Leitura
|Leitura
|Leitura
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Analistas de Testes
|Colaboração
|Colaboração
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Arquiteto de Software
|Colaboração
|Colaboração
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Auditor Técnico de Baseline
|Colaboração
|Colaboração
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Desenvolvedores
|Colaboração
|Colaboração
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Designer
|Colaboração
|Colaboração
|Colaboração
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Product Owner
|Colaboração
|Não se aplica
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Responsável pela Oportunidade
|Leitura
|Não se aplica
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Responsável por GPP
|Colaboração
|Não se aplica
|Leitura
|Leitura
|Colaboração
|Colaboração
|Leitura
|Leitura
|-
|Scrum Master
|Colaboração
|Colaboração
|Colaboração
|Leitura
|Leitura
|Leitura
|Leitura
|Leitura
|-
|}

Para cada célula, haverá um membro da equipe (Scrum Master) com acesso suficiente para administrar as permissões dos repositórios técnicos de produtos atendidos pela célula. Na falta desse integrante, deve ser nomeado um substituto para assumir a responsabilidade de manter as permissões dos repositórios devidamente atribuídas.

== Itens de configuração por repositório ==

Os projetos utilizam pelo menos dois repositórios distintos: um para os artefatos de gestão (nomeado nesse documento como repositório de gestão) e outro para os artefatos que compõem o produto a ser produzido ou mantido (nomeado nesse documento como repositório de produto).

Os projetos devem indicar os repositórios a serem utilizados, podendo utilizar mais de um repositório de produto. Os processos organizacionais possuem pelo menos um repositório para armazenamento de artefatos e registros de ações de acompanhamento.

As tabelas abaixo mostram a identificação dos itens de configuração e as seguintes informações: identificação do item, regra de nomenclatura, local para armazenamento, nível de controle, obrigatoriedade de ser gerado, necessidade de aprovação pelo cliente e ''baseline'' onde é incorporado.

* '''Repositórios de gestão do projeto'''
O repositório de gestão utiliza a ferramenta Redmine e esse ambiente é administrado pela MSTECH. A utilização desse repositório é obrigatória para todos os projetos de desenvolvimento de software.
Além disso, é utilizado um repositório na ferramenta Sharepoint, com a finalidade de armazenar informações contábeis dos projetos. A utilização deste repositório é obrigatória a todos os projetos e o ambiente é administrado pela MSTECH.

''http://redmine.mstech.com.br/ > Projetos > Nome do Projeto''

''http://portal.mstech.com.br/epcp/Lists/Projetos%20e%20prprojetos/AllItems.aspx''

Redmine:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Necessidades do cliente*
|(Nome do projeto)-NecessidadesCliente
|Documentos do pré-projeto no Redmine
|Versionado
|Sim
|Sim
|Entrega
|-
|Plano de projeto inicial
|(Nome do projeto)-PlanoProjetoInicial
|Documentos do pré-projeto no Redmine
|Versionado
|Sim
|Não
|Não íntegra
|-
|Checklist de auditoria de iniciação
|(Nome do projeto)-ChecklistIniciação
|Tarefa de auditoria de iniciação no Redmine do pré-projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Plano de projeto
|Não se aplica
|Wiki do Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Cronograma do projeto
|Não se aplica
|Gantt/ Calendário do Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Riscos do projeto
|Não se aplica
|Tarefa de risco no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Análise de viabilidade inicial
|Não se aplica
|Tarefa de análise de viabilidade inicial no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de comprometimento da equipe
|Não se aplica
|Tarefa de registro de validação de planejamento no Redmine no projeto + apontamento de horas do ''planning'', no ''Youtrack''
|Versionado
|Sim
|Não
|Não íntegra
|-
|Checklist de auditoria de planejamento
|(Nome do projeto)-ChecklistPlanejamento
|Tarefa de auditoria de planejamento no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Termo de aceite
|(Nome do projeto)-TermoAceite
|Documentos no no Redmine do projeto
|Versionado
|Sim
|Sim
|Não íntegra
|-
|Revisão de resultados do projeto
|Não se aplica
|Tarefa de revisão de resultados no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de problema do projeto
|Não se aplica
|Tarefa de problema no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Checklist de auditoria de encerramento
|(Nome do projeto)-ChecklistEncerramento
|Tarefa de auditoria de encerramento no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de ponto de controle
|Não se aplica
|Tarefa de ponto de controle no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de revisão de marco
|Não se aplica
|Tarefa de ponto de controle indicando revisão de marco no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de mudança
|Não se aplica
|Tarefa de registro de mudança no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Análise de viabilidade periódica
|Não se aplica
|Informação na tarefa de ponto de controle no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de lição aprendida do projeto
|Não se aplica
|Tarefa de lição aprendida no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de não conformidade de projeto
|Não se aplica
|Tarefa de não conformidade no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de cancelamento/ suspensão do projeto
|Não se aplica
|Tarefa de cancelamento/ suspensão do projeto no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Relatório de entrega
|(Nome do projeto)-RelatorioEntrega
|Documentos no Redmine do projeto
|Versionado
|Sim
|Sim
|Não íntegra
|-
|Checklist de auditoria periódica de projeto
|(Nome do projeto)-ChecklistPeriódica
|Anexo na tarefa de auditoria periódica do projeto no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Checklist de auditoria de entrega
|(Nome do projeto)-ChecklistEntrega
|Anexo na tarefa de auditoria de entrega no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|}

''* O documento é inserido no repositório técnico na fase de execução do projeto para que integre a baseline.''

SharePoint:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Ordem de serviço interna (pré-projeto)
|(Nome do pré-projeto)-OrdemServiço_(AAAAXXXXXX)
|Registro do projeto do Sharepoint
|Versionado
|Sim
|Não
|Não íntegra
|-
|Ordem de serviço interna (projeto)
|(Nome do projeto)-OrdemServiço_(AAAAXXXXXX)
|Registro do projeto do Sharepoint
|Versionado
|Sim
|Não
|Não íntegra
|}

* '''Repositórios de Produto'''
O repositório de artefatos técnicos do produto utiliza a ferramenta GitLab. O ambiente é administrado pela MSTECH e cada registro de projeto (na ferramenta SharePoint) possui a informação do nome do grupo do respectivo repositório. A utilização desses repositórios é obrigatória para todos os projetos.
Além disso, a ferramenta Youtrack deve ser utilizada para gestão do backlog dos produtos e apontamento de horas.

''http://gitlab.mstech.com.br/ > Projects > Groups > Grupo de Repositórios > Repositórios''

''https://youtrack.mstech.com.br/ > Projects > Container do produto''

GitLab:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Código-fonte
|Não se aplica
|Pasta “src” no repositório do produto
|Formal
|Sim
|Não
|Entrega
|-
|Manual de instalação e atualização
|Manual de instalação e atualização
|Wiki no repositório do produto/ Wiki do repositório "docs"
|Formal
|Não
|Não
|Entrega
|-
|Documento de arquitetura
|Arquitetura do Produto
|Wiki no repositório do produto/ Wiki do repositório "docs"
|Formal
|Sim
|Não
|Não íntegra
|-
|Necessidades do cliente
|(Nome do projeto)-NecessidadesCliente
|Repositório “docs” no(s) grupo(s) do produto
|Formal
|Sim
|Sim
|Entrega
|}

Youtrack:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Backlog da sprint
|Não se aplica
|Container do projeto no Youtrack
|Versionado
|Sim
|Não
|Não íntegra
|-
|Caso de teste
|Não se aplica
|Comentários nas tarefas de teste no container do projeto no Youtrack
|Formal
|Sim
|Não
|Não íntegra
|-
|Registro do sprint planning
|Planning - Sprint (nome da sprint)
|Comentário na tarefa de planning no container do projeto no Youtrack
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro do sprint review
|Review - Sprint (nome da sprint)
|Comentário na tarefa de review no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Tarefa de publicação em homologação
|Publicação em Homologação - v(número da versão)
|Container do projeto no Youtrack
|Versionado
|Sim
|Não
|Não íntegra
|-
|Tarefa de publicação em produção
|Publicação em Produção - v(número da versão)
|Container do projeto no Youtrack
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro da retrospectiva
|Retrospectiva - Sprint (nome da sprint)
|Comentário na tarefa de retrospectiva no container do projeto no Youtrack
|Versionado
|Sim
|Não
|Não íntegra
|}

* '''Repositório de Garantia da Qualidade'''
O repositório oficial de Garantia da Qualidade utiliza a ferramenta Redmine com o nome “Garantia da Qualidade”. O ambiente é administrado pela MSTECH e sua utilização é obrigatória.

''http://redmine.mstech.com.br/ > Projetos > Garantia da Qualidade''

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Cronograma de auditorias do QA
|Não se aplica
|Gantt/ Calendário do Redmine do QA
|Versionado
|Sim
|Não
|Não íntegra
|-
|Plano de Garantia da Qualidade
|Plano de Garantia da Qualidade
|Wiki no Redmine do QA
|Formal
|Sim
|Não
|Não íntegra
|-
|Relatório Gerencial QA
|RelatórioGerencialQA_DD_MM_AAAA
|Documentos no Redmine do QA
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de lição aprendida do QA
|Não se aplica
|Tarefa de lição aprendida no Redmine do QA
|Versionado
|Sim
|Não
|Não íntegra
|}

* '''Repositório de Gestão de Portfólio de Projetos'''
O repositório de uso do processo de Gestão de Portfólio de Projetos encontra-se na ferramenta Redmine com o nome “Gestão de Portfólio de Projetos”. O ambiente é mantido pela MSTECH e sua utilização é obrigatória.

''http://redmine.mstech.com.br/ > Projetos > Gestão de Portfólio de Projetos''

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Registro de não conformidade de GPP
|Não se aplica
|Tarefa de não conformidade no Redmine de GPP
|Versionado
|Não
|Não
|Não íntegra
|-
|Registro de lição aprendida de GPP
|Não se aplica
|Tarefa de lição aprendida no Redmine de GPP
|Versionado
|Sim
|Não
|Não íntegra
|-
|Objetivos estratégicos de GPP
|Objetivos Estratégicos
|Documentos no Redmine de GPP
|Formal
|Sim
|Não
|Não íntegra
|-
|Checklist de auditoria de execução de GPP
|GPP-ChecklistExecução
|Anexo na tarefa de auditoria de execução de GPP no Redmine de GPP
|Versionado
|Sim
|Não
|Não íntegra
|-
|Checklist de auditoria de planejamento anual de GPP
|GPP-ChecklistPlanejamentoAnual
|Anexo na tarefa de auditoria de planejamento anual de GPP no Redmine de GPP
|Versionado
|Sim
|Não
|Não íntegra
|-
|Análise de Viabilidade dos projetos
|Não se aplica
|Confirmação da viabilidade no Redmine de GPP
|Versionado
|Sim
|Não
|Não íntegra
|-
|Análise de cancelamento
|Não se aplica
|Tarefa de análise de cancelamento no Redmine de GPP
|Versionado
|Sim
|Não
|Não íntegra
|-
|Priorização de projetos
|Não se aplica
|Registro da priorização na lista de priorização de demandas, no Sharepoint
|Versionado
|Sim
|Não
|Não íntegra
|-
|Planos de ação
|Não se aplica
|Tarefas do tipo problema no Redmine de Gestão de Portfólio
|Versionado
|Sim
|Não
|Não íntegra
|-
|Planilhas de coleta de indicadores
|Global_MED_DD.MM.AAAA
|Documentos no Redmine de Gestão de Portfólio
|Versionado
|Sim
|Não
|Não íntegra
|-
|Reporte Mensal da Situação do Portfólio
|Global_MED_DD.MM.AAAA
|Documentos no Redmine de Gestão de Portfólio
|Versionado
|Sim
|Não
|Não íntegra
|-
|Critérios de aceite
|(Nome da oportunidade)-CriteriosAceite_AAAA
|Anexo ao registro da oportunidade de negócios
|Versionado
|Sim
|Não
|Não íntegra
|-
|Planejamento Anual
|PlanejamentoAnual_GPP_AAAA
|Documentos no projeto de Gestão de Portfólio de Projetos no Redmine
|Versionado
|Sim
|Não
|Não íntegra
|}

* '''Repositório de Medição'''
O repositório para armazenamento de artefatos concluídos de medição (com exceção de artefatos gerados pela coleta de indicadores de projetos) e análises de indicadores utiliza a ferramenta Redmine com o nome “Medição”. O ambiente é administrado pela MSTECH e sua utilização é obrigatória.

''http://redmine.mstech.com.br/ > Projetos > Medição''

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Planilha de coleta de indicadores globais
|Global_MED_DD-MM-AAAA
|Anexo na tarefa de coleta no Redmine de Medição
|Versionado
|Sim
|Não
|Não íntegra
|-
|Planilha de coleta de indicadores de projetos
|(Nome do projeto)_MED_DD-MM-AAAA
|Anexo na tarefa de coleta no Redmine de Medição
|Versionado
|Sim
|Não
|Não íntegra
|-
|Diretrizes de Medição
|MED_Diretrizes_AAAA
|Documentos no Redmine de Medição
|Versionado
|Sim
|Não
|Não íntegra
|}

* '''Repositório de Diretrizes'''
Todas as diretrizes existentes são mantidas na wiki corporativa da MSTECH, com exceção das diretrizes de Medição, que pode ser encontrada na página de processos, em "Medição".

''https://wiki.mstech.com.br/ > Padrões de Desenvolvimento MSTECH > Diretrizes''

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Diretrizes de Comunicação
|Diretrizes de Comunicação
|Página de padrões de desenvolvimento da MSTECH na Wiki corporativa
|Versionado
|Sim
|Não
|Não íntegra
|-
|Diretrizes de Gestão de Configuração
|Diretrizes de Gestão de Configuração
|Página de padrões de desenvolvimento da MSTECH na Wiki corporativa
|Versionado
|Sim
|Não
|Não íntegra
|-
|Diretrizes de Medição
|Diretrizes de Medição
|Página de processos
|Versionado
|Sim
|Não
|Não íntegra
|}

== ''Baseline'' de Produto ==

A ''baseline'' de cada entrega do produto é composta pela ''baseline'' de cada um dos repositórios alterados na entrega. As ''baselines'' são identificadas por ''tags'' no GitLab e deverão ser nomeadas de acordo com a regra abaixo, sendo que, os valores correspondem à versão do produto ou do documento.

'''v<X.X.X>'''

'''Exemplo:''' v1.2.1

A composição das ''baselines'' deve estar descrita no diário de bordo de cada projeto, localizado na wiki do Redmine.

Políticas dos processos MSTECH

2016-12-09T19:13:42Z

Lucimara.maiorali:

* [https://wikipedia.mstech.com.br/index.php/Politica_de_Padronizacao_de_Codigo_MSTECH Política de Padronização de Código da MSTECH] - '''(em construção)'''

* [https://wikipedia.mstech.com.br/index.php/Politica_Organizacional_MSTECH Política Organizacional da MSTECH]

* [[Política de Medição]]

Politica Organizacional MSTECH

2016-12-09T19:13:06Z

Lucimara.maiorali:

'''Versão 3.0'''

A Política Organizacional da MSTECH EDUCAÇÃO E TECNOLOGIA EIRELI abrange regras, métodos e conceitos para os projetos de '''Desenvolvimento de Software''' de '''toda a empresa'''. Este documento possui caráter oficial e tange como modelo de referência.

A página oficial dos Processos de Trabalho está disponível para toda a empresa. O local contém o Ciclo de Vida dos Projetos de Desenvolvimento de Software, além do fluxo geral dos Processos de Trabalho para Desenvolvimento de Software, Garantia da Qualidade e Gestão de Portfólio de Projetos. Por fim, há todos os templates de documentos utilizados pelo Processo de Desenvolvimento de Software e outros conteúdos importantes que auxiliam todos na utilização dos Processos de Trabalho. '''Todos os projetos de Desenvolvimento de Software''' (exceto Pesquisa e Desenvolvimento) '''da MSTECH devem utilizar os conteúdos supracitados''', de acordo com suas respectivas regras, além dos sistemas computacionais configurados para a gestão dos projetos/produtos e os softwares auxiliares que integram essas ferramentas.

O '''Processo de Trabalho de Desenvolvimento de Software''' é utilizado diretamente pelas áreas de '''Gestão de Projetos''' e de '''Requisitos''' e '''Gestão de Configuração'''. Suas quatro fases são cronológicas e possuem relação direta. Entretanto, a primeira e a última fase são únicas por projeto, e as intermediárias se repetem (cíclicas, não necessariamente de forma linear, tornando o processo iterativo) de acordo com o número de entregas do projeto. Há também etapas de monitoramento, que abrangem paralelamente todo o processo. Seu principal objetivo é conceder aos projetos de Desenvolvimento de Software padrões e procedimentos, visando garantir qualidade, desempenho e completa satisfação dos clientes, com resultados de alto valor agregado e condizentes com as necessidades estabelecidas. O processo deverá padronizar as atividades para as equipes de desenvolvimento da empresa, garantindo uniformidade em suas atividades de desenvolvimento de software. O processo deverá ser atualizado sempre que necessário, garantindo aderência para a realidade e objetivos estratégicos da MSTECH.

Todos os documentos obrigatórios e auxiliares dos projetos deverão ficar armazenados nos locais definidos pelo processo de desenvolvimento de software, sendo mantido para isso um sistema que possui a função de repositório. Nenhum documento deve conter informações de custos em valores monetários, tendo os custos apenas a tratativa em horas. Já os artefatos técnicos, que farão parte do Produto desenvolvido pelo projeto, deverão estar presentes no Sistema de Gestão de Configuração, contemplados como parte das Baselines do Produto. Todas as alterações nos documentos precisam ser registra-das nos respectivos locais de armazenamento, de acordo com as diretrizes da Gestão de Configuração (GCO), assim como as demais regras de acesso, nomenclaturas e controles de versões.

O '''Processo de Trabalho de Gestão de Portfólio de Projetos''' é utilizado pelos responsáveis da Gestão de Portfólio de Projetos (GPP) e tem como objetivo principal realizar a gestão da carteira de projetos e clientes da MSTECH. O processo possui duas fases, sendo que a primeira é executada anualmente (ou quando for estritamente necessário) e a segunda é cíclica. Através da definição dos Fatores Comerciais e suas respectivas Priorizações, a Presidência, em conjunto com o responsável da Gestão de Portfólio de Projetos deverá organizar os Objetivos Estratégicos da empresa e, por fim, oficializar a Estratégia do Portfólio de Projetos. Tal Estratégia visa manter a aderência dos processos e projetos de acordo com os objetivos organizacionais, buscando, como foco principal, resultados satisfatórios para os clientes.

O '''Processo de Trabalho de Garantia da Qualidade''' é utilizado pela equipe QA e demonstra a expectativa da empresa na aderência e conformidade das atividades executadas com base nos Processos de Trabalho definidos. Este processo garantirá que todos os Processos de Trabalho definidos estão sendo seguidos de forma correta e íntegra.

As auditorias de garantia da qualidade dos projetos devem ser planejadas nas fases do ciclo de vida do projeto, nos marcos de 50% (projetos com duração dois meses), mensal (projetos com duração maior que dois meses) e antes das entregas ao cliente, no que tange as auditorias de garantia da qualidade do processo organizacional da Gestão de Portfólio de Projetos devem ser planejadas no “Plano de Garantia da Qualidade”. Nesse contexto, o documento “Plano de Garantia da Qualidade” deverá ser elaborado anualmente e, atualizado juntamente com esta Política Organizacional, servindo de suporte para a equipe QA, sendo mantidos nas ferramentas da empresa. Por fim, é importante ressaltar que a auditoria Independente de QA deverá ser planejada anualmente.

Todas as auditorias de garantia da qualidade devem ser executadas com a utilização de checklists de garantia da qualidade. Toda não conformidade identificada será acompanhada até a sua resolução seguindo às criticidades e prazos definidos no “Processo de Trabalho de Garantia da Qualidade”. As não conformidades não solucionadas no prazo definido pela criticidade deverão ser escalonadas ao superior imediato conforme organograma da empresa.

Os resultados das auditorias de garantia da qualidade deverão ser reportados conforme definido no “Processo de Trabalho de Garantia da Qualidade”.

Os '''Indicadores''' (resultado de '''Medição''') são itens essenciais para a gestão da empresa, pois apresentam, de forma condensada e objetiva, conforme necessário, a situação da empresa em diversos aspectos. Os Indicadores devem fornecer informações para:

'''•''' Manter a aderência nos processos de trabalho estabelecidos, de forma geral e/ou em etapas/atividades específicas;

'''•''' Gerenciar a situação dos projetos, no que tange prazo e esforço;

'''•''' Aprimorar as estimativas para o planejamento dos projetos;

'''•''' Apresentar subsídios para avaliar os próprios Indicadores estabelecidos.

Todo o planejamento, desde a coleta dos Indicadores, até as ações oriundas dos resultados das Medições, está documentado e oficializado nas Diretrizes de Medição. Tal documento deverá ser revisado com periodicidade anual, juntamente com esta Política Organizacional, e validado pela Presidência da empresa.

Para exercer cada papel nos processos, o colaborador (que pode atuar em dois ou mais papeis no mesmo projeto/processo, de acordo com o planejamento realizado e seguindo os critérios/limites de cada papel) deverá possuir requisitos mínimos de conhecimento, comprovados através de histórico profissional (viabilizado/garantido pelo departamento de Recursos Humanos), formação acadêmica, certificações, cursos/treinamentos (inclusive internos) ou pela própria atuação na MSTECH (sendo comprovada, por exemplo, via histórico de participação em outros projetos). Os requisitos para atuar em cada papel nos processos de trabalho, bem como as suas respectivas '''responsabilidades''', estão descritos no documento “Catálogo de Papeis” (disponível na página oficial de Processos de Trabalho).

Somente o Escritório de PCP poderá alterar os Processos de Trabalho estabelecidos, mediante análise em reuniões ou através de solicitações da Presidência da empresa. Também é de responsabilidade do PCP definir se há, ou não, necessidade de novos treinamentos após mudanças nos processos de trabalho, mas é essencial que todos sejam avisados sobre as mudanças realizadas. Após a alteração de um processo, todos os projetos e áreas envolvidas devem utilizar a nova versão publicada. Essa regra é válida também para novos templates, exceto para o repositório de gestão de projetos (e seus templates) e cronograma. Não é necessário realizar nenhuma ação retroativa para ambas as situações citadas (exceto em casos em que o Escritório de PCP ou a Presidência solicitar correções/alterações).

Os resultados gerados pelos projetos de Desenvolvimento de Software podem, também, se tornar produtos da empresa, sendo absorvidos para o Portfólio de Produtos da MSTECH. Entretanto, não é qualquer situação que se enquadra nesse conceito. Há critérios para definir se o resultado de um projeto se tornará um produto da empresa. São eles:

'''•''' Se há ligação/semelhança do resultado do projeto com outros produtos da empresa. Nessa esfera, também é aplicável o critério de vínculos, quando o resultado do projeto é, de alguma forma, vinculado com um, ou mais, produtos existentes, tendo a possibilidade de absorver mais um produto ao Portfólio;

'''•''' Se há aplicabilidade do produto do projeto em outros clientes. Em muitas situações, o produto gerado pelo projeto poderia ser comercializado com outros clientes devido ao seu conteúdo, ou devido à sua estrutura – compatível com a necessidade de outros clientes;

'''•''' Se há diretrizes comerciais de alto nível, geralmente definidas pela Presidência da empresa ou com base na estratégia organizacional;

'''•''' Se há um nível baixo de customização necessária para a adaptação genérica do Produto gerado pelo projeto. Quando um produto é desenvolvido para determinado cliente, e essa entrega é específica para um negócio ou fim, geralmente não é interessante absorver esse resultado como produto, pois ele não é condizente com a necessidade de outros clientes, e nem aplicável em outras situações;

'''•''' Se o produto gerado pelo projeto for estratégico para o cliente. Quando determinado cliente solicitado algo específico, e que há um grande vínculo comercial e estratégico por parte do cliente, não é interessante anexar esse resultado ao Portfólio de Produtos.

Nesse contexto, a partir da análise dos itens supracitados, é possível determinar em qual momento um resultado de projeto se tornará um Produto da empresa, de qual forma e qual será a estratégia inicial para trabalhar essa evolução.
Todo o esforço de trabalho realizado com a utilização dos processos nos projetos deverá ser registrado no Sistema de Armazenamento de Horas de Trabalho, utilizando as tarefas relacionadas com o trabalho no respectivo projeto. Entretanto, o esforço utilizado com as Auditorias dos processos/projetos deverá ser registrado em um cronograma independente, pois os esforços despendidos para essas atividades não são registrados diretamente nos projetos.

Todos os colaboradores da empresa, que atuam nos Processos de Trabalho descritos neste documento, deverão possuir estações de trabalho configuradas (hardware, software e usuário de acesso pelo Active Directory) de acordo com as suas respectivas necessidades. Todos esses itens são gerenciados diretamente pelo departamento de Gestão da Tecnologia de Informação da MSTECH. É de responsabilidade dos responsáveis pelos projetos solicitar outros recursos materiais necessários para a execução do projeto.

Esta Política Organizacional deverá ser revisada anualmente (no mínimo) e aprovada pela Presidência da empresa, a contar da data de sua primeira publicação.

Políticas dos processos MSTECH

2016-12-09T18:44:03Z

Lucimara.maiorali:

Politica Organizacional MSTECH

2016-12-09T18:42:57Z

Lucimara.maiorali:

'''Versão 2.0'''

A Política Organizacional da MSTECH EDUCAÇÃO E TECNOLOGIA EIRELI abrange regras, métodos e conceitos para os projetos de '''Desenvolvimento de Software''' de '''toda a empresa'''. Este documento possui caráter oficial e tange como modelo de referência.

A página oficial dos Processos de Trabalho está disponível para toda a empresa. O local contém o Ciclo de Vida dos Projetos de Desenvolvimento de Software, além do fluxo geral dos Processos de Trabalho para Desenvolvimento de Software, Garantia da Qualidade e Gestão de Portfólio de Projetos. Por fim, há todos os templates de documentos utilizados pelo Processo de Desenvolvimento de Software e outros conteúdos importantes que auxiliam todos na utilização dos Processos de Trabalho. '''Todos os projetos de Desenvolvimento de Software''' (exceto Pesquisa e Desenvolvimento) '''da MSTECH devem utilizar os conteúdos supracitados''', de acordo com suas respectivas regras, além dos sistemas computacionais configurados para a gestão dos projetos/produtos e os softwares auxiliares que integram essas ferramentas.

O '''Processo de Trabalho de Desenvolvimento de Software''' é utilizado diretamente pelas áreas de '''Gestão de Projetos''' e de '''Requisitos''' e '''Gestão de Configuração'''. Suas quatro fases são cronológicas e possuem relação direta. Entretanto, a primeira e a última fase são únicas por projeto, e as intermediárias se repetem (cíclicas, não necessariamente de forma linear, tornando o processo iterativo) de acordo com o número de entregas do projeto. Há também etapas de monitoramento, que abrangem paralelamente todo o processo. Seu principal objetivo é conceder aos projetos de Desenvolvimento de Software padrões e procedimentos, visando garantir qualidade, desempenho e completa satisfação dos clientes, com resultados de alto valor agregado e condizentes com as necessidades estabelecidas. O processo deverá padronizar as atividades para as equipes de desenvolvimento da empresa, garantindo uniformidade em suas atividades de desenvolvimento de software. O processo deverá ser atualizado sempre que necessário, garantindo aderência para a realidade e objetivos estratégicos da MSTECH.

Todos os documentos obrigatórios e auxiliares dos projetos deverão ficar armazenados nos locais definidos pelo processo de desenvolvimento de software, sendo mantido para isso um sistema que possui a função de repositório. Nenhum documento deve conter informações de custos em valores monetários, tendo os custos apenas a tratativa em horas. Já os artefatos técnicos, que farão parte do Produto desenvolvido pelo projeto, deverão estar presentes no Sistema de Gestão de Configuração, contemplados como parte das Baselines do Produto. Todas as alterações nos documentos precisam ser registra-das nos respectivos locais de armazenamento, de acordo com as diretrizes da Gestão de Configuração (GCO), assim como as demais regras de acesso, nomenclaturas e controles de versões.

O '''Processo de Trabalho de Gestão de Portfólio de Projetos''' é utilizado pelos responsáveis da Gestão de Portfólio de Projetos (GPP) e tem como objetivo principal realizar a gestão da carteira de projetos e clientes da MSTECH. O processo possui duas fases, sendo que a primeira é executada anualmente (ou quando for estritamente necessário) e a segunda é cíclica. Através da definição dos Fatores Comerciais e suas respectivas Priorizações, a Presidência, em conjunto com o responsável da Gestão de Portfólio de Projetos deverá organizar os Objetivos Estratégicos da empresa e, por fim, oficializar a Estratégia do Portfólio de Projetos. Tal Estratégia visa manter a aderência dos processos e projetos de acordo com os objetivos organizacionais, buscando, como foco principal, resultados satisfatórios para os clientes.

O '''Processo de Trabalho de Garantia da Qualidade''' é utilizado pela equipe QA e demonstra a expectativa da empresa na aderência e conformidade das atividades executadas com base nos Processos de Trabalho definidos. Este processo garantirá que todos os Processos de Trabalho definidos estão sendo seguidos de forma correta e íntegra.

As auditorias de garantia da qualidade dos projetos devem ser planejadas nas fases do ciclo de vida do projeto, nos marcos de 50% (projetos com duração dois meses), mensal (projetos com duração maior que dois meses) e antes das entregas ao cliente, no que tange as auditorias de garantia da qualidade do processo organizacional da Gestão de Portfólio de Projetos devem ser planejadas no “Plano de Garantia da Qualidade”. Nesse contexto, o documento “Plano de Garantia da Qualidade” deverá ser elaborado anualmente e, atualizado juntamente com esta Política Organizacional, servindo de suporte para a equipe QA, sendo mantidos nas ferramentas da empresa. Por fim, é importante ressaltar que a auditoria Independente de QA deverá ser planejada anualmente.

Todas as auditorias de garantia da qualidade devem ser executadas com a utilização de checklists de garantia da qualidade. Toda não conformidade identificada será acompanhada até a sua resolução seguindo às criticidades e prazos definidos no “Processo de Trabalho de Garantia da Qualidade”. As não conformidades não solucionadas no prazo definido pela criticidade deverão ser escalonadas ao superior imediato conforme organograma da empresa.

Os resultados das auditorias de garantia da qualidade deverão ser reportados conforme definido no “Processo de Trabalho de Garantia da Qualidade”.

Os '''Indicadores''' (resultado de '''Medição''') são itens essenciais para a gestão da empresa, pois apresentam, de forma condensada e objetiva, conforme necessário, a situação da empresa em diversos aspectos. Os Indicadores devem fornecer informações para:

'''•''' Manter a aderência nos processos de trabalho estabelecidos, de forma geral e/ou em etapas/atividades específicas;

'''•''' Gerenciar a situação dos projetos, no que tange prazo e esforço;

'''•''' Aprimorar as estimativas para o planejamento dos projetos;

'''•''' Apresentar subsídios para avaliar os próprios Indicadores estabelecidos.

Todo o planejamento, desde a coleta dos Indicadores, até as ações oriundas dos resultados das Medições, está documentado e oficializado nas Diretrizes de Medição. Tal documento deverá ser revisado com periodicidade anual, juntamente com esta Política Organizacional, e validado pela Presidência da empresa.

Para exercer cada papel nos processos, o colaborador (que pode atuar em dois ou mais papeis no mesmo projeto/processo, de acordo com o planejamento realizado e seguindo os critérios/limites de cada papel) deverá possuir requisitos mínimos de conhecimento, comprovados através de histórico profissional (viabilizado/garantido pelo departamento de Recursos Humanos), formação acadêmica, certificações, cursos/treinamentos (inclusive internos) ou pela própria atuação na MSTECH (sendo comprovada, por exemplo, via histórico de participação em outros projetos). Os requisitos para atuar em cada papel nos processos de trabalho, bem como as suas respectivas '''responsabilidades''', estão descritos no documento “Catálogo de Papeis” (disponível na página oficial de Processos de Trabalho).

Somente o Escritório de PCP poderá alterar os Processos de Trabalho estabelecidos, mediante análise em reuniões ou através de solicitações da Presidência da empresa. Também é de responsabilidade do PCP definir se há, ou não, necessidade de novos treinamentos após mudanças nos processos de trabalho, mas é essencial que todos sejam avisados sobre as mudanças realizadas. Após a alteração de um processo, todos os projetos e áreas envolvidas devem utilizar a nova versão publicada. Essa regra é válida também para novos templates, exceto para o repositório de gestão de projetos (e seus templates) e cronograma. Não é necessário realizar nenhuma ação retroativa para ambas as situações citadas (exceto em casos em que o Escritório de PCP ou a Presidência solicitar correções/alterações).

Os resultados gerados pelos projetos de Desenvolvimento de Software podem, também, se tornar produtos da empresa, sendo absorvidos para o Portfólio de Produtos da MSTECH. Entretanto, não é qualquer situação que se enquadra nesse conceito. Há critérios para definir se o resultado de um projeto se tornará um produto da empresa. São eles:

'''•''' Se há ligação/semelhança do resultado do projeto com outros produtos da empresa. Nessa esfera, também é aplicável o critério de vínculos, quando o resultado do projeto é, de alguma forma, vinculado com um, ou mais, produtos existentes, tendo a possibilidade de absorver mais um produto ao Portfólio;

'''•''' Se há aplicabilidade do produto do projeto em outros clientes. Em muitas situações, o produto gerado pelo projeto poderia ser comercializado com outros clientes devido ao seu conteúdo, ou devido à sua estrutura – compatível com a necessidade de outros clientes;

'''•''' Se há diretrizes comerciais de alto nível, geralmente definidas pela Presidência da empresa ou com base na estratégia organizacional;

'''•''' Se há um nível baixo de customização necessária para a adaptação genérica do Produto gerado pelo projeto. Quando um produto é desenvolvido para determinado cliente, e essa entrega é específica para um negócio ou fim, geralmente não é interessante absorver esse resultado como produto, pois ele não é condizente com a necessidade de outros clientes, e nem aplicável em outras situações;

'''•''' Se o produto gerado pelo projeto for estratégico para o cliente. Quando determinado cliente solicitado algo específico, e que há um grande vínculo comercial e estratégico por parte do cliente, não é interessante anexar esse resultado ao Portfólio de Produtos.

Nesse contexto, a partir da análise dos itens supracitados, é possível determinar em qual momento um resultado de projeto se tornará um Produto da empresa, de qual forma e qual será a estratégia inicial para trabalhar essa evolução.
Todo o esforço de trabalho realizado com a utilização dos processos nos projetos deverá ser registrado no Sistema de Armazenamento de Horas de Trabalho, utilizando as tarefas relacionadas com o trabalho no respectivo projeto. Entretanto, o esforço utilizado com as Auditorias dos processos/projetos deverá ser registrado em um cronograma independente, pois os esforços despendidos para essas atividades não são registrados diretamente nos projetos.

Todos os colaboradores da empresa, que atuam nos Processos de Trabalho descritos neste documento, deverão possuir estações de trabalho configuradas (hardware, software e usuário de acesso pelo Active Directory) de acordo com as suas respectivas necessidades. Todos esses itens são gerenciados diretamente pelo departamento de Gestão da Tecnologia de Informação da MSTECH. É de responsabilidade dos responsáveis pelos projetos solicitar outros recursos materiais necessários para a execução do projeto.

Esta Política Organizacional deverá ser revisada anualmente (no mínimo) e aprovada pela Presidência da empresa, a contar da data de sua primeira publicação.

Politica Organizacional MSTECH

2016-12-09T18:42:14Z

Lucimara.maiorali:

'''Versão 2.0''' (Em aprovação da Presidência)

A Política Organizacional da MSTECH EDUCAÇÃO E TECNOLOGIA EIRELI abrange regras, métodos e conceitos para os projetos de '''Desenvolvimento de Software''' de '''toda a empresa'''. Este documento possui caráter oficial e tange como modelo de referência.

A página oficial dos Processos de Trabalho está disponível para toda a empresa. O local contém o Ciclo de Vida dos Projetos de Desenvolvimento de Software, além do fluxo geral dos Processos de Trabalho para Desenvolvimento de Software, Garantia da Qualidade e Gestão de Portfólio de Projetos. Por fim, há todos os templates de documentos utilizados pelo Processo de Desenvolvimento de Software e outros conteúdos importantes que auxiliam todos na utilização dos Processos de Trabalho. '''Todos os projetos de Desenvolvimento de Software''' (exceto Pesquisa e Desenvolvimento) '''da MSTECH devem utilizar os conteúdos supracitados''', de acordo com suas respectivas regras, além dos sistemas computacionais configurados para a gestão dos projetos/produtos e os softwares auxiliares que integram essas ferramentas.

O '''Processo de Trabalho de Desenvolvimento de Software''' é utilizado diretamente pelas áreas de '''Gestão de Projetos''' e de '''Requisitos''' e '''Gestão de Configuração'''. Suas quatro fases são cronológicas e possuem relação direta. Entretanto, a primeira e a última fase são únicas por projeto, e as intermediárias se repetem (cíclicas, não necessariamente de forma linear, tornando o processo iterativo) de acordo com o número de entregas do projeto. Há também etapas de monitoramento, que abrangem paralelamente todo o processo. Seu principal objetivo é conceder aos projetos de Desenvolvimento de Software padrões e procedimentos, visando garantir qualidade, desempenho e completa satisfação dos clientes, com resultados de alto valor agregado e condizentes com as necessidades estabelecidas. O processo deverá padronizar as atividades para as equipes de desenvolvimento da empresa, garantindo uniformidade em suas atividades de desenvolvimento de software. O processo deverá ser atualizado sempre que necessário, garantindo aderência para a realidade e objetivos estratégicos da MSTECH.

Todos os documentos obrigatórios e auxiliares dos projetos deverão ficar armazenados nos locais definidos pelo processo de desenvolvimento de software, sendo mantido para isso um sistema que possui a função de repositório. Nenhum documento deve conter informações de custos em valores monetários, tendo os custos apenas a tratativa em horas. Já os artefatos técnicos, que farão parte do Produto desenvolvido pelo projeto, deverão estar presentes no Sistema de Gestão de Configuração, contemplados como parte das Baselines do Produto. Todas as alterações nos documentos precisam ser registra-das nos respectivos locais de armazenamento, de acordo com as diretrizes da Gestão de Configuração (GCO), assim como as demais regras de acesso, nomenclaturas e controles de versões.

O '''Processo de Trabalho de Gestão de Portfólio de Projetos''' é utilizado pelos responsáveis da Gestão de Portfólio de Projetos (GPP) e tem como objetivo principal realizar a gestão da carteira de projetos e clientes da MSTECH. O processo possui duas fases, sendo que a primeira é executada anualmente (ou quando for estritamente necessário) e a segunda é cíclica. Através da definição dos Fatores Comerciais e suas respectivas Priorizações, a Presidência, em conjunto com o responsável da Gestão de Portfólio de Projetos deverá organizar os Objetivos Estratégicos da empresa e, por fim, oficializar a Estratégia do Portfólio de Projetos. Tal Estratégia visa manter a aderência dos processos e projetos de acordo com os objetivos organizacionais, buscando, como foco principal, resultados satisfatórios para os clientes.

O '''Processo de Trabalho de Garantia da Qualidade''' é utilizado pela equipe QA e demonstra a expectativa da empresa na aderência e conformidade das atividades executadas com base nos Processos de Trabalho definidos. Este processo garantirá que todos os Processos de Trabalho definidos estão sendo seguidos de forma correta e íntegra.

As auditorias de garantia da qualidade dos projetos devem ser planejadas nas fases do ciclo de vida do projeto, nos marcos de 50% (projetos com duração dois meses), mensal (projetos com duração maior que dois meses) e antes das entregas ao cliente, no que tange as auditorias de garantia da qualidade do processo organizacional da Gestão de Portfólio de Projetos devem ser planejadas no “Plano de Garantia da Qualidade”. Nesse contexto, o documento “Plano de Garantia da Qualidade” deverá ser elaborado anualmente e, atualizado juntamente com esta Política Organizacional, servindo de suporte para a equipe QA, sendo mantidos nas ferramentas da empresa. Por fim, é importante ressaltar que a auditoria Independente de QA deverá ser planejada anualmente.

Todas as auditorias de garantia da qualidade devem ser executadas com a utilização de checklists de garantia da qualidade. Toda não conformidade identificada será acompanhada até a sua resolução seguindo às criticidades e prazos definidos no “Processo de Trabalho de Garantia da Qualidade”. As não conformidades não solucionadas no prazo definido pela criticidade deverão ser escalonadas ao superior imediato conforme organograma da empresa.

Os resultados das auditorias de garantia da qualidade deverão ser reportados conforme definido no “Processo de Trabalho de Garantia da Qualidade”.

Os '''Indicadores''' (resultado de '''Medição''') são itens essenciais para a gestão da empresa, pois apresentam, de forma condensada e objetiva, conforme necessário, a situação da empresa em diversos aspectos. Os Indicadores devem fornecer informações para:

'''•''' Manter a aderência nos processos de trabalho estabelecidos, de forma geral e/ou em etapas/atividades específicas;

'''•''' Gerenciar a situação dos projetos, no que tange prazo e esforço;

'''•''' Aprimorar as estimativas para o planejamento dos projetos;

'''•''' Apresentar subsídios para avaliar os próprios Indicadores estabelecidos.

Todo o planejamento, desde a coleta dos Indicadores, até as ações oriundas dos resultados das Medições, está documentado e oficializado nas Diretrizes de Medição. Tal documento deverá ser revisado com periodicidade anual, juntamente com esta Política Organizacional, e validado pela Presidência da empresa.

Para exercer cada papel nos processos, o colaborador (que pode atuar em dois ou mais papeis no mesmo projeto/processo, de acordo com o planejamento realizado e seguindo os critérios/limites de cada papel) deverá possuir requisitos mínimos de conhecimento, comprovados através de histórico profissional (viabilizado/garantido pelo departamento de Recursos Humanos), formação acadêmica, certificações, cursos/treinamentos (inclusive internos) ou pela própria atuação na MSTECH (sendo comprovada, por exemplo, via histórico de participação em outros projetos). Os requisitos para atuar em cada papel nos processos de trabalho, bem como as suas respectivas '''responsabilidades''', estão descritos no documento “Catálogo de Papeis” (disponível na página oficial de Processos de Trabalho).

Somente o Escritório de PCP poderá alterar os Processos de Trabalho estabelecidos, mediante análise em reuniões ou através de solicitações da Presidência da empresa. Também é de responsabilidade do PCP definir se há, ou não, necessidade de novos treinamentos após mudanças nos processos de trabalho, mas é essencial que todos sejam avisados sobre as mudanças realizadas. Após a alteração de um processo, todos os projetos e áreas envolvidas devem utilizar a nova versão publicada. Essa regra é válida também para novos templates, exceto para o repositório de gestão de projetos (e seus templates) e cronograma. Não é necessário realizar nenhuma ação retroativa para ambas as situações citadas (exceto em casos em que o Escritório de PCP ou a Presidência solicitar correções/alterações).

Os resultados gerados pelos projetos de Desenvolvimento de Software podem, também, se tornar produtos da empresa, sendo absorvidos para o Portfólio de Produtos da MSTECH. Entretanto, não é qualquer situação que se enquadra nesse conceito. Há critérios para definir se o resultado de um projeto se tornará um produto da empresa. São eles:

'''•''' Se há ligação/semelhança do resultado do projeto com outros produtos da empresa. Nessa esfera, também é aplicável o critério de vínculos, quando o resultado do projeto é, de alguma forma, vinculado com um, ou mais, produtos existentes, tendo a possibilidade de absorver mais um produto ao Portfólio;

'''•''' Se há aplicabilidade do produto do projeto em outros clientes. Em muitas situações, o produto gerado pelo projeto poderia ser comercializado com outros clientes devido ao seu conteúdo, ou devido à sua estrutura – compatível com a necessidade de outros clientes;

'''•''' Se há diretrizes comerciais de alto nível, geralmente definidas pela Presidência da empresa ou com base na estratégia organizacional;

'''•''' Se há um nível baixo de customização necessária para a adaptação genérica do Produto gerado pelo projeto. Quando um produto é desenvolvido para determinado cliente, e essa entrega é específica para um negócio ou fim, geralmente não é interessante absorver esse resultado como produto, pois ele não é condizente com a necessidade de outros clientes, e nem aplicável em outras situações;

'''•''' Se o produto gerado pelo projeto for estratégico para o cliente. Quando determinado cliente solicitado algo específico, e que há um grande vínculo comercial e estratégico por parte do cliente, não é interessante anexar esse resultado ao Portfólio de Produtos.

Nesse contexto, a partir da análise dos itens supracitados, é possível determinar em qual momento um resultado de projeto se tornará um Produto da empresa, de qual forma e qual será a estratégia inicial para trabalhar essa evolução.
Todo o esforço de trabalho realizado com a utilização dos processos nos projetos deverá ser registrado no Sistema de Armazenamento de Horas de Trabalho, utilizando as tarefas relacionadas com o trabalho no respectivo projeto. Entretanto, o esforço utilizado com as Auditorias dos processos/projetos deverá ser registrado em um cronograma independente, pois os esforços despendidos para essas atividades não são registrados diretamente nos projetos.

Todos os colaboradores da empresa, que atuam nos Processos de Trabalho descritos neste documento, deverão possuir estações de trabalho configuradas (hardware, software e usuário de acesso pelo Active Directory) de acordo com as suas respectivas necessidades. Todos esses itens são gerenciados diretamente pelo departamento de Gestão da Tecnologia de Informação da MSTECH. É de responsabilidade dos responsáveis pelos projetos solicitar outros recursos materiais necessários para a execução do projeto.

Esta Política Organizacional deverá ser revisada anualmente (no mínimo) e aprovada pela Presidência da empresa, a contar da data de sua primeira publicação.

Aviso de resultado de auditoria

2016-12-08T18:13:28Z

Lucimara.maiorali:

O presente guia serve de sugestão para o modelo de envio de aviso dos resultados das auditorias de qualidade realizadas em projetos, pré-projetos e no Processo Organizacional por meio da Gestão de Portfólio de Projetos.

== Sobre o aviso ==
Conforme descrito no Processo de Garantia da Qualidade, ao finalizar a auditoria de garantia da qualidade do Processo Organizacional ou do projeto, o Analista de QA deverá divulgar o resultado das informações dos registros das não conformidades (caso identificadas) e o local para acompanhamento e tratamento das mesmas, ou o resultado da completa aderência ao respectivo processo de trabalho padrão.

É sugerido que o Analista de QA encaminhe este aviso via e-mail, conforme modelo apresentado a seguir.

== Modelo do e-mail de aviso (Projetos) ==
[[Arquivo:modelo-email-aviso-auditoria.jpg]]

=== Modelo em texto ===

Olá!

Informamos que foi finalizada a auditoria de garantia da qualidade da '''<fase do projeto>''' do projeto '''<NOME DO PROJETO>''' e todas as informações encontram-se no local '''<endereço da tarefa da auditoria>'''.

Resultado da aderência:

{| border=1
|-
| '''Total de itens''' || <nº total itens>
|-
| '''Itens em conf.''' || < nº itens em conf.>
|-
| '''% de aderência''' || %
|}

As não conformidades identificadas estão com prazo para tratamento e encontram-se no '''<endereço do filtro das tarefas do tipo “não conformidade” no projeto>'''.

Para o que precisar, nos contate.

Atenciosamente,

'''''Assinatura padrão'''''

== Modelo do e-mail de aviso (Processo Organizacional) ==
[[Arquivo:modelo-email-aviso-auditoria-gpp.jpg]]

=== Modelo em texto ===
Olá!

Foi finalizada a auditoria de garantia da qualidade periódica do processo organizacional Gestão de Portfólio de Projetos e todas as informações encontram-se no local '''<endereço da tarefa da auditoria>'''.

Resultado da aderência:

{| border=1
|-
| '''Total de itens''' || <nº total itens>
|-
| '''Itens em conf.''' || < nº itens em conf.>
|-
| '''% de aderência''' || %
|}

As não conformidades identificadas estão com prazo para tratamento e encontram-se no '''<endereço do filtro das tarefas do tipo “não conformidade” no projeto “Gestão de Portfólio de Projetos”>'''.

Para o que precisar, nos contate.

Atenciosamente,

'''''Assinatura padrão'''''

Políticas dos processos MSTECH

2016-12-06T19:08:48Z

Lucimara.maiorali:

Políticas dos processos MSTECH

2016-12-06T19:08:32Z

Lucimara.maiorali:

Politica Organizacional MSTECH

2016-12-06T19:07:54Z

Lucimara.maiorali:

'''Versão 2.0'''

A Política Organizacional da MSTECH EDUCAÇÃO E TECNOLOGIA EIRELI abrange regras, métodos e conceitos para os projetos de '''Desenvolvimento de Software''' de '''toda a empresa'''. Este documento possui caráter oficial e tange como modelo de referência.

A página oficial dos Processos de Trabalho está disponível para toda a empresa. O local contém o Ciclo de Vida dos Projetos de Desenvolvimento de Software, além do fluxo geral dos Processos de Trabalho para Desenvolvimento de Software, Garantia da Qualidade e Gestão de Portfólio de Projetos. Por fim, há todos os templates de documentos utilizados pelo Processo de Desenvolvimento de Software e outros conteúdos importantes que auxiliam todos na utilização dos Processos de Trabalho. '''Todos os projetos de Desenvolvimento de Software''' (exceto Pesquisa e Desenvolvimento) '''da MSTECH devem utilizar os conteúdos supracitados''', de acordo com suas respectivas regras, além dos sistemas computacionais configurados para a gestão dos projetos/produtos e os softwares auxiliares que integram essas ferramentas.

O '''Processo de Trabalho de Desenvolvimento de Software''' é utilizado diretamente pelas áreas de '''Gestão de Projetos''' e de '''Requisitos''' e '''Gestão de Configuração'''. Suas quatro fases são cronológicas e possuem relação direta. Entretanto, a primeira e a última fase são únicas por projeto, e as intermediárias se repetem (cíclicas, não necessariamente de forma linear, tornando o processo iterativo) de acordo com o número de entregas do projeto. Há também etapas de monitoramento, que abrangem paralelamente todo o processo. Seu principal objetivo é conceder aos projetos de Desenvolvimento de Software padrões e procedimentos, visando garantir qualidade, desempenho e completa satisfação dos clientes, com resultados de alto valor agregado e condizentes com as necessidades estabelecidas. O processo deverá padronizar as atividades para as equipes de desenvolvimento da empresa, garantindo uniformidade em suas atividades de desenvolvimento de software. O processo deverá ser atualizado sempre que necessário, garantindo aderência para a realidade e objetivos estratégicos da MSTECH.

Todos os documentos obrigatórios e auxiliares dos projetos deverão ficar armazenados nos locais definidos pelo processo de desenvolvimento de software, sendo mantido para isso um sistema que possui a função de repositório. Já os artefatos técnicos, que farão parte do Produto desenvolvido pelo projeto, deverão estar presentes no Sistema de Gestão de Configuração, contemplados como parte das Baselines do Produto. Todas as alterações nos documentos precisam ser registra-das nos respectivos locais de armazenamento, de acordo com as diretrizes da Gestão de Configuração (GCO), assim como as demais regras de acesso, nomenclaturas e controles de versões.

O '''Processo de Trabalho de Gestão de Portfólio de Projetos''' é utilizado pelos responsáveis da Gestão de Portfólio de Projetos (GPP) e tem como objetivo principal realizar a gestão da carteira de projetos e clientes da MSTECH. O processo possui duas fases, sendo que a primeira é executada anualmente (ou quando for estritamente necessário) e a segunda é cíclica. Através da definição dos Fatores Comerciais e suas respectivas Priorizações, a Presidência, em conjunto com o responsável da Gestão de Portfólio de Projetos deverá organizar os Objetivos Estratégicos da empresa e, por fim, oficializar a Estratégia do Portfólio de Projetos. Tal Estratégia visa manter a aderência dos processos e projetos de acordo com os objetivos organizacionais, buscando, como foco principal, resultados satisfatórios para os clientes.

O '''Processo de Trabalho de Garantia da Qualidade''' é utilizado pela equipe QA e demonstra a expectativa da empresa na aderência e conformidade das atividades executadas com base nos Processos de Trabalho definidos. Este processo garantirá que todos os Processos de Trabalho definidos estão sendo seguidos de forma correta e íntegra.

As auditorias de garantia da qualidade dos projetos devem ser planejadas nas fases do ciclo de vida do projeto, nos marcos de 50% (projetos com duração dois meses), mensal (projetos com duração maior que dois meses) e antes das entregas ao cliente, no que tange as auditorias de garantia da qualidade do processo organizacional da Gestão de Portfólio de Projetos devem ser planejadas no “Plano de Garantia da Qualidade”. Nesse contexto, o documento “Plano de Garantia da Qualidade” deverá ser elaborado anualmente e, atualizado juntamente com esta Política Organizacional, servindo de suporte para a equipe QA, sendo mantidos nas ferramentas da empresa. Por fim, é importante ressaltar que a auditoria Independente de QA deverá ser planejada anualmente.

Todas as auditorias de garantia da qualidade devem ser executadas com a utilização de checklists de garantia da qualidade. Toda não conformidade identificada será acompanhada até a sua resolução seguindo às criticidades e prazos definidos no “Processo de Trabalho de Garantia da Qualidade”. As não conformidades não solucionadas no prazo definido pela criticidade deverão ser escalonadas ao superior imediato conforme organograma da empresa.

Os resultados das auditorias de garantia da qualidade deverão ser reportados conforme definido no “Processo de Trabalho de Garantia da Qualidade”.

Os '''Indicadores''' (resultado de '''Medição''') são itens essenciais para a gestão da empresa, pois apresentam, de forma condensada e objetiva, conforme necessário, a situação da empresa em diversos aspectos. Os Indicadores devem fornecer informações para:

'''•''' Manter a aderência nos processos de trabalho estabelecidos, de forma geral e/ou em etapas/atividades específicas;

'''•''' Gerenciar a situação dos projetos, no que tange prazo e esforço;

'''•''' Aprimorar as estimativas para o planejamento dos projetos;

'''•''' Apresentar subsídios para avaliar os próprios Indicadores estabelecidos.

Todo o planejamento, desde a coleta dos Indicadores, até as ações oriundas dos resultados das Medições, está documentado e oficializado nas Diretrizes de Medição. Tal documento deverá ser revisado com periodicidade anual, juntamente com esta Política Organizacional, e validado pela Presidência da empresa.

Para exercer cada papel nos processos, o colaborador (que pode atuar em dois ou mais papeis no mesmo projeto/processo, de acordo com o planejamento realizado e seguindo os critérios/limites de cada papel) deverá possuir requisitos mínimos de conhecimento, comprovados através de histórico profissional (viabilizado/garantido pelo departamento de Recursos Humanos), formação acadêmica, certificações, cursos/treinamentos (inclusive internos) ou pela própria atuação na MSTECH (sendo comprovada, por exemplo, via histórico de participação em outros projetos). Os requisitos para atuar em cada papel nos processos de trabalho, bem como as suas respectivas '''responsabilidades''', estão descritos no documento “Catálogo de Papeis” (disponível na página oficial de Processos de Trabalho).

Somente o Escritório de PCP poderá alterar os Processos de Trabalho estabelecidos, mediante análise em reuniões ou através de solicitações da Presidência da empresa. Também é de responsabilidade do PCP definir se há, ou não, necessidade de novos treinamentos após mudanças nos processos de trabalho, mas é essencial que todos sejam avisados sobre as mudanças realizadas. Após a alteração de um processo, todos os projetos e áreas envolvidas devem utilizar a nova versão publicada. Essa regra é válida também para novos templates, exceto para o repositório de gestão de projetos (e seus templates) e cronograma. Não é necessário realizar nenhuma ação retroativa para ambas as situações citadas (exceto em casos em que o Escritório de PCP ou a Presidência solicitar correções/alterações).

Os resultados gerados pelos projetos de Desenvolvimento de Software podem, também, se tornar produtos da empresa, sendo absorvidos para o Portfólio de Produtos da MSTECH. Entretanto, não é qualquer situação que se enquadra nesse conceito. Há critérios para definir se o resultado de um projeto se tornará um produto da empresa. São eles:

'''•''' Se há ligação/semelhança do resultado do projeto com outros produtos da empresa. Nessa esfera, também é aplicável o critério de vínculos, quando o resultado do projeto é, de alguma forma, vinculado com um, ou mais, produtos existentes, tendo a possibilidade de absorver mais um produto ao Portfólio;

'''•''' Se há aplicabilidade do produto do projeto em outros clientes. Em muitas situações, o produto gerado pelo projeto poderia ser comercializado com outros clientes devido ao seu conteúdo, ou devido à sua estrutura – compatível com a necessidade de outros clientes;

'''•''' Se há diretrizes comerciais de alto nível, geralmente definidas pela Presidência da empresa ou com base na estratégia organizacional;

'''•''' Se há um nível baixo de customização necessária para a adaptação genérica do Produto gerado pelo projeto. Quando um produto é desenvolvido para determinado cliente, e essa entrega é específica para um negócio ou fim, geralmente não é interessante absorver esse resultado como produto, pois ele não é condizente com a necessidade de outros clientes, e nem aplicável em outras situações;

'''•''' Se o produto gerado pelo projeto for estratégico para o cliente. Quando determinado cliente solicitado algo específico, e que há um grande vínculo comercial e estratégico por parte do cliente, não é interessante anexar esse resultado ao Portfólio de Produtos.

Nesse contexto, a partir da análise dos itens supracitados, é possível determinar em qual momento um resultado de projeto se tornará um Produto da empresa, de qual forma e qual será a estratégia inicial para trabalhar essa evolução.
Todo o esforço de trabalho realizado com a utilização dos processos nos projetos deverá ser registrado no Sistema de Armazenamento de Horas de Trabalho, utilizando as tarefas relacionadas com o trabalho no respectivo projeto. Entretanto, o esforço utilizado com as Auditorias dos processos/projetos deverá ser registrado em um cronograma independente, pois os esforços despendidos para essas atividades não são registrados diretamente nos projetos.

Todos os colaboradores da empresa, que atuam nos Processos de Trabalho descritos neste documento, deverão possuir estações de trabalho configuradas (hardware, software e usuário de acesso pelo Active Directory) de acordo com as suas respectivas necessidades. Todos esses itens são gerenciados diretamente pelo departamento de Gestão da Tecnologia de Informação da MSTECH. É de responsabilidade dos responsáveis pelos projetos solicitar outros recursos materiais necessários para a execução do projeto.

Esta Política Organizacional deverá ser revisada anualmente (no mínimo) e aprovada pela Presidência da empresa, a contar da data de sua primeira publicação.

Politica Organizacional MSTECH

2016-12-01T13:45:45Z

Lucimara.maiorali:

'''Versão 2.0''' (aguardando aprovação da Presidência)

A Política Organizacional da MSTECH EDUCAÇÃO E TECNOLOGIA EIRELI abrange regras, métodos e conceitos para os projetos de '''Desenvolvimento de Software''' de '''toda a empresa'''. Este documento possui caráter oficial e tange como modelo de referência.

A página oficial dos Processos de Trabalho está disponível para toda a empresa. O local contém o Ciclo de Vida dos Projetos de Desenvolvimento de Software, além do fluxo geral dos Processos de Trabalho para Desenvolvimento de Software, Garantia da Qualidade e Gestão de Portfólio de Projetos. Por fim, há todos os templates de documentos utilizados pelo Processo de Desenvolvimento de Software e outros conteúdos importantes que auxiliam todos na utilização dos Processos de Trabalho. '''Todos os projetos de Desenvolvimento de Software''' (exceto Pesquisa e Desenvolvimento) '''da MSTECH devem utilizar os conteúdos supracitados''', de acordo com suas respectivas regras, além dos sistemas computacionais configurados para a gestão dos projetos/produtos e os softwares auxiliares que integram essas ferramentas.

O '''Processo de Trabalho de Desenvolvimento de Software''' é utilizado diretamente pelas áreas de '''Gestão de Projetos''' e de '''Requisitos''' e '''Gestão de Configuração'''. Suas quatro fases são cronológicas e possuem relação direta. Entretanto, a primeira e a última fase são únicas por projeto, e as intermediárias se repetem (cíclicas, não necessariamente de forma linear, tornando o processo iterativo) de acordo com o número de entregas do projeto. Há também etapas de monitoramento, que abrangem paralelamente todo o processo. Seu principal objetivo é conceder aos projetos de Desenvolvimento de Software padrões e procedimentos, visando garantir qualidade, desempenho e completa satisfação dos clientes, com resultados de alto valor agregado e condizentes com as necessidades estabelecidas. O processo deverá padronizar as atividades para as equipes de desenvolvimento da empresa, garantindo uniformidade em suas atividades de desenvolvimento de software. O processo deverá ser atualizado sempre que necessário, garantindo aderência para a realidade e objetivos estratégicos da MSTECH.

Todos os documentos obrigatórios e auxiliares dos projetos deverão ficar armazenados nos locais definidos pelo processo de desenvolvimento de software, sendo mantido para isso um sistema que possui a função de repositório. Já os artefatos técnicos, que farão parte do Produto desenvolvido pelo projeto, deverão estar presentes no Sistema de Gestão de Configuração, contemplados como parte das Baselines do Produto. Todas as alterações nos documentos precisam ser registra-das nos respectivos locais de armazenamento, de acordo com as diretrizes da Gestão de Configuração (GCO), assim como as demais regras de acesso, nomenclaturas e controles de versões.

O '''Processo de Trabalho de Gestão de Portfólio de Projetos''' é utilizado pelos responsáveis da Gestão de Portfólio de Projetos (GPP) e tem como objetivo principal realizar a gestão da carteira de projetos e clientes da MSTECH. O processo possui duas fases, sendo que a primeira é executada anualmente (ou quando for estritamente necessário) e a segunda é cíclica. Através da definição dos Fatores Comerciais e suas respectivas Priorizações, a Presidência, em conjunto com o responsável da Gestão de Portfólio de Projetos deverá organizar os Objetivos Estratégicos da empresa e, por fim, oficializar a Estratégia do Portfólio de Projetos. Tal Estratégia visa manter a aderência dos processos e projetos de acordo com os objetivos organizacionais, buscando, como foco principal, resultados satisfatórios para os clientes.

O '''Processo de Trabalho de Garantia da Qualidade''' é utilizado pela equipe QA e demonstra a expectativa da empresa na aderência e conformidade das atividades executadas com base nos Processos de Trabalho definidos. Este processo garantirá que todos os Processos de Trabalho definidos estão sendo seguidos de forma correta e íntegra.

As auditorias de garantia da qualidade dos projetos devem ser planejadas nas fases do ciclo de vida do projeto, nos marcos de 50% (projetos com duração dois meses), mensal (projetos com duração maior que dois meses) e antes das entregas ao cliente, no que tange as auditorias de garantia da qualidade do processo organizacional da Gestão de Portfólio de Projetos devem ser planejadas no “Plano de Garantia da Qualidade”. Nesse contexto, o documento “Plano de Garantia da Qualidade” deverá ser elaborado anualmente e, atualizado juntamente com esta Política Organizacional, servindo de suporte para a equipe QA, sendo mantidos nas ferramentas da empresa. Por fim, é importante ressaltar que a auditoria Independente de QA deverá ser planejada anualmente.

Todas as auditorias de garantia da qualidade devem ser executadas com a utilização de checklists de garantia da qualidade. Toda não conformidade identificada será acompanhada até a sua resolução seguindo às criticidades e prazos definidos no “Processo de Trabalho de Garantia da Qualidade”. As não conformidades não solucionadas no prazo definido pela criticidade deverão ser escalonadas ao superior imediato conforme organograma da empresa.

Os resultados das auditorias de garantia da qualidade deverão ser reportados conforme definido no “Processo de Trabalho de Garantia da Qualidade”.

Os '''Indicadores''' (resultado de '''Medição''') são itens essenciais para a gestão da empresa, pois apresentam, de forma condensada e objetiva, conforme necessário, a situação da empresa em diversos aspectos. Os Indicadores devem fornecer informações para:

'''•''' Manter a aderência nos processos de trabalho estabelecidos, de forma geral e/ou em etapas/atividades específicas;

'''•''' Gerenciar a situação dos projetos, no que tange prazo e esforço;

'''•''' Aprimorar as estimativas para o planejamento dos projetos;

'''•''' Apresentar subsídios para avaliar os próprios Indicadores estabelecidos.

Todo o planejamento, desde a coleta dos Indicadores, até as ações oriundas dos resultados das Medições, está documentado e oficializado nas Diretrizes de Medição. Tal documento deverá ser revisado com periodicidade anual, juntamente com esta Política Organizacional, e validado pela Presidência da empresa.

Para exercer cada papel nos processos, o colaborador (que pode atuar em dois ou mais papeis no mesmo projeto/processo, de acordo com o planejamento realizado e seguindo os critérios/limites de cada papel) deverá possuir requisitos mínimos de conhecimento, comprovados através de histórico profissional (viabilizado/garantido pelo departamento de Recursos Humanos), formação acadêmica, certificações, cursos/treinamentos (inclusive internos) ou pela própria atuação na MSTECH (sendo comprovada, por exemplo, via histórico de participação em outros projetos). Os requisitos para atuar em cada papel nos processos de trabalho, bem como as suas respectivas '''responsabilidades''', estão descritos no documento “Catálogo de Papeis” (disponível na página oficial de Processos de Trabalho).

Somente o Escritório de PCP poderá alterar os Processos de Trabalho estabelecidos, mediante análise em reuniões ou através de solicitações da Presidência da empresa. Também é de responsabilidade do PCP definir se há, ou não, necessidade de novos treinamentos após mudanças nos processos de trabalho, mas é essencial que todos sejam avisados sobre as mudanças realizadas. Após a alteração de um processo, todos os projetos e áreas envolvidas devem utilizar a nova versão publicada. Essa regra é válida também para novos templates, exceto para o repositório de gestão de projetos (e seus templates) e cronograma. Não é necessário realizar nenhuma ação retroativa para ambas as situações citadas (exceto em casos em que o Escritório de PCP ou a Presidência solicitar correções/alterações).

Os resultados gerados pelos projetos de Desenvolvimento de Software podem, também, se tornar produtos da empresa, sendo absorvidos para o Portfólio de Produtos da MSTECH. Entretanto, não é qualquer situação que se enquadra nesse conceito. Há critérios para definir se o resultado de um projeto se tornará um produto da empresa. São eles:

'''•''' Se há ligação/semelhança do resultado do projeto com outros produtos da empresa. Nessa esfera, também é aplicável o critério de vínculos, quando o resultado do projeto é, de alguma forma, vinculado com um, ou mais, produtos existentes, tendo a possibilidade de absorver mais um produto ao Portfólio;

'''•''' Se há aplicabilidade do produto do projeto em outros clientes. Em muitas situações, o produto gerado pelo projeto poderia ser comercializado com outros clientes devido ao seu conteúdo, ou devido à sua estrutura – compatível com a necessidade de outros clientes;

'''•''' Se há diretrizes comerciais de alto nível, geralmente definidas pela Presidência da empresa ou com base na estratégia organizacional;

'''•''' Se há um nível baixo de customização necessária para a adaptação genérica do Produto gerado pelo projeto. Quando um produto é desenvolvido para determinado cliente, e essa entrega é específica para um negócio ou fim, geralmente não é interessante absorver esse resultado como produto, pois ele não é condizente com a necessidade de outros clientes, e nem aplicável em outras situações;

'''•''' Se o produto gerado pelo projeto for estratégico para o cliente. Quando determinado cliente solicitado algo específico, e que há um grande vínculo comercial e estratégico por parte do cliente, não é interessante anexar esse resultado ao Portfólio de Produtos.

Nesse contexto, a partir da análise dos itens supracitados, é possível determinar em qual momento um resultado de projeto se tornará um Produto da empresa, de qual forma e qual será a estratégia inicial para trabalhar essa evolução.
Todo o esforço de trabalho realizado com a utilização dos processos nos projetos deverá ser registrado no Sistema de Armazenamento de Horas de Trabalho, utilizando as tarefas relacionadas com o trabalho no respectivo projeto. Entretanto, o esforço utilizado com as Auditorias dos processos/projetos deverá ser registrado em um cronograma independente, pois os esforços despendidos para essas atividades não são registrados diretamente nos projetos.

Todos os colaboradores da empresa, que atuam nos Processos de Trabalho descritos neste documento, deverão possuir estações de trabalho configuradas (hardware, software e usuário de acesso pelo Active Directory) de acordo com as suas respectivas necessidades. Todos esses itens são gerenciados diretamente pelo departamento de Gestão da Tecnologia de Informação da MSTECH. É de responsabilidade dos responsáveis pelos projetos solicitar outros recursos materiais necessários para a execução do projeto.

Esta Política Organizacional deverá ser revisada anualmente (no mínimo) e aprovada pela Presidência da empresa, a contar da data de sua primeira publicação.

Políticas dos processos MSTECH

2016-11-18T22:15:44Z

Lucimara.maiorali:

Políticas dos processos MSTECH

2016-11-18T22:10:50Z

Lucimara.maiorali:

Politica Organizacional MSTECH

2016-11-16T17:22:02Z

Lucimara.maiorali:

'''Versão 1.0'''

A Política Organizacional da MSTECH Educação e Tecnologia Ltda abrange regras, métodos e conceitos para os projetos de '''Desenvolvimento de Software''' de '''toda a empresa'''. Este documento possui caráter oficial e tange como modelo de referência.

A página oficial dos Processos de Trabalho está disponível para toda a empresa. O local contém o Ciclo de Vida dos Projetos de Desenvolvimento de Software, além do fluxo geral dos Processos de Trabalho para Desenvolvimento de Software, Garantia da Qualidade e Gestão de Portfólio de Projetos. Por fim, há todos os templates de documentos utilizados pelo Processo de Desenvolvimento de Software e outros conteúdos importantes que auxiliam todos na utilização dos Processos de Trabalho. '''Todos os projetos de Desenvolvimento de Software''' (exceto Pesquisa e Desenvolvimento) '''da MSTECH devem utilizar os conteúdos supracitados''', de acordo com suas respectivas regras, além dos sistemas computacionais configurados para a gestão dos projetos/produtos e os softwares auxiliares que integram essas ferramentas.

O '''Processo de Trabalho de Desenvolvimento de Software''' é utilizado diretamente pelas áreas de '''Gestão de Projetos''' e de '''Requisitos''' e '''Gestão de Configuração'''. Suas quatro fases são cronológicas e possuem relação direta. Entretanto, a primeira e a última fase são únicas por projeto, e as intermediárias se repetem (cíclicas, não necessariamente de forma linear, tornando o processo iterativo) de acordo com o número de entregas do projeto. Há também etapas de monitoramento, que abrangem paralelamente todo o processo. Seu principal objetivo é conceder aos projetos de Desenvolvimento de Software padrões e procedimentos, visando garantir qualidade, desempenho e completa satisfação dos clientes, com resultados de alto valor agregado e condizentes com as necessidades estabelecidas. O processo deverá padronizar as atividades para as equipes de desenvolvimento da empresa, garantindo uniformidade em suas atividades de desenvolvimento de software. O processo deverá ser atualizado sempre que necessário, garantindo aderência para a realidade e objetivos estratégicos da MSTECH.

Todos os documentos obrigatórios e auxiliares dos projetos deverão ficar armazenados nos locais definidos pelo processo de desenvolvimento de software, sendo mantido para isso um sistema que possui a função de repositório. Já os artefatos técnicos, que farão parte do Produto desenvolvido pelo projeto, deverão estar presentes no Sistema de Gestão de Configuração, contemplados como parte das Baselines do Produto. Todas as alterações nos documentos precisam ser registra-das nos respectivos locais de armazenamento, de acordo com as diretrizes da Gestão de Configuração (GCO), assim como as demais regras de acesso, nomenclaturas e controles de versões.

O '''Processo de Trabalho de Gestão de Portfólio de Projetos''' é utilizado pelos responsáveis da Gestão de Portfólio de Projetos (GPP) e tem como objetivo principal realizar a gestão da carteira de projetos e clientes da MSTECH. O processo possui duas fases, sendo que a primeira é executada anualmente (ou quando for estritamente necessário) e a segunda é cíclica. Através da definição dos Fatores Comerciais e suas respectivas Priorizações, a Presidência, em conjunto com o responsável da Gestão de Portfólio de Projetos deverá organizar os Objetivos Estratégicos da empresa e, por fim, oficializar a Estratégia do Portfólio de Projetos. Tal Estratégia visa manter a aderência dos processos e projetos de acordo com os objetivos organizacionais, buscando, como foco principal, resultados satisfatórios para os clientes.

O '''Processo de Trabalho de Garantia da Qualidade''' é utilizado pela equipe QA e demonstra a expectativa da empresa na aderência e conformidade das atividades executadas com base nos Processos de Trabalho definidos. Este processo garantirá que todos os Processos de Trabalho definidos estão sendo seguidos de forma correta e íntegra.

As auditorias de garantia da qualidade dos projetos devem ser planejadas nas fases do ciclo de vida do projeto, nos marcos de 50% (projetos com duração dois meses), mensal (projetos com duração maior que dois meses) e antes das entregas ao cliente, no que tange as auditorias de garantia da qualidade do processo organizacional da Gestão de Portfólio de Projetos devem ser planejadas no “Plano de Garantia da Qualidade”. Nesse contexto, o documento “Plano de Garantia da Qualidade” deverá ser elaborado anualmente e, atualizado juntamente com esta Política Organizacional, servindo de suporte para a equipe QA, sendo mantidos nas ferramentas da empresa. Por fim, é importante ressaltar que a auditoria Independente de QA deverá ser planejada anualmente.

Todas as auditorias de garantia da qualidade devem ser executadas com a utilização de checklists de garantia da qualidade. Toda não conformidade identificada será acompanhada até a sua resolução seguindo às criticidades e prazos definidos no “Processo de Trabalho de Garantia da Qualidade”. As não conformidades não solucionadas no prazo definido pela criticidade deverão ser escalonadas ao superior imediato conforme organograma da empresa.

Os resultados das auditorias de garantia da qualidade deverão ser reportados conforme definido no “Processo de Trabalho de Garantia da Qualidade”.

Os '''Indicadores''' (resultado de '''Medição''') são itens essenciais para a gestão da empresa, pois apresentam, de forma condensada e objetiva, conforme necessário, a situação da empresa em diversos aspectos. Os Indicadores devem fornecer informações para:

'''•''' Manter a aderência nos processos de trabalho estabelecidos, de forma geral e/ou em etapas/atividades específicas;

'''•''' Gerenciar a situação dos projetos, no que tange prazo e esforço;

'''•''' Aprimorar as estimativas para o planejamento dos projetos;

'''•''' Apresentar subsídios para avaliar os próprios Indicadores estabelecidos.

Todo o planejamento, desde a coleta dos Indicadores, até as ações oriundas dos resultados das Medições, está documentado e oficializado nas Diretrizes de Medição. Tal documento deverá ser revisado com periodicidade anual, juntamente com esta Política Organizacional, e validado pela Presidência da empresa.

Para exercer cada papel nos processos, o colaborador (que pode atuar em dois ou mais papeis no mesmo projeto/processo, de acordo com o planejamento realizado e seguindo os critérios/limites de cada papel) deverá possuir requisitos mínimos de conhecimento, comprovados através de histórico profissional (viabilizado/garantido pelo departamento de Recursos Humanos), formação acadêmica, certificações, cursos/treinamentos (inclusive internos) ou pela própria atuação na MSTECH (sendo comprovada, por exemplo, via histórico de participação em outros projetos). Os requisitos para atuar em cada papel nos processos de trabalho, bem como as suas respectivas '''responsabilidades''', estão descritos no documento “Catálogo de Papeis” (disponível na página oficial de Processos de Trabalho).

Somente o Escritório de PCP poderá alterar os Processos de Trabalho estabelecidos, mediante análise em reuniões ou através de solicitações da Presidência da empresa. Também é de responsabilidade do PCP definir se há, ou não, necessidade de novos treinamentos após mudanças nos processos de trabalho, mas é essencial que todos sejam avisados sobre as mudanças realizadas. Após a alteração de um processo, todos os projetos e áreas envolvidas devem utilizar a nova versão publicada. Essa regra é válida também para novos templates, exceto para o repositório de gestão de projetos (e seus templates) e cronograma. Não é necessário realizar nenhuma ação retroativa para ambas as situações citadas (exceto em casos em que o Escritório de PCP ou a Presidência solicitar correções/alterações).

Os resultados gerados pelos projetos de Desenvolvimento de Software podem, também, se tornar produtos da empresa, sendo absorvidos para o Portfólio de Produtos da MSTECH. Entretanto, não é qualquer situação que se enquadra nesse conceito. Há critérios para definir se o resultado de um projeto se tornará um produto da empresa. São eles:

'''•''' Se há ligação/semelhança do resultado do projeto com outros produtos da empresa. Nessa esfera, também é aplicável o critério de vínculos, quando o resultado do projeto é, de alguma forma, vinculado com um, ou mais, produtos existentes, tendo a possibilidade de absorver mais um produto ao Portfólio;

'''•''' Se há aplicabilidade do produto do projeto em outros clientes. Em muitas situações, o produto gerado pelo projeto poderia ser comercializado com outros clientes devido ao seu conteúdo, ou devido à sua estrutura – compatível com a necessidade de outros clientes;

'''•''' Se há diretrizes comerciais de alto nível, geralmente definidas pela Presidência da empresa ou com base na estratégia organizacional;

'''•''' Se há um nível baixo de customização necessária para a adaptação genérica do Produto gerado pelo projeto. Quando um produto é desenvolvido para determinado cliente, e essa entrega é específica para um negócio ou fim, geralmente não é interessante absorver esse resultado como produto, pois ele não é condizente com a necessidade de outros clientes, e nem aplicável em outras situações;

'''•''' Se o produto gerado pelo projeto for estratégico para o cliente. Quando determinado cliente solicitado algo específico, e que há um grande vínculo comercial e estratégico por parte do cliente, não é interessante anexar esse resultado ao Portfólio de Produtos.

Nesse contexto, a partir da análise dos itens supracitados, é possível determinar em qual momento um resultado de projeto se tornará um Produto da empresa, de qual forma e qual será a estratégia inicial para trabalhar essa evolução.
Todo o esforço de trabalho realizado com a utilização dos processos nos projetos deverá ser registrado no Sistema de Armazenamento de Horas de Trabalho, utilizando as tarefas relacionadas com o trabalho no respectivo projeto. Entretanto, o esforço utilizado com as Auditorias dos processos/projetos deverá ser registrado em um cronograma independente, pois os esforços despendidos para essas atividades não são registrados diretamente nos projetos.

Todos os colaboradores da empresa, que atuam nos Processos de Trabalho descritos neste documento, deverão possuir estações de trabalho configuradas (hardware, software e usuário de acesso pelo Active Directory) de acordo com as suas respectivas necessidades. Todos esses itens são gerenciados diretamente pelo departamento de Gestão da Tecnologia de Informação da MSTECH. É de responsabilidade dos responsáveis pelos projetos solicitar outros recursos materiais necessários para a execução do projeto.

Esta Política Organizacional deverá ser revisada anualmente (no mínimo) e aprovada pela Presidência da empresa, a contar da data de sua primeira publicação.

Políticas dos processos MSTECH

2016-11-16T12:08:32Z

Lucimara.maiorali:

Diretrizes de Gestão de Configuração

2016-11-14T20:48:36Z

Lucimara.maiorali:

== Objetivo ==
Esta página descreve como estão definidos os itens de configuração, ''baselines'' e níveis de controle nos projetos e processos organizacionais de Gestão de Portfólio de Projetos e Medição.

== Nível de Controle ==

Os documentos e artefatos gerados pelos projetos e processos organizacionais são considerados itens de configuração e são classificados entre:

* Formal
Itens controlados com histórico de alterações e recuperação de versões anteriores, com a necessidade de solicitação formal para a realização de alterações. São artefatos que definem os requisitos e que contenham informações para a produção do produto a ser entregue (Exemplos: códigos fonte, documento de arquitetura, documentos técnicos enviados pelo cliente, outros documentos técnicos).
As modificações em artefatos formais são autorizadas através de tickets na ferramenta Redmine ou tasks no Youtrack e estas devem seguir o padrão abaixo:

'''#ID Alteração de artefato: <nome do artefato>'''

Sendo que #ID é o número da issue na ferramenta (Redmine ou Youtrack).

* Versionado
Itens controlados com histórico de alterações e recuperação de versões anteriores, sem a necessidade de solicitação formal para a realização de alterações. São artefatos de gestão (por exemplo: atas, relatórios gerenciais, coleta de indicadores) e demais artefatos que não se encaixem como “Formal”.

Nos tópicos a seguir serão apresentados os itens de configuração definidos para os projetos, bem como seus níveis de controle e acesso.

== Repositórios e Estrutura Padrão de Pastas ==

Os projetos utilizam pelo menos dois repositórios distintos, um para os artefatos de gestão nomeado nesse documento como repositório de gestão e outro para os artefatos que compõem o produto a ser produzido ou mantido, nomeado nesse documento como repositório de produto.
Os processos organizacionais possuem pelo menos um repositório para armazenamento de artefatos e registros de ações de acompanhamento.
Os projetos devem indicar os repositórios a serem utilizados e pode ser utilizado mais de um repositório de produto.

* '''Repositórios de gestão do projeto'''
O repositório de gestão utiliza a ferramenta Redmine e esse ambiente é administrado pela MSTECH. A utilização desse repositório é obrigatória para todos os projetos.

Repositório de gestão do projeto:
http://sg-redmine.mstech.com.br/ > Projetos > Nome do Projeto

* '''Repositórios de Produto'''
O repositório de artefatos técnicos do produto pode utilizar a ferramenta TFS ou GitLab. Ambos os ambientes são administrados pela MSTECH e cada registro de projeto (na ferramenta SharePoint) possui a informação da ferramenta utilizada. A utilização de pelo menos um desses repositórios é obrigatória para todos os projetos.
Além disso, a ferramenta Youtrack deve ser utilizada para gestão do backlog e apontamento de horas.

Repositórios de produto:
tfs:8080/tfs/ > Collection > Produto
gitlab.mstech.com.br/ > Produto
https://youtrack.mstech.com.br/ > Container do produto

* '''Repositório de Garantia da Qualidade'''
O repositório oficial de Garantia da Qualidade utiliza a ferramenta Redmine com o nome “Garantia da Qualidade”. O ambiente é administrado pela MSTECH e sua utilização é obrigatória.

Repositório:
http://sg-redmine.mstech.com.br/ > Projetos > Garantia da Qualidade

* '''Repositórios de Gestão de Portfólio de Projetos'''
O repositório de uso do processo de Gestão de Portfólio de Projetos encontra-se na ferramenta Redmine com o nome “Gestão de Portfólio de Projetos”. O ambiente é mantido pela MSTECH e a utilização é obrigatória.

Repositórios:
http://sg-redmine.mstech.com.br/ > Projetos > Gestão de Portfólio de Projetos

* '''Repositórios de Medição'''
O repositório para armazenamento de artefatos concluídos de medição e análises de indicadores utiliza a ferramenta Redmine com o nome “Medição”. O ambiente é administrado pela MSTECH e sua utilização é obrigatória.

Repositório:
http://sg-redmine.mstech.com.br/ > Projetos > Medição

* '''Repositório de Diretrizes'''
Todas as diretrizes existentes são mantidas na wiki corporativa da MSTECH.

Repositório:
https://wiki.mstech.com.br/ > Padrões de Desenvolvimento MSTECH > Diretrizes

== Controle de Acessos ==

Para o repositório de gestão de projetos, o acesso é estabelecido no Redmine, conforme indicado abaixo:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" rowspan=2 |Papeis
! scope="col" |Repositório
|-
! scope="col"| Único
|-
|Product Owner
|Colaboração
|-
|Scrum Master
|Colaboração
|-
|Desenvolvedores
|Colaboração
|-
|Analistas de Testes
|Colaboração
|-
|Analistas de QA
|Leitura
|-
|Responsável por GPP
|Colaboração
|-
|Responsável por Medição
|Leitura
|-
|Diretoria
|Leitura
|-
|Escritório de PCP
|Colaboração
|-
|Arquiteto
|Colaboração
|}

Para artefatos de produtos, o acesso ao repositório no TFS é composto da seguinte forma:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" rowspan=2 |Papeis
! scope="col" colspan=4|Repositório
|-
! scope="col"| Src
! scope="col"| Docs
! scope="col"| Tests
! scope="col"| Build
|-
|Product Owner
|Leitura
|Colaboração
|Leitura
|Leitura
|-
|Scrum Master
|Colaboração
|Colaboração
|Colaboração
|Colaboração
|-
|Desenvolvedores
|Colaboração
|Colaboração
|Leitura
|Colaboração
|-
|Analistas de Testes
|Leitura
|Colaboração
|Colaboração
|Colaboração
|-
|Analistas de QA
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Responsável por GPP
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Responsável por Medição
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Diretoria
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Escritório de PCP
|Leitura
|Leitura
|Leitura
|Leitura
|-
|Arquiteto
|Colaboração
|Colaboração
|Colaboração
|Leitura
|}

Já o acesso ao repositório no GitLab é composto da seguinte forma:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" rowspan=2 |Papeis
! scope="col" |Repositório
|-
! scope="col"| Src
|-
|Product Owner
|Colaboração
|-
|Scrum Master
|Colaboração
|-
|Desenvolvedores
|Colaboração
|-
|Analistas de Testes
|Colaboração
|-
|Analistas de QA
|Colaboração
|-
|Responsável por GPP
|Colaboração
|-
|Responsável por Medição
|Colaboração
|-
|Diretoria
|Colaboração
|-
|Escritório de PCP
|Colaboração
|-
|Arquiteto
|Colaboração
|}

Por fim, o repositório para gestão do backlog do produto é configurado da forma abaixo:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" rowspan=2 |Papeis
! scope="col" |Repositório
|-
! scope="col"| Único
|-
|Product Owner
|Colaboração
|-
|Scrum Master
|Colaboração
|-
|Desenvolvedores
|Colaboração
|-
|Analistas de Testes
|Colaboração
|-
|Analistas de QA
|Leitura
|-
|Responsável por GPP
|Leitura
|-
|Responsável por Medição
|Leitura
|-
|Diretoria
|Leitura
|-
|Escritório de PCP
|Colaboração
|-
|Arquiteto
|Colaboração
|}

Para cada célula, haverá um membro da equipe com acesso suficiente para administrar todas as permissões dos repositórios de produtos atendidos pela célula. Na falta desse integrante, deve ser nomeado um substituto para assumir a responsabilidade de manter as permissões dos repositórios devidamente atribuídas.

Para artefatos gerados pelo QA, o acesso ao repositório se faz da seguinte maneira:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" rowspan=2 |Papeis
! scope="col" |Repositório
|-
! scope="col"| Único
|-
|Product Owner
|Leitura
|-
|Scrum Master
|Leitura
|-
|Desenvolvedores
|Leitura
|-
|Analistas de Testes
|Leitura
|-
|Analistas de QA
|Colaboração
|-
|Responsável por GPP
|Leitura
|-
|Responsável por Medição
|Leitura
|-
|Diretoria
|Leitura
|-
|Escritório de PCP
|Leitura
|-
|Arquiteto
|Leitura
|}

Para artefatos gerados por GPP na ferramenta Redmine, o acesso ao repositório se faz da seguinte maneira:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" rowspan=2 |Papeis
! scope="col" |Repositório
|-
! scope="col"| Único
|-
|Product Owner
|Leitura
|-
|Scrum Master
|Leitura
|-
|Desenvolvedores
|Leitura
|-
|Analistas de Testes
|Leitura
|-
|Analistas de QA
|Colaboração
|-
|Responsável por GPP
|Colaboração
|-
|Responsável por Medição
|Leitura
|-
|Diretoria
|Leitura
|-
|Escritório de PCP
|Colaboração
|-
|Arquiteto
|Leitura
|}

Para artefatos gerados por GPP na ferramenta Sharepoint, o acesso ao repositório se faz da seguinte maneira:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" rowspan=2 |Papeis
! scope="col" |Repositório
|-
! scope="col"| Único
|-
|Product Owner
|Colaboração
|-
|Scrum Master
|Colaboração
|-
|Desenvolvedores
|Leitura
|-
|Analistas de Testes
|Leitura
|-
|Analistas de QA
|Leitura
|-
|Responsável por GPP
|Colaboração
|-
|Responsável por Medição
|Leitura
|-
|Diretoria
|Leitura
|-
|Escritório de PCP
|Colaboração
|-
|Arquiteto
|Leitura
|}

Para os artefatos de medição, o acesso ao repositório é composto da forma abaixo:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" rowspan=2 |Papeis
! scope="col" |Repositório
|-
! scope="col"| Único
|-
|Product Owner
|Leitura
|-
|Scrum Master
|Leitura
|-
|Desenvolvedores
|Leitura
|-
|Analistas de Testes
|Leitura
|-
|Analistas de QA
|Leitura
|-
|Responsável por GPP
|Leitura
|-
|Responsável por Medição
|Colaboração
|-
|Diretoria
|Leitura
|-
|Escritório de PCP
|Colaboração
|-
|Arquiteto
|Leitura
|}

O repositório que armazena as diretrizes da MSTECH, por sua vez, possui o acesso composto da seguinte maneira:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" rowspan=2 |Papeis
! scope="col" |Repositório
|-
! scope="col"| Único
|-
|Product Owner
|Leitura
|-
|Scrum Master
|Leitura
|-
|Desenvolvedores
|Leitura
|-
|Analistas de Testes
|Leitura
|-
|Analistas de QA
|Leitura
|-
|Responsável por GPP
|Leitura
|-
|Responsável por Medição
|Leitura
|-
|Diretoria
|Leitura
|-
|Escritório de PCP
|Colaboração
|-
|Arquiteto
|Leitura
|}

== ''Baseline'' de Produto ==

As ''baselines'' de cada entrega do produto deverão ser nomeadas de acordo com a regra abaixo.

'''v<X.X.X.X.>'''

'''Exemplo:''' v1.2.1.3

Obs.: as ''baselines'' são estabelecidas utilizando ''labels'' (no TFS) ou ''tags'' (no GitLab).

== Itens de Configuração ==

As tabelas abaixo estão divididas de acordo com os repositórios definidos (de gestão, produto, QA, GPP e Medição) e mostram a identificação dos itens de configuração e as seguintes informações: identificação do item, regra de nomenclatura, local para armazenamento, nível de controle, obrigatoriedade de ser gerado, necessidade de aprovação pelo cliente, e ''baseline'' onde é incorporado.

=== Lista de itens no repositório do projeto ===

Redmine:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Necessidades do cliente
|(Nome do projeto)-NecessidadesCliente
|Documentos do pré-projeto no Redmine
|Formal
|Sim
|Sim
|Entrega
|-
|Plano de projeto inicial
|(Nome do projeto)-PlanoProjetoInicial
|Documentos do pré-projeto no Redmine
|Versionado
|Sim
|Não
|Não íntegra
|-
|Checklist de auditoria de iniciação
|(Nome do projeto)-ChecklistIniciação
|Tarefa de auditoria no Redmine
|Versionado
|Sim
|Não
|Não íntegra
|-
|Ordem de serviço interna
|OrdemServiço_AAAA-XXXXXX
|Registro do projeto do Sharepoint
|Versionado
|Sim
|Não
|Não íntegra
|-
|Plano de projeto
|Não se aplica
|Wiki do Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Cronograma do projeto
|Não se aplica
|Gantt/ Calendário do Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Riscos do projeto
|Não se aplica
|Tarefa de risco no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Análise de viabilidade inicial
|Não se aplica
|Tarefa de análise de viabilidade inicial no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de comprometimento da equipe
|Não se aplica
|Tarefa de registro de validação de planejamento no Redmine no projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Checklist de auditoria de planejamento
|(Nome do projeto)-ChecklistPlanejamento
|Tarefa de auditoria no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro do sprint review
|Review - Sprint (nome da sprint)
|Comentário na tarefa de review no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Autorização de publicação em produção
|(Nome do projeto)-AutorizaçãoPublicação
|Anexo na tarefa de publicação em produção no Redmine do projeto
|Versionado
|Sim
|Sim
|Não íntegra
|-
|Termo de aceite
|(Nome do projeto)-TermoAceite
|Anexo na tarefa de publicação em produção no Redmine do projeto
|Versionado
|Sim
|Sim
|Não íntegra
|-
|Revisão de resultados do projeto
|Revisão de Resultados
|Tarefa de revisão de resultados no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de problema do projeto
|Não se aplica
|Tarefa de problema no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Checklist de auditoria de encerramento
|(Nome do projeto)-ChecklistEncerramento
|Tarefa de auditoria no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de ponto de controle
|Ponto de Controle (número do ponto de controle)
|Tarefa de ponto de controle no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de revisão de marco
|Revisão de Marco - (nome do marco)
|Tarefa de revisão de marco no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de mudança
|Não se aplica
|Tarefa de registro de mudança no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Análise de viabilidade periódica
|Não se aplica
|Tarefa de análise de viabilidade periódica no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de lição aprendida do projeto
|Não se aplica
|Tarefa de lição aprendida no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de não conformidade de projeto
|Não se aplica
|Tarefa de não conformidade no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de cancelamento/ suspensão do projeto
|Não se aplica
|Tarefa de cancelamento/ suspensão do projeto no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Relatório de entrega
|(Nome do projeto)-RelatorioEntrega
|Anexo na tarefa de publicação em produção no Redmine do projeto (cronograma)
|Versionado
|Sim
|Sim
|Não íntegra
|-
|Checklist de auditoria periódica de projeto
|(Nome do projeto)-ChecklistPeriódica
|Anexo na tarefa de auditoria periódica do projeto no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|-
|Checklist de auditoria de entrega
|(Nome do projeto)-ChecklistEntrega
|Anexo na tarefa de auditoria de entrega no Redmine do projeto
|Versionado
|Sim
|Não
|Não íntegra
|}

SharePoint:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Documento de transição
|(Nome do projeto)-DocumentoTransição
|Anexo ao registro do hub no Sharepoint
|Versionado
|Não
|Não
|Não íntegra
|-
|Planilha de transição
|(Nome do Projeto)-Transição
|Anexo ao registro do hub no Sharepoint
|Versionado
|Sim
|Não
|Não íntegra
|-
|Ordem de Serviço
|(AAAA)_(NúmeroOS)
|Anexo ao registro do projeto no Sharepoint
|Versionado
|Sim
|Não
|Não íntegra
|}

Youtrack:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Backlog da sprint
|Não se aplica
|Container do projeto no Youtrack
|Versionado
|Sim
|Não
|Não íntegra
|-
|Caso de teste
|Não se aplica
|Comentários nas tarefas de teste no container do projeto no Youtrack
|Formal
|Sim
|Não
|Não íntegra
|-
|Registro do sprint planning
|Planning - Sprint (nome da sprint)
|Comentário na tarefa de planning no container do projeto no Youtrack
|Versionado
|Sim
|Não
|Não íntegra
|-
|Tarefa de publicação em produção
|Publicação em Produção - v(número da versão)
|Container do projeto no Youtrack
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro da retrospectiva
|Retrospectiva - Sprint (nome da sprint)
|Comentário na tarefa de retrospectiva no container do projeto no Youtrack
|Versionado
|Sim
|Não
|Não íntegra
|}

=== Lista de itens no repositório do produto ===

TFS/ GitLab

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Código-fonte
|(padrão CamelCase)
|Pasta “Src” no repositório do produto
|Formal
|Sim
|Não
|Entrega
|-
|Pacote de entrega do produto
|V(número da versão) - (Nome do produto)
|Repositório do produto
|Formal
|Sim
|Sim
|Entrega
|-
|Manual de instalação e atualização
|(Nome do produto)-ManualInstalacaoAtualizacao
|Wiki no repositório do produto (GitLab) / Pasta “Docs” no repositório do produto (TFS)
|Formal
|Não
|Sim
|Entrega
|-
|Documento de arquitetura
|Arquitetura do Produto
|Wiki no repositório do produto / Pasta “Docs” no repositório do produto (TFS)
|Formal
|Sim
|Não
|Não íntegra
|-
|Necessidades do cliente
|(Nome do projeto)-NecessidadesCliente
|Pasta “Docs” no repositório do produto
|Formal
|Sim
|Sim
|Entrega
|}

=== Lista de itens no repositório do QA ===

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Cronograma de auditorias do QA
|Não se aplica
|Gantt/ Calendário do Redmine do QA
|Versionado
|Sim
|Não
|Não íntegra
|-
|Plano de Garantia da Qualidade
|Plano de Garantia da Qualidade – (ano)
|Wiki no Redmine do QA
|Formal
|Sim
|Não
|Não íntegra
|-
|Relatório gerencial de não conformidades
|Relatório Gerencial - (mês)
|Documentos no Redmine do QA
|Versionado
|Sim
|Não
|Não íntegra
|-
|Registro de lição aprendida do QA
|Não se aplica
|Tarefa de lição aprendida no Redmine do QA
|Versionado
|Sim
|Não
|Não íntegra
|}

=== Lista de Itens no repositório de GPP ===

Redmine:

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Registro de não conformidade de GPP
|Não se aplica
|Tarefa de não conformidade no Redmine de GPP
|Versionado
|Não
|Não
|Não íntegra
|-
|Registro de lição aprendida de GPP
|Não se aplica
|Tarefa de lição aprendida no Redmine de GPP
|Versionado
|Sim
|Não
|Não íntegra
|-
|Objetivos estratégicos de GPP
|Objetivos Estratégicos
|Documentos no Redmine de GPP
|Formal
|Sim
|Não
|Não íntegra
|-
|Checklist de auditoria de execução de GPP
|GPP-ChecklistExecução
|Anexo na tarefa de auditoria de execução de GPP no Redmine de GPP
|Versionado
|Sim
|Não
|Não íntegra
|-
|Checklist de auditoria de planejamento anual de GPP
|GPP-ChecklistPlanejamentoAnual
|Anexo na tarefa de auditoria de planejamento anual de GPP no Redmine de GPP
|Versionado
|Sim
|Não
|Não íntegra
|}

=== Lista de Itens no repositório de Medição ===

=== Lista de itens no repositório de diretrizes ===

{| class="wikitable" style="text-align: center; style="margin: auto;"
|-
! scope="col" |Artefato (por Projeto/Produto)
! scope="col" |Regra de Nomenclatura
! scope="col" |Armazenamento (do artefato concluído)
! scope="col" |Tipo
! scope="col" |Obrigatório?
! scope="col" |Aprovado pelo cliente?
! scope="col" |Baseline
|-
|Diretrizes de Comunicação
|Diretrizes de Comunicação
|Página de padrões de desenvolvimento da MSTECH na Wiki corporativa
|Versionado
|Sim
|Não
|Não íntegra
|-
|Diretrizes de Gestão de Configuração
|Diretrizes de Gestão de Configuração
|Página de padrões de desenvolvimento da MSTECH na Wiki corporativa
|Versionado
|Sim
|Não
|Não íntegra
|-
|Diretrizes de Medição
|Diretrizes de Medição
|Página de padrões de desenvolvimento da MSTECH na Wiki corporativa
|Versionado
|Sim
|Não
|Não íntegra
|}

Politica Organizacional MSTECH

2016-11-10T22:40:41Z

Lucimara.maiorali:

'''Versão 1.0'''

A Política Organizacional da MSTECH Educação e Tecnologia Ltda abrange regras, métodos e conceitos para os projetos de '''Desenvolvimento de Software''' de '''toda a empresa'''. Este documento possui caráter oficial e tange como modelo de referência.

A página oficial dos Processos de Trabalho está disponível para toda a empresa. O local contém o Ciclo de Vida dos Projetos de Desenvolvimento de Software, além do fluxo geral dos Processos de Trabalho para Desenvolvimento de Software, Garantia da Qualidade e Gestão de Portfólio de Projetos. Por fim, há todos os templates de documentos utilizados pelo Processo de Desenvolvimento de Software e outros conteúdos importantes que auxiliam todos na utilização dos Processos de Trabalho. '''Todos os projetos de Desenvolvimento de Software''' (exceto Pesquisa e Desenvolvimento) '''da MSTECH devem utilizar os conteúdos supracitados''', de acordo com suas respectivas regras, além dos sistemas computacionais configurados para a gestão dos projetos/produtos e os softwares auxiliares que integram essas ferramentas.

O '''Processo de Trabalho de Desenvolvimento de Software''' é utilizado diretamente pelas áreas de '''Gestão de Projetos''' e de '''Requisitos''' e '''Gestão de Configuração'''. Suas quatro fases são cronológicas e possuem relação direta. Entretanto, a primeira e a última fase são únicas por projeto, e as intermediárias se repetem (cíclicas, não necessariamente de forma linear, tornando o processo iterativo) de acordo com o número de entregas do projeto. Há também etapas de monitoramento, que abrangem paralelamente todo o processo. Seu principal objetivo é conceder aos projetos de Desenvolvimento de Software padrões e procedimentos, visando garantir qualidade, desempenho e completa satisfação dos clientes, com resultados de alto valor agregado e condizentes com as necessidades estabelecidas. O processo deverá padronizar as atividades para as equipes de desenvolvimento da empresa, garantindo uniformidade em suas atividades de desenvolvimento de software. O processo deverá ser atualizado sempre que necessário, garantindo aderência para a realidade e objetivos estratégicos da MSTECH.

Todos os documentos obrigatórios e auxiliares dos projetos deverão ficar armazenados nos locais definidos pelo processo de desenvolvimento de software, sendo mantido para isso um sistema que possui a função de repositório. Já os artefatos técnicos, que farão parte do Produto desenvolvido pelo projeto, deverão estar presentes no Sistema de Gestão de Configuração, contemplados como parte das Baselines do Produto. Todas as alterações nos documentos precisam ser registra-das nos respectivos locais de armazenamento, de acordo com as diretrizes da Gestão de Configuração (GCO), assim como as demais regras de acesso, nomenclaturas e controles de versões.

O '''Processo de Trabalho de Gestão de Portfólio de Projetos''' é utilizado pelos responsáveis da Gestão de Portfólio de Projetos (GPP) e tem como objetivo principal realizar a gestão da carteira de projetos e clientes da MSTECH. O processo possui duas fases, sendo que a primeira é executada anualmente (ou quando for estritamente necessário) e a segunda é cíclica. Através da definição dos Fatores Comerciais e suas respectivas Priorizações, a Presidência, em conjunto com o responsável da Gestão de Portfólio de Projetos deverá organizar os Objetivos Estratégicos da empresa e, por fim, oficializar a Estratégia do Portfólio de Projetos. Tal Estratégia visa manter a aderência dos processos e projetos de acordo com os objetivos organizacionais, buscando, como foco principal, resultados satisfatórios para os clientes.

O '''Processo de Trabalho de Garantia da Qualidade''' é utilizado pela equipe QA e demonstra a expectativa da empresa na aderência e conformidade das atividades executadas com base nos Processos de Trabalho definidos. Este processo garantirá que todos os Processos de Trabalho definidos estão sendo seguidos de forma correta e íntegra.

As auditorias QA dos projetos devem ser planejadas nas fases do ciclo de vida do projeto, nos marcos de 50% (projetos com duração dois meses), mensal (projetos com duração maior que dois meses) e antes das entregas ao cliente, no que tange as auditorias QA do processo organizacional da Gestão de Portfólio de Projetos devem ser planejadas no “Plano de Garantia da Qualidade”. Nesse contexto, o documento “Plano de Garantia da Qualidade” deverá ser elaborado anualmente e, atualizado juntamente com esta Política Organizacional, servindo de suporte para a equipe QA, sendo mantidos nas ferramentas da empresa. Por fim, é importante ressaltar que a auditoria Independente de QA deverá ser planejada anualmente.

Todas as auditorias QA devem ser executadas com a utilização de checklists de garantia da qualidade. Toda não conformidade identificada será acompanhada até a sua resolução seguindo às criticidades e prazos definidos no “Processo de Trabalho de Garantia da Qualidade”. As não conformidades não solucionadas no prazo definido pela criticidade deverão ser escalonadas ao superior imediato conforme organograma da empresa.
Os resultados das auditorias QA deverão ser reportados conforme definido no “Processo de Trabalho de Garantia da Qualidade”.

Os '''Indicadores''' (resultado de '''Medição''') são itens essenciais para a gestão da empresa, pois apresentam, de forma condensada e objetiva, conforme necessário, a situação da empresa em diversos aspectos. Os Indicadores devem fornecer informações para:

'''•''' Manter a aderência nos processos de trabalho estabelecidos, de forma geral e/ou em etapas/atividades específicas;

'''•''' Gerenciar a situação dos projetos, no que tange prazo e esforço;

'''•''' Aprimorar as estimativas para o planejamento dos projetos;

'''•''' Apresentar subsídios para avaliar os próprios Indicadores estabelecidos.

Todo o planejamento, desde a coleta dos Indicadores, até as ações oriundas dos resultados das Medições, está documentado e oficializado nas Diretrizes de Medição. Tal documento deverá ser revisado com periodicidade anual, juntamente com esta Política Organizacional, e validado pela Presidência da empresa.

Para exercer cada papel nos processos, o colaborador (que pode atuar em dois ou mais papeis no mesmo projeto/processo, de acordo com o planejamento realizado e seguindo os critérios/limites de cada papel) deverá possuir requisitos mínimos de conhecimento, comprovados através de histórico profissional (viabilizado/garantido pelo departamento de Recursos Humanos), formação acadêmica, certificações, cursos/treinamentos (inclusive internos) ou pela própria atuação na MSTECH (sendo comprovada, por exemplo, via histórico de participação em outros projetos). Os requisitos para atuar em cada papel nos processos de trabalho, bem como as suas respectivas '''responsabilidades''', estão descritos no documento “Catálogo de Papeis” (disponível na página oficial de Processos de Trabalho).

Somente o Escritório de PCP poderá alterar os Processos de Trabalho estabelecidos, mediante análise em reuniões ou através de solicitações da Presidência da empresa. Também é de responsabilidade do PCP definir se há, ou não, necessidade de novos treinamentos após mudanças nos processos de trabalho, mas é essencial que todos sejam avisados sobre as mudanças realizadas. Após a alteração de um processo, todos os projetos e áreas envolvidas devem utilizar a nova versão publicada. Essa regra é válida também para novos templates, exceto para o repositório de gestão de projetos (e seus templates) e cronograma. Não é necessário realizar nenhuma ação retroativa para ambas as situações citadas (exceto em casos em que o Escritório de PCP ou a Presidência solicitar correções/alterações).

Os resultados gerados pelos projetos de Desenvolvimento de Software podem, também, se tornar produtos da empresa, sendo absorvidos para o Portfólio de Produtos da MSTECH. Entretanto, não é qualquer situação que se enquadra nesse conceito. Há critérios para definir se o resultado de um projeto se tornará um produto da empresa. São eles:

'''•''' Se há ligação/semelhança do resultado do projeto com outros produtos da empresa. Nessa esfera, também é aplicável o critério de vínculos, quando o resultado do projeto é, de alguma forma, vinculado com um, ou mais, produtos existentes, tendo a possibilidade de absorver mais um produto ao Portfólio;

'''•''' Se há aplicabilidade do produto do projeto em outros clientes. Em muitas situações, o produto gerado pelo projeto poderia ser comercializado com outros clientes devido ao seu conteúdo, ou devido à sua estrutura – compatível com a necessidade de outros clientes;

'''•''' Se há diretrizes comerciais de alto nível, geralmente definidas pela Presidência da empresa ou com base na estratégia organizacional;

'''•''' Se há um nível baixo de customização necessária para a adaptação genérica do Produto gerado pelo projeto. Quando um produto é desenvolvido para determinado cliente, e essa entrega é específica para um negócio ou fim, geralmente não é interessante absorver esse resultado como produto, pois ele não é condizente com a necessidade de outros clientes, e nem aplicável em outras situações;

'''•''' Se o produto gerado pelo projeto for estratégico para o cliente. Quando determinado cliente solicitado algo específico, e que há um grande vínculo comercial e estratégico por parte do cliente, não é interessante anexar esse resultado ao Portfólio de Produtos.

Nesse contexto, a partir da análise dos itens supracitados, é possível determinar em qual momento um resultado de projeto se tornará um Produto da empresa, de qual forma e qual será a estratégia inicial para trabalhar essa evolução.
Todo o esforço de trabalho realizado com a utilização dos processos nos projetos deverá ser registrado no Sistema de Armazenamento de Horas de Trabalho, utilizando as tarefas relacionadas com o trabalho no respectivo projeto. Entretanto, o esforço utilizado com as Auditorias dos processos/projetos deverá ser registrado em um cronograma independente, pois os esforços despendidos para essas atividades não são registrados diretamente nos projetos.

Todos os colaboradores da empresa, que atuam nos Processos de Trabalho descritos neste documento, deverão possuir estações de trabalho configuradas (hardware, software e usuário de acesso pelo Active Directory) de acordo com as suas respectivas necessidades. Todos esses itens são gerenciados diretamente pelo departamento de Gestão da Tecnologia de Informação da MSTECH. É de responsabilidade dos responsáveis pelos projetos solicitar outros recursos materiais necessários para a execução do projeto.

Esta Política Organizacional deverá ser revisada anualmente (no mínimo) e aprovada pela Presidência da empresa, a contar da data de sua primeira publicação.

Politica Organizacional MSTECH

2016-11-10T22:28:23Z

Lucimara.maiorali:

'''Versão 1.0'''

A Política Organizacional da MSTECH Educação e Tecnologia Ltda abrange regras, métodos e conceitos para os projetos de '''Desenvolvimento de Software''' de '''toda a empresa'''. Este documento possui caráter oficial e tange como modelo de referência.

A página oficial dos Processos de Trabalho está disponível para toda a empresa. O local contém o Ciclo de Vida dos Projetos de Desenvolvimento de Software, além do fluxo geral dos Processos de Trabalho para Desenvolvimento de Software, Garantia da Qualidade e Gestão de Portfólio de Projetos. Por fim, há todos os templates de documentos utilizados pelo Processo de Desenvolvimento de Software e outros conteúdos importantes que auxiliam todos na utilização dos Processos de Trabalho. '''Todos os projetos de Desenvolvimento de Software''' (exceto Pesquisa e Desenvolvimento) '''da MSTECH devem utilizar os conteúdos supracitados''', de acordo com suas respectivas regras, além dos sistemas computacionais configurados para a gestão dos projetos/produtos e os softwares auxiliares que integram essas ferramentas.

O '''Processo de Trabalho de Desenvolvimento de Software''' é utilizado diretamente pelas áreas de '''Gestão de Projetos''' e de '''Requisitos''' e '''Gestão de Configuração'''. Suas quatro fases são cronológicas e possuem relação direta. Entretanto, a primeira e a última fase são únicas por projeto, e as intermediárias se repetem (cíclicas, não necessariamente de forma linear, tornando o processo iterativo) de acordo com o número de entregas do projeto. Há também etapas de monitoramento, que abrangem paralelamente todo o processo. Seu principal objetivo é conceder aos projetos de Desenvolvimento de Software padrões e procedimentos, visando garantir qualidade, desempenho e completa satisfação dos clientes, com resultados de alto valor agregado e condizentes com as necessidades estabelecidas. O processo deverá padronizar as atividades para as equipes de desenvolvimento da empresa, garantindo uniformidade em suas atividades de desenvolvimento de software. O processo deverá ser atualizado sempre que necessário, garantindo aderência para a realidade e objetivos estratégicos da MSTECH.

Todos os documentos obrigatórios e auxiliares dos projetos deverão ficar armazenados nos locais definidos pelo processo de desenvolvimento de software, sendo mantido para isso um sistema que possui a função de repositório. Já os artefatos técnicos, que farão parte do Produto desenvolvido pelo projeto, deverão estar presentes no Sistema de Gestão de Configuração, contemplados como parte das Baselines do Produto. Todas as alterações nos documentos precisam ser registra-das nos respectivos locais de armazenamento, de acordo com as diretrizes da Gestão de Configuração (GCO), assim como as demais regras de acesso, nomenclaturas e controles de versões.

O '''Processo de Trabalho de Gestão de Portfólio de Projetos''' é utilizado pelos responsáveis da Gestão de Portfólio de Projetos (GPP) e tem como objetivo principal realizar a gestão da carteira de projetos e clientes da MSTECH. O processo possui duas fases, sendo que a primeira é executada anualmente (ou quando for estritamente necessário) e a segunda é cíclica. Através da definição dos Fatores Comerciais e suas respectivas Priorizações, a Presidência, em conjunto com o responsável da Gestão de Portfólio de Projetos deverá organizar os Objetivos Estratégicos da empresa e, por fim, oficializar a Estratégia do Portfólio de Projetos. Tal Estratégia visa manter a aderência dos processos e projetos de acordo com os objetivos organizacionais, buscando, como foco principal, resultados satisfatórios para os clientes.

O '''Processo de Trabalho de Garantia da Qualidade''' é utilizado pela equipe QA e demonstra a expectativa da empresa na aderência e conformidade das atividades executadas com base nos Processos de Trabalho definidos. Este processo garantirá que todos os Processos de Trabalho definidos estão sendo seguidos de forma correta e íntegra, as auditorias QA dos projetos devem ser planejadas nas fases do ciclo de vida do projeto, nos marcos de 50% (projetos com duração dois meses), mensal (projetos com duração maior que dois meses) e antes das entregas ao cliente, no que tange as auditorias QA do processo organizacional da Gestão de Portfólio de Projetos devem ser planejadas no “Plano de Garantia da Qualidade”. Nesse contexto, o documento “Plano de Garantia da Qualidade” deverá ser elaborado anualmente e, atualizado juntamente com esta Política Organizacional, servindo de suporte para a equipe QA, sendo mantidos nas ferramentas da empresa. Por fim, é importante ressaltar que a auditoria Independente de QA deverá ser planejada anualmente.

Todas as auditorias QA devem ser executadas com a utilização de checklists de garantia da qualidade. Toda não conformidade identificada será acompanhada até a sua resolução seguindo às criticidades e prazos definidos no “Processo de Trabalho de Garantia da Qualidade”. As não conformidades não solucionadas no prazo definido pela criticidade deverão ser escalonadas ao superior imediato conforme organograma da empresa.
Os resultados das auditorias QA deverão ser reportados conforme definido no “Processo de Trabalho de Garantia da Qualidade”.

Os '''Indicadores''' (resultado de '''Medição''') são itens essenciais para a gestão da empresa, pois apresentam, de forma condensada e objetiva, conforme necessário, a situação da empresa em diversos aspectos. Os Indicadores devem fornecer informações para:

'''•''' Manter a aderência nos processos de trabalho estabelecidos, de forma geral e/ou em etapas/atividades específicas;

'''•''' Gerenciar a situação dos projetos, no que tange prazo e esforço;

'''•''' Aprimorar as estimativas para o planejamento dos projetos;

'''•''' Apresentar subsídios para avaliar os próprios Indicadores estabelecidos.

Todo o planejamento, desde a coleta dos Indicadores, até as ações oriundas dos resultados das Medições, está documentado e oficializado nas Diretrizes de Medição. Tal documento deverá ser revisado com periodicidade anual, juntamente com esta Política Organizacional, e validado pela Presidência da empresa.

Para exercer cada papel nos processos, o colaborador (que pode atuar em dois ou mais papeis no mesmo projeto/processo, de acordo com o planejamento realizado e seguindo os critérios/limites de cada papel) deverá possuir requisitos mínimos de conhecimento, comprovados através de histórico profissional (viabilizado/garantido pelo departamento de Recursos Humanos), formação acadêmica, certificações, cursos/treinamentos (inclusive internos) ou pela própria atuação na MSTECH (sendo comprovada, por exemplo, via histórico de participação em outros projetos). Os requisitos para atuar em cada papel nos processos de trabalho, bem como as suas respectivas '''responsabilidades''', estão descritos no documento “Catálogo de Papeis” (disponível na página oficial de Processos de Trabalho).

Somente o Escritório de PCP poderá alterar os Processos de Trabalho estabelecidos, mediante análise em reuniões ou através de solicitações da Presidência da empresa. Também é de responsabilidade do PCP definir se há, ou não, necessidade de novos treinamentos após mudanças nos processos de trabalho, mas é essencial que todos sejam avisados sobre as mudanças realizadas. Após a alteração de um processo, todos os projetos e áreas envolvidas devem utilizar a nova versão publicada. Essa regra é válida também para novos templates, exceto para o repositório de gestão de projetos (e seus templates) e cronograma. Não é necessário realizar nenhuma ação retroativa para ambas as situações citadas (exceto em casos em que o Escritório de PCP ou a Presidência solicitar correções/alterações).

Os resultados gerados pelos projetos de Desenvolvimento de Software podem, também, se tornar produtos da empresa, sendo absorvidos para o Portfólio de Produtos da MSTECH. Entretanto, não é qualquer situação que se enquadra nesse conceito. Há critérios para definir se o resultado de um projeto se tornará um produto da empresa. São eles:

'''•''' Se há ligação/semelhança do resultado do projeto com outros produtos da empresa. Nessa esfera, também é aplicável o critério de vínculos, quando o resultado do projeto é, de alguma forma, vinculado com um, ou mais, produtos existentes, tendo a possibilidade de absorver mais um produto ao Portfólio;

'''•''' Se há aplicabilidade do produto do projeto em outros clientes. Em muitas situações, o produto gerado pelo projeto poderia ser comercializado com outros clientes devido ao seu conteúdo, ou devido à sua estrutura – compatível com a necessidade de outros clientes;

'''•''' Se há diretrizes comerciais de alto nível, geralmente definidas pela Presidência da empresa ou com base na estratégia organizacional;

'''•''' Se há um nível baixo de customização necessária para a adaptação genérica do Produto gerado pelo projeto. Quando um produto é desenvolvido para determinado cliente, e essa entrega é específica para um negócio ou fim, geralmente não é interessante absorver esse resultado como produto, pois ele não é condizente com a necessidade de outros clientes, e nem aplicável em outras situações;

'''•''' Se o produto gerado pelo projeto for estratégico para o cliente. Quando determinado cliente solicitado algo específico, e que há um grande vínculo comercial e estratégico por parte do cliente, não é interessante anexar esse resultado ao Portfólio de Produtos.

Nesse contexto, a partir da análise dos itens supracitados, é possível determinar em qual momento um resultado de projeto se tornará um Produto da empresa, de qual forma e qual será a estratégia inicial para trabalhar essa evolução.
Todo o esforço de trabalho realizado com a utilização dos processos nos projetos deverá ser registrado no Sistema de Armazenamento de Horas de Trabalho, utilizando as tarefas relacionadas com o trabalho no respectivo projeto. Entretanto, o esforço utilizado com as Auditorias dos processos/projetos deverá ser registrado em um cronograma independente, pois os esforços despendidos para essas atividades não são registrados diretamente nos projetos.

Todos os colaboradores da empresa, que atuam nos Processos de Trabalho descritos neste documento, deverão possuir estações de trabalho configuradas (hardware, software e usuário de acesso pelo Active Directory) de acordo com as suas respectivas necessidades. Todos esses itens são gerenciados diretamente pelo departamento de Gestão da Tecnologia de Informação da MSTECH. É de responsabilidade dos responsáveis pelos projetos solicitar outros recursos materiais necessários para a execução do projeto.

Esta Política Organizacional deverá ser revisada anualmente (no mínimo) e aprovada pela Presidência da empresa, a contar da data de sua primeira publicação.

Politica Organizacional MSTECH

2016-11-10T22:21:32Z

Lucimara.maiorali:

'''Versão 1.0'''

A Política Organizacional da MSTECH Educação e Tecnologia Ltda abrange regras, métodos e conceitos para os projetos de '''Desenvolvimento de Software''' de '''toda a empresa'''. Este documento possui caráter oficial e tange como modelo de referência.

A página oficial dos Processos de Trabalho está disponível para toda a empresa. O local contém o Ciclo de Vida dos Projetos de Desenvolvimento de Software, além do fluxo geral dos Processos de Trabalho para Desenvolvimento de Software, Garantia da Qualidade e Gestão de Portfólio de Projetos. Por fim, há todos os templates de documentos utilizados pelo Processo de Desenvolvimento de Software e outros conteúdos importantes que auxiliam todos na utilização dos Processos de Trabalho. '''Todos os projetos de Desenvolvimento de Software''' (exceto Pesquisa e Desenvolvimento) '''da MSTECH devem utilizar os conteúdos supracitados''', de acordo com suas respectivas regras, além dos sistemas computacionais configurados para a gestão dos projetos/produtos e os softwares auxiliares que integram essas ferramentas.

O '''Processo de Trabalho de Desenvolvimento de Software''' é utilizado diretamente pelas áreas de '''Gestão de Projetos''' e de '''Requisitos''' e '''Gestão de Configuração'''. Suas quatro fases são cronológicas e possuem relação direta. Entretanto, a primeira e a última fase são únicas por projeto, e as intermediárias se repetem (cíclicas, não necessariamente de forma linear, tornando o processo iterativo) de acordo com o número de entregas do projeto. Há também etapas de monitoramento, que abrangem paralelamente todo o processo. Seu principal objetivo é conceder aos projetos de Desenvolvimento de Software padrões e procedimentos, visando garantir qualidade, desempenho e completa satisfação dos clientes, com resultados de alto valor agregado e condizentes com as necessidades estabelecidas. O processo deverá padronizar as atividades para as equipes de desenvolvimento da empresa, garantindo uniformidade em suas atividades de desenvolvimento de software. O processo deverá ser atualizado sempre que necessário, garantindo aderência para a realidade e objetivos estratégicos da MSTECH.

Todos os documentos obrigatórios e auxiliares dos projetos deverão ficar armazenados nos locais definidos pelo processo de desenvolvimento de software, sendo mantido para isso um sistema que possui a função de repositório. Já os artefatos técnicos, que farão parte do Produto desenvolvido pelo projeto, deverão estar presentes no Sistema de Gestão de Configuração, contemplados como parte das Baselines do Produto. Todas as alterações nos documentos precisam ser registra-das nos respectivos locais de armazenamento, de acordo com as diretrizes da Gestão de Configuração (GCO), assim como as demais regras de acesso, nomenclaturas e controles de versões.

O '''Processo de Trabalho de Gestão de Portfólio de Projetos''' é utilizado pelos responsáveis da Gestão de Portfólio de Projetos (GPP) e tem como objetivo principal realizar a gestão da carteira de projetos e clientes da MSTECH. O processo possui duas fases, sendo que a primeira é executada anualmente (ou quando for estritamente necessário) e a segunda é cíclica. Através da definição dos Fatores Comerciais e suas respectivas Priorizações, a Presidência, em conjunto com o responsável da Gestão de Portfólio de Projetos deverá organizar os Objetivos Estratégicos da empresa e, por fim, oficializar a Estratégia do Portfólio de Projetos. Tal Estratégia visa manter a aderência dos processos e projetos de acordo com os objetivos organizacionais, buscando, como foco principal, resultados satisfatórios para os clientes.

O '''Processo de Trabalho de Garantia da Qualidade''' é utilizado pela equipe QA e demonstra a expectativa da empresa na aderência e conformidade das atividades executadas com base nos Processos de Trabalho definidos. Este processo garantirá que todos os Processos de Trabalho definidos estão sendo seguidos de forma correta e íntegra, as auditorias QA dos projetos devem ser planejadas nas fases do ciclo de vida do projeto, nos marcos de 50% (projetos com duração dois meses), mensal (projetos com duração maior que dois meses) e antes das entregas ao cliente, no que tange as auditorias QA do processo organizacional da Gestão de Portfólio de Projetos devem ser planejadas no “Plano de Garantia da Qualidade”. Nesse contexto, o documento “Plano de Garantia da Qualidade” deverá ser elaborado anualmente e, atualizado juntamente com esta Política Organizacional, servindo de suporte para a equipe QA, sendo mantidos nas ferramentas da empresa. Por fim, é importante ressaltar que a auditoria Independente de QA deverá ser planejada anualmente.

Todas as auditorias QA devem ser executadas com a utilização de checklists de garantia da qualidade. Toda não conformidade identificada será acompanhada até a sua resolução seguindo às criticidades e prazos definidos no processo de Garantia da Qualidade. As não conformidades não solucionadas no prazo definido pela criticidade deverão ser escalonadas ao superior imediato conforme organograma da empresa.

Os resultados das auditorias QA deverão ser reportados conforme definido no “Processo de Trabalho de Garantia da Qualidade”.

Os '''Indicadores''' (resultado de '''Medição''') são itens essenciais para a gestão da empresa, pois apresentam, de forma condensada e objetiva, conforme necessário, a situação da empresa em diversos aspectos. Os Indicadores devem fornecer informações para:

'''•''' Manter a aderência nos processos de trabalho estabelecidos, de forma geral e/ou em etapas/atividades específicas;

'''•''' Gerenciar a situação dos projetos, no que tange prazo e esforço;

'''•''' Aprimorar as estimativas para o planejamento dos projetos;

'''•''' Apresentar subsídios para avaliar os próprios Indicadores estabelecidos.

Todo o planejamento, desde a coleta dos Indicadores, até as ações oriundas dos resultados das Medições, está documentado e oficializado nas Diretrizes de Medição. Tal documento deverá ser revisado com periodicidade anual, juntamente com esta Política Organizacional, e validado pela Presidência da empresa.

Para exercer cada papel nos processos, o colaborador (que pode atuar em dois ou mais papeis no mesmo projeto/processo, de acordo com o planejamento realizado e seguindo os critérios/limites de cada papel) deverá possuir requisitos mínimos de conhecimento, comprovados através de histórico profissional (viabilizado/garantido pelo departamento de Recursos Humanos), formação acadêmica, certificações, cursos/treinamentos (inclusive internos) ou pela própria atuação na MSTECH (sendo comprovada, por exemplo, via histórico de participação em outros projetos). Os requisitos para atuar em cada papel nos processos de trabalho, bem como as suas respectivas '''responsabilidades''', estão descritos no documento “Catálogo de Papeis” (disponível na página oficial de Processos de Trabalho).

Somente o Escritório de PCP poderá alterar os Processos de Trabalho estabelecidos, mediante análise em reuniões ou através de solicitações da Presidência da empresa. Também é de responsabilidade do PCP definir se há, ou não, necessidade de novos treinamentos após mudanças nos processos de trabalho, mas é essencial que todos sejam avisados sobre as mudanças realizadas. Após a alteração de um processo, todos os projetos e áreas envolvidas devem utilizar a nova versão publicada. Essa regra é válida também para novos templates, exceto para o repositório de gestão de projetos (e seus templates) e cronograma. Não é necessário realizar nenhuma ação retroativa para ambas as situações citadas (exceto em casos em que o Escritório de PCP ou a Presidência solicitar correções/alterações).

Os resultados gerados pelos projetos de Desenvolvimento de Software podem, também, se tornar produtos da empresa, sendo absorvidos para o Portfólio de Produtos da MSTECH. Entretanto, não é qualquer situação que se enquadra nesse conceito. Há critérios para definir se o resultado de um projeto se tornará um produto da empresa. São eles:

'''•''' Se há ligação/semelhança do resultado do projeto com outros produtos da empresa. Nessa esfera, também é aplicável o critério de vínculos, quando o resultado do projeto é, de alguma forma, vinculado com um, ou mais, produtos existentes, tendo a possibilidade de absorver mais um produto ao Portfólio;

'''•''' Se há aplicabilidade do produto do projeto em outros clientes. Em muitas situações, o produto gerado pelo projeto poderia ser comercializado com outros clientes devido ao seu conteúdo, ou devido à sua estrutura – compatível com a necessidade de outros clientes;

'''•''' Se há diretrizes comerciais de alto nível, geralmente definidas pela Presidência da empresa ou com base na estratégia organizacional;

'''•''' Se há um nível baixo de customização necessária para a adaptação genérica do Produto gerado pelo projeto. Quando um produto é desenvolvido para determinado cliente, e essa entrega é específica para um negócio ou fim, geralmente não é interessante absorver esse resultado como produto, pois ele não é condizente com a necessidade de outros clientes, e nem aplicável em outras situações;

'''•''' Se o produto gerado pelo projeto for estratégico para o cliente. Quando determinado cliente solicitado algo específico, e que há um grande vínculo comercial e estratégico por parte do cliente, não é interessante anexar esse resultado ao Portfólio de Produtos.

Nesse contexto, a partir da análise dos itens supracitados, é possível determinar em qual momento um resultado de projeto se tornará um Produto da empresa, de qual forma e qual será a estratégia inicial para trabalhar essa evolução.
Todo o esforço de trabalho realizado com a utilização dos processos nos projetos deverá ser registrado no Sistema de Armazenamento de Horas de Trabalho, utilizando as tarefas relacionadas com o trabalho no respectivo projeto. Entretanto, o esforço utilizado com as Auditorias dos processos/projetos deverá ser registrado em um cronograma independente, pois os esforços despendidos para essas atividades não são registrados diretamente nos projetos.

Todos os colaboradores da empresa, que atuam nos Processos de Trabalho descritos neste documento, deverão possuir estações de trabalho configuradas (hardware, software e usuário de acesso pelo Active Directory) de acordo com as suas respectivas necessidades. Todos esses itens são gerenciados diretamente pelo departamento de Gestão da Tecnologia de Informação da MSTECH. É de responsabilidade dos responsáveis pelos projetos solicitar outros recursos materiais necessários para a execução do projeto.

Esta Política Organizacional deverá ser revisada anualmente (no mínimo) e aprovada pela Presidência da empresa, a contar da data de sua primeira publicação.

Politica Organizacional MSTECH

2016-11-10T20:57:32Z

Lucimara.maiorali:

'''Versão 1.0'''

A Política Organizacional da MSTECH Educação e Tecnologia Ltda abrange regras, métodos e conceitos para os projetos de '''Desenvolvimento de Software''' de '''toda a empresa'''.Este documento possui caráter oficial e tange como modelo de referência.

A página oficial dos Processos de Trabalho está disponível para toda a empresa. O local contém o Ciclo de Vida dos Projetos de Desenvolvimento de Software, além do fluxo geral dos Processos de Trabalho para Desenvolvimento de Software, Garantia da Qualidade e Gestão de Portfólio de Projetos. Por fim, há todos os templates de documentos utilizados pelo Processo de Desenvolvimento de Software e outros conteúdos importantes que auxiliam todos na utilização dos Processos de Trabalho. '''Todos os projetos de Desenvolvimento de Software''' (exceto Pesquisa e Desenvolvimento) '''da MSTECH devem utilizar os conteúdos supracitados''', de acordo com suas respectivas regras, além dos sistemas computacionais configurados para a gestão dos projetos/produtos e os softwares auxiliares que integram essas ferramentas.

O '''Processo de Trabalho de Desenvolvimento de Software''' é utilizado diretamente pelas áreas de '''Gestão de Projetos''' e de '''Requisitos''' e '''Gestão de Configuração'''. Suas quatro fases são cronológicas e possuem relação direta. Entretanto, a primeira e a última fase são únicas por projeto, e as intermediárias se repetem (cíclicas, não necessariamente de forma linear, tornando o processo iterativo) de acordo com o número de entregas do projeto. Há também etapas de monitoramento, que abrangem paralelamente todo o processo. Seu principal objetivo é conceder aos projetos de Desenvolvimento de Software padrões e procedimentos, visando garantir qualidade, desempenho e completa satisfação dos clientes, com resultados de alto valor agregado e condizentes com as necessidades estabelecidas. O processo deverá padronizar as atividades para as equipes de desenvolvimento da empresa, garantindo uniformidade em suas atividades de desenvolvimento de software. O processo deverá ser atualizado sempre que necessário, garantindo aderência para a realidade e objetivos estratégicos da MSTECH.

Todos os documentos obrigatórios e auxiliares dos projetos deverão ficar armazenados nos locais definidos pelo processo de desenvolvimento de software, sendo mantido para isso um sistema que possui a função de repositório. Já os artefatos técnicos, que farão parte do Produto desenvolvido pelo projeto, deverão estar presentes no Sistema de Gestão de Configuração, contemplados como parte das Baselines do Produto. Todas as alterações nos documentos precisam ser registra-das nos respectivos locais de armazenamento, de acordo com as diretrizes da Gestão de Configuração (GCO), assim como as demais regras de acesso, nomenclaturas e controles de versões.

O '''Processo de Trabalho de Gestão de Portfólio de Projetos''' é utilizado pelos responsáveis da Gestão de Portfólio de Projetos (GPP) e tem como objetivo principal realizar a gestão da carteira de projetos e clientes da MSTECH. O processo possui duas fases, sendo que a primeira é executada anualmente (ou quando for estritamente necessário) e a segunda é cíclica. Através da definição dos Fatores Comerciais e suas respectivas Priorizações, a Presidência, em conjunto com o responsável da Gestão de Portfólio de Projetos deverá organizar os Objetivos Estratégicos da empresa e, por fim, oficializar a Estratégia do Portfólio de Projetos. Tal Estratégia visa manter a aderência dos processos e projetos de acordo com os objetivos organizacionais, buscando, como foco principal, resultados satisfatórios para os clientes.

O '''Processo de Trabalho de Garantia da Qualidade''' é utilizado pela equipe QA e demonstra a expectativa da empresa na aderência e conformidade das atividades executadas com base nos Processos de Trabalho definidos. Este processo garantirá que todos os Processos de Trabalho definidos estão sendo seguidos de forma correta e íntegra, as auditorias QA dos projetos devem ser planejadas nas fases do ciclo de vida do projeto, periodicamente nos marcos de 50% (projetos com duração dois meses) e mensalmente (projetos com duração maior que dois meses) e antes das entregas ao cliente. As auditorias QA do processo organizacional de Gestão de Portfólio de Projetos devem ser planejadas mensalmente e, após o planejamento anual da Gestão de Portfólio de Projetos (GPP). Nesse contexto, o documento “Plano de Garantia da Qualidade” deverá ser elaborado anualmente e, atualizado juntamente com esta Política Organizacional, servindo de suporte para a equipe QA, sendo mantidos nas ferramentas da empresa. Por fim, é importante ressaltar que a auditoria Independente de QA deverá ser realizada anualmente por um auditor externo à empresa.

Todas as auditorias QA devem ser executadas com a utilização de checklists de garantia da qualidade. Toda não conformidade identificada será acompanhada até a sua resolução seguindo a criticidade definida como (Alta) impacto direto no projeto e (Baixa) sem impacto direto no projeto. As não conformidades não solucionadas no prazo definido pela criticidade deverão ser escalonadas ao superior imediato conforme organograma da empresa.

Ao término de cada auditoria QA deverá ser reportado o seu resultado aos responsáveis dos projetos e da Gestão de Portfólio de Projetos para ciência, mensal às Gerências de Desenvolvimento e Negócios e trimestral à Presidência da empresa.

Os '''Indicadores''' (resultado de '''Medição''') são itens essenciais para a gestão da empresa, pois apresentam, de forma condensada e objetiva, conforme necessário, a situação da empresa em diversos aspectos. Os Indicadores devem fornecer informações para:
• Manter a aderência nos processos de trabalho estabelecidos, de forma geral e/ou em etapas/atividades específicas;
• Gerenciar a situação dos projetos, no que tange prazo e esforço;
• Aprimorar as estimativas para o planejamento dos projetos;
• Apresentar subsídios para avaliar os próprios Indicadores estabelecidos.

Todo o planejamento, desde a coleta dos Indicadores, até as ações oriundas dos resultados das Medições, está documentado e oficializado nas Diretrizes de Medição. Tal documento deverá ser revisado com periodicidade anual, juntamente com esta Política Organizacional, e validado pela Presidência da empresa.

Para exercer cada papel nos processos, o colaborador (que pode atuar em dois ou mais papeis no mesmo projeto/processo, de acordo com o planejamento realizado e seguindo os critérios/limites de cada papel) deverá possuir requisitos mínimos de conhecimento, comprovados através de histórico profissional (viabilizado/garantido pelo departamento de Recursos Humanos), formação acadêmica, certificações, cursos/treinamentos (inclusive internos) ou pela própria atuação na MSTECH (sendo comprovada, por exemplo, via histórico de participação em outros projetos). Os requisitos para atuar em cada papel nos processos de trabalho, bem como as suas respectivas '''responsabilidades''', estão descritos no documento “Catálogo de Papeis” (disponível na página oficial de Processos de Trabalho).

Somente o Escritório de PCP poderá alterar os Processos de Trabalho estabelecidos, medi-ante análise em reuniões ou através de solicitações da Presidência da empresa. Também é de responsabilidade do PCP definir se há, ou não, necessidade de novos treinamentos após mudanças nos processos de trabalho, mas é essencial que todos sejam avisados sobre as mudanças realiza-das. Após a alteração de um processo, todos os projetos e áreas envolvidas devem utilizar a nova versão publicada. Essa regra é válida também para novos templates, exceto para o repositório de gestão de projetos (e seus templates) e cronograma. Não é necessário realizar nenhuma ação retroativa para ambas as situações citadas (exceto em casos em que o Escritório de PCP ou a Presidência solicitar correções/alterações).

Os resultados gerados pelos projetos de Desenvolvimento de Software podem, também, se tornar produtos da empresa, sendo absorvidos para o Portfólio de Produtos da MSTECH. Entretanto, não é qualquer situação que se enquadra nesse conceito. Há critérios para definir se o resultado de um projeto se tornará um produto da empresa. São eles:
• Se há ligação/semelhança do resultado do projeto com outros produtos da empresa. Nessa esfera, também é aplicável o critério de vínculos, quando o resultado do projeto é, de alguma forma, vinculado com um, ou mais, produtos existentes, tendo a possibilidade de absorver mais um produto ao Portfólio;
• Se há aplicabilidade do produto do projeto em outros clientes. Em muitas situações, o produto gerado pelo projeto poderia ser comercializado com outros clientes devido ao seu conteúdo, ou devido à sua estrutura – compatível com a necessidade de outros clientes;
• Se há diretrizes comerciais de alto nível, geralmente definidas pela Presidência da empresa ou com base na estratégia organizacional;
• Se há um nível baixo de customização necessária para a adaptação genérica do Produto gerado pelo projeto. Quando um produto é desenvolvido para determinado cliente, e essa entrega é específica para um negócio ou fim, geralmente não é interessante absorver esse resultado como produto, pois ele não é condizente com a necessidade de outros clientes, e nem aplicável em outras situações;
• Se o produto gerado pelo projeto for estratégico para o cliente. Quando determinado cliente solicitado algo específico, e que há um grande vínculo comercial e estratégico por parte do cliente, não é interessante anexar esse resultado ao Portfólio de Produtos.

Nesse contexto, a partir da análise dos itens supracitados, é possível determinar em qual momento um resultado de projeto se tornará um Produto da empresa, de qual forma e qual será a estratégia inicial para trabalhar essa evolução.
Todo o esforço de trabalho realizado com a utilização dos processos nos projetos deverá ser registrado no Sistema de Armazenamento de Horas de Trabalho, utilizando as tarefas relacionadas com o trabalho no respectivo projeto. Entretanto, o esforço utilizado com as Auditorias dos processos/projetos deverá ser registrado em um cronograma independente, pois os esforços despendidos para essas atividades não são registrados diretamente nos projetos.
Todos os colaboradores da empresa, que atuam nos Processos de Trabalho descritos neste documento, deverão possuir estações de trabalho configuradas (hardware, software e usuário de acesso pelo Active Directory) de acordo com as suas respectivas necessidades. Todos esses itens são gerenciados diretamente pelo departamento de Gestão da Tecnologia de Informação da MSTECH. É de responsabilidade dos responsáveis pelos projetos solicitar outros recursos materiais necessários para a execução do projeto.
Esta Política Organizacional deverá ser revisada anualmente (no mínimo) e aprovada pela Presidência da empresa, a contar da data de sua primeira publicação.

Politica Organizacional MSTECH

2016-11-10T18:05:22Z

Lucimara.maiorali:

Politica Organizacional MSTECH

2016-11-10T18:01:58Z

Lucimara.maiorali:

Politica Organizacional MSTECH

2016-11-10T18:01:25Z

Lucimara.maiorali:

Politica Organizacional MSTECH

2016-11-10T17:56:32Z

Lucimara.maiorali: Criou página com ''''Versão 1.0 - publicada em 10/11/2016 A Política Organizacional da MSTECH Educação e Tecnologia Ltda abrange regras, méto-dos e conceitos para os projetos de Desenvolv...'

'''Versão 1.0 - publicada em 10/11/2016

A Política Organizacional da MSTECH Educação e Tecnologia Ltda abrange regras, méto-dos e conceitos para os projetos de Desenvolvimento de Software de toda a empresa. Este do-cumento possui caráter oficial e tange como modelo de referência.

Políticas dos processos MSTECH

2016-11-10T17:27:17Z

Lucimara.maiorali:

Diretrizes de Comunicação

2016-10-24T16:22:24Z

Lucimara.maiorali:

{| class="wikitable"
|-
! scope="col"| Evento
! scope="col"| Responsável (emissor)
! scope="col"| Destinatários
! scope="col"| Canal
! scope="col"| Frequência
|-
|Entendimento das necessidades do cliente - negócios
|Product Owner
|Reponsável pela Oportunidade
|Reunião
|Pontual
|-
|Entendimento das necessidades do cliente - cliente
|Product Owner
|Cliente
|Reunião
|Pontual
|-
|Estimativas de requisitos
|Scrum Master
|Product Owner
|E-mail/ Reuniões
|Pontual
|-
|Divulgação dos subsídios da proposta
|Product Owner
|Responsável pela Oportunidade, Escritório de PCP, Scrum Master(s), Especialista(s)
|E-mail
|Pontual
|-
|Transição
|Responsável pela Oportunidade
|Product Owner(s), Scrum Master(s), Analista de PCP, Representante do Departamento Jurídico, Responsável pela Gerência de Portfólio de Projetos, Especialista(s)
|Reunião
|Pontual
|-
|Reporte da auditoria da fase de iniciação
|Analista de GQA
|Product Owner
|E-mail
|Pontual
|-
|Vínculo do contrato ao hub
|Representante do Departamento Jurídico
|Escritório de PCP
|E-mail
|Pontual
|-
|Solicitação de projeto contábil
|Analista de PCP
|Controladoria
|Registro no Sharepoint
|Pontual
|-
|Criação de ambientes
|Analista de PCP
|Product Owner, Scrum Master, Time Scrum, Escritório de PCP, Equipe de GQA
|E-mail
|Pontual
|-
|Atribuição de risco
|Product Owner
|Responsável pelo risco
|Issue no Redmine
|Pontual
|-
|Análise de viabilidade inicial
|Responsável pela Gerência de Portfólio de Projetos
|Product Owner
|Issue no Redmine
|Pontual
|-
|Apresentação do planejamento
|Product Owner
|Analista de GQA, Analista de Operação, Auditor Técnico de Baseline
|Issue no Redmine
|Pontual
|-
|Comprometimento da equipe
|Analista de GQA, Analista de Operação, Auditor Técnico de Baseline
|Product Owner
|Issue no Redmine
|Pontual
|-
|Reporte da auditoria da fase de planejamento
|Analista de GQA
|Product Owner
|E-mail
|Pontual
|-
|Divulgação de especificação da arquitetura
|Arquiteto de Soluções
|Time Scrum
|E-mail
|Pontual
|-
|Apresentação do escopo do projeto
|Product Owner
|Time Scrum
|Reunião de Grooming/ Planning
|Pontual
|-
|Definição da tecnologia
|Time Scrum
|Product Owner
|Reunião de Grooming/ Planning
|Pontual
|-
|Pontuação dos requisitos
|Time Scrum
|Product Owner
|Reunião de Planning
|Pontual
|-
|Coleta de aceite do cliente
|Product Owner
|Cliente
|Reunião/ E-mail
|Pontual
|-
|Reporte de auditoria técnica de baseline
|Auditor Técnico de Baseline
|Scrum Master
|Issue no Redmine
|Pontual
|-
|Reporte de auditoria de execução
|Analista de GQA
|Product Owner, Scrum Master
|E-mail
|Pontual
|-
|Aceite de tarefas concluídas
|Product Owner
|Time Scrum
|Reunião de Review
|Pontual
|-
|Sugestão de mudança no processo
|Time Scrum
|Grupo de Processos
|Issue no Redmine
|Pontual
|-
|Solicitação de mudança - equipe
|Time Scrum
|Product Owner
|Issue no Redmine
|Pontual
|-
|Solicitação de mudança - outros
|Product Owner
|Product Owner
|Não se aplica
|Pontual
|-
|Análise de viabilidade 50%
|Responsável pela Gerência de Portfólio de Projetos
|Product Owner
|Issue no Redmine
|Pontual
|-
|Registro de problemas
|Product Owner
|Responsável pela resolução do problema
|Issue no Redmine
|Pontual
|-
|Suspensão do projeto
|Presidência
|Product Owner
|E-mail
|Pontual
|-
|Conclusão do projeto
|Product Owner
|Escritório de PCP
|E-mail
|Pontual
|-
|Reporte de auditoria de encerramento
|Analista de GQA
|Product Owner
|E-mail
|Pontual

Atribuição 1.0.5.0

2016-10-20T16:36:29Z

Lucimara.maiorali: /* Verificação de Segurança */

== Sistemas Verificados ==

*Atribuição de aula, versão 1.0.5.0
*CoreSSO, versão 1.28.0.0
*Gestão acadêmica, versão 1.65.0.0
*Gestão acadêmica API, versão 1.61.0.0

== Verificação de Segurança ==

== Verificação de Desempenho ==

=== Observação do teste ===

Durante a construção dos cenários de testes foram encontrados alguns bugs, segue relação dos mesmos abaixo:
* Imagens faltando no carregamento da página.
* Erro ao abrir o painel de controle.
* O sistema não exibe loader para o usuário, este ponto não é interessante para a experiência do usuário, tendo em vista que a impressão que o sistema esta travado.
* Na tela de cadastro de vaga ao clicar em "Enviar" não é exibido nenhuma informação que a página está carregando e é possível interagir com a tela. Deste modo é possível forçar um erro no sistema ao clicar novamente no botão "Enviar".
* Na tela de cadastro de vaga ao clicar em "Enviar" novamente enquanto a tela carrega o pop-up exibido não habilita as ações dos botões.
* Não são todas as mensagens de erro (mensagens com o fundo vermelho) que são salvas no banco de dados.

Para a realização dos teste foi utilizado:
* 1 Servidor de banco dados: SQL
* 1 Servidor de banco de dados: Mongo
* 1 Servidor ARR
* 2 Servidores web (denominados WEB1 e WEB2)
* 1 Controller
* 1 Test agent

Para melhor visualização nos relatórios o cenário 1 foi abreviado para C1 e o cenário 2 para C2.

=== Análise do teste ===

* Dados obtidos nos dois cenários de teste

A aplicação possui diferentes comportamentos com relação ao hardware utilizado no momento de considerar ou não a SEDE. O processamento possui grande variação entre os webs quando a atribuição de aulas considera o vinculo SEDE, um dos servidores web acaba tendo processamento superior. Neste cenário, enquanto a distribuição pelo ARR estava em 52,64% para o WEB1 e 47,36 para o WEB2 a diferença de processamento entre eles foi superior a 30%. Quando, na atribuição, não é considerada o vínculo, o processamento entre os servidores web é mais equilibrado.

O mesmo cenário de variação observada no processador pode ser observada na memória e na rede enquanto os testes eram executados. Referente ao cenário 2, o processador possui uma elevada taxa de mudança de contexto, o que significa que o processador é compartilhado repetidamente, por exemplo, por muitos segmentos de igual prioridade. A alta taxa de contexto-chave muitas vezes indica que existem muitos segmentos que competem para os processadores no sistema. A taxa de trocas de contexto também pode afetar o desempenho de computadores com múltiplos processadores.

Foi possível observar os pontos listados abaixo durante a execução dos teste:
*1) Quando considerado o vínculo SEDE, a memória virtual comprometida dos servidores web ficam próximos da utilização do servidor de banco de dados. Quando não é considerado, o servidor mais utilizado é o do banco de dados, enquanto o ARR, WEB01, e WEB02 possui uma quantidade próxima de utilização.
*2) Quanto maior a quantidade de usuários no cenário 2 menor o tempo ocioso do disco, enquanto no cenário 1 o processamento é estável.
*3) A fila do disco está dentro do valor recomendado.
*4) A média da quantidade de sessões foi superior no cenário 1.
*5) A expectativa de vida da página é superior quando o cenário 2 é executado.

=== Cenários de uso ===

{| class="wikitable"
!colspan="6"|Cenário de uso #1 - Atribuição com lista de importação que não considera vínculo sede.
|-
|colspan="2"| Ação realizada || Think Time: Atraso constante (segundos) || Think Time: Desvio (segundos)
|-
|colspan="2"|1 - Acessar tela de login || style="text-align: center; | 5 || style="text-align: center; | 1
|-
|colspan="2"|1 - Realizar login || style="text-align: center; | 15 || style="text-align: center; | 3
|-
|colspan="2"|1 - Selecionar sistema || style="text-align: center; | 6 || style="text-align: center; | 1
|-
|colspan="2"|2 - Acessar tela "Atribuição de aula" || style="text-align: center; | 5 || style="text-align: center; | 1
|-
|colspan="2"|2 - Preencher campo "Fase" || style="text-align: center; | 7 || style="text-align: center; | 2
|-
|colspan="2"|2 - Preencher campo "Cenário" || style="text-align: center; | 7 || style="text-align: center; | 2
|-
|colspan="2"|2 - Clicar em "Pesquisar" || style="text-align: center; | 4 || style="text-align: center; | 1
|-
|colspan="2"|2 - Clicar em "Concluir" || style="text-align: center; | 10 || style="text-align: center; | 3
|-
|colspan="2"|2 - Acessar painel de vagas || style="text-align: center; | 10 || style="text-align: center; | 3
|-
|}

{| class="wikitable"
!colspan="6"|Cenário de uso #2 - Atribuição com lista de importação que não considera vínculo sede.
|-
|colspan="2"| Ação realizada || Think Time: Atraso constante (segundos) || Think Time: Desvio (segundos)
|-
|colspan="2"|1 - Acessar tela de login || style="text-align: center; | 5 || style="text-align: center; | 1
|-
|colspan="2"|1 - Realizar login || style="text-align: center; | 15 || style="text-align: center; | 3
|-
|colspan="2"|1 - Selecionar sistema || style="text-align: center; | 6 || style="text-align: center; | 1
|-
|colspan="2"|2 - Acessar tela "Atribuição de aula" || style="text-align: center; | 5 || style="text-align: center; | 1
|-
|colspan="2"|2 - Preencher campo "Fase" || style="text-align: center; | 7 || style="text-align: center; | 2
|-
|colspan="2"|2 - Preencher campo "Cenário" || style="text-align: center; | 7 || style="text-align: center; | 2
|-
|colspan="2"|2 - Clicar em "Pesquisar" || style="text-align: center; | 4 || style="text-align: center; | 1
|-
|colspan="2"|2 - Clicar em "Concluir" || style="text-align: center; | 10 || style="text-align: center; | 3
|-
|colspan="2"|2 - Acessar painel de vagas || style="text-align: center; | 10 || style="text-align: center; | 3
|-
|}

=== TOP queries mais lentas ===

* Item 1
: Média do CPU: 6256
: Tempo decorrido: 18156

<syntaxhighlight lang="sql" line="1" >
INSERT INTO @teachersAttributed
SELECT a.TeacherEnrollment_Id
FROM Attribution AS a WITH(NOLOCK)
INNER JOIN AttributionStep AS ats WITH(NOLOCK)
ON a.Id = ats.Attribution_Id
WHERE
a.Process_Id = @processId
AND ats.Step_Id = @stepId
AND ats.Situation = 2
</syntaxhighlight>

*Item 2
: Média do CPU: 839
: Tempo decorrido: 75624

<syntaxhighlight lang="sql" line="1" >
SELECT TOP (1)
Result.[Rank]
FROM (
SELECT
lc.[Rank] AS [Rank]
FROM
ListContent AS lc WITH(NOLOCK)
INNER JOIN TeacherEnrollment AS te WITH(NOLOCK)
ON lc.TeacherEnrollment_Id = te.Id
AND te.State = 1
INNER JOIN JourneyList AS jl WITH(NOLOCK)
ON te.JourneyList_Id = jl.Id
AND jl.State = 1
WHERE
lc.State = 1
AND lc.Discipline_Id = @disciplineId
AND lc.ListImport_Id = @listImportId
AND ((@localExecution = 1 AND lc.School_Id = @schoolId) OR (@localExecution = 2))
AND NOT EXISTS (SELECT 1 FROM @teachersAttributed ta WHERE ta.TeacherEnrollment_Id = lc.TeacherEnrollment_Id)
) AS Result
ORDER BY Result.[Rank] ASC
</syntaxhighlight>

=== Resultado dos testes ===
Nesta seção serão apresentados os resultados obtidos da execução dos testes.

*'''Processador'''

: Contador: Percentagem de tempo ocioso.
: Descrição: Este contador fornece quanto tempo o disco permaneceu em estado de repouso, ou seja, todos os pedidos do sistema operacional para o disco ter sido concluída e há zero de pedidos pendentes. Este contador varia de 100 (ou seja, sempre ocioso) para 0 (ou seja, sempre ocupado).
: Limite recomendado: Abaixo de 75 %.
: Análise: O disco fica ocioso.

:::::: [[Arquivo:2016-10-20 AtribuicaoAulas TempoOcioso.png]]

: Contador: Percentagem de espaço livre.
: Descrição: Mostra a porcentagem do espaço total utilizável no disco lógico selecionado.
: Limite recomendado: Acima de 25%.
: Análise: Aplicação está dentro do recomendado.

:::::: [[Arquivo:2016-10-20 Atribuicao EspacoLivre.png]]

: Tempo total do processador.
: Descrição: Mede a utilização da CPU de cada processador.
: Limite recomendado: Não exceder 80% por mais de 10 minutos ao longo do período de teste.
: Análise: Aplicação está dentro do recomendando.

:::::: [[Arquivo:2016-10-20 Atribuicao TempoTotalProcessador.png]]

: Contador: Mudança de contexto.
: Descrição: A mudança de contexto ocorre quando o kernel muda o processador de um segmento para outro, por exemplo, quando um segmento com uma prioridade maior do que o segmento em execução torna-se pronto.
: Limite recomendado: Quanto menor melhor.
: Análise: Grande variação entre os servidores WEB quando executado o cenário 2.

:::::: [[Arquivo:2016-10-20 Atribuicao MudancaContexto.png]]

*'''Memória'''

: Contador: Páginas/segundo.
: Descrição: Mede o número de páginas por segundo que são paginadas fora da memória RAM para a memória virtual.
: Limite recomendado: Se o número for alto indica falhas graves. O limite normalmente é de 20 páginas/s
: Análise: Grande quantidade de páginas quando executado o cenário 2.

:::::: [[Arquivo:2016-10-20 Atribuicao PaginasSegundo.png]]

: Contador: % Memória virtual comprometida.
: Descrição: Indica a percentagem da memória comprometida utilizada dentro do limite dado pela soma da memória RAM e Page File.
: Limite recomendado: Abaixo de 75% e que não tenha grande variação no indicador.
: Análise: Aplicação está dentro do recomendado.

:::::: [[Arquivo:2016-10-20 Atribuicao MemoriaVirtualComprometida.png]]

: Contador: Memória disponível em MBytes.
: Descrição: Indica quantidade de memória disponível para alocação em MBytes.
: Limite recomendado: Se o valor for inferior a 20/25 por cento de RAM instalada é uma indicação de memória insuficiente. Menos de 100 MB é uma indicação de que o sistema é muito carente de memória e paginação.
: Análise: Em verificação

:::::: [[Arquivo:2016-10-20 Atribuicao MemoriaDisponivel.png]]

*'''Network'''

: Contador: Kbytes totais pela interface de rede.
: Descrição: Indica quantos Kbytes foram enviados e recebidos a cada segundo pela interface de rede.
: Limite recomendado: Menor que 5 Mbytes para uma rede de 100Mbps, menor que 50 Mbytes para uma rede de 1000 Mbps. (Quanto menor melhor).
: Análise: Aplicação está dentro do recomendado.

:::::: [[Arquivo:2016-10-20 Atribuicao InterfaceTotalRede.png]]

: Contador: Falhas de conexão (TCP)
: Descrição: Este é o número bruto de conexões TCP que falharam desde que o servidor foi iniciado. Uma falha normalmente indica uma perda de dados em lugar no processo. A perda pode ocorrer em muitos locais. Esta poderia ser uma indicação de um outro dispositivo que está sendo para baixo, ou problemas com a configuração do lado do cliente do software.
: Limite recomendado: Quanto menor melhor.
: Análise: O servidor WEB1 possui uma quantidade superior de falhas.

:::::: [[Arquivo:2016-10-20 Atribuicao ConexoesFalhas.png]]

*'''SQL'''

: Contador: Expectativa de vida da página.
: Descrição: Indica o número em segundos que uma página vai ficar na área de buffers, sem referências.
: Limite recomendado: Quanto menor melhor.
: Análise: No cenário 2 a expectativa de vida é superior.

:::::: [[Arquivo:2016-10-20 Atribuicao ExpectativaVidaPagina.png]]

: Contador: Request bloqueados.
: Descrição: Informa a quantidade de resquest bloqueados.
: Limite recomendado: Quanto menor melhor.

:::::: [[Arquivo:2016-10-20 Atribuicao RequestsBloqueados.png]]

*'''Aplicação'''

: Dado: Sampler
:Descrição: Informa a quantidade threads.
: Limite recomendado: Quanto maior melhor.

:::::: [[Arquivo:2016-10-20 Atribuicao Sampler.png]]

: Dado: 90% dos melhores tempos de resposta
:Descrição: Informa os 90% melhores tempos de respostas.
: Limite recomendado: Quanto menor melhor.

:::::: [[Arquivo:2016-10-20 Atribuicao 90MelhoresTemposRespostas.png]]

: Dado: Porcentagem de erros
:Descrição: Informa porcentagem de erro no sistema durante os testes.
: Limite recomendado: Quanto menor melhor.

:::::: [[Arquivo:2016-10-20 Atribuicao PorcentagemErros.png]]

: Dado: Vazão
:Descrição: Informa a quantidade de dados transferidos.

:::::: [[Arquivo:2016-10-20 Atribuicao RequestsSegundo.png]]

Verificação de segurança e desempenho

2016-10-03T21:00:21Z

Lucimara.maiorali:

O objetivo da '''verificação de segurança e desempenho''' é analisar através dos testes não funcionais dois dos principais requisitos não funcionais que podem afetar de forma drástica a estabilidade e a qualidade das nossas entregas, sendo de extrema importância na obtenção de um diagnóstico cada vez mais preciso nas ações de melhoria contínua e na garantia da qualidade, visando alcançar patamares mais elevados no desenvolvimento dos nossos produtos.

== Pré-requisitos para execução da verificação de segurança e desempenho ==

*Providenciar a publicação do sistema/aplicação, com a última versão estável, em ambiente de teste administrado pelo DevOps;
*Definir o escopo do teste de segurança e desempenho;
*Descrição resumida das funcionalidades do sistema/aplicação, considerar também as funcionalidades mais críticas (que diferenciam e destacam o produto);
*Informação da existência de problemas de segurança e desempenho conhecidos no sistema/aplicação;
*Definir as permissões por nível de usuário para as principais funcionalidades e ativos do sistema(lista de credenciais ativas(usuário e senha)com pelo menos um usuário para cada nível de permissão.

== Verificação de segurança ==

A verificação de segurança consiste identificar vulnerabilidades, classificá-las e indicar estratégias de mitigação para estas. É realizada uma análise ativa na qual são simulados ataques a um determinado sistema, identificando vulnerabilidades que podem ser exploradas em um ataque real.

Uma '''vulnerabilidade''' é uma falha ou fraqueza no design, implementação, operação ou gerenciamento de um sistema que pode ser explorada a fim de violar a política de segurança do mesmo. Uma '''ameaça''' é um ataque em potencial que, explorando uma vulnerabilidade, pode comprometer os ativos de uma aplicação (recursos, dados, funcionalidades).

Esse processo, conhecido como ''"Vulnerability Assessment"'', deve ser executado em uma versão estável do sistema, após a etapa de desenvolvimento. Primeiramente o sistema é submetido a ''scanners'' de vulnerabilidades automáticos. As vulnerabilidades encontradas pelos ''scripts'' automáticos são então verificadas, para eliminar falsos positivos.

Após o processo automático, o sistema é verificado manualmente por vulnerabilidades de detecção mais difícil, seguindo as diretrizes do [https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents OWASP Guide v4]

A verificação de segurança é executada por [mailto:paulo.souza@mstech.com.br Paulo Roberto Lopes de Souza]

=== Ferramentas utilizadas ===

*'''Ferramentas de Proxy web''' (WebScarab,CAT,OWASP ZAP,Paros)
*'''''Scanners'' de vulnerabilidades automatizados''' (WCSA,OWASP ZAP,N-Stalker,Web Securify,Microsoft WACA,W3AF,VEGA)
*'''''Sniffers''''' (Wireshark,Ettercap)
*'''Gerador de pacotes e requisições ''HTTP''''' (Engage Packet Builder,WebScarab,CAT)

== Verificação de desempenho ==

A verificação de desempenho é uma classe de testes implementada e executada para caracterizar o desempenho relacionado a características do sistema/produto, como fluxos de execução, tempos de respostas e limites operacionais. A verificação de desempenho abrange os seguintes tipos de testes:

*'''Teste de carga''': Verifica a aceitabilidade do comportamento de desempenho do objeto de teste em condições operacionais variáveis (como número de usuários, número de transações, entre outros), enquanto as configurações permanecem as mesmas.

*'''Teste de stress:''' Verifica a aceitabilidade do comportamento de desempenho do objeto de teste quando condições anormais ou externas forem encontradas, como a redução dos recursos ou um número extremamente alto de usuários.

*'''Teste de desempenho:''' Testa a aplicação em uma situação normal de uso, verificando se o tempo de resposta e a utilização do hardware são os desejados.

A verificação de desempenho é executada por [mailto:taynara.nakashima@mstech.com.br Taynara Nakashima]

=== Ambiente padrão de teste ===

Para a realização dos testes foi criado um ambiente padrão composto de servidores web e servidor SQL com distribuição de carga pelo ARR. A VM utilizada para simular usuários navegando pelo sistema é denominado Test Agent e o controlador dos agentes denominado Test Controller. Abaixo é apresentada a configuração dos equipamentos que compõe o ambiente gerador de carga para os testes.

{| class="wikitable"
!colspan="6"|Ambiente padrão de teste
|-
|colspan="2"|ARR
|Estão configurados com DFS entre os arquivos de sistema. Cada um tem 4 núcleos, 4GB de RAM e disco de 200GB dinâmico.
|-
|colspan="2"|HOST
|É um Xeon 2.3 Ghz com 48 núcleos de 384GBde RAM.
|-
|colspan="2"|Servidores Web
|Possuem 8 núcleos cada, 6GB de RAM e disco de 100GB dinâmico. O acesso ao site é através de uma pasta compartilhada no servidor hospedeiro, utilizando o parâmetro caspol do .NET 32 e 64 bits v3.5 e 4 com opção fulltrust.
|-
|colspan="2"|Servidor SQL
|O SQL Server está na versão 2014 Standard e o servidor tem 16 GB de RAM, 16 núcleos, 100GB de disco para dados, 1TB de disco para bancos e 500 GB de disco de backup. Os discos de bancos e backup são volumes diretos na storage, utilizando conexão iSCSI.
|-
|colspan="2"|Test Controller
|Possuem 8 núcleos e 8 GB de RAM, com disdo de 200GB para SO.
|-
|colspan="2"|Test Agent
|Os slaves do JMeter possuem 8 núcleos e 8 GB de RAM com disco de 200GB para SO cada.
|-
|}

=== Ferramentas utilizadas ===

*'''Ferramenta de teste''' (JMeter)
*'''Web Debugging Proxy''' (Fiddler)
*'''Resource and Performance Monitor''' (Perfmon)
*'''Zabbix

== Resultado da verificação de segurança e desempenho ==

Como resultado da verificação de segurança e desempenho será enviado um relatório aos responsáveis do produto contendo as vulnerabilidades e itens de melhorias que deverão ser inseridas na '''Product Backlog''' e analisadas em conjunto com a equipe e responsáveis pelas verificações. Este resultado também será disponibilizado no menu "Produtos" [[https://wiki.mstech.com.br/index.php/Produtos Plataforma de Produtos MSTECH]].

{| class="wikitable"
!colspan="6"|Produtos verificados
|-
|colspan="1"| Sistema
|colspan="2"| Teste de desempenho
|colspan="3"| Teste de segurança
|-
|colspan="1"|Transporte Escolar
|colspan="2"| [[Transporte 1.1.1.21|Versão 1.1.1.21]]
|colspan="3"| [[Transporte 1.1.1.21|Versão 1.1.1.21]]
|-
|colspan="1"|Controle Patrimonial
|colspan="2"| [[Conpat 2.25.2.0|Versão 2.25.2.0]]
|colspan="3"| [[Conpat 2.25.2.0|Versão 2.25.2.0]]
|-
|colspan="1"|Biblioteca
|colspan="2"|[[Biblioteca 1.45.0.0|Versão 1.45.0.0]]
|colspan="3"|
|-
|colspan="1"|Approxima
|colspan="2"|[[Approxima 1.0.0.74 |Versão 1.0.0.74]]
|colspan="3"|
|-
|colspan="1"|Portal Construtor
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Almoxarifado
|colspan="2"|[[Almoxarifado 1.1.0.0|Versão 1.1.0.0]]
|colspan="3"|
|-
|colspan="1"|Atribuição de Aulas
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Avalia+
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Alimentação
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|BlueMonitor
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|BlueControlWeb
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|BlueControl
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Boletim Online
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|ClassPad
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Censo Escolar
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Central de Projetos
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|CoreSSO
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Coreedu
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Certificados
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Controle de Obras
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Controle Financeiro de Repasses
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Dupla Regência
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Educopédia
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Fiscalização e Contratos
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Fluxos DRH
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Gestão Acadêmica
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Gestão Escolar / SGP
|colspan="2"|[[SGP Comparação de versões 01 |Comparação de versões 01 - Verificação de ambientes]]
|colspan="3"|
|-
|colspan="1"|Gestão Privado
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Gestão de Metas
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Loomi
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Mapa de Indicadores
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Moodle
|colspan="2"|[[Moodle 3.1.1 |Versão 3.1.1 - Verificação de ambientes]]
[[Moodle - Verificação de SO | Verificação de SO]]
|colspan="3"|
|-
|colspan="1"|OpenId
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Portal Institucional
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Quadro de Horários
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Remoção
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Repositório OA
|colspan="2"|
|colspan="3"|
|-
|colspan="1"|Sala de Gestão
|colspan="2"|
|colspan="3"|
|-
|}

Abertura de projetos e pré-projetos

2016-09-08T21:13:53Z

Lucimara.maiorali: Limpou toda a página

Backlog da equipe de Testes

2016-08-05T16:14:32Z

Lucimara.maiorali: /* Finalizados */

Atualizado em 13/07/2016.

==Finalizados==

{| {{table}} class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Problema raiz'''
| align="center" style="background:#f0f0f0;"|'''Atividades'''
| align="center" style="background:#f0f0f0;"|'''Data de finalização'''
| align="center" style="background:#f0f0f0;"|'''Resolução'''
|-
|Não há uma categorização padrão de bugs
|Definir categorias
|11/04/2016
|Foi criado o documento [[Padrões para classificação de bugs]]
Novos campos de classificação adicionados ao TFS e ao Youtrack (apenas em projetos criados a partir de 25/05/2016).
|-
|Não há como garantir a qualidade no final da sprint apenas
|Definir critérios de aceite de um requisito
|11/04/2016
| 1. Requisito finalizado (todas as tarefas da sprint para o requisito terminadas)
2. Testes unitários aprovados (passou ou não) - Opcional

3. Testes funcionais (pelos testers ou teste cruzado)
Como comprovar teste cruzado?
Criar tarefa e o escritorio validar se foi realizado

4. Review ser no ambiente de Homologação Interna - opcional

5. Aprovação do PO (PO aprovaria requisito com baixa criticidade)
|-
|Entender como o desenvolvedor recebe o bug: o que pode ser melhorado?
|Pesquisa com desenvolvedores
|11/04/2016
|Vídeos só em casos em que o problema é complicado de explicar

Imagens - utilizar anotações na imagem e anotar, no nome da imagem, uma descrição rápida do bug + data

Tudo, até ortografia, deve ser registrado

Anexar também evidências de que o item foi corrigido
|-
|Entender os casos de teste: utilidade, eficácia, armazenamento
|Realizar dinâmica para cada um apresentar como descrever caso de teste
Como tratar o armazenamento dos casos de teste pensando no reaproveitamento deles

Apresentar planilha usada pela célula do Gestão
|26/04/2016
|Realização de Dojo na construção de casos de teste
Avaliação do TestLink
|-
|Solicitações para não cadastrar bugs
|Alinhamento com a equipe de testes
|09/05/2016
|Bugs devem ser cadastrados sempre. Se foi aberto por engano, deve ser fechado, e não excluído. Não há exceções.
|-
|Acessibilidade
|Definir escopo dos testes
|30/05/2016
|Testar funcionalidades aparentes de acessibilidade, como tamanho de fonte e alto contraste.
|-
|Entender os casos de teste: utilidade, eficácia, armazenamento
|Ferramenta de registro de caso de teste: Avaliar o TestLink
|30/05/2016
|Testlink foi avaliado e, nesse momento, não parece adequado para nossa realidade. Revisitar futuramente.
|-
|Como é o apontamento de sugestões de melhorias?
|Estudar como registrar QoS de forma que o PO, o SM, o tester e a empresa tenham acesso.
|16/06/2016
|Pesquisa indicou que as empresas não usam QoS. Será utilizado Bug com criticidade "Melhoria"
|-
|Não há uma categorização padrão de bugs
|Definir critérios para a priorização de severidade
|16/06/2016
| Foi criado o documento [[Padrões para definição de criticidade de bugs]]
|-
| Alocação de última hora
|Levantar lista do que cada tester já testou
|13/07/2016
|Foi criada uma pesquisa, onde cada Analista de testes respondeu seu nível de conhecimento em cada produto. Os resultados foram tabulados e enviados para o Escritório de Aplicação.
|-
|Não há uma categorização padrão de bugs
|Comunicar os desenvolvedores sobre o uso das classificações
|04/08/2016
|Foi comunicado aos SMs, POs e Desenvolvedores.
|-
|Não há como garantir a qualidade no final da sprint apenas
|Publicar os critérios de aceite (criticidade e categorização de bugs)
|04/08/2016
|Foram publicados os critérios de aceite e divulgado nas reuniões de PO e SM.
|-
|Entender os casos de teste: utilidade, eficácia, armazenamento
|Avaliar se há algum plugin gratuito do GitLab para test case
|04/08/2016
|Foi considerado o uso do Youtrack para criação de casos de testes.
|-
|}

==Aguardando==

{| {{table}} class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Problema raiz'''
| align="center" style="background:#f0f0f0;"|'''Atividades'''
| align="center" style="background:#f0f0f0;"|'''Equipe de avaliação'''
| align="center" style="background:#f0f0f0;"|'''Data de início'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Resolução'''
|-
| Descrever os testes não funcionais referente à performance||Desenvolver menu||Taynara||28/03/2016||Aguardando||
|-
| Descrever os testes não funcionais referente à performance||Desenvolver pré-requisitos||Taynara||28/03/2016||Aguardando||
|-
| Descrever os testes não funcionais referente à performance||Desenvolver questionário||Taynara||28/03/2016||Aguardando||
|-
| Não há como garantir a qualidade no final da sprint apenas||Definir um ambiente padrão de testes de homologação para a empresa||||||Aguardando||Trazer o DEVOPS junto na conversa
|-
| Acessibilidade||Não temos profissionais com muita experiência em testes de acessibilidade. É algo interessante para começarmos a estudar.||||||Aguardando||Taynara mandou um material inicial. Vamos conversar sobre essa capacitação
|-
| Acessibilidade||Incluir nos testes se o comportamento de forms com "tab" está ok||||||Aguardando||
|-
| Hoje o teste não é obrigatório para aceite||||Ricardo / André||||Aguardando||Na review, apresentar relatório dos bugs para tomada de decisão com o PO. Divulgar isso como parte do processo.
|-
| Melhorar a produtividade Tester: como fazer mais? Materiais de estudo: onde e como se especializar?||Construir um repositório de conhecimento||||||Aguardando||
|-
| Não há como garantir a qualidade no final da sprint apenas||No sprint review, envolver o tester para que este indique como aprovado ou não o RF||Mara / Ricardo||||Aguardando||Escritório será envolvido; sugestão de nova questão no questionário da retrospectiva; testers mandarão e-mail com parecer
|-
| Descrever os testes não funcionais referente à performance||"Não iniciado / em desenvolvimento / entregue /finalizado" - Kanbam||||||Aguardando||
|-
| Não há uma organização padrão dos casos de testes||Definir o critério de organização dos casos de testes||||||Aguardando||Está sendo utilizada planilha de casos de teste que o Gestão criou.
|-
| Pra onde caminha o processo de testes na MSTECH? (Seria interessante passar a visão da empresa sobre a importância dos testes no nosso processo de desenvolvimento)||Levar questões para SM e escritório||Ricardo||||Aguardando||
|-
| Testes de desempenho||Capacitação do teste de desempenho para os demais||||||Aguardando||Aguardando Taynara estar com menos atividades. Procurar alguma capacitação externa para desempenho e segurança
|-
|}

==Em andamento==

{| {{table}} class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Problema raiz'''
| align="center" style="background:#f0f0f0;"|'''Atividades'''
| align="center" style="background:#f0f0f0;"|'''Equipe de avaliação'''
| align="center" style="background:#f0f0f0;"|'''Data de início'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Resolução'''
|-
| Não há uma categorização padrão de bugs||Divulgar o relatório de bugs||André||30/05/2016||Em andamento||André vai montar um relatório padrão de bugs no Excel junto com Flávia
|-
| Alocação de última hora||Checklist da planning. Perguntas para confirmar se tudo que o PO e SM tinham que fazer para o planning foi feito (especialmente alocação da base)||Karystha, Debora, Mara, Ricardo||16/06/2016||Em andamento||
|-
| Alocação de última hora||Organizar/Comunicar/Lembrar fluxo de alocação da base||Karystha, Debora, Mara, Ricardo||16/06/2016||Em andamento||Muitas vezes os POs e SMs vão falar direto com o tester. O escritório não tem ciência da alocação.
|-
| Métricas para acompanhar a evolução da melhoria||Construção de métricas de projeto e da evolução das frentes||André / Ricardo||||Em andamento||Construção das métricas de bugs dos projetos. Em relação ao fórum, temos métricas dos itens que já foram resolvidos
|-
| Entender os casos de teste: utilidade, eficácia, armazenamento||Avaliar o uso do Youtrack para criação de caso de teste||Ricardo / Mara / Eric||16/06/2016||Em andamento||
|-
| Calendario de alocação||Verificar a possibilidade de construir um calendário com a alocação dos testers||Mara||07/07/2016||Em andamento||
|-
| Testers estão ficando sem alocação / sem resposta do escritório.||Verificar o problema com o escritório.||André / Mara / Ricardo||07/07/2016||Em andamento ||
|-
| ||Verificar a ideia de cada tester ficar em projetos fixos.||André / Mara / Ricardo||07/07/2016||Em andamento ||
|-
| ||Testers ficam sem atividade no começo da sprint (Halana)||André / Mara / Ricardo||07/07/2016||Em andamento ||
|-
| Testers não são considerados no planning||Testers não participam do planning||André / Mara / Ricardo||07/07/2016||Em andamento ||
|-
| ||Testers precisam ficar próximos ao projeto que estão testando e participar do ciclo||André / Mara / Ricardo||07/07/2016||Em andamento ||
|-
| Melhores práticas||Melhores práticas: testes com console aberto||Elizabeth||07/07/2016||Em andamento ||
|-
|Entender os casos de teste: utilidade, eficácia, armazenamento||Verificar armazenamento de casos de teste na Wiki||Jaque||07/07/2016||Em andamento ||
|-
| ||Testes de desempenho e segurança - Marcar um workshop (sábado)||Taynara/Paulo/Mara||07/07/2016||Em andamento ||
|-
|Falta de ambiente de testes ||Ensinar os testers a publicar||André / Mara||07/07/2016||Em andamento||
|-
|Falta de ambiente de testes ||Ambiente exclusivo para testes||André / Mara||07/07/2016||Em andamento||
|-
|Aprendizado de testes não funcionais||Repositório e links para aprendizado||Taynara / Paulo||07/07/2016||Em andamento||
|-
|Padronização de bugs||Rever e apontar sugestões no documento de padrões de cadastro de bugs da Wiki||Equipe||07/07/2016||Em andamento||
|-
|Entender os casos de teste: utilidade, eficácia, armazenamento
|Verificar a ferramenta LeanTesting disponível em www.leantesting.com
|Equipe
|14/07/2016
|Em andamento||
|-
|}

Backlog da equipe de Testes

2016-08-05T16:13:55Z

Lucimara.maiorali: /* Em andamento */

Atualizado em 13/07/2016.

==Finalizados==

{| {{table}} class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Problema raiz'''
| align="center" style="background:#f0f0f0;"|'''Atividades'''
| align="center" style="background:#f0f0f0;"|'''Data de finalização'''
| align="center" style="background:#f0f0f0;"|'''Resolução'''
|-
|Não há uma categorização padrão de bugs
|Definir categorias
|11/04/2016
|Foi criado o documento [[Padrões para classificação de bugs]]
Novos campos de classificação adicionados ao TFS e ao Youtrack (apenas em projetos criados a partir de 25/05/2016).
|-
|Não há como garantir a qualidade no final da sprint apenas
|Definir critérios de aceite de um requisito
|11/04/2016
| 1. Requisito finalizado (todas as tarefas da sprint para o requisito terminadas)
2. Testes unitários aprovados (passou ou não) - Opcional

3. Testes funcionais (pelos testers ou teste cruzado)
Como comprovar teste cruzado?
Criar tarefa e o escritorio validar se foi realizado

4. Review ser no ambiente de Homologação Interna - opcional

5. Aprovação do PO (PO aprovaria requisito com baixa criticidade)
|-
|Entender como o desenvolvedor recebe o bug: o que pode ser melhorado?
|Pesquisa com desenvolvedores
|11/04/2016
|Vídeos só em casos em que o problema é complicado de explicar

Imagens - utilizar anotações na imagem e anotar, no nome da imagem, uma descrição rápida do bug + data

Tudo, até ortografia, deve ser registrado

Anexar também evidências de que o item foi corrigido
|-
|Entender os casos de teste: utilidade, eficácia, armazenamento
|Realizar dinâmica para cada um apresentar como descrever caso de teste
Como tratar o armazenamento dos casos de teste pensando no reaproveitamento deles

Apresentar planilha usada pela célula do Gestão
|26/04/2016
|Realização de Dojo na construção de casos de teste
Avaliação do TestLink
|-
|Solicitações para não cadastrar bugs
|Alinhamento com a equipe de testes
|09/05/2016
|Bugs devem ser cadastrados sempre. Se foi aberto por engano, deve ser fechado, e não excluído. Não há exceções.
|-
|Acessibilidade
|Definir escopo dos testes
|30/05/2016
|Testar funcionalidades aparentes de acessibilidade, como tamanho de fonte e alto contraste.
|-
|Entender os casos de teste: utilidade, eficácia, armazenamento
|Ferramenta de registro de caso de teste: Avaliar o TestLink
|30/05/2016
|Testlink foi avaliado e, nesse momento, não parece adequado para nossa realidade. Revisitar futuramente.
|-
|Como é o apontamento de sugestões de melhorias?
|Estudar como registrar QoS de forma que o PO, o SM, o tester e a empresa tenham acesso.
|16/06/2016
|Pesquisa indicou que as empresas não usam QoS. Será utilizado Bug com criticidade "Melhoria"
|-
|Não há uma categorização padrão de bugs
|Definir critérios para a priorização de severidade
|16/06/2016
| Foi criado o documento [[Padrões para definição de criticidade de bugs]]
|-
| Alocação de última hora
|Levantar lista do que cada tester já testou
|13/07/2016
|Foi criada uma pesquisa, onde cada Analista de testes respondeu seu nível de conhecimento em cada produto. Os resultados foram tabulados e enviados para o Escritório de Aplicação.
|-
|}

==Aguardando==

{| {{table}} class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Problema raiz'''
| align="center" style="background:#f0f0f0;"|'''Atividades'''
| align="center" style="background:#f0f0f0;"|'''Equipe de avaliação'''
| align="center" style="background:#f0f0f0;"|'''Data de início'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Resolução'''
|-
| Descrever os testes não funcionais referente à performance||Desenvolver menu||Taynara||28/03/2016||Aguardando||
|-
| Descrever os testes não funcionais referente à performance||Desenvolver pré-requisitos||Taynara||28/03/2016||Aguardando||
|-
| Descrever os testes não funcionais referente à performance||Desenvolver questionário||Taynara||28/03/2016||Aguardando||
|-
| Não há como garantir a qualidade no final da sprint apenas||Definir um ambiente padrão de testes de homologação para a empresa||||||Aguardando||Trazer o DEVOPS junto na conversa
|-
| Acessibilidade||Não temos profissionais com muita experiência em testes de acessibilidade. É algo interessante para começarmos a estudar.||||||Aguardando||Taynara mandou um material inicial. Vamos conversar sobre essa capacitação
|-
| Acessibilidade||Incluir nos testes se o comportamento de forms com "tab" está ok||||||Aguardando||
|-
| Hoje o teste não é obrigatório para aceite||||Ricardo / André||||Aguardando||Na review, apresentar relatório dos bugs para tomada de decisão com o PO. Divulgar isso como parte do processo.
|-
| Melhorar a produtividade Tester: como fazer mais? Materiais de estudo: onde e como se especializar?||Construir um repositório de conhecimento||||||Aguardando||
|-
| Não há como garantir a qualidade no final da sprint apenas||No sprint review, envolver o tester para que este indique como aprovado ou não o RF||Mara / Ricardo||||Aguardando||Escritório será envolvido; sugestão de nova questão no questionário da retrospectiva; testers mandarão e-mail com parecer
|-
| Descrever os testes não funcionais referente à performance||"Não iniciado / em desenvolvimento / entregue /finalizado" - Kanbam||||||Aguardando||
|-
| Não há uma organização padrão dos casos de testes||Definir o critério de organização dos casos de testes||||||Aguardando||Está sendo utilizada planilha de casos de teste que o Gestão criou.
|-
| Pra onde caminha o processo de testes na MSTECH? (Seria interessante passar a visão da empresa sobre a importância dos testes no nosso processo de desenvolvimento)||Levar questões para SM e escritório||Ricardo||||Aguardando||
|-
| Testes de desempenho||Capacitação do teste de desempenho para os demais||||||Aguardando||Aguardando Taynara estar com menos atividades. Procurar alguma capacitação externa para desempenho e segurança
|-
|}

==Em andamento==

{| {{table}} class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Problema raiz'''
| align="center" style="background:#f0f0f0;"|'''Atividades'''
| align="center" style="background:#f0f0f0;"|'''Equipe de avaliação'''
| align="center" style="background:#f0f0f0;"|'''Data de início'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Resolução'''
|-
| Não há uma categorização padrão de bugs||Divulgar o relatório de bugs||André||30/05/2016||Em andamento||André vai montar um relatório padrão de bugs no Excel junto com Flávia
|-
| Alocação de última hora||Checklist da planning. Perguntas para confirmar se tudo que o PO e SM tinham que fazer para o planning foi feito (especialmente alocação da base)||Karystha, Debora, Mara, Ricardo||16/06/2016||Em andamento||
|-
| Alocação de última hora||Organizar/Comunicar/Lembrar fluxo de alocação da base||Karystha, Debora, Mara, Ricardo||16/06/2016||Em andamento||Muitas vezes os POs e SMs vão falar direto com o tester. O escritório não tem ciência da alocação.
|-
| Métricas para acompanhar a evolução da melhoria||Construção de métricas de projeto e da evolução das frentes||André / Ricardo||||Em andamento||Construção das métricas de bugs dos projetos. Em relação ao fórum, temos métricas dos itens que já foram resolvidos
|-
| Entender os casos de teste: utilidade, eficácia, armazenamento||Avaliar o uso do Youtrack para criação de caso de teste||Ricardo / Mara / Eric||16/06/2016||Em andamento||
|-
| Calendario de alocação||Verificar a possibilidade de construir um calendário com a alocação dos testers||Mara||07/07/2016||Em andamento||
|-
| Testers estão ficando sem alocação / sem resposta do escritório.||Verificar o problema com o escritório.||André / Mara / Ricardo||07/07/2016||Em andamento ||
|-
| ||Verificar a ideia de cada tester ficar em projetos fixos.||André / Mara / Ricardo||07/07/2016||Em andamento ||
|-
| ||Testers ficam sem atividade no começo da sprint (Halana)||André / Mara / Ricardo||07/07/2016||Em andamento ||
|-
| Testers não são considerados no planning||Testers não participam do planning||André / Mara / Ricardo||07/07/2016||Em andamento ||
|-
| ||Testers precisam ficar próximos ao projeto que estão testando e participar do ciclo||André / Mara / Ricardo||07/07/2016||Em andamento ||
|-
| Melhores práticas||Melhores práticas: testes com console aberto||Elizabeth||07/07/2016||Em andamento ||
|-
|Entender os casos de teste: utilidade, eficácia, armazenamento||Verificar armazenamento de casos de teste na Wiki||Jaque||07/07/2016||Em andamento ||
|-
| ||Testes de desempenho e segurança - Marcar um workshop (sábado)||Taynara/Paulo/Mara||07/07/2016||Em andamento ||
|-
|Falta de ambiente de testes ||Ensinar os testers a publicar||André / Mara||07/07/2016||Em andamento||
|-
|Falta de ambiente de testes ||Ambiente exclusivo para testes||André / Mara||07/07/2016||Em andamento||
|-
|Aprendizado de testes não funcionais||Repositório e links para aprendizado||Taynara / Paulo||07/07/2016||Em andamento||
|-
|Padronização de bugs||Rever e apontar sugestões no documento de padrões de cadastro de bugs da Wiki||Equipe||07/07/2016||Em andamento||
|-
|Entender os casos de teste: utilidade, eficácia, armazenamento
|Verificar a ferramenta LeanTesting disponível em www.leantesting.com
|Equipe
|14/07/2016
|Em andamento||
|-
|}

Testes

2016-08-05T15:13:22Z

Lucimara.maiorali: /* A equipe */

==Sobre o teste de software na MSTECH==

A MSTECH tem um longo histórico de comprometimento com a qualidade dos produtos desenvolvidos. Criou, estimulou e dá constante suporte à equipe de testes de softwares, que foi se adaptando e evoluindo para atender às necessidades internas.

====A equipe====

Contamos com oito profissionais de testes que estão aptos para realizar diversas verificações nos produtos da empresa.
Conheça o time de testes da MSTECH!

{| class="wikitable"
|-
|[mailto:ana.guedes@mstech.com.br Ana Guedes] || Testes funcionais || Em licença
|-
|[mailto:andre.iguera@mstech.com.br André Iguera] || Testes funcionais ||Em férias
|-
|[mailto:elizabeth.fidencio@mstech.com.br Elizabeth Fidencio] ||Testes funcionais ||
|-
|[mailto:halana.camuci@mstech.com.br Halana Camuci] ||Testes funcionais ||
|-
|[mailto:jaqueline.sgarbi@mstech.com.br Jaqueline Sgarbi] ||Testes funcionais ||
|-
|[mailto:marriely.garcia@mstech.com.br Marriely Garcia] ||Testes funcionais ||
|-
|[mailto:paulo.souza@mstech.com.br Paulo Souza] ||Testes de segurança e desempenho||
|-
|[mailto:taynara.nakashima@mstech.com.br Taynara Jacon] ||Testes de desempenho ||
|-
|}

====Testes funcionais e não funcionais====
A equipe de testes da MSTECH está preparada para realizar diversas verificações nos produtos desenvolvidos: teste funcional baseado em requisitos, teste exploratório, teste de acessibilidade, teste de desempenho e teste de segurança.

====Melhorias do produto e experiência do usuário====
Os analistas de testes podem sugerir melhorias aos responsáveis pelos produtos com base em suas experiências de uso do software, sempre direcionando esfoços para oferecer aos nossos clientes a melhor experiência de uso.

====Melhoria interna contínua====
Através dos fóruns de especialidades, estamos criando, reciclando e discutindo novas formas de trabalho.

==Verificação de segurança e desempenho==

Contém uma visão geral sobre a realização de testes de segurança e desempenho, objetivos, pré-requisitos, ferramentas utilizadas, configuração do ambiente padrão e resultados das verificações nos produtos.

*[[Verificação de segurança e desempenho]]

==Fórum de especialidades==

Os fóruns da especialidade Testes ocorrem quinzenalmente. São trazidos problemas, sugestões, críticas e propostas de melhoria no processo de testes de softwares. Após as discussões e outras diligências, ações são tomadas e registradas.

*[[Backlog da equipe de Testes]]

==Glossário de testes==

O Glossário de testes contém os termos mais utilizados no processo de testes.

*[[Glossário de testes]]

==Softwares e utilitários==

Lista de softwares e sites utilizados para a realização de testes nos sistemas desenvolvidos.

*[[Softwares e utilitários para testes]]

==Melhores práticas==

*[[Melhores práticas de teste de software]]

==Documentos, guias e padrões==

*[[Introdução ao teste de software]]
*[[Guia para geração de relatórios de bugs do Youtrack]]
*[[Padrões para o cadastro de bugs]]
*[[Padrões para classificação de bugs]]
*[[Padrões para definição de criticidade de bugs]]
*[[Regras de ortografia e gramática]]

Conpat 2.25.2.0

2016-07-27T16:29:03Z

Lucimara.maiorali: /* Resultado dos testes */

== Sistemas Verificados ==

*Controle de patrimônio (Conpat), versão 2.25.2.0
== Verificação de Segurança ==

Em verificação.

== Verificação de Desempenho ==

=== Análise do teste ===
Durante todos os testes, o percentual de processamento manteve-se dentro dos padrões estabelecidos tendo grande utilização de memória. A média de fila em disco entra-se dentro do aconselhado. O tempo médio de resposta das requisições manteve-se no limite estabelecido, exceto o request de salvar que, em média, demora o dobro dos demais requests.

O sistema apresentou picos nos indicadores "Lazy Write Fluses/sec", "Disk Write/sec" e "Dirty Pages".

A aplicação suporta no máximo até 350 usuários simultâneos, devido a transação de salvar na tabela de cadastro de bens. Não foi possível continuar a realizar os testes devido a grande quantidade de deadlock, que ocorrem a partir de 2 usuários simultâneos. Os mesmos ainda resultam em outros erros de eventvalidation.

Durante os testes foi possível observar que a partir de 50 usuários simultâneos começa a ocorrer erro de conflito da chave estrangeira "FK_BemItemWorkFlow_BemItem". Segue abaixo os logs de erros encontrados:

* Logs de erro do Conpat

:- Log01
'''Exception Type:''' System.Data.SqlClient.SqlException
'''Exception:''' The INSERT statement conflicted with the FOREIGN KEY constraint "FK_BemItemWorkflow_BemItem". The conflict occurred in database "Conpat", table "dbo.BemItem".
The statement has been terminated.
'''Source:''' .Net SqlClient Data Provider
'''Stack Trace: '''
at MSTech.ConPat.BLL.BemItemWorkflowBO.SalvarWFlow(Int64 _bem_Id, Int32 _bit_Id, Int32 _biw_id, Int32 _bws_id, Guid _usu_id, String _bws_observacao, _WorkId _TipoWF, _PassosWF _Passo, Int64 _tmo_id, TalkDBTransaction banco) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\MSTech.ConPat.BLL\BemItemWorkflowBO.cs:line 137
at MSTech.ConPat.BLL.BemItemBO.AtualizarPlaquetas(Int32 uni_idPlaquetas, List`1 listaBensPlaqueta, Int32 cfg_id, Guid usu_idLogado) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\MSTech.ConPat.BLL\BemItemBO.cs:line 875
at WebConPat.AreaAdm.Cadastro.Bens.CadastrarPlaqueta.btnSalvar_Click(Object sender, EventArgs e) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\WebConPat\AreaAdm\Cadastro\Bens\CadastrarPlaqueta.aspx.cs:line 173

:- Log02
'''Exception Type: '''System.Data.SqlClient.SqlException
'''Exception:''' Transaction (Process ID 61) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
'''Source:''' .Net SqlClient Data Provider
'''Stack Trace: '''
at MSTech.ConPat.BLL.BemPatrimonialBO.Save(BemPatrimonial entityBemPatrimonial, List`1 listBemArquivo, BemItem entityBemItem, List`1 listBemItemArquivo, Boolean IsMovBemPatrimonial, eAction actionLegado, DataTable dtDocumentos, String dirArquivo, String dirArquivoTemp, DataTable dtCentroDeCusto, List`1 listGarantia, Boolean importacaoServico, BemPatrimonialHistoricoDescricao bemPatrimonialHistoricoDescricao, Boolean descricaoMaiuscula, List`1 lstHistorico, eOrigem VS_Origem, PreBens preBem) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\MSTech.ConPat.BLL\BemPatrimonialBO.cs:line 1129
at WebConPat.AreaAdm.Cadastro.Bens.Cadastro._Salvar() in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\WebConPat\AreaAdm\Cadastro\Bens\Cadastro.aspx.cs:line 3363

:- Log03
'''Inner Exception Type:''' System.ArgumentException
'''Inner Exception: '''Invalid postback or callback argument. Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%@ Page EnableEventValidation="true" %> in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.
'''Inner Source:'''System.Web
'''Inner Stack Trace: '''
at System.Web.UI.ClientScriptManager.ValidateEvent(String uniqueId, String argument)
at System.Web.UI.Control.ValidateEvent(String uniqueID, String eventArgument)
at System.Web.UI.WebControls.TextBox.LoadPostData(String postDataKey, NameValueCollection postCollection)
at System.Web.UI.Page.ProcessPostData(NameValueCollection postData, Boolean fBeforeLoad)
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
'''Exception Type:''' System.Web.HttpUnhandledException
'''Exception:''' Exception of type 'System.Web.HttpUnhandledException' was thrown.
'''Source:''' System.Web
'''Stack Trace: '''
at System.Web.UI.Page.HandleError(Exception e)
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest()
at System.Web.UI.Page.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

* Logs de erro CoreSSO

:- Log01
'''Exception Type:''' System.Xml.XmlException
'''Exception:''' Data at the root level is invalid. Line 1, position 1.
'''Source:''' System.Xml
'''Stack Trace: '''
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.ParseRootLevelWhitespace()
at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
at System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace)
at System.Xml.XmlDocument.Load(XmlReader reader)
at System.Xml.XmlDocument.LoadXml(String xml)
at MSTech.ConPat.Web.WebProject.LogOn.ProcessRequest(HttpContext context) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\MSTech.ConPat.Web.WebProject\LogOn.cs:line 58

:- Log02
'''Exception Type:''' System.NullReferenceException
'''Exception:''' Object reference not set to an instance of an object.
'''Source:''' WebConPat
'''Stack Trace:'''
at WebConPat.SelecionaUnidade.Page_Load(Object sender, EventArgs e) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\WebConPat\SelecionaUnidade.aspx.cs:line 19

=== Cenários de uso ===

{| class="wikitable"
!colspan="6"|Cenário de uso #1 - Login
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|1 - Acessar tela de login || style="text-align: center; | 3
|-
|colspan="2"|1 - Realizar login || style="text-align: center; | 7
|-
|colspan="2"|1 - Selecionar sistema Transporte Escolar || style="text-align: center; | 5
|}

{| class="wikitable"
!colspan="6"|Cenário de uso #2 - Cadastro de bem
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|2 - Acessar tela de consulta de bens || style="text-align: center; | 3
|-
|colspan="2"|2 - Acessar tela de cadastro de bens || style="text-align: center; | 3
|-
|colspan="2"|2 - Preencher "Tipo" || style="text-align: center; | 3
|-
|colspan="2"|2 - Preencher campos de data || style="text-align: center; | 5
|-
|colspan="2"|2 - Preencher campo valor || style="text-align: center; | 4
|-
|colspan="2"|2 - Adicionar fornecedor || style="text-align: center; | 13
|-
|colspan="2"|2 - Selecionar grupo de bens || style="text-align: center; | 7
|-
|colspan="2"|2 - Adicionar documento || style="text-align: center; | 10
|-
|colspan="2"|2 - Marcar bem como sem garantia || style="text-align: center; | 3
|-
|colspan="2"|2 - Adicionar centro de custo || style="text-align: center; | 7
|-
|colspan="2"|2 - Salvar cadastro || style="text-align: center; | 10
|}

{| class="wikitable"
!colspan="6"|Cenário de uso #3 - Recebimento de bem
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|3 - Acessar home || style="text-align: center; | 3
|-
|colspan="2"|3 - Expandir painel || style="text-align: center; | 3
|-
|colspan="2"|3 - Clicar em "Envio de bens" || style="text-align: center; | 2
|-
|colspan="2"|3 - Clicar em "Aguardando recebimento" || style="text-align: center; | 2
|-
|colspan="2"|3 - Mudar status do item || style="text-align: center; | 8
|-
|}

{| class="wikitable"
!colspan="6"|Cenário de uso #4 - Incorporação do bem
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|4 - Acessar tela de movimentação manual de bens || style="text-align: center; | 5
|-
|colspan="2"|4 - Selecionar movimentação de incorporação || style="text-align: center; | 3
|-
|colspan="2"|4 - Pesquisar bens para incorporação || style="text-align: center; | 7
|-
|colspan="2"|4 - Clicar em "Exibir itens" || style="text-align: center; | 2
|-
|colspan="2"|4 - Clicar em "Confirmar seleção" || style="text-align: center; | 5
|-
|colspan="2"|4 - Clicar em "Carregar dados" || style="text-align: center; | 4
|-
|colspan="2"|4 - Salvar movimentação || style="text-align: center; | 10
|-
|}

{| class="wikitable"
!colspan="6"|Cenário de uso #5 - Logout
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|5 - Logout || style="text-align: center; | 5
|-
|}

=== Resultado dos testes ===
Nesta seção serão apresentados os resultados obtidos da execução dos testes.

*'''Porcentagem de tempo do processador'''
: Descrição: Mede a saturação do processador e mostra a quantidade de tempo despendida para processar as threads por todas as CPUs.
: Limite recomendado: Abaixo de 75 %.
: Análise: A aplicação demonstrou desempenho esperado.

:::::: [[Arquivo:2016-07-04_Conpat_ResponseTime.png]]

*'''Porcentagem de memória utilizada'''
: Descrição: Indica a porcentagem de memória utilizada para uso dos processos.
: Limite recomendado: Abaixo de 75 %.
: Análise: A aplicação utiliza uma quantidade significativa de memória.
:::::: [[Arquivo:2016-07-04_Conpat_MemoriaUtilizada.png]]

*'''Kbytes totais pela interface de rede'''
: Descrição: Indica quantos Kbytes foram enviados e recebidos a cada segundo pela interface de rede.
: Limite recomendado: Menor que 5 Mbytes para uma rede de 100Mbps, menor que 50 Mbytes para uma rede de 1000 Mbps. (Quanto menor melhor).
: Análise: Ocorre picos de envio e recebimento de Kbytes realizados pelo sistema.

:::::: [[Arquivo:2016-07-04_Conpat_InterfaceTotalDeRede.png]]

*'''Tempo médio de resposta das requisições'''
: Descrição: Indica o tempo médio de resposta das requisições.
: Limite recomendado: 5 segundos.
: Análise: A aplicação demonstrou desempenho esperado próximo à 350 usuários, com uma quantidade superior de usuários os servidores ficam sobrecarregados, aumentando significativamente o tempo de resposta.

:::::: [[Arquivo:2016-07-04_Conpat_TempoDeResposta.png]]
::::::: [[Arquivo:2016-07-04_Conpat_TempoDeRespostaLegenda.png]]

*'''Tempo de vazão'''
: Descrição: Indica a quantidade total de request por segundo.
: Limite recomendado: Quanto maior melhor.
: A aplicação demonstrou desempenho esperado até atingir 400 usuários simultâneos.

:::::: [[Arquivo:2016-07-04_Conpat_Vazao.png]]
::::::: [[Arquivo:2016-07-04_Conpat_VazaoLegenda.png]]

*'''Porcentagem de erro'''
: Descrição: Indica a porcentagem de erro.
: Limite recomendado: Quanto menor melhor.
: A aplicação demonstrou grande porcentagem de erro.

:::::: [[Arquivo:2016-07-04_Conpat_PorcentagemErros.png]]

Conpat 2.25.2.0

2016-07-27T16:27:05Z

Lucimara.maiorali: /* Análise do teste */

== Sistemas Verificados ==

*Controle de patrimônio (Conpat), versão 2.25.2.0
== Verificação de Segurança ==

Em verificação.

== Verificação de Desempenho ==

=== Análise do teste ===
Durante todos os testes, o percentual de processamento manteve-se dentro dos padrões estabelecidos tendo grande utilização de memória. A média de fila em disco entra-se dentro do aconselhado. O tempo médio de resposta das requisições manteve-se no limite estabelecido, exceto o request de salvar que, em média, demora o dobro dos demais requests.

O sistema apresentou picos nos indicadores "Lazy Write Fluses/sec", "Disk Write/sec" e "Dirty Pages".

A aplicação suporta no máximo até 350 usuários simultâneos, devido a transação de salvar na tabela de cadastro de bens. Não foi possível continuar a realizar os testes devido a grande quantidade de deadlock, que ocorrem a partir de 2 usuários simultâneos. Os mesmos ainda resultam em outros erros de eventvalidation.

Durante os testes foi possível observar que a partir de 50 usuários simultâneos começa a ocorrer erro de conflito da chave estrangeira "FK_BemItemWorkFlow_BemItem". Segue abaixo os logs de erros encontrados:

* Logs de erro do Conpat

:- Log01
'''Exception Type:''' System.Data.SqlClient.SqlException
'''Exception:''' The INSERT statement conflicted with the FOREIGN KEY constraint "FK_BemItemWorkflow_BemItem". The conflict occurred in database "Conpat", table "dbo.BemItem".
The statement has been terminated.
'''Source:''' .Net SqlClient Data Provider
'''Stack Trace: '''
at MSTech.ConPat.BLL.BemItemWorkflowBO.SalvarWFlow(Int64 _bem_Id, Int32 _bit_Id, Int32 _biw_id, Int32 _bws_id, Guid _usu_id, String _bws_observacao, _WorkId _TipoWF, _PassosWF _Passo, Int64 _tmo_id, TalkDBTransaction banco) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\MSTech.ConPat.BLL\BemItemWorkflowBO.cs:line 137
at MSTech.ConPat.BLL.BemItemBO.AtualizarPlaquetas(Int32 uni_idPlaquetas, List`1 listaBensPlaqueta, Int32 cfg_id, Guid usu_idLogado) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\MSTech.ConPat.BLL\BemItemBO.cs:line 875
at WebConPat.AreaAdm.Cadastro.Bens.CadastrarPlaqueta.btnSalvar_Click(Object sender, EventArgs e) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\WebConPat\AreaAdm\Cadastro\Bens\CadastrarPlaqueta.aspx.cs:line 173

:- Log02
'''Exception Type: '''System.Data.SqlClient.SqlException
'''Exception:''' Transaction (Process ID 61) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
'''Source:''' .Net SqlClient Data Provider
'''Stack Trace: '''
at MSTech.ConPat.BLL.BemPatrimonialBO.Save(BemPatrimonial entityBemPatrimonial, List`1 listBemArquivo, BemItem entityBemItem, List`1 listBemItemArquivo, Boolean IsMovBemPatrimonial, eAction actionLegado, DataTable dtDocumentos, String dirArquivo, String dirArquivoTemp, DataTable dtCentroDeCusto, List`1 listGarantia, Boolean importacaoServico, BemPatrimonialHistoricoDescricao bemPatrimonialHistoricoDescricao, Boolean descricaoMaiuscula, List`1 lstHistorico, eOrigem VS_Origem, PreBens preBem) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\MSTech.ConPat.BLL\BemPatrimonialBO.cs:line 1129
at WebConPat.AreaAdm.Cadastro.Bens.Cadastro._Salvar() in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\WebConPat\AreaAdm\Cadastro\Bens\Cadastro.aspx.cs:line 3363

:- Log03
'''Inner Exception Type:''' System.ArgumentException
'''Inner Exception: '''Invalid postback or callback argument. Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%@ Page EnableEventValidation="true" %> in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.
'''Inner Source:'''System.Web
'''Inner Stack Trace: '''
at System.Web.UI.ClientScriptManager.ValidateEvent(String uniqueId, String argument)
at System.Web.UI.Control.ValidateEvent(String uniqueID, String eventArgument)
at System.Web.UI.WebControls.TextBox.LoadPostData(String postDataKey, NameValueCollection postCollection)
at System.Web.UI.Page.ProcessPostData(NameValueCollection postData, Boolean fBeforeLoad)
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
'''Exception Type:''' System.Web.HttpUnhandledException
'''Exception:''' Exception of type 'System.Web.HttpUnhandledException' was thrown.
'''Source:''' System.Web
'''Stack Trace: '''
at System.Web.UI.Page.HandleError(Exception e)
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest()
at System.Web.UI.Page.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

* Logs de erro CoreSSO

:- Log01
'''Exception Type:''' System.Xml.XmlException
'''Exception:''' Data at the root level is invalid. Line 1, position 1.
'''Source:''' System.Xml
'''Stack Trace: '''
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.ParseRootLevelWhitespace()
at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
at System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace)
at System.Xml.XmlDocument.Load(XmlReader reader)
at System.Xml.XmlDocument.LoadXml(String xml)
at MSTech.ConPat.Web.WebProject.LogOn.ProcessRequest(HttpContext context) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\MSTech.ConPat.Web.WebProject\LogOn.cs:line 58

:- Log02
'''Exception Type:''' System.NullReferenceException
'''Exception:''' Object reference not set to an instance of an object.
'''Source:''' WebConPat
'''Stack Trace:'''
at WebConPat.SelecionaUnidade.Page_Load(Object sender, EventArgs e) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\WebConPat\SelecionaUnidade.aspx.cs:line 19

=== Cenários de uso ===

{| class="wikitable"
!colspan="6"|Cenário de uso #1 - Login
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|1 - Acessar tela de login || style="text-align: center; | 3
|-
|colspan="2"|1 - Realizar login || style="text-align: center; | 7
|-
|colspan="2"|1 - Selecionar sistema Transporte Escolar || style="text-align: center; | 5
|}

{| class="wikitable"
!colspan="6"|Cenário de uso #2 - Cadastro de bem
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|2 - Acessar tela de consulta de bens || style="text-align: center; | 3
|-
|colspan="2"|2 - Acessar tela de cadastro de bens || style="text-align: center; | 3
|-
|colspan="2"|2 - Preencher "Tipo" || style="text-align: center; | 3
|-
|colspan="2"|2 - Preencher campos de data || style="text-align: center; | 5
|-
|colspan="2"|2 - Preencher campo valor || style="text-align: center; | 4
|-
|colspan="2"|2 - Adicionar fornecedor || style="text-align: center; | 13
|-
|colspan="2"|2 - Selecionar grupo de bens || style="text-align: center; | 7
|-
|colspan="2"|2 - Adicionar documento || style="text-align: center; | 10
|-
|colspan="2"|2 - Marcar bem como sem garantia || style="text-align: center; | 3
|-
|colspan="2"|2 - Adicionar centro de custo || style="text-align: center; | 7
|-
|colspan="2"|2 - Salvar cadastro || style="text-align: center; | 10
|}

{| class="wikitable"
!colspan="6"|Cenário de uso #3 - Recebimento de bem
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|3 - Acessar home || style="text-align: center; | 3
|-
|colspan="2"|3 - Expandir painel || style="text-align: center; | 3
|-
|colspan="2"|3 - Clicar em "Envio de bens" || style="text-align: center; | 2
|-
|colspan="2"|3 - Clicar em "Aguardando recebimento" || style="text-align: center; | 2
|-
|colspan="2"|3 - Mudar status do item || style="text-align: center; | 8
|-
|}

{| class="wikitable"
!colspan="6"|Cenário de uso #4 - Incorporação do bem
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|4 - Acessar tela de movimentação manual de bens || style="text-align: center; | 5
|-
|colspan="2"|4 - Selecionar movimentação de incorporação || style="text-align: center; | 3
|-
|colspan="2"|4 - Pesquisar bens para incorporação || style="text-align: center; | 7
|-
|colspan="2"|4 - Clicar em "Exibir itens" || style="text-align: center; | 2
|-
|colspan="2"|4 - Clicar em "Confirmar seleção" || style="text-align: center; | 5
|-
|colspan="2"|4 - Clicar em "Carregar dados" || style="text-align: center; | 4
|-
|colspan="2"|4 - Salvar movimentação || style="text-align: center; | 10
|-
|}

{| class="wikitable"
!colspan="6"|Cenário de uso #5 - Logout
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|5 - Logout || style="text-align: center; | 5
|-
|}

=== Resultado dos testes ===
Nesta seção serão apresentados os resultados obtidos da execução dos testes.

*'''Porcentagem de tempo do processador'''
: Descrição: Mede a saturação do processador e mostra a quantidade de tempo despendida para processar as threads por todas as CPUs.
: Limite recomendado: Abaixo de 75 %.
: Análise: A aplicação demonstrou desempenho esperado.

:::::: [[Arquivo:2016-07-04_Conpat_ResponseTime.png]]

*'''Porcentagem de memória utilizada'''
: Descrição: Indica a porcentagem de memória utilizada para uso dos processos.
: Limite recomendado: Abaixo de 75 %.
: Análise: A aplicação utiliza utiliza uma quantidade significativa de memória.
:::::: [[Arquivo:2016-07-04_Conpat_MemoriaUtilizada.png]]

*'''Kbytes totais pela interface de rede'''
: Descrição: Indica quantos Kbytes foram enviados e recebidos a cada segundo pela interface de rede.
: Limite recomendado: Menor que 5 Mbytes para uma rede de 100Mbps, menor que 50 Mbytes para uma rede de 1000 Mbps. (Quanto menor melhor).
: Análise: Ocorre picos de envio e recebimento de Kbytes realizados pelo sistema.

:::::: [[Arquivo:2016-07-04_Conpat_InterfaceTotalDeRede.png]]

*'''Tempo médio de resposta das requisições'''
: Descrição: Indica o tempo médio de resposta das requisições.
: Limite recomendado: 5 segundos.
: Análise: A aplicação demonstrou desempenho esperado próximo à 350 usuários, com uma quantidade superior de usuários os servidores ficam sobrecarregados, aumentando significativamente o tempo de resposta.

:::::: [[Arquivo:2016-07-04_Conpat_TempoDeResposta.png]]
::::::: [[Arquivo:2016-07-04_Conpat_TempoDeRespostaLegenda.png]]

*'''Tempo de vazão'''
: Descrição: Indica a quantidade total de request por segundo.
: Limite recomendado: Quanto maior melhor.
: A aplicação demonstrou desempenho esperado até atingir 400 usuários simultâneos.

:::::: [[Arquivo:2016-07-04_Conpat_Vazao.png]]
::::::: [[Arquivo:2016-07-04_Conpat_VazaoLegenda.png]]

*'''Porcentagem de erro'''
: Descrição: Indica a porcentagem de erro.
: Limite recomendado: Quanto menor melhor.
: A aplicação demonstrou grande porcentagem de erro.

:::::: [[Arquivo:2016-07-04_Conpat_PorcentagemErros.png]]

Conpat 2.25.2.0

2016-07-27T16:26:00Z

Lucimara.maiorali: /* Análise do teste */

== Sistemas Verificados ==

*Controle de patrimônio (Conpat), versão 2.25.2.0
== Verificação de Segurança ==

Em verificação.

== Verificação de Desempenho ==

=== Análise do teste ===
Durante todos os testes, o percentual de processamento manteve-se dentro dos padrões estabelecidos tendo grande utilização de memória. A média de fila em disco entra-se dentro do aconselhado. O tempo médio de resposta das requisições manteve-se no limite estabelecido, exceto o request de salvar que, em média, demora o dobro dos demais requests.

O sistema apresentou picos nos indicadores "Lazy Write Fluses/sec", "Disk Write/sec" e "Dirty Pages".

A aplicação suporta no máximo até 350 usuários simultâneos, devido a transação de salvar na tabela de cadastro de bens. Não foi possível continuar a realizar os teste devido a grande quantidade de deadlock, que ocorrem a partir de 2 usuários simultâneos. Os mesmos ainda resultam em outros erros de eventvalidation.

Durante os teste foi possível observar que a partir de 50 usuários simultâneos começa a ocorrer erro de conflito da chave estrangeira "FK_BemItemWorkFlow_BemItem". Segue abaixo os logs de erros encontrados:

* Logs de erro do Conpat

:- Log01
'''Exception Type:''' System.Data.SqlClient.SqlException
'''Exception:''' The INSERT statement conflicted with the FOREIGN KEY constraint "FK_BemItemWorkflow_BemItem". The conflict occurred in database "Conpat", table "dbo.BemItem".
The statement has been terminated.
'''Source:''' .Net SqlClient Data Provider
'''Stack Trace: '''
at MSTech.ConPat.BLL.BemItemWorkflowBO.SalvarWFlow(Int64 _bem_Id, Int32 _bit_Id, Int32 _biw_id, Int32 _bws_id, Guid _usu_id, String _bws_observacao, _WorkId _TipoWF, _PassosWF _Passo, Int64 _tmo_id, TalkDBTransaction banco) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\MSTech.ConPat.BLL\BemItemWorkflowBO.cs:line 137
at MSTech.ConPat.BLL.BemItemBO.AtualizarPlaquetas(Int32 uni_idPlaquetas, List`1 listaBensPlaqueta, Int32 cfg_id, Guid usu_idLogado) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\MSTech.ConPat.BLL\BemItemBO.cs:line 875
at WebConPat.AreaAdm.Cadastro.Bens.CadastrarPlaqueta.btnSalvar_Click(Object sender, EventArgs e) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\WebConPat\AreaAdm\Cadastro\Bens\CadastrarPlaqueta.aspx.cs:line 173

:- Log02
'''Exception Type: '''System.Data.SqlClient.SqlException
'''Exception:''' Transaction (Process ID 61) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
'''Source:''' .Net SqlClient Data Provider
'''Stack Trace: '''
at MSTech.ConPat.BLL.BemPatrimonialBO.Save(BemPatrimonial entityBemPatrimonial, List`1 listBemArquivo, BemItem entityBemItem, List`1 listBemItemArquivo, Boolean IsMovBemPatrimonial, eAction actionLegado, DataTable dtDocumentos, String dirArquivo, String dirArquivoTemp, DataTable dtCentroDeCusto, List`1 listGarantia, Boolean importacaoServico, BemPatrimonialHistoricoDescricao bemPatrimonialHistoricoDescricao, Boolean descricaoMaiuscula, List`1 lstHistorico, eOrigem VS_Origem, PreBens preBem) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\MSTech.ConPat.BLL\BemPatrimonialBO.cs:line 1129
at WebConPat.AreaAdm.Cadastro.Bens.Cadastro._Salvar() in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\WebConPat\AreaAdm\Cadastro\Bens\Cadastro.aspx.cs:line 3363

:- Log03
'''Inner Exception Type:''' System.ArgumentException
'''Inner Exception: '''Invalid postback or callback argument. Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%@ Page EnableEventValidation="true" %> in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.
'''Inner Source:'''System.Web
'''Inner Stack Trace: '''
at System.Web.UI.ClientScriptManager.ValidateEvent(String uniqueId, String argument)
at System.Web.UI.Control.ValidateEvent(String uniqueID, String eventArgument)
at System.Web.UI.WebControls.TextBox.LoadPostData(String postDataKey, NameValueCollection postCollection)
at System.Web.UI.Page.ProcessPostData(NameValueCollection postData, Boolean fBeforeLoad)
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
'''Exception Type:''' System.Web.HttpUnhandledException
'''Exception:''' Exception of type 'System.Web.HttpUnhandledException' was thrown.
'''Source:''' System.Web
'''Stack Trace: '''
at System.Web.UI.Page.HandleError(Exception e)
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest()
at System.Web.UI.Page.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

* Logs de erro CoreSSO

:- Log01
'''Exception Type:''' System.Xml.XmlException
'''Exception:''' Data at the root level is invalid. Line 1, position 1.
'''Source:''' System.Xml
'''Stack Trace: '''
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.ParseRootLevelWhitespace()
at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
at System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace)
at System.Xml.XmlDocument.Load(XmlReader reader)
at System.Xml.XmlDocument.LoadXml(String xml)
at MSTech.ConPat.Web.WebProject.LogOn.ProcessRequest(HttpContext context) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\MSTech.ConPat.Web.WebProject\LogOn.cs:line 58

:- Log02
'''Exception Type:''' System.NullReferenceException
'''Exception:''' Object reference not set to an instance of an object.
'''Source:''' WebConPat
'''Stack Trace:'''
at WebConPat.SelecionaUnidade.Page_Load(Object sender, EventArgs e) in d:\b\ControlePatrimonio\ControlePatrimonio_Main.Revision\src\ControlePatrimonio\Main\Src\WebConPat\SelecionaUnidade.aspx.cs:line 19

=== Cenários de uso ===

{| class="wikitable"
!colspan="6"|Cenário de uso #1 - Login
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|1 - Acessar tela de login || style="text-align: center; | 3
|-
|colspan="2"|1 - Realizar login || style="text-align: center; | 7
|-
|colspan="2"|1 - Selecionar sistema Transporte Escolar || style="text-align: center; | 5
|}

{| class="wikitable"
!colspan="6"|Cenário de uso #2 - Cadastro de bem
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|2 - Acessar tela de consulta de bens || style="text-align: center; | 3
|-
|colspan="2"|2 - Acessar tela de cadastro de bens || style="text-align: center; | 3
|-
|colspan="2"|2 - Preencher "Tipo" || style="text-align: center; | 3
|-
|colspan="2"|2 - Preencher campos de data || style="text-align: center; | 5
|-
|colspan="2"|2 - Preencher campo valor || style="text-align: center; | 4
|-
|colspan="2"|2 - Adicionar fornecedor || style="text-align: center; | 13
|-
|colspan="2"|2 - Selecionar grupo de bens || style="text-align: center; | 7
|-
|colspan="2"|2 - Adicionar documento || style="text-align: center; | 10
|-
|colspan="2"|2 - Marcar bem como sem garantia || style="text-align: center; | 3
|-
|colspan="2"|2 - Adicionar centro de custo || style="text-align: center; | 7
|-
|colspan="2"|2 - Salvar cadastro || style="text-align: center; | 10
|}

{| class="wikitable"
!colspan="6"|Cenário de uso #3 - Recebimento de bem
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|3 - Acessar home || style="text-align: center; | 3
|-
|colspan="2"|3 - Expandir painel || style="text-align: center; | 3
|-
|colspan="2"|3 - Clicar em "Envio de bens" || style="text-align: center; | 2
|-
|colspan="2"|3 - Clicar em "Aguardando recebimento" || style="text-align: center; | 2
|-
|colspan="2"|3 - Mudar status do item || style="text-align: center; | 8
|-
|}

{| class="wikitable"
!colspan="6"|Cenário de uso #4 - Incorporação do bem
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|4 - Acessar tela de movimentação manual de bens || style="text-align: center; | 5
|-
|colspan="2"|4 - Selecionar movimentação de incorporação || style="text-align: center; | 3
|-
|colspan="2"|4 - Pesquisar bens para incorporação || style="text-align: center; | 7
|-
|colspan="2"|4 - Clicar em "Exibir itens" || style="text-align: center; | 2
|-
|colspan="2"|4 - Clicar em "Confirmar seleção" || style="text-align: center; | 5
|-
|colspan="2"|4 - Clicar em "Carregar dados" || style="text-align: center; | 4
|-
|colspan="2"|4 - Salvar movimentação || style="text-align: center; | 10
|-
|}

{| class="wikitable"
!colspan="6"|Cenário de uso #5 - Logout
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|5 - Logout || style="text-align: center; | 5
|-
|}

=== Resultado dos testes ===
Nesta seção serão apresentados os resultados obtidos da execução dos testes.

*'''Porcentagem de tempo do processador'''
: Descrição: Mede a saturação do processador e mostra a quantidade de tempo despendida para processar as threads por todas as CPUs.
: Limite recomendado: Abaixo de 75 %.
: Análise: A aplicação demonstrou desempenho esperado.

:::::: [[Arquivo:2016-07-04_Conpat_ResponseTime.png]]

*'''Porcentagem de memória utilizada'''
: Descrição: Indica a porcentagem de memória utilizada para uso dos processos.
: Limite recomendado: Abaixo de 75 %.
: Análise: A aplicação utiliza utiliza uma quantidade significativa de memória.
:::::: [[Arquivo:2016-07-04_Conpat_MemoriaUtilizada.png]]

*'''Kbytes totais pela interface de rede'''
: Descrição: Indica quantos Kbytes foram enviados e recebidos a cada segundo pela interface de rede.
: Limite recomendado: Menor que 5 Mbytes para uma rede de 100Mbps, menor que 50 Mbytes para uma rede de 1000 Mbps. (Quanto menor melhor).
: Análise: Ocorre picos de envio e recebimento de Kbytes realizados pelo sistema.

:::::: [[Arquivo:2016-07-04_Conpat_InterfaceTotalDeRede.png]]

*'''Tempo médio de resposta das requisições'''
: Descrição: Indica o tempo médio de resposta das requisições.
: Limite recomendado: 5 segundos.
: Análise: A aplicação demonstrou desempenho esperado próximo à 350 usuários, com uma quantidade superior de usuários os servidores ficam sobrecarregados, aumentando significativamente o tempo de resposta.

:::::: [[Arquivo:2016-07-04_Conpat_TempoDeResposta.png]]
::::::: [[Arquivo:2016-07-04_Conpat_TempoDeRespostaLegenda.png]]

*'''Tempo de vazão'''
: Descrição: Indica a quantidade total de request por segundo.
: Limite recomendado: Quanto maior melhor.
: A aplicação demonstrou desempenho esperado até atingir 400 usuários simultâneos.

:::::: [[Arquivo:2016-07-04_Conpat_Vazao.png]]
::::::: [[Arquivo:2016-07-04_Conpat_VazaoLegenda.png]]

*'''Porcentagem de erro'''
: Descrição: Indica a porcentagem de erro.
: Limite recomendado: Quanto menor melhor.
: A aplicação demonstrou grande porcentagem de erro.

:::::: [[Arquivo:2016-07-04_Conpat_PorcentagemErros.png]]

Produtos

2016-07-26T14:58:03Z

Lucimara.maiorali: /* Plataforma de Produtos MSTECH */

Essa página deverá conter um índice de links dos produtos e projetos disponíveis na MSTECH.

Nas páginas dos produtos, pedimos que sejam colocadas todas as informações referentes à ele, como Requisitos do projeto/produto, roadmap futuro de evolução, documentos de arquitetura e implantação, manuais de usuários, clientes que possuem a ferramenta e sua versão e materiais informativos para fins comerciais.

Novamente lembrando, a Wiki é colaborativa então todos podem contribuir com o conteúdo!

* [[Template de documentação]]

== Plataforma de Produtos MSTECH ==
* [[Almoxarifado]]
* [[Aluno Monitor / Office 365]]
* [[Alimentação]]
* [[Approxima]]
* [[Atribuição de Aulas]]
* [[Avalia+]]
* [[Biblioteca]]
* [[Bluemonitor]]
* [[BlueControlWeb]]
* [[BlueControl]]
* [[Classpad]]
* [[Controle Patrimonial]]
* [[CoreSSO]]
* [[Coredu]]
* [[Educopédia]]
* [[Gestão Escolar / SGP]]
* [[Gestão Privado]]
* [[Loomi]]
* [[Moodle]]
* [[OpenId]]
* [[Portal Construtor]]
* [[Transporte Escolar]]
[http://www.example.com título do link]

Verificação de segurança e desempenho

2016-07-26T14:51:46Z

Lucimara.maiorali: /* Resultado da verificação de segurança e desempenho */

O objetivo da '''verificação de segurança e desempenho''' é analisar através dos testes não funcionais dois dos principais requisitos não funcionais que podem afetar de forma drástica a estabilidade e a qualidade das nossas entregas, sendo de extrema importância na obtenção de um diagnóstico cada vez mais preciso nas ações de melhoria contínua e na garantia da qualidade, visando alcançar patamares mais elevados no desenvolvimento dos nossos produtos.

== Pré-requisitos para execução da verificação de segurança e desempenho ==

*Providenciar a publicação do sistema/aplicação, com a última versão estável, em ambiente de teste administrado pelo DevOps;
*Definir o escopo do teste de segurança e desempenho;
*Descrição resumida das funcionalidades do sistema/aplicação, considerar também as funcionalidades mais críticas (que diferenciam e destacam o produto);
*Informação da existência de problemas de segurança e desempenho conhecidos no sistema/aplicação;
*Definir as permissões por nível de usuário para as principais funcionalidades e ativos do sistema(lista de credenciais ativas(usuário e senha)com pelo menos um usuário para cada nível de permissão.

== Verificação de segurança ==

A verificação de segurança consiste identificar vulnerabilidades, classificá-las e indicar estratégias de mitigação para estas. É realizada uma análise ativa na qual são simulados ataques a um determinado sistema, identificando vulnerabilidades que podem ser exploradas em um ataque real.

Uma '''vulnerabilidade''' é uma falha ou fraqueza no design, implementação, operação ou gerenciamento de um sistema que pode ser explorada a fim de violar a política de segurança do mesmo. Uma '''ameaça''' é um ataque em potencial que, explorando uma vulnerabilidade, pode comprometer os ativos de uma aplicação (recursos, dados, funcionalidades).

Esse processo, conhecido como ''"Vulnerability Assessment"'', deve ser executado em uma versão estável do sistema, após a etapa de desenvolvimento. Primeiramente o sistema é submetido a ''scanners'' de vulnerabilidades automáticos. As vulnerabilidades encontradas pelos ''scripts'' automáticos são então verificadas, para eliminar falsos positivos.

Após o processo automático, o sistema é verificado manualmente por vulnerabilidades de detecção mais difícil, seguindo as diretrizes do [https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents OWASP Guide v4]

A verificação de segurança é executada por [mailto:paulo.souza@mstech.com.br Paulo Roberto Lopes de Souza]

=== Ferramentas utilizadas ===

*'''Ferramentas de Proxy web''' (WebScarab,CAT,OWASP ZAP,Paros)
*'''''Scanners'' de vulnerabilidades automatizados''' (WCSA,OWASP ZAP,N-Stalker,Web Securify,Microsoft WACA,W3AF,VEGA)
*'''''Sniffers''''' (Wireshark,Ettercap)
*'''Gerador de pacotes e requisições ''HTTP''''' (Engage Packet Builder,WebScarab,CAT)

== Verificação de desempenho ==

A verificação de desempenho é uma classe de testes implementada e executada para caracterizar o desempenho relacionado a características do sistema/produto, como fluxos de execução, tempos de respostas e limites operacionais. A verificação de desempenho abrange os seguintes tipos de testes:

*'''Teste de carga''': Verifica a aceitabilidade do comportamento de desempenho do objeto de teste em condições operacionais variáveis (como número de usuários, número de transações, entre outros), enquanto as configurações permanecem as mesmas.

*'''Teste de stress:''' Verifica a aceitabilidade do comportamento de desempenho do objeto de teste quando condições anormais ou externas forem encontradas, como a redução dos recursos ou um número extremamente alto de usuários.

*'''Teste de desempenho:''' Testa a aplicação em uma situação normal de uso, verificando se o tempo de resposta e a utilização do hardware são os desejados.

A verificação de desempenho é executada por [mailto:taynara.nakashima@mstech.com.br Taynara Nakashima]

=== Ambiente padrão de teste ===

Para a realização dos testes foi criado um ambiente padrão composto de servidores web e servidor SQL com distribuição de carga pelo ARR. A VM utilizada para simular usuários navegando pelo sistema é denominado Test Agent e o controlador dos agentes denominado Test Controller. Abaixo é apresentada a configuração dos equipamentos que compõe o ambiente gerador de carga para os testes.

{| class="wikitable"
!colspan="6"|Ambiente padrão de teste
|-
|colspan="2"|ARR
|Estão configurados com DFS entre os arquivos de sistema. Cada um tem 4 núcleos, 4GB de RAM e disco de 200GB dinâmico.
|-
|colspan="2"|HOST
|É um Xeon 2.3 Ghz com 48 núcleos de 384GBde RAM.
|-
|colspan="2"|Servidores Web
|Possuem 8 núcleos cada, 6GB de RAM e disco de 100GB dinâmico. O acesso ao site é através de uma pasta compartilhada no servidor hospedeiro, utilizando o parâmetro caspol do .NET 32 e 64 bits v3.5 e 4 com opção fulltrust.
|-
|colspan="2"|Servidor SQL
|O SQL Server está na versão 2014 Standard e o servidor tem 16 GB de RAM, 16 núcleos, 100GB de disco para dados, 1TB de disco para bancos e 500 GB de disco de backup. Os discos de bancos e backup são volumes diretos na storage, utilizando conexão iSCSI.
|-
|colspan="2"|Test Controller
|Possuem 8 núcleos e 8 GB de RAM, com disdo de 200GB para SO.
|-
|colspan="2"|Test Agent
|Os slaves do JMeter possuem 8 núcleos e 8 GB de RAM com disco de 200GB para SO cada.
|-
|}

=== Ferramentas utilizadas ===

*'''Ferramenta de teste''' (JMeter)
*'''Web Debugging Proxy''' (Fiddler)
*'''Resource and Performance Monitor''' (Perfmon) / Em estudo uso do Zabbix

== Resultado da verificação de segurança e desempenho ==

Como resultado da verificação de segurança e desempenho será enviado um relatório aos responsáveis do produto contendo as vulnerabilidades e itens de melhorias que deverão ser inseridas na '''Product Backlog''' e analisadas em conjunto com a equipe e responsáveis pelas verificações. Este resultado também será disponibilizado no menu "Produtos" [[https://wiki.mstech.com.br/index.php/Produtos Plataforma de Produtos MSTECH]].

{| class="wikitable"
!colspan="6"|Produtos verificados
|-
|colspan="2"|Transporte Escolar
|[[Transporte 1.1.1.21|Versão 1.1.1.21]]
|-
|colspan="2"|Controle Patrimonial
|[[Conpat 2.25.2.0|Versão 2.25.2.0]] (Em verificação)
|-
|colspan="2"|Biblioteca
|[[Biblioteca 1.45.0.0|Versão 1.45.0.0]] (Em verificação)
|-
|colspan="2"|Approxima
|
|-
|colspan="2"|Portal Construtor
|
|-
|colspan="2"|Almoxarifado
|[[Almoxarifado 1.1.0.0|Versão 1.1.0.0]] (Em verificação)
|-
|colspan="2"|Atribuição de Aulas
|
|-
|colspan="2"|Avalia+
|
|-
|colspan="2"|Alimentação
|
|-
|colspan="2"|BlueMonitor
|
|-
|colspan="2"|BlueControlWeb
|
|-
|colspan="2"|BlueControl
|
|-
|colspan="2"|Boletim Online
|
|-
|colspan="2"|ClassPad
|
|-
|colspan="2"|Censo Escolar
|
|-
|colspan="2"|Central de Projetos
|
|-
|colspan="2"|CoreSSO
|
|-
|colspan="2"|Coreedu
|
|-
|colspan="2"|Certificados
|
|-
|colspan="2"|Controle de Obras
|
|-
|colspan="2"|Controle Financeiro de Repasses
|
|-
|colspan="2"|Dupla Regência
|
|-
|colspan="2"|Educopédia
|
|-
|colspan="2"|Fiscalização e Contratos
|
|-
|colspan="2"|Fluxos DRH
|
|-
|colspan="2"|Gestão Acadêmica
|
|-
|colspan="2"|Gestão Escolar / SGP
|
|-
|colspan="2"|Gestão Privado
|
|-
|colspan="2"|Gestão de Metas
|
|-
|colspan="2"|Loomi
|
|-
|colspan="2"|Mapa de Indicadores
|
|-
|colspan="2"|Moodle
|
|-
|colspan="2"|OpenId
|
|-
|colspan="2"|Portal Institucional
|
|-
|colspan="2"|Quadro de Horários
|
|-
|colspan="2"|Remoção
|
|-
|colspan="2"|Repositório OA
|
|-
|colspan="2"|Sala de Gestão
|
|}

Produtos

2016-07-26T13:42:44Z

Lucimara.maiorali: /* Plataforma de Produtos MSTECH */

Essa página deverá conter um índice de links dos produtos e projetos disponíveis na MSTECH.

Nas páginas dos produtos, pedimos que sejam colocadas todas as informações referentes à ele, como Requisitos do projeto/produto, roadmap futuro de evolução, documentos de arquitetura e implantação, manuais de usuários, clientes que possuem a ferramenta e sua versão e materiais informativos para fins comerciais.

Novamente lembrando, a Wiki é colaborativa então todos podem contribuir com o conteúdo!

* [[Template de documentação]]

== Plataforma de Produtos MSTECH ==
* [[Almoxarifado]]
* [[Aluno Monitor / Office 365]]
* [[Alimentação]]
* [[Approxima]]
* [[Atribuição de Aulas]]
* [[Avalia+]]
* [[Biblioteca]]
* [[Bluemonitor]]
* [[BlueControlWeb]]
* [[BlueControl]]
* [[Classpad]]
* [[Controle Patrimonial]]
* [[CoreSSO]]
* [[Coredu]]
* [[Educopédia]]
* [[Gestão Escolar / SGP]]
* [[Gestão Privado]]
* [[Loomi]]
* [[OpenId]]
* [[Portal Construtor]]
* [[Transporte Escolar]]
[http://www.example.com título do link]

Verificação de segurança e desempenho

2016-07-26T13:39:22Z

Lucimara.maiorali: /* Resultado da verificação de segurança e desempenho */

O objetivo da '''verificação de segurança e desempenho''' é analisar através dos testes não funcionais dois dos principais requisitos não funcionais que podem afetar de forma drástica a estabilidade e a qualidade das nossas entregas, sendo de extrema importância na obtenção de um diagnóstico cada vez mais preciso nas ações de melhoria contínua e na garantia da qualidade, visando alcançar patamares mais elevados no desenvolvimento dos nossos produtos.

== Pré-requisitos para execução da verificação de segurança e desempenho ==

*Providenciar a publicação do sistema/aplicação, com a última versão estável, em ambiente de teste administrado pelo DevOps;
*Definir o escopo do teste de segurança e desempenho;
*Descrição resumida das funcionalidades do sistema/aplicação, considerar também as funcionalidades mais críticas (que diferenciam e destacam o produto);
*Informação da existência de problemas de segurança e desempenho conhecidos no sistema/aplicação;
*Definir as permissões por nível de usuário para as principais funcionalidades e ativos do sistema(lista de credenciais ativas(usuário e senha)com pelo menos um usuário para cada nível de permissão.

== Verificação de segurança ==

A verificação de segurança consiste identificar vulnerabilidades, classificá-las e indicar estratégias de mitigação para estas. É realizada uma análise ativa na qual são simulados ataques a um determinado sistema, identificando vulnerabilidades que podem ser exploradas em um ataque real.

Uma '''vulnerabilidade''' é uma falha ou fraqueza no design, implementação, operação ou gerenciamento de um sistema que pode ser explorada a fim de violar a política de segurança do mesmo. Uma '''ameaça''' é um ataque em potencial que, explorando uma vulnerabilidade, pode comprometer os ativos de uma aplicação (recursos, dados, funcionalidades).

Esse processo, conhecido como ''"Vulnerability Assessment"'', deve ser executado em uma versão estável do sistema, após a etapa de desenvolvimento. Primeiramente o sistema é submetido a ''scanners'' de vulnerabilidades automáticos. As vulnerabilidades encontradas pelos ''scripts'' automáticos são então verificadas, para eliminar falsos positivos.

Após o processo automático, o sistema é verificado manualmente por vulnerabilidades de detecção mais difícil, seguindo as diretrizes do [https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents OWASP Guide v4]

A verificação de segurança é executada por [mailto:paulo.souza@mstech.com.br Paulo Roberto Lopes de Souza]

=== Ferramentas utilizadas ===

*'''Ferramentas de Proxy web''' (WebScarab,CAT,OWASP ZAP,Paros)
*'''''Scanners'' de vulnerabilidades automatizados''' (WCSA,OWASP ZAP,N-Stalker,Web Securify,Microsoft WACA,W3AF,VEGA)
*'''''Sniffers''''' (Wireshark,Ettercap)
*'''Gerador de pacotes e requisições ''HTTP''''' (Engage Packet Builder,WebScarab,CAT)

== Verificação de desempenho ==

A verificação de desempenho é uma classe de testes implementada e executada para caracterizar o desempenho relacionado a características do sistema/produto, como fluxos de execução, tempos de respostas e limites operacionais. A verificação de desempenho abrange os seguintes tipos de testes:

*'''Teste de carga''': Verifica a aceitabilidade do comportamento de desempenho do objeto de teste em condições operacionais variáveis (como número de usuários, número de transações, entre outros), enquanto as configurações permanecem as mesmas.

*'''Teste de stress:''' Verifica a aceitabilidade do comportamento de desempenho do objeto de teste quando condições anormais ou externas forem encontradas, como a redução dos recursos ou um número extremamente alto de usuários.

*'''Teste de desempenho:''' Testa a aplicação em uma situação normal de uso, verificando se o tempo de resposta e a utilização do hardware são os desejados.

A verificação de desempenho é executada por [mailto:taynara.nakashima@mstech.com.br Taynara Nakashima]

=== Ambiente padrão de teste ===

Para a realização dos testes foi criado um ambiente padrão composto de servidores web e servidor SQL com distribuição de carga pelo ARR. A VM utilizada para simular usuários navegando pelo sistema é denominado Test Agent e o controlador dos agentes denominado Test Controller. Abaixo é apresentada a configuração dos equipamentos que compõe o ambiente gerador de carga para os testes.

{| class="wikitable"
!colspan="6"|Ambiente padrão de teste
|-
|colspan="2"|ARR
|Estão configurados com DFS entre os arquivos de sistema. Cada um tem 4 núcleos, 4GB de RAM e disco de 200GB dinâmico.
|-
|colspan="2"|HOST
|É um Xeon 2.3 Ghz com 48 núcleos de 384GBde RAM.
|-
|colspan="2"|Servidores Web
|Possuem 8 núcleos cada, 6GB de RAM e disco de 100GB dinâmico. O acesso ao site é através de uma pasta compartilhada no servidor hospedeiro, utilizando o parâmetro caspol do .NET 32 e 64 bits v3.5 e 4 com opção fulltrust.
|-
|colspan="2"|Servidor SQL
|O SQL Server está na versão 2014 Standard e o servidor tem 16 GB de RAM, 16 núcleos, 100GB de disco para dados, 1TB de disco para bancos e 500 GB de disco de backup. Os discos de bancos e backup são volumes diretos na storage, utilizando conexão iSCSI.
|-
|colspan="2"|Test Controller
|Possuem 8 núcleos e 8 GB de RAM, com disdo de 200GB para SO.
|-
|colspan="2"|Test Agent
|Os slaves do JMeter possuem 8 núcleos e 8 GB de RAM com disco de 200GB para SO cada.
|-
|}

=== Ferramentas utilizadas ===

*'''Ferramenta de teste''' (JMeter)
*'''Web Debugging Proxy''' (Fiddler)
*'''Resource and Performance Monitor''' (Perfmon) / Em estudo uso do Zabbix

== Resultado da verificação de segurança e desempenho ==

Como resultado da verificação de segurança e desempenho será enviado um relatório aos responsáveis do produto contendo as vulnerabilidades e itens de melhorias que deverão ser inseridas na '''Product Backlog''' e analisadas em conjunto com a equipe e responsáveis pelas verificações. Este resultado também será disponibilizado no menu "Produtos" [[https://wiki.mstech.com.br/index.php/Produtos Plataforma de Produtos MSTECH]].

{| class="wikitable"
!colspan="6"|Produtos verificados
|-
|colspan="2"|Transporte Escolar
|[[Transporte 1.1.1.21|Versão 1.1.1.21]]
|-
|colspan="2"|Controle Patrimonial
|[[Conpat 2.25.2.0|Versão 2.25.2.0]] (Em verificação)
|-
|colspan="2"|Biblioteca
|[[Biblioteca 1.45.0.0|Versão 1.45.0.0]] (Em verificação)
|-
|colspan="2"|Approxima
|
|-
|colspan="2"|Portal Construtor
|
|-
|colspan="2"|Almoxarifado
|[[Almoxarifado 1.1.0.0|Versão 1.1.0.0]] (Em verificação)
|-
|colspan="2"|Atribuição de Aulas
|
|-
|colspan="2"|Avalia+
|
|-
|colspan="2"|Alimentação
|
|-
|colspan="2"|BlueMonitor
|
|-
|colspan="2"|BlueControlWeb
|
|-
|colspan="2"|BlueControl
|
|-
|colspan="2"|Boletim Online
|
|-
|colspan="2"|ClassPad
|
|-
|colspan="2"|Censo Escolar
|
|-
|colspan="2"|Central de Projetos
|
|-
|colspan="2"|CoreSSO
|
|-
|colspan="2"|Coreedu
|
|-
|colspan="2"|Certificados
|
|-
|colspan="2"|Controle de Obras
|
|-
|colspan="2"|Controle Financeiro de Repasses
|
|-
|colspan="2"|Dupla Regência
|
|-
|colspan="2"|Educopédia
|
|-
|colspan="2"|Fiscalização e Contratos
|
|-
|colspan="2"|Fluxos DRH
|
|-
|colspan="2"|Gestão Acadêmica
|
|-
|colspan="2"|Gestão Escolar / SGP
|
|-
|colspan="2"|Gestão Privado
|
|-
|colspan="2"|Gestão de Metas
|
|-
|colspan="2"|Loomi
|
|-
|colspan="2"|Mapa de Indicadores
|
|-
|colspan="2"|OpenId
|
|-
|colspan="2"|Portal Institucional
|
|-
|colspan="2"|Quadro de Horários
|
|-
|colspan="2"|Remoção
|
|-
|colspan="2"|Repositório OA
|
|-
|colspan="2"|Sala de Gestão
|
|}

Transporte 1.1.1.21

2016-07-01T17:35:27Z

Lucimara.maiorali: /* Resultados dos Testes */

== Sistemas Verificados ==

*Transporte Escolar, versão 1.1.1.21
*Transporte Escolar Api, versão 1.0.0.0

== Verificação de Segurança ==

=== Testes Realizados ===

{| class="wikitable"
!Item de Teste
!Referência OWASP
!Resultado
|-
|Review Webpage Comments and Metadata for Information Leakage
|[https://www.owasp.org/index.php/Review_webpage_comments_and_metadata_for_information_leakage_(OTG-INFO-005) OTG-INFO-005]
|OK
|-
|Test Application Platform Configuration
|[https://www.owasp.org/index.php/Test_Application_Platform_Configuration_(OTG-CONFIG-002) OTG-CONFIG-002]
|NA
|-
|Test File Extensions Handling for Sensitive Information
|[https://www.owasp.org/index.php/Test_File_Extensions_Handling_for_Sensitive_Information_(OTG-CONFIG-003) OTG-CONFIG-003]
|OK
|-
|Review Old, Backup and Unreferenced Files for Sensitive Information
|[https://www.owasp.org/index.php/Review_Old,_Backup_and_Unreferenced_Files_for_Sensitive_Information_(OTG-CONFIG-004) OTG-CONFIG-004]
|F
|-
|Test HTTP Methods
|[https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006) OTG-CONFIG-006]
|NA
|-
|Test HTTP Strict Transport Security
|[https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007) OTG-CONFIG-007]
|F
|-
|Test RIA cross domain policy
|[https://www.owasp.org/index.php/Test_RIA_cross_domain_policy_(OTG-CONFIG-008) OTG-CONFIG-008]
|NA
|-
|Test Role Definitions
|[https://www.owasp.org/index.php/Test_Role_Definitions_(OTG-IDENT-001) OTG-IDENT-001]
|NA
|-
|Test User Registration Process
|[https://www.owasp.org/index.php/Test_User_Registration_Process_(OTG-IDENT-002) OTG-IDENT-002]
|NA
|-
|Test Account Provisioning Process
|[https://www.owasp.org/index.php/Test_Account_Provisioning_Process_(OTG-IDENT-003) OTG-IDENT-003]
|NA
|-
|Testing for Account Enumeration and Guessable User Account
|[https://www.owasp.org/index.php/Testing_for_Account_Enumeration_and_Guessable_User_Account_(OTG-IDENT-004) OTG-IDENT-004]
|OK
|-
|Testing for Credentials Transported over an Encrypted Channel
|[https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001) OTG-AUTHN-001]
|F
|-
|Testing for default credentials
|[https://www.owasp.org/index.php/Testing_for_default_credentials_(OTG-AUTHN-002) OTG-AUTHN-002]
|OK
|-
|Testing for Weak lock out mechanism
|[https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) OTG-AUTHN-003]
|NA
|-
|Testing for Bypassing Authentication Schema
|[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) OTG-AUTHN-004]
|OK
|-
|Testing for Vulnerable Remember Password
|[https://www.owasp.org/index.php/Testing_for_Vulnerable_Remember_Password_(OTG-AUTHN-005) OTG-AUTHN-005]
|NA
|-
|Testing for Browser cache weakness
|[https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OTG-AUTHN-006) OTG-AUTHN-006]
|OK
|-
|Testing for Weak password policy
|[https://www.owasp.org/index.php?title=Testing_for_Weak_password_policy_(OTG-AUTHN-007)&setlang=en OTG-AUTHN-007]
|NA
|-
|Testing for weak password change or reset functionalities
|[https://www.owasp.org/index.php/Testing_for_weak_password_change_or_reset_functionalities_(OTG-AUTHN-009) OTG-AUTHN-009]
|NA
|-
|Testing for Weaker authentication in alternative channel
|[https://www.owasp.org/index.php/Testing_for_Weaker_authentication_in_alternative_channel_(OTG-AUTHN-010) OTG-AUTHN-010]
|NA
|-
|Testing Directory traversal/file include
|[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) OTG-AUTHZ-001]
|OK
|-
|Testing for Bypassing Authorization Schema
|[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) OTG-AUTHZ-002]
|F
|-
|Testing for Privilege escalation
|[https://www.owasp.org/index.php?title=Testing_for_Privilege_escalation_(OTG-AUTHZ-003)&setlang=en OTG-AUTHZ-003]
|OK
|-
|Testing for Insecure Direct Object References
|[https://www.owasp.org/index.php?title=Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)&setlang=en OTG-AUTHZ-004]
|F
|-
|Testing for Session Management Schema
|[https://www.owasp.org/index.php/Testing_for_Session_Management_Schema_(OTG-SESS-001) OTG-SESS-001]
|F
|-
|Testing for cookies attributes
|[https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002) OTG-SESS-002]
|OK
|-
|Testing for Session Fixation
|[https://www.owasp.org/index.php/Testing_for_Session_Fixation_(OTG-SESS-003) OTG-SESS-003]
|OK
|-
|Testing for Exposed Session Variables
|[https://www.owasp.org/index.php/Testing_for_Exposed_Session_Variables_(OTG-SESS-004) OTG-SESS-004]
|OK
|-
|Testing for CSRF
|[https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005) OTG-SESS-005]
|F
|-
|Testing for logout functionality
|[https://www.owasp.org/index.php/Testing_for_logout_functionality_(OTG-SESS-006) OTG-SESS-006]
|F
|-
|Testing for Session Timeout
|[https://www.owasp.org/index.php?title=Test_Session_Timeout_(OTG-SESS-007)&setlang=en OTG-SESS-007]
|OK
|-
|Testing for Session puzzling
|[https://www.owasp.org/index.php/Testing_for_Session_puzzling_(OTG-SESS-008) OTG-SESS-008]
|OK
|-
|Testing for Reflected Cross site scripting
|[https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001) OTG-INPVAL-001]
|OK
|-
|Testing for Stored Cross site scripting
|[https://www.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002) OTG-INPVAL-002]
|OK
|-
|Testing for HTTP Verb Tampering
|[https://www.owasp.org/index.php?title=Testing_for_HTTP_Verb_Tampering_(OTG-INPVAL-003)&setlang=en OTG-INPVAL-003]
|NA
|-
|Testing for HTTP Parameter pollution
|[https://www.owasp.org/index.php/Testing_for_HTTP_Parameter_pollution_(OTG-INPVAL-004) OTG-INPVAL-004]
|OK
|-
|Testing for SQL Injection
|[https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) OTG-INPVAL-005]
|OK
|-
|Testing for LDAP Injection
|[https://www.owasp.org/index.php/Testing_for_LDAP_Injection_(OTG-INPVAL-006) OTG-INPVAL-006]
|NA
|-
|Testing for XML Injection
|[https://www.owasp.org/index.php?title=Testing_for_XML_Injection_(OTG-INPVAL-008)&setlang=en OTG-INPVAL-008]
|NA
|-
|Testing for SSI Injection
|[https://www.owasp.org/index.php?title=Testing_for_SSI_Injection_(OTG-INPVAL-009)&setlang=en OTG-INPVAL-009]
|NA
|-
|Testing for XPath Injection
|[https://www.owasp.org/index.php?title=Testing_for_XPath_Injection_(OTG-INPVAL-010)&setlang=en OTG-INPVAL-010]
|NA
|-
|Testing for IMAP/SMTP Injection
|[https://www.owasp.org/index.php/Testing_for_IMAP/SMTP_Injection_(OTG-INPVAL-011) OTG-INPVAL-011]
|NA
|-
|Testing for Code Injection
|[https://www.owasp.org/index.php?title=Testing_for_Code_Injection_(OTG-INPVAL-012)&setlang=en OTG-INPVAL-012]
|OK
|-
|Testing for Command Injection
|[https://www.owasp.org/index.php?title=Testing_for_Command_Injection_(OTG-INPVAL-013)&setlang=en OTG-INPVAL-013]
|OK
|-
|Testing for Buffer Overflow
|[https://www.owasp.org/index.php/Testing_for_Buffer_Overflow_(OTG-INPVAL-014) OTG-INPVAL-014]
|NA
|-
|Testing for Incubated Vulnerability
|[https://www.owasp.org/index.php?title=Testing_for_Incubated_Vulnerability_(OTG-INPVAL-015)&setlang=en OTG-INPVAL-015]
|OK
|-
|Testing for HTTP Splitting/Smuggling
|[https://www.owasp.org/index.php?title=Testing_for_HTTP_Splitting/Smuggling_(OTG-INPVAL-016)&setlang=en OTG-INPVAL-016]
|OK
|-
|Testing for Information Disclosure
|[https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) OTG-ERR-001], [https://www.owasp.org/index.php/Testing_for_Stack_Traces_(OTG-ERR-002) OTG-ERR-002]
|OK
|-
|Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection
|[https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001) OTG-CRYPST-001]
|NA
|-
|Testing for Padding Oracle
|[https://www.owasp.org/index.php?title=Testing_for_Padding_Oracle_(OTG-CRYPST-002)&setlang=en OTG-CRYPST-002]
|NA
|-
|Testing for Sensitive information sent via unencrypted channels
|[https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)&setlang=en OTG-CRYPST-003]
|NA
|-
|Tests of business logic
|[https://www.owasp.org/index.php/Testing_for_business_logic OTG-BUSLOGIC-001..009]
|OK
|-
|Testing for DOM-based Cross site scripting
|[https://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_(OTG-CLIENT-001) OTG-CLIENT-001]
|OK
|-
|Testing for JavaScript Execution
|[https://www.owasp.org/index.php/Testing_for_JavaScript_Execution_(OTG-CLIENT-002) OTG-CLIENT-002]
|OK
|-
|Testing for HTML Injection
|[https://www.owasp.org/index.php/Testing_for_HTML_Injection_(OTG-CLIENT-003) OTG-CLIENT-003]
|OK
|-
|Testing for Client Side URL Redirect
|[https://www.owasp.org/index.php/Testing_for_Client_Side_URL_Redirect_(OTG-CLIENT-004) OTG-CLIENT-004]
|F
|-
|Testing for CSS Injection
|[https://www.owasp.org/index.php/Testing_for_CSS_Injection_(OTG-CLIENT-005) OTG-CLIENT-005]
|OK
|-
|Testing for Client Side Resource Manipulation
|[https://www.owasp.org/index.php/Testing_for_Client_Side_Resource_Manipulation_(OTG-CLIENT-006) OTG-CLIENT-006]
|OK
|-
|Test Cross Origin Resource Sharing
|[https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007) OTG-CLIENT-007]
|OK
|-
|Testing for Cross site flashing
|[https://www.owasp.org/index.php?title=Testing_for_Cross_site_flashing_(OTG-CLIENT-008)&setlang=en OTG-CLIENT-008]
|OK
|-
|Testing for Clickjacking
|[https://www.owasp.org/index.php/Testing_for_Clickjacking_(OTG-CLIENT-009) OTG-CLIENT-009]
|OK
|-
|Testing WebSockets
|[https://www.owasp.org/index.php?title=Testing_WebSockets_(OTG-CLIENT-010)&setlang=en OTG-CLIENT-010]
|NA
|-
|Test Web Messaging
|[https://www.owasp.org/index.php?title=Test_Web_Messaging_(OTG-CLIENT-011)&setlang=en OTG-CLIENT-011]
|NA
|-
|Test Local Storage
|[https://www.owasp.org/index.php?title=Test_Local_Storage_(OTG-CLIENT-012)&setlang=en OTG-CLIENT-012]
|NA
|}

:OK (Nenhum problema encontrado); F (Teste falhou, verificar os resultados); NA (Teste não aplicado)


=== Resultados dos Testes ===

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-AUTHZ-002, OTG-AUTHZ-004
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|O handler "fileHandler.ashx" não possui controle de acesso, podendo ser acessado diretamente por um usuário não autenticado. Assim ele permite o download de qualquer arquivo disponível através do seu id, que é um número sequencial e portanto de fácil previsão.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.3_Controle_de_acesso|"3.3 Controle de acesso"]], [[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.9_Arquivos_e_recursos|"3.9 Arquivos e recursos"]]
|-
|'''Sugestões'''
|
*Implementar um controle de acesso para o fileHandler e para os arquivos em si, de forma que apenas os usuários com a devida permissão consigam realizar o download dos arquivos.
*Utilizar identificadores aleatórios e não previsíveis para dificultar o acesso aos arquivos diretamente.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-CONFIG-007, OTG-AUTHN-001
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|As informações enviados para e pelo sistema não são criptografadas, susceptíveis a interceptações e alterações entre o cliente e o servidor.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.8_Seguran.C3.A7a_nas_comunica.C3.A7.C3.B5es|"3.8 Segurança nas comunicações"]]
|-
|'''Sugestões'''
|
*Implementar o protocolo TLS seguindo as orientações de boas práticas.
*Utilizar em ambientes de produção certificados gerados por autoridades certificadores confiáveis. Em ambientes de teste e homologação podem ser utilizados certificados auto-assinados.
|-
|'''Referências'''
|
*https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-CONFIG-004
|-
|'''Severidade'''
|Baixa
|-
|'''Descrição'''
|O diretório do site no servidor possui arquivos de código fonte (.cs).
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.7_Prote.C3.A7.C3.A3o_de_dados|"3.7 Proteção de dados"]]
|-
|'''Sugestões'''
|
*Em produção, deve-se procurar manter apenas os arquivos compilados e necessários para o funcionamento do sistema.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-AUTHZ-002
|-
|'''Severidade'''
|Baixa
|-
|'''Descrição'''
|A api do sistema e o WS "SvcTransporteEscolar" não possuem controle de acesso, podendo ser acessados diretamente por um usuário não autenticado.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.11_Web_Services_e_API.C2.B4s|"3.11 Web Services e API´s"]]
|-
|'''Sugestões'''
|
*Implementar mecanismos de autenticação e autorização para as APIs e Webservices.
|-
|'''Referências'''
|
*http://www.asp.net/web-api/overview/security/authentication-andauthorization-in-aspnet-web-api
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-SESS-005
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|O sistema não implementa um mecanismo anti-CSRF, e permite que as páginas sejam renderizadas a partir de outros domínios (em um frame, iframe ou object).
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.12.1_Configura.C3.A7.C3.B5es_para_servidor_web|"3.12.1 Configurações para servidor web"]], [[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.4_Gerenciamento_de_sess.C3.A3o|"3.4 Gerenciamento de sessão"]]
|-
|'''Sugestões'''
|
*Implementar um token anti-CSRF para prevenir ataques desse tipo.
*Verificar os cabeçalhos "Origin" e/ou "Referer" para identificar a origem do request.
*Setar o cabeçalho "X-Frame-Options" para "sameorigin" ou "deny".
|-
|'''Referências'''
|
*https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
*https://www.owasp.org/index.php/Anti_CSRF_Tokens_ASP.NET
*https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-SESS-001, OTG-SESS-006
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|Ao realizar o logout o cookie de autenticação não é invalidado no servidor, apenas excluido no lado cliente. Assim, forçando o navegador a utilizar o valor antigo do cookie o usuário consegue novamente acesso ao sistema sem realizar o login.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.4_Gerenciamento_de_sess.C3.A3o|"3.4 Gerenciamento de sessão"]]
|-
|'''Sugestões'''
|
*Invalidar o cookie de autenticação no lado servidor quando o usuário realiza o logout.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-SESS-001
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|Ao realizar a primeira requisição para o sistema o usuário recebe um cookie de sessão, e assim que realiza o login com sucesso ele recebe um cookie de autenticação. No entanto o sistema não faz a validação de ambos os cookies, podendo o usuário depois de autenticado continuar navegando apenas com o cookie de sessão ou de autenticação (nesse caso recebendo uma nova sessão).
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.4_Gerenciamento_de_sess.C3.A3o|"3.4 Gerenciamento de sessão"]]
|-
|'''Sugestões'''
|
*Sempre verificar no lado servidor a validade de ambos os cookies, e caso algum cookie esteja ausente ou alterado realizar o logout da sessão do usuário, invalidando ambos os cookies.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-CLIENT-004
|-
|'''Severidade'''
|Baixa
|-
|'''Descrição'''
|O sistema faz o redirecionamento do usuário para outros domínios quando o parâmentro "relaystate" da página "Login.ashx" é alterado para uma url qualquer.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.1_Valida.C3.A7.C3.A3o_dos_dados|"3.1 Validação dos dados"]]
|-
|'''Sugestões'''
|
*Fazer a validação do valor do relaystate antes de redirecionar o usuário, para previnir o redirecionamento para outros domínios no caso da requisição ter sido alterada ou forjada.
|-
|'''Referências'''
|
|}

{| class="wikitable"
|colspan="2" style="text-align: center; | '''Índices''' || '''Resultados'''
|-
|colspan="2"|Número de itens testes|| style="text-align: center; | 64
|-
|colspan="2"|Número de itens verificados|| style="text-align: center; |40
|-
|colspan="2"|Número de itens (NA)|| style="text-align: center; |24
|-
|colspan="2"|Número de itens (OK)|| style="text-align: center; |31
|-
|colspan="2"|Número de itens (F)|| style="text-align: center; |9
|-
|colspan="2"|Índice de aderência|| style="text-align: center; |78%
|}

== Verificação de Desempenho ==

=== Observações sobre o teste ===
O CoreSSO utilizado inicialmente para os testes foi o indicado pela equipe do Transportes, copiado do TS-IIS02 e TS-BD. Contudo, o CoreSSO, apresentou problemas, dentre eles o não cadastro da tabela de layout padrão, gerando diversos erros. Desta forma, substituímos o banco e o site por outra versão indicada pela equipe do CoreSSO na época.

Vale ressaltar que o sistema conforme indicação da equipe do Transportes suportaria, em seu limite, o acesso simultâneo de 200 usuários com uma alta taxa de erro no momento de acesso ao sistema Transporte Escolar, tornando necessário a verificação e ajuste do SAML.

=== Cenário de uso ===

{| class="wikitable"
!colspan="6"|Cenário de uso #1
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|1 - Acessar tela de login || style="text-align: center; | 3
|-
|colspan="2"|1 - Realizar login || style="text-align: center; |7
|-
|colspan="2"|1 - Selecionar sistema Transporte Escolar || style="text-align: center; |5
|-
|colspan="2"|2 - Acessar tela de consulta de veículos || style="text-align: center; |5
|-
|colspan="2"|2 - Preencher aba "Documentação" || style="text-align: center; |20
|-
|colspan="2"|2 - Preencher aba "Aquisição" || style="text-align: center; |7
|-
|colspan="2"|2 - Preencher aba "Condutor" || style="text-align: center; |38
|-
|colspan="2"|2 - Preencher aba "Peças e acessórios" || style="text-align: center; |25
|-
|colspan="2"|2 - Preencher aba "Despesas" || style="text-align: center; |15
|-
|colspan="2"|2 - Salvar cadastro || style="text-align: center; |5
|-
|colspan="2"|3 - Logout || style="text-align: center; |5
|}

=== Resultado dos testes ===
Nesta seção serão apresentados os resultados obtidos da execução dos testes.

*'''Porcentagem de tempo do processador'''
: Descrição: Mede a saturação do processador e mostra a quantidade de tempo despendida para processar as threads por todas as CPUs.
: Limite recomendado: Abaixo de 75 %.

:::::: [[Arquivo:2016-06-21 TransporteEscolar TempoDeProcessador.png]]

*'''Porcentagem de memória utilizada'''
: Descrição: Indica a porcentagem de memória utilizada para uso dos processos.
: Limite recomendado: Abaixo de 75 %.

:::::: [[Arquivo:2016-06-21_TransporteEscolar_MemoriaUtilizada.png]]

*'''Kbytes totais pela interface de rede'''
: Descrição: Indica quantos Bbytes foram enviados e recebidos a cada segundo pela interface de rede.
: Limite recomendado: Menor que 5 Mbytes para uma rede de 100Mbps, menor que 50 Mbytes para uma rede de 1000 Mbps. (Quanto menor melhor)

:::::: [[Arquivo:2016-06-21_TransporteEscolar_NetworkTotal.png]]

*'''Tempo médio de resposta das requisições'''
: Descrição: Indica o tempo médio de resposta das requisições.
: Limite recomendado: 5 segundos.

:::::: [[Arquivo:2016-06-21_TransporteEscolar_ResponseTime.png]]

*'''Tempo de vazão'''
: Descrição: Indica a quantidade total de request por segundo.
: Limite recomendado: Quanto maior melhor.

:::::: [[Arquivo:2016-06-22 13-37-47.png]]

Transporte 1.1.1.21

2016-07-01T17:32:38Z

Lucimara.maiorali: /* Resultados dos Testes */

== Sistemas Verificados ==

*Transporte Escolar, versão 1.1.1.21
*Transporte Escolar Api, versão 1.0.0.0

== Verificação de Segurança ==

=== Testes Realizados ===

{| class="wikitable"
!Item de Teste
!Referência OWASP
!Resultado
|-
|Review Webpage Comments and Metadata for Information Leakage
|[https://www.owasp.org/index.php/Review_webpage_comments_and_metadata_for_information_leakage_(OTG-INFO-005) OTG-INFO-005]
|OK
|-
|Test Application Platform Configuration
|[https://www.owasp.org/index.php/Test_Application_Platform_Configuration_(OTG-CONFIG-002) OTG-CONFIG-002]
|NA
|-
|Test File Extensions Handling for Sensitive Information
|[https://www.owasp.org/index.php/Test_File_Extensions_Handling_for_Sensitive_Information_(OTG-CONFIG-003) OTG-CONFIG-003]
|OK
|-
|Review Old, Backup and Unreferenced Files for Sensitive Information
|[https://www.owasp.org/index.php/Review_Old,_Backup_and_Unreferenced_Files_for_Sensitive_Information_(OTG-CONFIG-004) OTG-CONFIG-004]
|F
|-
|Test HTTP Methods
|[https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006) OTG-CONFIG-006]
|NA
|-
|Test HTTP Strict Transport Security
|[https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007) OTG-CONFIG-007]
|F
|-
|Test RIA cross domain policy
|[https://www.owasp.org/index.php/Test_RIA_cross_domain_policy_(OTG-CONFIG-008) OTG-CONFIG-008]
|NA
|-
|Test Role Definitions
|[https://www.owasp.org/index.php/Test_Role_Definitions_(OTG-IDENT-001) OTG-IDENT-001]
|NA
|-
|Test User Registration Process
|[https://www.owasp.org/index.php/Test_User_Registration_Process_(OTG-IDENT-002) OTG-IDENT-002]
|NA
|-
|Test Account Provisioning Process
|[https://www.owasp.org/index.php/Test_Account_Provisioning_Process_(OTG-IDENT-003) OTG-IDENT-003]
|NA
|-
|Testing for Account Enumeration and Guessable User Account
|[https://www.owasp.org/index.php/Testing_for_Account_Enumeration_and_Guessable_User_Account_(OTG-IDENT-004) OTG-IDENT-004]
|OK
|-
|Testing for Credentials Transported over an Encrypted Channel
|[https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001) OTG-AUTHN-001]
|F
|-
|Testing for default credentials
|[https://www.owasp.org/index.php/Testing_for_default_credentials_(OTG-AUTHN-002) OTG-AUTHN-002]
|OK
|-
|Testing for Weak lock out mechanism
|[https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) OTG-AUTHN-003]
|NA
|-
|Testing for Bypassing Authentication Schema
|[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) OTG-AUTHN-004]
|OK
|-
|Testing for Vulnerable Remember Password
|[https://www.owasp.org/index.php/Testing_for_Vulnerable_Remember_Password_(OTG-AUTHN-005) OTG-AUTHN-005]
|NA
|-
|Testing for Browser cache weakness
|[https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OTG-AUTHN-006) OTG-AUTHN-006]
|OK
|-
|Testing for Weak password policy
|[https://www.owasp.org/index.php?title=Testing_for_Weak_password_policy_(OTG-AUTHN-007)&setlang=en OTG-AUTHN-007]
|NA
|-
|Testing for weak password change or reset functionalities
|[https://www.owasp.org/index.php/Testing_for_weak_password_change_or_reset_functionalities_(OTG-AUTHN-009) OTG-AUTHN-009]
|NA
|-
|Testing for Weaker authentication in alternative channel
|[https://www.owasp.org/index.php/Testing_for_Weaker_authentication_in_alternative_channel_(OTG-AUTHN-010) OTG-AUTHN-010]
|NA
|-
|Testing Directory traversal/file include
|[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) OTG-AUTHZ-001]
|OK
|-
|Testing for Bypassing Authorization Schema
|[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) OTG-AUTHZ-002]
|F
|-
|Testing for Privilege escalation
|[https://www.owasp.org/index.php?title=Testing_for_Privilege_escalation_(OTG-AUTHZ-003)&setlang=en OTG-AUTHZ-003]
|OK
|-
|Testing for Insecure Direct Object References
|[https://www.owasp.org/index.php?title=Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)&setlang=en OTG-AUTHZ-004]
|F
|-
|Testing for Session Management Schema
|[https://www.owasp.org/index.php/Testing_for_Session_Management_Schema_(OTG-SESS-001) OTG-SESS-001]
|F
|-
|Testing for cookies attributes
|[https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002) OTG-SESS-002]
|OK
|-
|Testing for Session Fixation
|[https://www.owasp.org/index.php/Testing_for_Session_Fixation_(OTG-SESS-003) OTG-SESS-003]
|OK
|-
|Testing for Exposed Session Variables
|[https://www.owasp.org/index.php/Testing_for_Exposed_Session_Variables_(OTG-SESS-004) OTG-SESS-004]
|OK
|-
|Testing for CSRF
|[https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005) OTG-SESS-005]
|F
|-
|Testing for logout functionality
|[https://www.owasp.org/index.php/Testing_for_logout_functionality_(OTG-SESS-006) OTG-SESS-006]
|F
|-
|Testing for Session Timeout
|[https://www.owasp.org/index.php?title=Test_Session_Timeout_(OTG-SESS-007)&setlang=en OTG-SESS-007]
|OK
|-
|Testing for Session puzzling
|[https://www.owasp.org/index.php/Testing_for_Session_puzzling_(OTG-SESS-008) OTG-SESS-008]
|OK
|-
|Testing for Reflected Cross site scripting
|[https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001) OTG-INPVAL-001]
|OK
|-
|Testing for Stored Cross site scripting
|[https://www.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002) OTG-INPVAL-002]
|OK
|-
|Testing for HTTP Verb Tampering
|[https://www.owasp.org/index.php?title=Testing_for_HTTP_Verb_Tampering_(OTG-INPVAL-003)&setlang=en OTG-INPVAL-003]
|NA
|-
|Testing for HTTP Parameter pollution
|[https://www.owasp.org/index.php/Testing_for_HTTP_Parameter_pollution_(OTG-INPVAL-004) OTG-INPVAL-004]
|OK
|-
|Testing for SQL Injection
|[https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) OTG-INPVAL-005]
|OK
|-
|Testing for LDAP Injection
|[https://www.owasp.org/index.php/Testing_for_LDAP_Injection_(OTG-INPVAL-006) OTG-INPVAL-006]
|NA
|-
|Testing for XML Injection
|[https://www.owasp.org/index.php?title=Testing_for_XML_Injection_(OTG-INPVAL-008)&setlang=en OTG-INPVAL-008]
|NA
|-
|Testing for SSI Injection
|[https://www.owasp.org/index.php?title=Testing_for_SSI_Injection_(OTG-INPVAL-009)&setlang=en OTG-INPVAL-009]
|NA
|-
|Testing for XPath Injection
|[https://www.owasp.org/index.php?title=Testing_for_XPath_Injection_(OTG-INPVAL-010)&setlang=en OTG-INPVAL-010]
|NA
|-
|Testing for IMAP/SMTP Injection
|[https://www.owasp.org/index.php/Testing_for_IMAP/SMTP_Injection_(OTG-INPVAL-011) OTG-INPVAL-011]
|NA
|-
|Testing for Code Injection
|[https://www.owasp.org/index.php?title=Testing_for_Code_Injection_(OTG-INPVAL-012)&setlang=en OTG-INPVAL-012]
|OK
|-
|Testing for Command Injection
|[https://www.owasp.org/index.php?title=Testing_for_Command_Injection_(OTG-INPVAL-013)&setlang=en OTG-INPVAL-013]
|OK
|-
|Testing for Buffer Overflow
|[https://www.owasp.org/index.php/Testing_for_Buffer_Overflow_(OTG-INPVAL-014) OTG-INPVAL-014]
|NA
|-
|Testing for Incubated Vulnerability
|[https://www.owasp.org/index.php?title=Testing_for_Incubated_Vulnerability_(OTG-INPVAL-015)&setlang=en OTG-INPVAL-015]
|OK
|-
|Testing for HTTP Splitting/Smuggling
|[https://www.owasp.org/index.php?title=Testing_for_HTTP_Splitting/Smuggling_(OTG-INPVAL-016)&setlang=en OTG-INPVAL-016]
|OK
|-
|Testing for Information Disclosure
|[https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) OTG-ERR-001], [https://www.owasp.org/index.php/Testing_for_Stack_Traces_(OTG-ERR-002) OTG-ERR-002]
|OK
|-
|Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection
|[https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001) OTG-CRYPST-001]
|NA
|-
|Testing for Padding Oracle
|[https://www.owasp.org/index.php?title=Testing_for_Padding_Oracle_(OTG-CRYPST-002)&setlang=en OTG-CRYPST-002]
|NA
|-
|Testing for Sensitive information sent via unencrypted channels
|[https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)&setlang=en OTG-CRYPST-003]
|NA
|-
|Tests of business logic
|[https://www.owasp.org/index.php/Testing_for_business_logic OTG-BUSLOGIC-001..009]
|OK
|-
|Testing for DOM-based Cross site scripting
|[https://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_(OTG-CLIENT-001) OTG-CLIENT-001]
|OK
|-
|Testing for JavaScript Execution
|[https://www.owasp.org/index.php/Testing_for_JavaScript_Execution_(OTG-CLIENT-002) OTG-CLIENT-002]
|OK
|-
|Testing for HTML Injection
|[https://www.owasp.org/index.php/Testing_for_HTML_Injection_(OTG-CLIENT-003) OTG-CLIENT-003]
|OK
|-
|Testing for Client Side URL Redirect
|[https://www.owasp.org/index.php/Testing_for_Client_Side_URL_Redirect_(OTG-CLIENT-004) OTG-CLIENT-004]
|F
|-
|Testing for CSS Injection
|[https://www.owasp.org/index.php/Testing_for_CSS_Injection_(OTG-CLIENT-005) OTG-CLIENT-005]
|OK
|-
|Testing for Client Side Resource Manipulation
|[https://www.owasp.org/index.php/Testing_for_Client_Side_Resource_Manipulation_(OTG-CLIENT-006) OTG-CLIENT-006]
|OK
|-
|Test Cross Origin Resource Sharing
|[https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007) OTG-CLIENT-007]
|OK
|-
|Testing for Cross site flashing
|[https://www.owasp.org/index.php?title=Testing_for_Cross_site_flashing_(OTG-CLIENT-008)&setlang=en OTG-CLIENT-008]
|OK
|-
|Testing for Clickjacking
|[https://www.owasp.org/index.php/Testing_for_Clickjacking_(OTG-CLIENT-009) OTG-CLIENT-009]
|OK
|-
|Testing WebSockets
|[https://www.owasp.org/index.php?title=Testing_WebSockets_(OTG-CLIENT-010)&setlang=en OTG-CLIENT-010]
|NA
|-
|Test Web Messaging
|[https://www.owasp.org/index.php?title=Test_Web_Messaging_(OTG-CLIENT-011)&setlang=en OTG-CLIENT-011]
|NA
|-
|Test Local Storage
|[https://www.owasp.org/index.php?title=Test_Local_Storage_(OTG-CLIENT-012)&setlang=en OTG-CLIENT-012]
|NA
|}

:OK (Nenhum problema encontrado); F (Teste falhou, verificar os resultados); NA (Teste não aplicado)


=== Resultados dos Testes ===

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-AUTHZ-002, OTG-AUTHZ-004
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|O handler "fileHandler.ashx" não possui controle de acesso, podendo ser acessado diretamente por um usuário não autenticado. Assim ele permite o download de qualquer arquivo disponível através do seu id, que é um número sequencial e portanto de fácil previsão.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.3_Controle_de_acesso|"3.3 Controle de acesso"]], [[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.9_Arquivos_e_recursos|"3.9 Arquivos e recursos"]]
|-
|'''Sugestões'''
|
*Implementar um controle de acesso para o fileHandler e para os arquivos em si, de forma que apenas os usuários com a devida permissão consigam realizar o download dos arquivos.
*Utilizar identificadores aleatórios e não previsíveis para dificultar o acesso aos arquivos diretamente.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-CONFIG-007, OTG-AUTHN-001
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|As informações enviados para e pelo sistema não são criptografadas, susceptíveis a interceptações e alterações entre o cliente e o servidor.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.8_Seguran.C3.A7a_nas_comunica.C3.A7.C3.B5es|"3.8 Segurança nas comunicações"]]
|-
|'''Sugestões'''
|
*Implementar o protocolo TLS seguindo as orientações de boas práticas.
*Utilizar em ambientes de produção certificados gerados por autoridades certificadores confiáveis. Em ambientes de teste e homologação podem ser utilizados certificados auto-assinados.
|-
|'''Referências'''
|
*https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-CONFIG-004
|-
|'''Severidade'''
|Baixa
|-
|'''Descrição'''
|O diretório do site no servidor possui arquivos de código fonte (.cs).
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.7_Prote.C3.A7.C3.A3o_de_dados|"3.7 Proteção de dados"]]
|-
|'''Sugestões'''
|
*Em produção, deve-se procurar manter apenas os arquivos compilados e necessários para o funcionamento do sistema.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-AUTHZ-002
|-
|'''Severidade'''
|Baixa
|-
|'''Descrição'''
|A api do sistema e o WS "SvcTransporteEscolar" não possuem controle de acesso, podendo ser acessados diretamente por um usuário não autenticado.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.11_Web_Services_e_API.C2.B4s|"3.11 Web Services e API´s"]]
|-
|'''Sugestões'''
|
*Implementar mecanismos de autenticação e autorização para as APIs e Webservices.
|-
|'''Referências'''
|
*http://www.asp.net/web-api/overview/security/authentication-andauthorization-in-aspnet-web-api
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-SESS-005
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|O sistema não implementa um mecanismo anti-CSRF, e permite que as páginas sejam renderizadas a partir de outros domínios (em um frame, iframe ou object).
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.12.1_Configura.C3.A7.C3.B5es_para_servidor_web|"3.12.1 Configurações para servidor web"]], [[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.4_Gerenciamento_de_sess.C3.A3o|"3.4 Gerenciamento de sessão"]]
|-
|'''Sugestões'''
|
*Implementar um token anti-CSRF para prevenir ataques desse tipo.
*Verificar os cabeçalhos "Origin" e/ou "Referer" para identificar a origem do request.
*Setar o cabeçalho "X-Frame-Options" para "sameorigin" ou "deny".
|-
|'''Referências'''
|
*https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
*https://www.owasp.org/index.php/Anti_CSRF_Tokens_ASP.NET
*https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-SESS-001, OTG-SESS-006
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|Ao realizar o logout o cookie de autenticação não é invalidado no servidor, apenas excluido no lado cliente. Assim, forçando o navegador a utilizar o valor antigo do cookie o usuário consegue novamente acesso ao sistema sem realizar o login.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.4_Gerenciamento_de_sess.C3.A3o|"3.4 Gerenciamento de sessão"]]
|-
|'''Sugestões'''
|
*Invalidar o cookie de autenticação no lado servidor quando o usuário realiza o logout.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-SESS-001
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|Ao realizar a primeira requisição para o sistema o usuário recebe um cookie de sessão, e assim que realiza o login com sucesso ele recebe um cookie de autenticação. No entanto o sistema não faz a validação de ambos os cookies, podendo o usuário depois de autenticado continuar navegando apenas com o cookie de sessão ou de autenticação (nesse caso recebendo uma nova sessão).
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.4_Gerenciamento_de_sess.C3.A3o|"3.4 Gerenciamento de sessão"]]
|-
|'''Sugestões'''
|
*Sempre verificar no lado servidor a validade de ambos os cookies, e caso algum cookie esteja ausente ou alterado realizar o logout da sessão do usuário, invalidando ambos os cookies.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-CLIENT-004
|-
|'''Severidade'''
|Baixa
|-
|'''Descrição'''
|O sistema faz o redirecionamento do usuário para outros domínios quando o parâmentro "relaystate" da página "Login.ashx" é alterado para uma url qualquer.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.1_Valida.C3.A7.C3.A3o_dos_dados|"3.1 Validação dos dados"]]
|-
|'''Sugestões'''
|
*Fazer a validação do valor do relaystate antes de redirecionar o usuário, para previnir o redirecionamento para outros domínios no caso da requisição ter sido alterada ou forjada.
|-
|'''Referências'''
|
|}

{| class="wikitable"
|colspan="2" style="text-align: center; | Índices || Resultados
|-
|colspan="2"|Número de itens testes|| style="text-align: center; | 64
|-
|colspan="2"|Número de itens verificados|| style="text-align: center; |40
|-
|colspan="2"|Número de itens (NA)|| style="text-align: center; |24
|-
|colspan="2"|Número de itens (OK)|| style="text-align: center; |31
|-
|colspan="2"|Número de itens (F)|| style="text-align: center; |9
|-
|colspan="2"|Índice de aderência|| style="text-align: center; |78%
|}

== Verificação de Desempenho ==

=== Observações sobre o teste ===
O CoreSSO utilizado inicialmente para os testes foi o indicado pela equipe do Transportes, copiado do TS-IIS02 e TS-BD. Contudo, o CoreSSO, apresentou problemas, dentre eles o não cadastro da tabela de layout padrão, gerando diversos erros. Desta forma, substituímos o banco e o site por outra versão indicada pela equipe do CoreSSO na época.

Vale ressaltar que o sistema conforme indicação da equipe do Transportes suportaria, em seu limite, o acesso simultâneo de 200 usuários com uma alta taxa de erro no momento de acesso ao sistema Transporte Escolar, tornando necessário a verificação e ajuste do SAML.

=== Cenário de uso ===

{| class="wikitable"
!colspan="6"|Cenário de uso #1
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|1 - Acessar tela de login || style="text-align: center; | 3
|-
|colspan="2"|1 - Realizar login || style="text-align: center; |7
|-
|colspan="2"|1 - Selecionar sistema Transporte Escolar || style="text-align: center; |5
|-
|colspan="2"|2 - Acessar tela de consulta de veículos || style="text-align: center; |5
|-
|colspan="2"|2 - Preencher aba "Documentação" || style="text-align: center; |20
|-
|colspan="2"|2 - Preencher aba "Aquisição" || style="text-align: center; |7
|-
|colspan="2"|2 - Preencher aba "Condutor" || style="text-align: center; |38
|-
|colspan="2"|2 - Preencher aba "Peças e acessórios" || style="text-align: center; |25
|-
|colspan="2"|2 - Preencher aba "Despesas" || style="text-align: center; |15
|-
|colspan="2"|2 - Salvar cadastro || style="text-align: center; |5
|-
|colspan="2"|3 - Logout || style="text-align: center; |5
|}

=== Resultado dos testes ===
Nesta seção serão apresentados os resultados obtidos da execução dos testes.

*'''Porcentagem de tempo do processador'''
: Descrição: Mede a saturação do processador e mostra a quantidade de tempo despendida para processar as threads por todas as CPUs.
: Limite recomendado: Abaixo de 75 %.

:::::: [[Arquivo:2016-06-21 TransporteEscolar TempoDeProcessador.png]]

*'''Porcentagem de memória utilizada'''
: Descrição: Indica a porcentagem de memória utilizada para uso dos processos.
: Limite recomendado: Abaixo de 75 %.

:::::: [[Arquivo:2016-06-21_TransporteEscolar_MemoriaUtilizada.png]]

*'''Kbytes totais pela interface de rede'''
: Descrição: Indica quantos Bbytes foram enviados e recebidos a cada segundo pela interface de rede.
: Limite recomendado: Menor que 5 Mbytes para uma rede de 100Mbps, menor que 50 Mbytes para uma rede de 1000 Mbps. (Quanto menor melhor)

:::::: [[Arquivo:2016-06-21_TransporteEscolar_NetworkTotal.png]]

*'''Tempo médio de resposta das requisições'''
: Descrição: Indica o tempo médio de resposta das requisições.
: Limite recomendado: 5 segundos.

:::::: [[Arquivo:2016-06-21_TransporteEscolar_ResponseTime.png]]

*'''Tempo de vazão'''
: Descrição: Indica a quantidade total de request por segundo.
: Limite recomendado: Quanto maior melhor.

:::::: [[Arquivo:2016-06-22 13-37-47.png]]

Transporte 1.1.1.21

2016-07-01T17:30:15Z

Lucimara.maiorali: /* Resultados dos Testes */

== Sistemas Verificados ==

*Transporte Escolar, versão 1.1.1.21
*Transporte Escolar Api, versão 1.0.0.0

== Verificação de Segurança ==

=== Testes Realizados ===

{| class="wikitable"
!Item de Teste
!Referência OWASP
!Resultado
|-
|Review Webpage Comments and Metadata for Information Leakage
|[https://www.owasp.org/index.php/Review_webpage_comments_and_metadata_for_information_leakage_(OTG-INFO-005) OTG-INFO-005]
|OK
|-
|Test Application Platform Configuration
|[https://www.owasp.org/index.php/Test_Application_Platform_Configuration_(OTG-CONFIG-002) OTG-CONFIG-002]
|NA
|-
|Test File Extensions Handling for Sensitive Information
|[https://www.owasp.org/index.php/Test_File_Extensions_Handling_for_Sensitive_Information_(OTG-CONFIG-003) OTG-CONFIG-003]
|OK
|-
|Review Old, Backup and Unreferenced Files for Sensitive Information
|[https://www.owasp.org/index.php/Review_Old,_Backup_and_Unreferenced_Files_for_Sensitive_Information_(OTG-CONFIG-004) OTG-CONFIG-004]
|F
|-
|Test HTTP Methods
|[https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006) OTG-CONFIG-006]
|NA
|-
|Test HTTP Strict Transport Security
|[https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007) OTG-CONFIG-007]
|F
|-
|Test RIA cross domain policy
|[https://www.owasp.org/index.php/Test_RIA_cross_domain_policy_(OTG-CONFIG-008) OTG-CONFIG-008]
|NA
|-
|Test Role Definitions
|[https://www.owasp.org/index.php/Test_Role_Definitions_(OTG-IDENT-001) OTG-IDENT-001]
|NA
|-
|Test User Registration Process
|[https://www.owasp.org/index.php/Test_User_Registration_Process_(OTG-IDENT-002) OTG-IDENT-002]
|NA
|-
|Test Account Provisioning Process
|[https://www.owasp.org/index.php/Test_Account_Provisioning_Process_(OTG-IDENT-003) OTG-IDENT-003]
|NA
|-
|Testing for Account Enumeration and Guessable User Account
|[https://www.owasp.org/index.php/Testing_for_Account_Enumeration_and_Guessable_User_Account_(OTG-IDENT-004) OTG-IDENT-004]
|OK
|-
|Testing for Credentials Transported over an Encrypted Channel
|[https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001) OTG-AUTHN-001]
|F
|-
|Testing for default credentials
|[https://www.owasp.org/index.php/Testing_for_default_credentials_(OTG-AUTHN-002) OTG-AUTHN-002]
|OK
|-
|Testing for Weak lock out mechanism
|[https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) OTG-AUTHN-003]
|NA
|-
|Testing for Bypassing Authentication Schema
|[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) OTG-AUTHN-004]
|OK
|-
|Testing for Vulnerable Remember Password
|[https://www.owasp.org/index.php/Testing_for_Vulnerable_Remember_Password_(OTG-AUTHN-005) OTG-AUTHN-005]
|NA
|-
|Testing for Browser cache weakness
|[https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OTG-AUTHN-006) OTG-AUTHN-006]
|OK
|-
|Testing for Weak password policy
|[https://www.owasp.org/index.php?title=Testing_for_Weak_password_policy_(OTG-AUTHN-007)&setlang=en OTG-AUTHN-007]
|NA
|-
|Testing for weak password change or reset functionalities
|[https://www.owasp.org/index.php/Testing_for_weak_password_change_or_reset_functionalities_(OTG-AUTHN-009) OTG-AUTHN-009]
|NA
|-
|Testing for Weaker authentication in alternative channel
|[https://www.owasp.org/index.php/Testing_for_Weaker_authentication_in_alternative_channel_(OTG-AUTHN-010) OTG-AUTHN-010]
|NA
|-
|Testing Directory traversal/file include
|[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) OTG-AUTHZ-001]
|OK
|-
|Testing for Bypassing Authorization Schema
|[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) OTG-AUTHZ-002]
|F
|-
|Testing for Privilege escalation
|[https://www.owasp.org/index.php?title=Testing_for_Privilege_escalation_(OTG-AUTHZ-003)&setlang=en OTG-AUTHZ-003]
|OK
|-
|Testing for Insecure Direct Object References
|[https://www.owasp.org/index.php?title=Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)&setlang=en OTG-AUTHZ-004]
|F
|-
|Testing for Session Management Schema
|[https://www.owasp.org/index.php/Testing_for_Session_Management_Schema_(OTG-SESS-001) OTG-SESS-001]
|F
|-
|Testing for cookies attributes
|[https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002) OTG-SESS-002]
|OK
|-
|Testing for Session Fixation
|[https://www.owasp.org/index.php/Testing_for_Session_Fixation_(OTG-SESS-003) OTG-SESS-003]
|OK
|-
|Testing for Exposed Session Variables
|[https://www.owasp.org/index.php/Testing_for_Exposed_Session_Variables_(OTG-SESS-004) OTG-SESS-004]
|OK
|-
|Testing for CSRF
|[https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005) OTG-SESS-005]
|F
|-
|Testing for logout functionality
|[https://www.owasp.org/index.php/Testing_for_logout_functionality_(OTG-SESS-006) OTG-SESS-006]
|F
|-
|Testing for Session Timeout
|[https://www.owasp.org/index.php?title=Test_Session_Timeout_(OTG-SESS-007)&setlang=en OTG-SESS-007]
|OK
|-
|Testing for Session puzzling
|[https://www.owasp.org/index.php/Testing_for_Session_puzzling_(OTG-SESS-008) OTG-SESS-008]
|OK
|-
|Testing for Reflected Cross site scripting
|[https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001) OTG-INPVAL-001]
|OK
|-
|Testing for Stored Cross site scripting
|[https://www.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002) OTG-INPVAL-002]
|OK
|-
|Testing for HTTP Verb Tampering
|[https://www.owasp.org/index.php?title=Testing_for_HTTP_Verb_Tampering_(OTG-INPVAL-003)&setlang=en OTG-INPVAL-003]
|NA
|-
|Testing for HTTP Parameter pollution
|[https://www.owasp.org/index.php/Testing_for_HTTP_Parameter_pollution_(OTG-INPVAL-004) OTG-INPVAL-004]
|OK
|-
|Testing for SQL Injection
|[https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) OTG-INPVAL-005]
|OK
|-
|Testing for LDAP Injection
|[https://www.owasp.org/index.php/Testing_for_LDAP_Injection_(OTG-INPVAL-006) OTG-INPVAL-006]
|NA
|-
|Testing for XML Injection
|[https://www.owasp.org/index.php?title=Testing_for_XML_Injection_(OTG-INPVAL-008)&setlang=en OTG-INPVAL-008]
|NA
|-
|Testing for SSI Injection
|[https://www.owasp.org/index.php?title=Testing_for_SSI_Injection_(OTG-INPVAL-009)&setlang=en OTG-INPVAL-009]
|NA
|-
|Testing for XPath Injection
|[https://www.owasp.org/index.php?title=Testing_for_XPath_Injection_(OTG-INPVAL-010)&setlang=en OTG-INPVAL-010]
|NA
|-
|Testing for IMAP/SMTP Injection
|[https://www.owasp.org/index.php/Testing_for_IMAP/SMTP_Injection_(OTG-INPVAL-011) OTG-INPVAL-011]
|NA
|-
|Testing for Code Injection
|[https://www.owasp.org/index.php?title=Testing_for_Code_Injection_(OTG-INPVAL-012)&setlang=en OTG-INPVAL-012]
|OK
|-
|Testing for Command Injection
|[https://www.owasp.org/index.php?title=Testing_for_Command_Injection_(OTG-INPVAL-013)&setlang=en OTG-INPVAL-013]
|OK
|-
|Testing for Buffer Overflow
|[https://www.owasp.org/index.php/Testing_for_Buffer_Overflow_(OTG-INPVAL-014) OTG-INPVAL-014]
|NA
|-
|Testing for Incubated Vulnerability
|[https://www.owasp.org/index.php?title=Testing_for_Incubated_Vulnerability_(OTG-INPVAL-015)&setlang=en OTG-INPVAL-015]
|OK
|-
|Testing for HTTP Splitting/Smuggling
|[https://www.owasp.org/index.php?title=Testing_for_HTTP_Splitting/Smuggling_(OTG-INPVAL-016)&setlang=en OTG-INPVAL-016]
|OK
|-
|Testing for Information Disclosure
|[https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) OTG-ERR-001], [https://www.owasp.org/index.php/Testing_for_Stack_Traces_(OTG-ERR-002) OTG-ERR-002]
|OK
|-
|Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection
|[https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001) OTG-CRYPST-001]
|NA
|-
|Testing for Padding Oracle
|[https://www.owasp.org/index.php?title=Testing_for_Padding_Oracle_(OTG-CRYPST-002)&setlang=en OTG-CRYPST-002]
|NA
|-
|Testing for Sensitive information sent via unencrypted channels
|[https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)&setlang=en OTG-CRYPST-003]
|NA
|-
|Tests of business logic
|[https://www.owasp.org/index.php/Testing_for_business_logic OTG-BUSLOGIC-001..009]
|OK
|-
|Testing for DOM-based Cross site scripting
|[https://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_(OTG-CLIENT-001) OTG-CLIENT-001]
|OK
|-
|Testing for JavaScript Execution
|[https://www.owasp.org/index.php/Testing_for_JavaScript_Execution_(OTG-CLIENT-002) OTG-CLIENT-002]
|OK
|-
|Testing for HTML Injection
|[https://www.owasp.org/index.php/Testing_for_HTML_Injection_(OTG-CLIENT-003) OTG-CLIENT-003]
|OK
|-
|Testing for Client Side URL Redirect
|[https://www.owasp.org/index.php/Testing_for_Client_Side_URL_Redirect_(OTG-CLIENT-004) OTG-CLIENT-004]
|F
|-
|Testing for CSS Injection
|[https://www.owasp.org/index.php/Testing_for_CSS_Injection_(OTG-CLIENT-005) OTG-CLIENT-005]
|OK
|-
|Testing for Client Side Resource Manipulation
|[https://www.owasp.org/index.php/Testing_for_Client_Side_Resource_Manipulation_(OTG-CLIENT-006) OTG-CLIENT-006]
|OK
|-
|Test Cross Origin Resource Sharing
|[https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007) OTG-CLIENT-007]
|OK
|-
|Testing for Cross site flashing
|[https://www.owasp.org/index.php?title=Testing_for_Cross_site_flashing_(OTG-CLIENT-008)&setlang=en OTG-CLIENT-008]
|OK
|-
|Testing for Clickjacking
|[https://www.owasp.org/index.php/Testing_for_Clickjacking_(OTG-CLIENT-009) OTG-CLIENT-009]
|OK
|-
|Testing WebSockets
|[https://www.owasp.org/index.php?title=Testing_WebSockets_(OTG-CLIENT-010)&setlang=en OTG-CLIENT-010]
|NA
|-
|Test Web Messaging
|[https://www.owasp.org/index.php?title=Test_Web_Messaging_(OTG-CLIENT-011)&setlang=en OTG-CLIENT-011]
|NA
|-
|Test Local Storage
|[https://www.owasp.org/index.php?title=Test_Local_Storage_(OTG-CLIENT-012)&setlang=en OTG-CLIENT-012]
|NA
|}

:OK (Nenhum problema encontrado); F (Teste falhou, verificar os resultados); NA (Teste não aplicado)


=== Resultados dos Testes ===

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-AUTHZ-002, OTG-AUTHZ-004
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|O handler "fileHandler.ashx" não possui controle de acesso, podendo ser acessado diretamente por um usuário não autenticado. Assim ele permite o download de qualquer arquivo disponível através do seu id, que é um número sequencial e portanto de fácil previsão.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.3_Controle_de_acesso|"3.3 Controle de acesso"]], [[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.9_Arquivos_e_recursos|"3.9 Arquivos e recursos"]]
|-
|'''Sugestões'''
|
*Implementar um controle de acesso para o fileHandler e para os arquivos em si, de forma que apenas os usuários com a devida permissão consigam realizar o download dos arquivos.
*Utilizar identificadores aleatórios e não previsíveis para dificultar o acesso aos arquivos diretamente.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-CONFIG-007, OTG-AUTHN-001
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|As informações enviados para e pelo sistema não são criptografadas, susceptíveis a interceptações e alterações entre o cliente e o servidor.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.8_Seguran.C3.A7a_nas_comunica.C3.A7.C3.B5es|"3.8 Segurança nas comunicações"]]
|-
|'''Sugestões'''
|
*Implementar o protocolo TLS seguindo as orientações de boas práticas.
*Utilizar em ambientes de produção certificados gerados por autoridades certificadores confiáveis. Em ambientes de teste e homologação podem ser utilizados certificados auto-assinados.
|-
|'''Referências'''
|
*https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-CONFIG-004
|-
|'''Severidade'''
|Baixa
|-
|'''Descrição'''
|O diretório do site no servidor possui arquivos de código fonte (.cs).
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.7_Prote.C3.A7.C3.A3o_de_dados|"3.7 Proteção de dados"]]
|-
|'''Sugestões'''
|
*Em produção, deve-se procurar manter apenas os arquivos compilados e necessários para o funcionamento do sistema.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-AUTHZ-002
|-
|'''Severidade'''
|Baixa
|-
|'''Descrição'''
|A api do sistema e o WS "SvcTransporteEscolar" não possuem controle de acesso, podendo ser acessados diretamente por um usuário não autenticado.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.11_Web_Services_e_API.C2.B4s|"3.11 Web Services e API´s"]]
|-
|'''Sugestões'''
|
*Implementar mecanismos de autenticação e autorização para as APIs e Webservices.
|-
|'''Referências'''
|
*http://www.asp.net/web-api/overview/security/authentication-andauthorization-in-aspnet-web-api
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-SESS-005
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|O sistema não implementa um mecanismo anti-CSRF, e permite que as páginas sejam renderizadas a partir de outros domínios (em um frame, iframe ou object).
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.12.1_Configura.C3.A7.C3.B5es_para_servidor_web|"3.12.1 Configurações para servidor web"]], [[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.4_Gerenciamento_de_sess.C3.A3o|"3.4 Gerenciamento de sessão"]]
|-
|'''Sugestões'''
|
*Implementar um token anti-CSRF para prevenir ataques desse tipo.
*Verificar os cabeçalhos "Origin" e/ou "Referer" para identificar a origem do request.
*Setar o cabeçalho "X-Frame-Options" para "sameorigin" ou "deny".
|-
|'''Referências'''
|
*https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
*https://www.owasp.org/index.php/Anti_CSRF_Tokens_ASP.NET
*https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-SESS-001, OTG-SESS-006
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|Ao realizar o logout o cookie de autenticação não é invalidado no servidor, apenas excluido no lado cliente. Assim, forçando o navegador a utilizar o valor antigo do cookie o usuário consegue novamente acesso ao sistema sem realizar o login.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.4_Gerenciamento_de_sess.C3.A3o|"3.4 Gerenciamento de sessão"]]
|-
|'''Sugestões'''
|
*Invalidar o cookie de autenticação no lado servidor quando o usuário realiza o logout.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-SESS-001
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|Ao realizar a primeira requisição para o sistema o usuário recebe um cookie de sessão, e assim que realiza o login com sucesso ele recebe um cookie de autenticação. No entanto o sistema não faz a validação de ambos os cookies, podendo o usuário depois de autenticado continuar navegando apenas com o cookie de sessão ou de autenticação (nesse caso recebendo uma nova sessão).
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.4_Gerenciamento_de_sess.C3.A3o|"3.4 Gerenciamento de sessão"]]
|-
|'''Sugestões'''
|
*Sempre verificar no lado servidor a validade de ambos os cookies, e caso algum cookie esteja ausente ou alterado realizar o logout da sessão do usuário, invalidando ambos os cookies.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-CLIENT-004
|-
|'''Severidade'''
|Baixa
|-
|'''Descrição'''
|O sistema faz o redirecionamento do usuário para outros domínios quando o parâmentro "relaystate" da página "Login.ashx" é alterado para uma url qualquer.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.1_Valida.C3.A7.C3.A3o_dos_dados|"3.1 Validação dos dados"]]
|-
|'''Sugestões'''
|
*Fazer a validação do valor do relaystate antes de redirecionar o usuário, para previnir o redirecionamento para outros domínios no caso da requisição ter sido alterada ou forjada.
|-
|'''Referências'''
|
|}

{| class="wikitable"
|colspan="2" style="text-align: center; | Índices || Resultados
|-
|colspan="2"|Número de itens testes|| style="text-align: center; | 64
|-
|colspan="2"|Número de itens verificados|| style="text-align: center; |40
|-
|colspan="2"|Número de itens (OK)|| style="text-align: center; |31
|-
|colspan="2"|Número de itens (F)|| style="text-align: center; |9
|-
|colspan="2"|Número de itens (NA)|| style="text-align: center; |24
|-
|colspan="2"|Índice de aderência|| style="text-align: center; |78%
|}

== Verificação de Desempenho ==

=== Observações sobre o teste ===
O CoreSSO utilizado inicialmente para os testes foi o indicado pela equipe do Transportes, copiado do TS-IIS02 e TS-BD. Contudo, o CoreSSO, apresentou problemas, dentre eles o não cadastro da tabela de layout padrão, gerando diversos erros. Desta forma, substituímos o banco e o site por outra versão indicada pela equipe do CoreSSO na época.

Vale ressaltar que o sistema conforme indicação da equipe do Transportes suportaria, em seu limite, o acesso simultâneo de 200 usuários com uma alta taxa de erro no momento de acesso ao sistema Transporte Escolar, tornando necessário a verificação e ajuste do SAML.

=== Cenário de uso ===

{| class="wikitable"
!colspan="6"|Cenário de uso #1
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|1 - Acessar tela de login || style="text-align: center; | 3
|-
|colspan="2"|1 - Realizar login || style="text-align: center; |7
|-
|colspan="2"|1 - Selecionar sistema Transporte Escolar || style="text-align: center; |5
|-
|colspan="2"|2 - Acessar tela de consulta de veículos || style="text-align: center; |5
|-
|colspan="2"|2 - Preencher aba "Documentação" || style="text-align: center; |20
|-
|colspan="2"|2 - Preencher aba "Aquisição" || style="text-align: center; |7
|-
|colspan="2"|2 - Preencher aba "Condutor" || style="text-align: center; |38
|-
|colspan="2"|2 - Preencher aba "Peças e acessórios" || style="text-align: center; |25
|-
|colspan="2"|2 - Preencher aba "Despesas" || style="text-align: center; |15
|-
|colspan="2"|2 - Salvar cadastro || style="text-align: center; |5
|-
|colspan="2"|3 - Logout || style="text-align: center; |5
|}

=== Resultado dos testes ===
Nesta seção serão apresentados os resultados obtidos da execução dos testes.

*'''Porcentagem de tempo do processador'''
: Descrição: Mede a saturação do processador e mostra a quantidade de tempo despendida para processar as threads por todas as CPUs.
: Limite recomendado: Abaixo de 75 %.

:::::: [[Arquivo:2016-06-21 TransporteEscolar TempoDeProcessador.png]]

*'''Porcentagem de memória utilizada'''
: Descrição: Indica a porcentagem de memória utilizada para uso dos processos.
: Limite recomendado: Abaixo de 75 %.

:::::: [[Arquivo:2016-06-21_TransporteEscolar_MemoriaUtilizada.png]]

*'''Kbytes totais pela interface de rede'''
: Descrição: Indica quantos Bbytes foram enviados e recebidos a cada segundo pela interface de rede.
: Limite recomendado: Menor que 5 Mbytes para uma rede de 100Mbps, menor que 50 Mbytes para uma rede de 1000 Mbps. (Quanto menor melhor)

:::::: [[Arquivo:2016-06-21_TransporteEscolar_NetworkTotal.png]]

*'''Tempo médio de resposta das requisições'''
: Descrição: Indica o tempo médio de resposta das requisições.
: Limite recomendado: 5 segundos.

:::::: [[Arquivo:2016-06-21_TransporteEscolar_ResponseTime.png]]

*'''Tempo de vazão'''
: Descrição: Indica a quantidade total de request por segundo.
: Limite recomendado: Quanto maior melhor.

:::::: [[Arquivo:2016-06-22 13-37-47.png]]

Transporte 1.1.1.21

2016-07-01T17:24:20Z

Lucimara.maiorali:

== Sistemas Verificados ==

*Transporte Escolar, versão 1.1.1.21
*Transporte Escolar Api, versão 1.0.0.0

== Verificação de Segurança ==

=== Testes Realizados ===

{| class="wikitable"
!Item de Teste
!Referência OWASP
!Resultado
|-
|Review Webpage Comments and Metadata for Information Leakage
|[https://www.owasp.org/index.php/Review_webpage_comments_and_metadata_for_information_leakage_(OTG-INFO-005) OTG-INFO-005]
|OK
|-
|Test Application Platform Configuration
|[https://www.owasp.org/index.php/Test_Application_Platform_Configuration_(OTG-CONFIG-002) OTG-CONFIG-002]
|NA
|-
|Test File Extensions Handling for Sensitive Information
|[https://www.owasp.org/index.php/Test_File_Extensions_Handling_for_Sensitive_Information_(OTG-CONFIG-003) OTG-CONFIG-003]
|OK
|-
|Review Old, Backup and Unreferenced Files for Sensitive Information
|[https://www.owasp.org/index.php/Review_Old,_Backup_and_Unreferenced_Files_for_Sensitive_Information_(OTG-CONFIG-004) OTG-CONFIG-004]
|F
|-
|Test HTTP Methods
|[https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006) OTG-CONFIG-006]
|NA
|-
|Test HTTP Strict Transport Security
|[https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007) OTG-CONFIG-007]
|F
|-
|Test RIA cross domain policy
|[https://www.owasp.org/index.php/Test_RIA_cross_domain_policy_(OTG-CONFIG-008) OTG-CONFIG-008]
|NA
|-
|Test Role Definitions
|[https://www.owasp.org/index.php/Test_Role_Definitions_(OTG-IDENT-001) OTG-IDENT-001]
|NA
|-
|Test User Registration Process
|[https://www.owasp.org/index.php/Test_User_Registration_Process_(OTG-IDENT-002) OTG-IDENT-002]
|NA
|-
|Test Account Provisioning Process
|[https://www.owasp.org/index.php/Test_Account_Provisioning_Process_(OTG-IDENT-003) OTG-IDENT-003]
|NA
|-
|Testing for Account Enumeration and Guessable User Account
|[https://www.owasp.org/index.php/Testing_for_Account_Enumeration_and_Guessable_User_Account_(OTG-IDENT-004) OTG-IDENT-004]
|OK
|-
|Testing for Credentials Transported over an Encrypted Channel
|[https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001) OTG-AUTHN-001]
|F
|-
|Testing for default credentials
|[https://www.owasp.org/index.php/Testing_for_default_credentials_(OTG-AUTHN-002) OTG-AUTHN-002]
|OK
|-
|Testing for Weak lock out mechanism
|[https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) OTG-AUTHN-003]
|NA
|-
|Testing for Bypassing Authentication Schema
|[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) OTG-AUTHN-004]
|OK
|-
|Testing for Vulnerable Remember Password
|[https://www.owasp.org/index.php/Testing_for_Vulnerable_Remember_Password_(OTG-AUTHN-005) OTG-AUTHN-005]
|NA
|-
|Testing for Browser cache weakness
|[https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OTG-AUTHN-006) OTG-AUTHN-006]
|OK
|-
|Testing for Weak password policy
|[https://www.owasp.org/index.php?title=Testing_for_Weak_password_policy_(OTG-AUTHN-007)&setlang=en OTG-AUTHN-007]
|NA
|-
|Testing for weak password change or reset functionalities
|[https://www.owasp.org/index.php/Testing_for_weak_password_change_or_reset_functionalities_(OTG-AUTHN-009) OTG-AUTHN-009]
|NA
|-
|Testing for Weaker authentication in alternative channel
|[https://www.owasp.org/index.php/Testing_for_Weaker_authentication_in_alternative_channel_(OTG-AUTHN-010) OTG-AUTHN-010]
|NA
|-
|Testing Directory traversal/file include
|[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) OTG-AUTHZ-001]
|OK
|-
|Testing for Bypassing Authorization Schema
|[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) OTG-AUTHZ-002]
|F
|-
|Testing for Privilege escalation
|[https://www.owasp.org/index.php?title=Testing_for_Privilege_escalation_(OTG-AUTHZ-003)&setlang=en OTG-AUTHZ-003]
|OK
|-
|Testing for Insecure Direct Object References
|[https://www.owasp.org/index.php?title=Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)&setlang=en OTG-AUTHZ-004]
|F
|-
|Testing for Session Management Schema
|[https://www.owasp.org/index.php/Testing_for_Session_Management_Schema_(OTG-SESS-001) OTG-SESS-001]
|F
|-
|Testing for cookies attributes
|[https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002) OTG-SESS-002]
|OK
|-
|Testing for Session Fixation
|[https://www.owasp.org/index.php/Testing_for_Session_Fixation_(OTG-SESS-003) OTG-SESS-003]
|OK
|-
|Testing for Exposed Session Variables
|[https://www.owasp.org/index.php/Testing_for_Exposed_Session_Variables_(OTG-SESS-004) OTG-SESS-004]
|OK
|-
|Testing for CSRF
|[https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005) OTG-SESS-005]
|F
|-
|Testing for logout functionality
|[https://www.owasp.org/index.php/Testing_for_logout_functionality_(OTG-SESS-006) OTG-SESS-006]
|F
|-
|Testing for Session Timeout
|[https://www.owasp.org/index.php?title=Test_Session_Timeout_(OTG-SESS-007)&setlang=en OTG-SESS-007]
|OK
|-
|Testing for Session puzzling
|[https://www.owasp.org/index.php/Testing_for_Session_puzzling_(OTG-SESS-008) OTG-SESS-008]
|OK
|-
|Testing for Reflected Cross site scripting
|[https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001) OTG-INPVAL-001]
|OK
|-
|Testing for Stored Cross site scripting
|[https://www.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002) OTG-INPVAL-002]
|OK
|-
|Testing for HTTP Verb Tampering
|[https://www.owasp.org/index.php?title=Testing_for_HTTP_Verb_Tampering_(OTG-INPVAL-003)&setlang=en OTG-INPVAL-003]
|NA
|-
|Testing for HTTP Parameter pollution
|[https://www.owasp.org/index.php/Testing_for_HTTP_Parameter_pollution_(OTG-INPVAL-004) OTG-INPVAL-004]
|OK
|-
|Testing for SQL Injection
|[https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) OTG-INPVAL-005]
|OK
|-
|Testing for LDAP Injection
|[https://www.owasp.org/index.php/Testing_for_LDAP_Injection_(OTG-INPVAL-006) OTG-INPVAL-006]
|NA
|-
|Testing for XML Injection
|[https://www.owasp.org/index.php?title=Testing_for_XML_Injection_(OTG-INPVAL-008)&setlang=en OTG-INPVAL-008]
|NA
|-
|Testing for SSI Injection
|[https://www.owasp.org/index.php?title=Testing_for_SSI_Injection_(OTG-INPVAL-009)&setlang=en OTG-INPVAL-009]
|NA
|-
|Testing for XPath Injection
|[https://www.owasp.org/index.php?title=Testing_for_XPath_Injection_(OTG-INPVAL-010)&setlang=en OTG-INPVAL-010]
|NA
|-
|Testing for IMAP/SMTP Injection
|[https://www.owasp.org/index.php/Testing_for_IMAP/SMTP_Injection_(OTG-INPVAL-011) OTG-INPVAL-011]
|NA
|-
|Testing for Code Injection
|[https://www.owasp.org/index.php?title=Testing_for_Code_Injection_(OTG-INPVAL-012)&setlang=en OTG-INPVAL-012]
|OK
|-
|Testing for Command Injection
|[https://www.owasp.org/index.php?title=Testing_for_Command_Injection_(OTG-INPVAL-013)&setlang=en OTG-INPVAL-013]
|OK
|-
|Testing for Buffer Overflow
|[https://www.owasp.org/index.php/Testing_for_Buffer_Overflow_(OTG-INPVAL-014) OTG-INPVAL-014]
|NA
|-
|Testing for Incubated Vulnerability
|[https://www.owasp.org/index.php?title=Testing_for_Incubated_Vulnerability_(OTG-INPVAL-015)&setlang=en OTG-INPVAL-015]
|OK
|-
|Testing for HTTP Splitting/Smuggling
|[https://www.owasp.org/index.php?title=Testing_for_HTTP_Splitting/Smuggling_(OTG-INPVAL-016)&setlang=en OTG-INPVAL-016]
|OK
|-
|Testing for Information Disclosure
|[https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) OTG-ERR-001], [https://www.owasp.org/index.php/Testing_for_Stack_Traces_(OTG-ERR-002) OTG-ERR-002]
|OK
|-
|Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection
|[https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001) OTG-CRYPST-001]
|NA
|-
|Testing for Padding Oracle
|[https://www.owasp.org/index.php?title=Testing_for_Padding_Oracle_(OTG-CRYPST-002)&setlang=en OTG-CRYPST-002]
|NA
|-
|Testing for Sensitive information sent via unencrypted channels
|[https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)&setlang=en OTG-CRYPST-003]
|NA
|-
|Tests of business logic
|[https://www.owasp.org/index.php/Testing_for_business_logic OTG-BUSLOGIC-001..009]
|OK
|-
|Testing for DOM-based Cross site scripting
|[https://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_(OTG-CLIENT-001) OTG-CLIENT-001]
|OK
|-
|Testing for JavaScript Execution
|[https://www.owasp.org/index.php/Testing_for_JavaScript_Execution_(OTG-CLIENT-002) OTG-CLIENT-002]
|OK
|-
|Testing for HTML Injection
|[https://www.owasp.org/index.php/Testing_for_HTML_Injection_(OTG-CLIENT-003) OTG-CLIENT-003]
|OK
|-
|Testing for Client Side URL Redirect
|[https://www.owasp.org/index.php/Testing_for_Client_Side_URL_Redirect_(OTG-CLIENT-004) OTG-CLIENT-004]
|F
|-
|Testing for CSS Injection
|[https://www.owasp.org/index.php/Testing_for_CSS_Injection_(OTG-CLIENT-005) OTG-CLIENT-005]
|OK
|-
|Testing for Client Side Resource Manipulation
|[https://www.owasp.org/index.php/Testing_for_Client_Side_Resource_Manipulation_(OTG-CLIENT-006) OTG-CLIENT-006]
|OK
|-
|Test Cross Origin Resource Sharing
|[https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007) OTG-CLIENT-007]
|OK
|-
|Testing for Cross site flashing
|[https://www.owasp.org/index.php?title=Testing_for_Cross_site_flashing_(OTG-CLIENT-008)&setlang=en OTG-CLIENT-008]
|OK
|-
|Testing for Clickjacking
|[https://www.owasp.org/index.php/Testing_for_Clickjacking_(OTG-CLIENT-009) OTG-CLIENT-009]
|OK
|-
|Testing WebSockets
|[https://www.owasp.org/index.php?title=Testing_WebSockets_(OTG-CLIENT-010)&setlang=en OTG-CLIENT-010]
|NA
|-
|Test Web Messaging
|[https://www.owasp.org/index.php?title=Test_Web_Messaging_(OTG-CLIENT-011)&setlang=en OTG-CLIENT-011]
|NA
|-
|Test Local Storage
|[https://www.owasp.org/index.php?title=Test_Local_Storage_(OTG-CLIENT-012)&setlang=en OTG-CLIENT-012]
|NA
|}

:OK (Nenhum problema encontrado); F (Teste falhou, verificar os resultados); NA (Teste não aplicado)


=== Resultados dos Testes ===

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-AUTHZ-002, OTG-AUTHZ-004
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|O handler "fileHandler.ashx" não possui controle de acesso, podendo ser acessado diretamente por um usuário não autenticado. Assim ele permite o download de qualquer arquivo disponível através do seu id, que é um número sequencial e portanto de fácil previsão.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.3_Controle_de_acesso|"3.3 Controle de acesso"]], [[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.9_Arquivos_e_recursos|"3.9 Arquivos e recursos"]]
|-
|'''Sugestões'''
|
*Implementar um controle de acesso para o fileHandler e para os arquivos em si, de forma que apenas os usuários com a devida permissão consigam realizar o download dos arquivos.
*Utilizar identificadores aleatórios e não previsíveis para dificultar o acesso aos arquivos diretamente.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-CONFIG-007, OTG-AUTHN-001
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|As informações enviados para e pelo sistema não são criptografadas, susceptíveis a interceptações e alterações entre o cliente e o servidor.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.8_Seguran.C3.A7a_nas_comunica.C3.A7.C3.B5es|"3.8 Segurança nas comunicações"]]
|-
|'''Sugestões'''
|
*Implementar o protocolo TLS seguindo as orientações de boas práticas.
*Utilizar em ambientes de produção certificados gerados por autoridades certificadores confiáveis. Em ambientes de teste e homologação podem ser utilizados certificados auto-assinados.
|-
|'''Referências'''
|
*https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-CONFIG-004
|-
|'''Severidade'''
|Baixa
|-
|'''Descrição'''
|O diretório do site no servidor possui arquivos de código fonte (.cs).
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.7_Prote.C3.A7.C3.A3o_de_dados|"3.7 Proteção de dados"]]
|-
|'''Sugestões'''
|
*Em produção, deve-se procurar manter apenas os arquivos compilados e necessários para o funcionamento do sistema.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-AUTHZ-002
|-
|'''Severidade'''
|Baixa
|-
|'''Descrição'''
|A api do sistema e o WS "SvcTransporteEscolar" não possuem controle de acesso, podendo ser acessados diretamente por um usuário não autenticado.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.11_Web_Services_e_API.C2.B4s|"3.11 Web Services e API´s"]]
|-
|'''Sugestões'''
|
*Implementar mecanismos de autenticação e autorização para as APIs e Webservices.
|-
|'''Referências'''
|
*http://www.asp.net/web-api/overview/security/authentication-andauthorization-in-aspnet-web-api
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-SESS-005
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|O sistema não implementa um mecanismo anti-CSRF, e permite que as páginas sejam renderizadas a partir de outros domínios (em um frame, iframe ou object).
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.12.1_Configura.C3.A7.C3.B5es_para_servidor_web|"3.12.1 Configurações para servidor web"]], [[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.4_Gerenciamento_de_sess.C3.A3o|"3.4 Gerenciamento de sessão"]]
|-
|'''Sugestões'''
|
*Implementar um token anti-CSRF para prevenir ataques desse tipo.
*Verificar os cabeçalhos "Origin" e/ou "Referer" para identificar a origem do request.
*Setar o cabeçalho "X-Frame-Options" para "sameorigin" ou "deny".
|-
|'''Referências'''
|
*https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
*https://www.owasp.org/index.php/Anti_CSRF_Tokens_ASP.NET
*https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-SESS-001, OTG-SESS-006
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|Ao realizar o logout o cookie de autenticação não é invalidado no servidor, apenas excluido no lado cliente. Assim, forçando o navegador a utilizar o valor antigo do cookie o usuário consegue novamente acesso ao sistema sem realizar o login.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.4_Gerenciamento_de_sess.C3.A3o|"3.4 Gerenciamento de sessão"]]
|-
|'''Sugestões'''
|
*Invalidar o cookie de autenticação no lado servidor quando o usuário realiza o logout.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-SESS-001
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|Ao realizar a primeira requisição para o sistema o usuário recebe um cookie de sessão, e assim que realiza o login com sucesso ele recebe um cookie de autenticação. No entanto o sistema não faz a validação de ambos os cookies, podendo o usuário depois de autenticado continuar navegando apenas com o cookie de sessão ou de autenticação (nesse caso recebendo uma nova sessão).
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.4_Gerenciamento_de_sess.C3.A3o|"3.4 Gerenciamento de sessão"]]
|-
|'''Sugestões'''
|
*Sempre verificar no lado servidor a validade de ambos os cookies, e caso algum cookie esteja ausente ou alterado realizar o logout da sessão do usuário, invalidando ambos os cookies.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-CLIENT-004
|-
|'''Severidade'''
|Baixa
|-
|'''Descrição'''
|O sistema faz o redirecionamento do usuário para outros domínios quando o parâmentro "relaystate" da página "Login.ashx" é alterado para uma url qualquer.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.1_Valida.C3.A7.C3.A3o_dos_dados|"3.1 Validação dos dados"]]
|-
|'''Sugestões'''
|
*Fazer a validação do valor do relaystate antes de redirecionar o usuário, para previnir o redirecionamento para outros domínios no caso da requisição ter sido alterada ou forjada.
|-
|'''Referências'''
|
|}

{| class="wikitable"
|colspan="2" style="text-align: center; | Índices || Resultados
|-
|colspan="2"|Número de itens testes|| style="text-align: center; | 64
|-
|colspan="2"|Número de itens verificados|| style="text-align: center; |40
|-
|colspan="2"|Número de itens (OK)|| style="text-align: center; |31
|-
|colspan="2"|Número de itens (F)|| style="text-align: center; |9
|-
|colspan="2"|Número de itens (NA)|| style="text-align: center; |24
|-
|colspan="2"|Índice de aderência|| style="text-align: center; |78%
|-
|colspan="2"|Índice de não-aderência|| style="text-align: center; |22%
|}

== Verificação de Desempenho ==

=== Observações sobre o teste ===
O CoreSSO utilizado inicialmente para os testes foi o indicado pela equipe do Transportes, copiado do TS-IIS02 e TS-BD. Contudo, o CoreSSO, apresentou problemas, dentre eles o não cadastro da tabela de layout padrão, gerando diversos erros. Desta forma, substituímos o banco e o site por outra versão indicada pela equipe do CoreSSO na época.

Vale ressaltar que o sistema conforme indicação da equipe do Transportes suportaria, em seu limite, o acesso simultâneo de 200 usuários com uma alta taxa de erro no momento de acesso ao sistema Transporte Escolar, tornando necessário a verificação e ajuste do SAML.

=== Cenário de uso ===

{| class="wikitable"
!colspan="6"|Cenário de uso #1
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|1 - Acessar tela de login || style="text-align: center; | 3
|-
|colspan="2"|1 - Realizar login || style="text-align: center; |7
|-
|colspan="2"|1 - Selecionar sistema Transporte Escolar || style="text-align: center; |5
|-
|colspan="2"|2 - Acessar tela de consulta de veículos || style="text-align: center; |5
|-
|colspan="2"|2 - Preencher aba "Documentação" || style="text-align: center; |20
|-
|colspan="2"|2 - Preencher aba "Aquisição" || style="text-align: center; |7
|-
|colspan="2"|2 - Preencher aba "Condutor" || style="text-align: center; |38
|-
|colspan="2"|2 - Preencher aba "Peças e acessórios" || style="text-align: center; |25
|-
|colspan="2"|2 - Preencher aba "Despesas" || style="text-align: center; |15
|-
|colspan="2"|2 - Salvar cadastro || style="text-align: center; |5
|-
|colspan="2"|3 - Logout || style="text-align: center; |5
|}

=== Resultado dos testes ===
Nesta seção serão apresentados os resultados obtidos da execução dos testes.

*'''Porcentagem de tempo do processador'''
: Descrição: Mede a saturação do processador e mostra a quantidade de tempo despendida para processar as threads por todas as CPUs.
: Limite recomendado: Abaixo de 75 %.

:::::: [[Arquivo:2016-06-21 TransporteEscolar TempoDeProcessador.png]]

*'''Porcentagem de memória utilizada'''
: Descrição: Indica a porcentagem de memória utilizada para uso dos processos.
: Limite recomendado: Abaixo de 75 %.

:::::: [[Arquivo:2016-06-21_TransporteEscolar_MemoriaUtilizada.png]]

*'''Kbytes totais pela interface de rede'''
: Descrição: Indica quantos Bbytes foram enviados e recebidos a cada segundo pela interface de rede.
: Limite recomendado: Menor que 5 Mbytes para uma rede de 100Mbps, menor que 50 Mbytes para uma rede de 1000 Mbps. (Quanto menor melhor)

:::::: [[Arquivo:2016-06-21_TransporteEscolar_NetworkTotal.png]]

*'''Tempo médio de resposta das requisições'''
: Descrição: Indica o tempo médio de resposta das requisições.
: Limite recomendado: 5 segundos.

:::::: [[Arquivo:2016-06-21_TransporteEscolar_ResponseTime.png]]

*'''Tempo de vazão'''
: Descrição: Indica a quantidade total de request por segundo.
: Limite recomendado: Quanto maior melhor.

:::::: [[Arquivo:2016-06-22 13-37-47.png]]

Verificação de segurança e desempenho

2016-06-29T13:28:36Z

Lucimara.maiorali: /* Resultado da verificação de segurança e desempenho */

O objetivo da '''verificação de segurança e desempenho''' é analisar através dos testes não funcionais dois dos principais requisitos não funcionais que podem afetar de forma drástica a estabilidade e a qualidade das nossas entregas, sendo de extrema importância na obtenção de um diagnóstico cada vez mais preciso nas ações de melhoria contínua e na garantia da qualidade, visando alcançar patamares mais elevados no desenvolvimento dos nossos produtos.

== Pré-requisitos para execução da verificação de segurança e desempenho ==

*Providenciar a publicação do sistema/aplicação, com a última versão estável, em ambiente de teste administrado pelo DevOps;
*Definir o escopo do teste de segurança e desempenho;
*Descrição resumida das funcionalidades do sistema/aplicação, considerar também as funcionalidades mais críticas (que diferenciam e destacam o produto);
*Informação da existência de problemas de segurança e desempenho conhecidos no sistema/aplicação;
*Definir as permissões por nível de usuário para as principais funcionalidades e ativos do sistema(lista de credenciais ativas(usuário e senha)com pelo menos um usuário para cada nível de permissão.

== Verificação de segurança ==

A verificação de segurança consiste identificar vulnerabilidades, classificá-las e indicar estratégias de mitigação para estas. É realizada uma análise ativa na qual são simulados ataques a um determinado sistema, identificando vulnerabilidades que podem ser exploradas em um ataque real.

Uma '''vulnerabilidade''' é uma falha ou fraqueza no design, implementação, operação ou gerenciamento de um sistema que pode ser explorada a fim de violar a política de segurança do mesmo. Uma '''ameaça''' é um ataque em potencial que, explorando uma vulnerabilidade, pode comprometer os ativos de uma aplicação (recursos, dados, funcionalidades).

Esse processo, conhecido como ''"Vulnerability Assessment"'', deve ser executado em uma versão estável do sistema, após a etapa de desenvolvimento. Primeiramente o sistema é submetido a ''scanners'' de vulnerabilidades automáticos. As vulnerabilidades encontradas pelos ''scripts'' automáticos são então verificadas, para eliminar falsos positivos.

Após o processo automático, o sistema é verificado manualmente por vulnerabilidades de detecção mais difícil, seguindo as diretrizes do [https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents OWASP Guide v4]

A verificação de segurança é executada por [mailto:paulo.souza@mstech.com.br Paulo Roberto Lopes de Souza]

=== Ferramentas utilizadas ===

*'''Ferramentas de Proxy web''' (WebScarab,CAT,OWASP ZAP,Paros)
*'''''Scanners'' de vulnerabilidades automatizados''' (WCSA,OWASP ZAP,N-Stalker,Web Securify,Microsoft WACA,W3AF,VEGA)
*'''''Sniffers''''' (Wireshark,Ettercap)
*'''Gerador de pacotes e requisições ''HTTP''''' (Engage Packet Builder,WebScarab,CAT)

== Verificação de desempenho ==

A verificação de desempenho é uma classe de testes implementada e executada para caracterizar o desempenho relacionado a características do sistema/produto, como fluxos de execução, tempos de respostas e limites operacionais. A verificação de desempenho abrange os seguintes tipos de testes:

*'''Teste de carga''': Verifica a aceitabilidade do comportamento de desempenho do objeto de teste em condições operacionais variáveis (como número de usuários, número de transações, entre outros), enquanto as configurações permanecem as mesmas.

*'''Teste de stress:''' Verifica a aceitabilidade do comportamento de desempenho do objeto de teste quando condições anormais ou externas forem encontradas, como a redução dos recursos ou um número extremamente alto de usuários.

*'''Teste de desempenho:''' Testa a aplicação em uma situação normal de uso, verificando se o tempo de resposta e a utilização do hardware são os desejados.

A verificação de desempenho é executada por [mailto:taynara.nakashima@mstech.com.br Taynara Nakashima]

=== Ambiente padrão de teste ===

Para a realização dos testes foi criado um ambiente padrão composto de servidores web e servidor SQL com distribuição de carga pelo ARR. A VM utilizada para simular usuários navegando pelo sistema é denominado Test Agent e o controlador dos agentes denominado Test Controller. Abaixo é apresentada a configuração dos equipamentos que compõe o ambiente gerador de carga para os testes.

{| class="wikitable"
!colspan="6"|Ambiente padrão de teste
|-
|colspan="2"|ARR
|Estão configurados com DFS entre os arquivos de sistema. Cada um tem 4 núcleos, 4GB de RAM e disco de 200GB dinâmico.
|-
|colspan="2"|HOST
|É um Xeon 2.3 Ghz com 48 núcleos de 384GBde RAM.
|-
|colspan="2"|Servidores Web
|Possuem 8 núcleos cada, 6GB de RAM e disco de 100GB dinâmico. O acesso ao site é através de uma pasta compartilhada no servidor hospedeiro, utilizando o parâmetro caspol do .NET 32 e 64 bits v3.5 e 4 com opção fulltrust.
|-
|colspan="2"|Servidor SQL
|O SQL Server está na versão 2014 Standard e o servidor tem 16 GB de RAM, 16 núcleos, 100GB de disco para dados, 1TB de disco para bancos e 500 GB de disco de backup. Os discos de bancos e backup são volumes diretos na storage, utilizando conexão iSCSI.
|-
|colspan="2"|Test Controller
|Possuem 8 núcleos e 8 GB de RAM, com disdo de 200GB para SO.
|-
|colspan="2"|Test Agent
|Os slaves do JMeter possuem 8 núcleos e 8 GB de RAM com disco de 200GB para SO cada.
|-
|}

=== Ferramentas utilizadas ===

*'''Ferramenta de teste''' (JMeter)
*'''Web Debugging Proxy''' (Fiddler)
*'''Resource and Performance Monitor''' (Perfmon) / Em estudo uso do Zabbix

== Resultado da verificação de segurança e desempenho ==

Como resultado da verificação de segurança e desempenho será enviado um relatório aos responsáveis do produto contendo as vulnerabilidades e itens de melhorias que deverão ser inseridas na '''Product Backlog''' e analisadas em conjunto com a equipe e responsáveis pelas verificações. Este resultado também será disponibilizado no menu "Produtos" [[https://wiki.mstech.com.br/index.php/Produtos Plataforma de Produtos MSTECH]].

{| class="wikitable"
!colspan="6"|Produtos verificados
|-
|colspan="2"|Transporte Escolar
|[[Transporte 1.1.1.21|Versão 1.1.1.21]]
|-
|colspan="2"|Controle Patrimonial
|[[Conpat 2.52.2.0|Versão 2.25.2.0]] em verificação
|-
|colspan="2"|Avalia+
|
|-
|colspan="2"|Approxima
|
|-
|colspan="2"|Portal Construtor
|
|-
|colspan="2"|Almoxarifado
|
|-
|colspan="2"|Atribuição de Aulas
|
|-
|colspan="2"|Biblioteca
|
|-
|colspan="2"|BlueMonitor
|
|-
|colspan="2"|BlueControlWeb
|
|-
|colspan="2"|BlueControl
|
|-
|colspan="2"|Boletim Online
|
|-
|colspan="2"|ClassPad
|
|-
|colspan="2"|Censo Escolar
|
|-
|colspan="2"|Central de Projetos
|
|-
|colspan="2"|CoreSSO
|
|-
|colspan="2"|Coreedu
|
|-
|colspan="2"|Certificados
|
|-
|colspan="2"|Controle de Obras
|
|-
|colspan="2"|Controle Financeiro de Repasses
|
|-
|colspan="2"|Dupla Regência
|
|-
|colspan="2"|Educopédia
|
|-
|colspan="2"|Fiscalização e Contratos
|
|-
|colspan="2"|Fluxos DRH
|
|-
|colspan="2"|Gestão Acadêmica
|
|-
|colspan="2"|Gestão Escolar / SGP
|
|-
|colspan="2"|Gestão Privado
|
|-
|colspan="2"|Gestão de Metas
|
|-
|colspan="2"|Loomi
|
|-
|colspan="2"|Mapa de Indicadores
|
|-
|colspan="2"|OpenId
|
|-
|colspan="2"|Portal Institucional
|
|-
|colspan="2"|Quadro de Horários
|
|-
|colspan="2"|Remoção
|
|-
|colspan="2"|Repositório OA
|
|-
|colspan="2"|Sala de Gestão
|
|}

Introdução ao teste de software

2016-06-29T13:13:47Z

Lucimara.maiorali: /* Testes de desempenho */

Versão 1.0 de 17/06/2016

==O que é testar?==

Encontramos na literatura algumas definições sobre o que é a atividade de testar:

“Testar é analisar um programa com a intenção de descobrir erros e defeitos.” (Myers)
“Testar é exercitar ou simular a operação de um programa ou sistema. ”
“Testar é confiar que um sistema faz o que se espera que ele faça e não faz o que se espera que não faça. ”
“Testar é medir a qualidade e funcionalidade de um sistema. ”
“O teste de programas pode ser usado para mostrar a presença de defeitos, mas nunca para mostrar a sua ausência.” (Dijkstra)

===Objetivo dos testes===

O objetivo principal dos testes é reduzir a probabilidade da ocorrência de um defeito quando o software estiver em produção, minimizando os riscos para o negócio e garantindo que as necessidades do cliente estão sendo atendidas.

===Erro, Defeito e Falha===

*Erro (error): é uma ação humana que produz um resultado incorreto.

*Defeito (fault): A manifestação de um erro no software.
**Também conhecido como Bug;
**Se executado, o defeito pode causar uma falha.

*Falha (failure): diferença indesejável entre o observado e o esperado. (Defeito encontrado)

'''Falha é um evento. Defeito é um estado do software, causado por um erro.'''

===Por que defeitos ocorrem no software?===

*Softwares são escritos por humanos;
*As pessoas não conhecem e não dominam tudo;
*As pessoas têm habilidades, mas não são perfeitas;
*As pessoas cometem erros;
*Tempo de desenvolvimento curto;
*Sem tempo para checar as atividades realizadas;
*Sistemas podem estar incompletos.

===O custo da falta de qualidade e da correção de defeitos===

Estatísticas de mercado apontam que para cada R$ 1,00 investido no desenvolvimento e manutenção de software, entre R$ 2,00 e R$ 3,00 são gastos com retrabalho.

*Talvez o software ou parte dele precise ser refeito, o que aumenta ainda mais os custos;
*Não se sabe, através de métricas claras e precisas, quais são as principais áreas de produção que geram retrabalho.

Existem alguns tipos de sistemas onde:

*As falhas causam prejuízos diretos, ou
*As falhas causam a perda de confiança do público (clientes e usuários).

A Regra 10 de Myers indica que o custo da correção de um defeito tende a ser cada vez maior quanto mais tarde ele for descoberto. Defeitos encontrados nas fases iniciais da etapa de desenvolvimento do software são mais baratos de serem corrigidos do que aqueles encontrados na produção.

===Por que testar é necessário?===

*Porque é provável que o software possua defeitos;
*Para descobrir a confiabilidade do software;
*Porque falhas podem custar muito caro;
*Para demonstrar as conformidades com os requisitos;
*Para assegurar que as necessidades dos usuários estejam sendo atendidas;
*Para reduzir custos;
*Para avaliar a qualidade do software.

====Não devemos testar====

*Para provar que o software não tem defeitos;
*Apenas porque os testes estão incluídos no plano de projeto.

===Mitos sobre o teste de software===

'''O testador é inimigo do desenvolvedor.'''
*Todos fazem parte da mesma equipe e trabalham para o sucesso dos projetos. O papel do testador não é apontar erros do desenvolvedor e sim trabalhar em conjunto para agregar qualidade ao produto final.
*Os desenvolvedores jamais devem levar o cadastro de bugs de uma tarefa que desenvolveu como algo pessoal, assim como os testadores devem entender quando a equipe não priorizar um ou mais bugs que tenha encontrado.

'''A equipe de testes pode ser formada pelos desenvolvedores menos qualificados.'''
*Uma equipe de testes necessita de pessoas que conheçam os sistemas, técnicas de teste, conhecimento em diversos tipos de teste, além de competências como atenção, olhar crítico, organização, etc.

'''*Quando estiver tudo pronto, o sistema vai para teste.'''
*O ideal é que o teste seja envolvido mais cedo no processo de desenvolvimento. Quando antes os testes forem realizados, mais cedo os problemas serão encontrados e resolvidos.

'''Teste de software não exige muito intelectualmente.'''
*Se há apenas repetições de ações predefinidas, teste realmente pode não exigir muito do testador nesse aspecto. Mas é importante pensar em testes como uma forma de explorar, coletar informações e encontrar respostas a coisas que ainda não foram questionadas. E para alcançar esse nível de detalhamento é preciso pensar, observar e analisar muito o sistema a ser testado.

'''Se o software foi testado, então não pode ter bugs.'''
*Este é um dos mitos mais comuns entre clientes e gestores de projetos. Ninguém pode afirmar com absoluta certeza que um software está 100% livre de bugs, mesmo que tenha sido testado por um testador com capacidades magníficas.

'''Os testadores são os únicos responsáveis pela qualidade do produto.'''
*É uma atitude muito comum pensar que apenas os testadores (ou a equipe de testes) são responsáveis pela qualidade do produto. As responsabilidades dos testadores incluem a detecção de bugs para os responsáveis pelo projeto, e são os responsáveis que decidem se efetuam correções ou se dão o software como concluído.
*A qualidade do produto é um dever de todos os integrantes da equipe de desenvolvimento, e não apenas do testador.

==Tipos de testes==

===Testes de segurança===

A principal meta do teste de segurança é garantir que os dados ou funções de um sistema possam ser acessados apenas por atores autorizados a acessá-los. Todas as formas de ataque de acesso indevido devem ser simuladas.

'''Objetivos:'''

*Garantir que os dados do sistema estão protegidos adequadamente;
*Assegurar que todos os riscos que envolvem os acessos indevidos foram identificados;
*Analisar as ameaças e vulnerabilidades, tanto físicas como lógicas;
*Assegurar que os mecanismos de controle contra acessos indevidos foram corretamente implementados.

'''Quando usar:'''

*Testes básicos de segurança devem ser aplicados a todos os softwares;
*Quando a informação que circula através do software for de importância fundamental para a organização.

===Testes de performance===

O teste de performance, ou de desempenho como também é conhecido, mede e avalia o tempo de resposta, o número de transações e outros requisitos sensíveis ao tempo de resposta do sistema.

'''Objetivos:'''

*Determinar o tempo de resposta das transações;
*Verificar se os critérios de desempenho estabelecidos estão sendo atendidos;
*Identificar pontos de gargalo no sistema;
*Verificar o nível de utilização do hardware e software.

'''Quando usar:'''

*Quando se deseja avaliar o tempo de resposta de uma funcionalidade do sistema ou de todo o sistema;
*Devem ser realizados quando ainda há tempo hábil de serem realizadas correções.

===Testes funcionais baseados em requisitos===

O teste funcional baseado em requisitos tem por meta verificar se o software executa corretamente suas funções, se a implementação das regras de negócio foi apropriada e se o sistema é capaz de sustentar sua correta execução por um período contínuo de uso.

'''Objetivos:'''

*Assegurar a funcionalidade do sistema, incluindo entrada de dados, processamento e resposta;
*Verificar se os requisitos dos usuários estão implementados;
*Verificar se o sistema funciona corretamente após um período contínuo de utilização.

'''Quando usar:'''

*Qualquer sistema deve ter suas funcionalidades testadas;
*Pode ser usado desde a fase de especificação de requisitos até a fase de operação do sistema.

===Teste de usabilidade===

O teste de usabilidade verifica a facilidade que o software possui de ser claramente entendido e facilmente operado pelos usuários.

'''Objetivos:'''

*Verificar a facilidade de operação do sistema pelo usuário;
*Verificar a facilidade de entendimento das funções do sistema pelo usuário, através da utilização de manuais, on-line help, agentes e assistentes eletrônicos, etc.

'''Quando usar:'''

*Quando se deseja avaliar a complexidade de entendimento das telas e o fluxo de informação;
*Pode ser executado em conjunto com outros testes (funcionalidade, acessibilidade).

==Visão geral sobre o processo de testes na MSTECH==

Na MSTECH, '''TODOS''' são responsáveis pela qualidade dos produtos desenvolvidos.

*Os Analistas de requisitos e POs devem prezar pela qualidade das informações trazidas dos clientes e apresentar documentações de sistema consistentes;

*Os Desenvolvedores devem prezar pela qualidade dos sistemas, verificando:
**Se tirou todas as dúvidas sobre o requisito que vai desenvolver;
**Se desenvolveu tudo o que foi solicitado no documento de requisitos;
**Se codificou de acordo com os padrões definidos pela MSTECH;
**Se realizou testes em todos os fluxos das páginas desenvolvidas, incluindo regras de campos numéricos, textos e regras de negócio do cliente.

*Os Analistas de testes devem analisar o sistema desenvolvido, planejar testes de acordo com as regras de negócio e executá-los, a fim de encontrar defeitos nos sistemas.
**Os analistas de testes devem ter seu foco principal em encontrar problemas de regras de negócio que vão impactar diretamente o cliente.
**Entende-se que, quando o desenvolvedor terminou sua tarefa, ele realizou os testes básicos (se campos de data aceitam datas inválidas, se campos numéricos aceitam letras, etc.);
**O analista de testes deve prezar pela qualidade dos sistemas, tendo um entendimento amplo de seu funcionamento e suas regras de negócio;
**Deve registrar todos os problemas encontrados.

===A qualidade nas etapas de desenvolvimento===

====Planning====

A MSTECH utiliza a metodologia rápida de desenvolvimento SCRUM.
Antes do início de uma nova Sprint, os membros da equipe recebem do PO o documento de requisitos para a próxima versão do sistema. Esse documento deve conter os requisitos do cliente, suas regras de negócio e observações. Os membros da equipe devem ler o documento e anotar dúvidas, sugestões e problemas para serem discutidos no planning.

====Desenvolvimento====

Após o Planning, os desenvolvedores iniciarão a construção do sistema, enquanto os Analistas de testes planejam e criam casos de teste.
É importante que o desenvolvedor tenha sanado todas as suas dúvidas antes de iniciar suas atividades.
Quando um desenvolvedor termina sua tarefa, é muito importante que ele revise tudo o que foi desenvolvido:

*Todas as regras de negócio foram implementadas?
*O desenvolvimento foi feito dentro dos padrões?
*Todos os campos se comportam como o esperado?
*A tela executa todos os fluxos (Cadastrar, Alterar, Excluir, etc.)?

====Testes funcionais das tarefas desenvolvidas====

Quando um desenvolvedor termina o desenvolvimento, realiza testes e dá a tarefa como encerrada, os Analistas de testes vão repassar todas as regras de negócio e verificar se tudo foi desenvolvido conforme o requisito exige.

====Bugs====

Durante os testes, os Analistas de testes podem encontrar problemas, que podem ser de regras de negócio, problemas de funcionalidades, usabilidade, acessibidade, etc.
Os bugs serão cadastrados no sistema destinado para isso (Youtrack ou TFS), contendo:

*Título (descrição resumida);
*Ambiente de testes em que o bug foi encontrado, incluindo o BD utilizado;
*Passos para a reprodução do problema;
*Resultado obtido;
*Resultado esperado;
*Imagens e vídeos para ajudar no entendimento do problema.

Além disso, os bugs contém campos de classificação. Todos os bugs devem ser classificados de acordo com seu tipo: Funcionalidade, Usabilidade, Configuração, Layout ou Acessibilidade. Através dessa classificação, os gestores podem fazer análises estatísticas dos bugs abertos e elaborar planos de melhoria do desenvolvimento.
Existe um Guia para auxiliar na classificação de bugs e, em caso de dúvidas, os analistas de testes estão preparados para auxiliar.
Os desenvolvedores podem e devem conversar com os analistas de testes, tirando dúvidas sobre o sistema e sobre os bugs.
Vale lembrar que qualquer pessoa da equipe pode cadastrar um bug. Não é uma exclusividade dos Analistas de testes.

====Correção e reteste====

Os desenvolvedores deverão analisar os bugs abertos. Constatando o problema, deverá proceder com a correção. Pode ocorrer do bug cadastrado não ser válido (regra de negócio mudou, PO mudou a definição e não atualizou o documento, etc.). Nesses casos, o desenvolvedor deve registrar o ocorrido no bug e devolvê-lo para reteste.
Os Analistas de testes ficarão responsáveis por realizar novos testes e verificar as correções.

===A equipe de testes===

Atualmente a MSTECH conta com 8 analistas de testes, que estão capacitados para executar testes funcionais e não funcionais.

*André Iguera (Testes funcionais)
*Ana Guedes (Testes funcionais)
*Elizabeth Fidencio (Testes funcionais)
*Halana Camuci (Testes funcionais)
*Jaqueline Sgarbi (Testes funcionais)
*Marrielly Garcia (Testes funcionais)
*Paulo Souza (Testes de performance e segurança)
*Taynara Jacon (Testes funcionais e performance)

===Quando os testes são executados?===

Os testes funcionais baseados em requisitos e os testes de usabilidade são executados em paralelo com o desenvolvimento das entregas.
Os testes de segurança, performance e acessibilidade são executados com agendamento prévio pelos responsáveis pelos projetos.

Introdução ao teste de software

2016-06-29T13:13:21Z

Lucimara.maiorali: /* Testes de performance */

Versão 1.0 de 17/06/2016

==O que é testar?==

Encontramos na literatura algumas definições sobre o que é a atividade de testar:

“Testar é analisar um programa com a intenção de descobrir erros e defeitos.” (Myers)
“Testar é exercitar ou simular a operação de um programa ou sistema. ”
“Testar é confiar que um sistema faz o que se espera que ele faça e não faz o que se espera que não faça. ”
“Testar é medir a qualidade e funcionalidade de um sistema. ”
“O teste de programas pode ser usado para mostrar a presença de defeitos, mas nunca para mostrar a sua ausência.” (Dijkstra)

===Objetivo dos testes===

O objetivo principal dos testes é reduzir a probabilidade da ocorrência de um defeito quando o software estiver em produção, minimizando os riscos para o negócio e garantindo que as necessidades do cliente estão sendo atendidas.

===Erro, Defeito e Falha===

*Erro (error): é uma ação humana que produz um resultado incorreto.

*Defeito (fault): A manifestação de um erro no software.
**Também conhecido como Bug;
**Se executado, o defeito pode causar uma falha.

*Falha (failure): diferença indesejável entre o observado e o esperado. (Defeito encontrado)

'''Falha é um evento. Defeito é um estado do software, causado por um erro.'''

===Por que defeitos ocorrem no software?===

*Softwares são escritos por humanos;
*As pessoas não conhecem e não dominam tudo;
*As pessoas têm habilidades, mas não são perfeitas;
*As pessoas cometem erros;
*Tempo de desenvolvimento curto;
*Sem tempo para checar as atividades realizadas;
*Sistemas podem estar incompletos.

===O custo da falta de qualidade e da correção de defeitos===

Estatísticas de mercado apontam que para cada R$ 1,00 investido no desenvolvimento e manutenção de software, entre R$ 2,00 e R$ 3,00 são gastos com retrabalho.

*Talvez o software ou parte dele precise ser refeito, o que aumenta ainda mais os custos;
*Não se sabe, através de métricas claras e precisas, quais são as principais áreas de produção que geram retrabalho.

Existem alguns tipos de sistemas onde:

*As falhas causam prejuízos diretos, ou
*As falhas causam a perda de confiança do público (clientes e usuários).

A Regra 10 de Myers indica que o custo da correção de um defeito tende a ser cada vez maior quanto mais tarde ele for descoberto. Defeitos encontrados nas fases iniciais da etapa de desenvolvimento do software são mais baratos de serem corrigidos do que aqueles encontrados na produção.

===Por que testar é necessário?===

*Porque é provável que o software possua defeitos;
*Para descobrir a confiabilidade do software;
*Porque falhas podem custar muito caro;
*Para demonstrar as conformidades com os requisitos;
*Para assegurar que as necessidades dos usuários estejam sendo atendidas;
*Para reduzir custos;
*Para avaliar a qualidade do software.

====Não devemos testar====

*Para provar que o software não tem defeitos;
*Apenas porque os testes estão incluídos no plano de projeto.

===Mitos sobre o teste de software===

'''O testador é inimigo do desenvolvedor.'''
*Todos fazem parte da mesma equipe e trabalham para o sucesso dos projetos. O papel do testador não é apontar erros do desenvolvedor e sim trabalhar em conjunto para agregar qualidade ao produto final.
*Os desenvolvedores jamais devem levar o cadastro de bugs de uma tarefa que desenvolveu como algo pessoal, assim como os testadores devem entender quando a equipe não priorizar um ou mais bugs que tenha encontrado.

'''A equipe de testes pode ser formada pelos desenvolvedores menos qualificados.'''
*Uma equipe de testes necessita de pessoas que conheçam os sistemas, técnicas de teste, conhecimento em diversos tipos de teste, além de competências como atenção, olhar crítico, organização, etc.

'''*Quando estiver tudo pronto, o sistema vai para teste.'''
*O ideal é que o teste seja envolvido mais cedo no processo de desenvolvimento. Quando antes os testes forem realizados, mais cedo os problemas serão encontrados e resolvidos.

'''Teste de software não exige muito intelectualmente.'''
*Se há apenas repetições de ações predefinidas, teste realmente pode não exigir muito do testador nesse aspecto. Mas é importante pensar em testes como uma forma de explorar, coletar informações e encontrar respostas a coisas que ainda não foram questionadas. E para alcançar esse nível de detalhamento é preciso pensar, observar e analisar muito o sistema a ser testado.

'''Se o software foi testado, então não pode ter bugs.'''
*Este é um dos mitos mais comuns entre clientes e gestores de projetos. Ninguém pode afirmar com absoluta certeza que um software está 100% livre de bugs, mesmo que tenha sido testado por um testador com capacidades magníficas.

'''Os testadores são os únicos responsáveis pela qualidade do produto.'''
*É uma atitude muito comum pensar que apenas os testadores (ou a equipe de testes) são responsáveis pela qualidade do produto. As responsabilidades dos testadores incluem a detecção de bugs para os responsáveis pelo projeto, e são os responsáveis que decidem se efetuam correções ou se dão o software como concluído.
*A qualidade do produto é um dever de todos os integrantes da equipe de desenvolvimento, e não apenas do testador.

==Tipos de testes==

===Testes de segurança===

A principal meta do teste de segurança é garantir que os dados ou funções de um sistema possam ser acessados apenas por atores autorizados a acessá-los. Todas as formas de ataque de acesso indevido devem ser simuladas.

'''Objetivos:'''

*Garantir que os dados do sistema estão protegidos adequadamente;
*Assegurar que todos os riscos que envolvem os acessos indevidos foram identificados;
*Analisar as ameaças e vulnerabilidades, tanto físicas como lógicas;
*Assegurar que os mecanismos de controle contra acessos indevidos foram corretamente implementados.

'''Quando usar:'''

*Testes básicos de segurança devem ser aplicados a todos os softwares;
*Quando a informação que circula através do software for de importância fundamental para a organização.

===Testes de desempenho===

O teste de desempenho, ou de desempenho como também é conhecido, mede e avalia o tempo de resposta, o número de transações e outros requisitos sensíveis ao tempo de resposta do sistema.

'''Objetivos:'''

*Determinar o tempo de resposta das transações;
*Verificar se os critérios de desempenho estabelecidos estão sendo atendidos;
*Identificar pontos de gargalo no sistema;
*Verificar o nível de utilização do hardware e software.

'''Quando usar:'''

*Quando se deseja avaliar o tempo de resposta de uma funcionalidade do sistema ou de todo o sistema;
*Devem ser realizados quando ainda há tempo hábil de serem realizadas correções.

===Testes funcionais baseados em requisitos===

O teste funcional baseado em requisitos tem por meta verificar se o software executa corretamente suas funções, se a implementação das regras de negócio foi apropriada e se o sistema é capaz de sustentar sua correta execução por um período contínuo de uso.

'''Objetivos:'''

*Assegurar a funcionalidade do sistema, incluindo entrada de dados, processamento e resposta;
*Verificar se os requisitos dos usuários estão implementados;
*Verificar se o sistema funciona corretamente após um período contínuo de utilização.

'''Quando usar:'''

*Qualquer sistema deve ter suas funcionalidades testadas;
*Pode ser usado desde a fase de especificação de requisitos até a fase de operação do sistema.

===Teste de usabilidade===

O teste de usabilidade verifica a facilidade que o software possui de ser claramente entendido e facilmente operado pelos usuários.

'''Objetivos:'''

*Verificar a facilidade de operação do sistema pelo usuário;
*Verificar a facilidade de entendimento das funções do sistema pelo usuário, através da utilização de manuais, on-line help, agentes e assistentes eletrônicos, etc.

'''Quando usar:'''

*Quando se deseja avaliar a complexidade de entendimento das telas e o fluxo de informação;
*Pode ser executado em conjunto com outros testes (funcionalidade, acessibilidade).

==Visão geral sobre o processo de testes na MSTECH==

Na MSTECH, '''TODOS''' são responsáveis pela qualidade dos produtos desenvolvidos.

*Os Analistas de requisitos e POs devem prezar pela qualidade das informações trazidas dos clientes e apresentar documentações de sistema consistentes;

*Os Desenvolvedores devem prezar pela qualidade dos sistemas, verificando:
**Se tirou todas as dúvidas sobre o requisito que vai desenvolver;
**Se desenvolveu tudo o que foi solicitado no documento de requisitos;
**Se codificou de acordo com os padrões definidos pela MSTECH;
**Se realizou testes em todos os fluxos das páginas desenvolvidas, incluindo regras de campos numéricos, textos e regras de negócio do cliente.

*Os Analistas de testes devem analisar o sistema desenvolvido, planejar testes de acordo com as regras de negócio e executá-los, a fim de encontrar defeitos nos sistemas.
**Os analistas de testes devem ter seu foco principal em encontrar problemas de regras de negócio que vão impactar diretamente o cliente.
**Entende-se que, quando o desenvolvedor terminou sua tarefa, ele realizou os testes básicos (se campos de data aceitam datas inválidas, se campos numéricos aceitam letras, etc.);
**O analista de testes deve prezar pela qualidade dos sistemas, tendo um entendimento amplo de seu funcionamento e suas regras de negócio;
**Deve registrar todos os problemas encontrados.

===A qualidade nas etapas de desenvolvimento===

====Planning====

A MSTECH utiliza a metodologia rápida de desenvolvimento SCRUM.
Antes do início de uma nova Sprint, os membros da equipe recebem do PO o documento de requisitos para a próxima versão do sistema. Esse documento deve conter os requisitos do cliente, suas regras de negócio e observações. Os membros da equipe devem ler o documento e anotar dúvidas, sugestões e problemas para serem discutidos no planning.

====Desenvolvimento====

Após o Planning, os desenvolvedores iniciarão a construção do sistema, enquanto os Analistas de testes planejam e criam casos de teste.
É importante que o desenvolvedor tenha sanado todas as suas dúvidas antes de iniciar suas atividades.
Quando um desenvolvedor termina sua tarefa, é muito importante que ele revise tudo o que foi desenvolvido:

*Todas as regras de negócio foram implementadas?
*O desenvolvimento foi feito dentro dos padrões?
*Todos os campos se comportam como o esperado?
*A tela executa todos os fluxos (Cadastrar, Alterar, Excluir, etc.)?

====Testes funcionais das tarefas desenvolvidas====

Quando um desenvolvedor termina o desenvolvimento, realiza testes e dá a tarefa como encerrada, os Analistas de testes vão repassar todas as regras de negócio e verificar se tudo foi desenvolvido conforme o requisito exige.

====Bugs====

Durante os testes, os Analistas de testes podem encontrar problemas, que podem ser de regras de negócio, problemas de funcionalidades, usabilidade, acessibidade, etc.
Os bugs serão cadastrados no sistema destinado para isso (Youtrack ou TFS), contendo:

*Título (descrição resumida);
*Ambiente de testes em que o bug foi encontrado, incluindo o BD utilizado;
*Passos para a reprodução do problema;
*Resultado obtido;
*Resultado esperado;
*Imagens e vídeos para ajudar no entendimento do problema.

Além disso, os bugs contém campos de classificação. Todos os bugs devem ser classificados de acordo com seu tipo: Funcionalidade, Usabilidade, Configuração, Layout ou Acessibilidade. Através dessa classificação, os gestores podem fazer análises estatísticas dos bugs abertos e elaborar planos de melhoria do desenvolvimento.
Existe um Guia para auxiliar na classificação de bugs e, em caso de dúvidas, os analistas de testes estão preparados para auxiliar.
Os desenvolvedores podem e devem conversar com os analistas de testes, tirando dúvidas sobre o sistema e sobre os bugs.
Vale lembrar que qualquer pessoa da equipe pode cadastrar um bug. Não é uma exclusividade dos Analistas de testes.

====Correção e reteste====

Os desenvolvedores deverão analisar os bugs abertos. Constatando o problema, deverá proceder com a correção. Pode ocorrer do bug cadastrado não ser válido (regra de negócio mudou, PO mudou a definição e não atualizou o documento, etc.). Nesses casos, o desenvolvedor deve registrar o ocorrido no bug e devolvê-lo para reteste.
Os Analistas de testes ficarão responsáveis por realizar novos testes e verificar as correções.

===A equipe de testes===

Atualmente a MSTECH conta com 8 analistas de testes, que estão capacitados para executar testes funcionais e não funcionais.

*André Iguera (Testes funcionais)
*Ana Guedes (Testes funcionais)
*Elizabeth Fidencio (Testes funcionais)
*Halana Camuci (Testes funcionais)
*Jaqueline Sgarbi (Testes funcionais)
*Marrielly Garcia (Testes funcionais)
*Paulo Souza (Testes de performance e segurança)
*Taynara Jacon (Testes funcionais e performance)

===Quando os testes são executados?===

Os testes funcionais baseados em requisitos e os testes de usabilidade são executados em paralelo com o desenvolvimento das entregas.
Os testes de segurança, performance e acessibilidade são executados com agendamento prévio pelos responsáveis pelos projetos.

Testes

2016-06-29T12:59:40Z

Lucimara.maiorali: /* Testes funcionais e não funcionais */

==Sobre o teste de software na MSTECH==

A MSTECH tem um longo histórico de comprometimento com a qualidade dos produtos desenvolvidos. Criou, estimulou e dá constante suporte à equipe de testes de softwares, que foi se adaptando e evoluindo para atender às necessidades internas.

====A equipe====

Contamos com oito profissionais de testes que estão aptos para realizar diversas verificações nos produtos da empresa.
Conheça o time de testes da MSTECH!

* Ana Guedes
* André Iguera
* Elizabeth Fidencio
* Halana Camuci
* Jaqueline Sgarbi
* Marrielly Garcia
* Paulo Souza
* Taynara Jacon

====Testes funcionais e não funcionais====
A equipe de testes da MSTECH está preparada para realizar diversas verificações nos produtos desenvolvidos: teste funcional baseado em requisitos, teste exploratório, teste de acessibilidade, teste de desempenho e teste de segurança.

====Melhorias do produto e experiência do usuário====
Os analistas de testes podem sugerir melhorias aos responsáveis pelos produtos com base em suas experiências de uso do software, sempre direcionando esfoços para oferecer aos nossos clientes a melhor experiência de uso.

====Melhoria interna contínua====
Através dos fóruns de especialidades, estamos criando, reciclando e discutindo novas formas de trabalho.

==Fórum de especialidades==

Os fóruns da especialidade Testes ocorrem quinzenalmente. São trazidos problemas, sugestões, críticas e propostas de melhoria no processo de testes de softwares. Após as discussões e outras diligências, ações são tomadas e registradas.

*[[Decisões tomadas da equipe de Testes]]

==Glossário de testes==

O Glossário de testes contém os termos mais utilizados no processo de testes.

*[[Glossário de testes]]

==Softwares e utilitários==

Lista de softwares e sites utilizados para a realização de testes nos sistemas desenvolvidos.

*[[Softwares e utilitários para testes]]

==Documentos, guias e padrões==

*[[Introdução ao teste de software]]
*[[Guia e padrões para o cadastro de bugs]] (Pendente)
*[[Dicas de português]]
*[[Guia para classificação de bugs]]
*[[Guia para geração de relatórios de bugs do Youtrack]]
*[[Padrões para definição de criticidade de bugs]]

Verificação de segurança e desempenho

2016-06-27T18:17:22Z

Lucimara.maiorali: /* Ambiente de teste */

O objetivo da '''verificação de segurança e desempenho''' é analisar através dos testes não funcionais dois dos principais requisitos não funcionais que podem afetar de forma drástica a estabilidade e a qualidade das nossas entregas, sendo de extrema importância na obtenção de um diagnóstico cada vez mais preciso nas ações de melhoria contínua e na garantia da qualidade, visando alcançar patamares mais elevados no desenvolvimento dos nossos produtos.

== Pré-requisitos para execução da verificação de segurança e desempenho ==

*Providenciar a publicação do sistema/aplicação, com a última versão estável, em ambiente de teste administrado pelo DevOps;
*Definir o escopo do teste de segurança e desempenho;
*Descrição resumida das funcionalidades do sistema/aplicação, considerar também as funcionalidades mais críticas (que diferenciam e destacam o produto);
*Informação da existência de problemas de segurança e desempenho conhecidos no sistema/aplicação;
*Definir as permissões por nível de usuário para as principais funcionalidades e ativos do sistema(lista de credenciais ativas(usuário e senha)com pelo menos um usuário para cada nível de permissão.

== Verificação de segurança ==

A verificação de segurança consiste identificar vulnerabilidades, classificá-las e indicar estratégias de mitigação para estas. É realizada uma análise ativa na qual são simulados ataques a um determinado sistema, identificando vulnerabilidades que podem ser exploradas em um ataque real.

Uma '''vulnerabilidade''' é uma falha ou fraqueza no design, implementação, operação ou gerenciamento de um sistema que pode ser explorada a fim de violar a política de segurança do mesmo. Uma '''ameaça''' é um ataque em potencial que, explorando uma vulnerabilidade, pode comprometer os ativos de uma aplicação (recursos, dados, funcionalidades).

Esse processo, conhecido como ''"Vulnerability Assessment"'', deve ser executado em uma versão estável do sistema, após a etapa de desenvolvimento. Primeiramente o sistema é submetido a ''scanners'' de vulnerabilidades automáticos. As vulnerabilidades encontradas pelos ''scripts'' automáticos são então verificadas, para eliminar falsos positivos.

Após o processo automático, o sistema é verificado manualmente por vulnerabilidades de detecção mais difícil, seguindo as diretrizes do [https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents OWASP Guide v4]

A verificação de segurança é executada por [mailto:paulo.souza@mstech.com.br Paulo Roberto Lopes de Souza]

=== Ferramentas utilizadas ===

*'''Ferramentas de Proxy web''' (WebScarab,CAT,OWASP ZAP,Paros)
*'''''Scanners'' de vulnerabilidades automatizados''' (WCSA,OWASP ZAP,N-Stalker,Web Securify,Microsoft WACA,W3AF,VEGA)
*'''''Sniffers''''' (Wireshark,Ettercap)
*'''Gerador de pacotes e requisições ''HTTP''''' (Engage Packet Builder,WebScarab,CAT)

== Verificação de desempenho ==

A verificação de desempenho é uma classe de testes implementada e executada para caracterizar o desempenho relacionado a características do sistema/produto, como fluxos de execução, tempos de respostas e limites operacionais. A verificação de desempenho abrange os seguintes tipos de testes:

*'''Teste de carga''': Verifica a aceitabilidade do comportamento de desempenho do objeto de teste em condições operacionais variáveis (como número de usuários, número de transações, entre outros), enquanto as configurações permanecem as mesmas.

*'''Teste de stress:''' Verifica a aceitabilidade do comportamento de desempenho do objeto de teste quando condições anormais ou externas forem encontradas, como a redução dos recursos ou um número extremamente alto de usuários.

*'''Teste de desempenho:''' Testa a aplicação em uma situação normal de uso, verificando se o tempo de resposta e a utilização do hardware são os desejados.

A verificação de desempenho é executada por [mailto:taynara.nakashima@mstech.com.br Taynara Nakashima]

=== Ambiente padrão de teste ===

Para a realização dos testes foi criado um ambiente padrão composto de servidores web e servidor SQL com distribuição de carga pelo ARR. A VM utilizada para simular usuários navegando pelo sistema é denominado Test Agent e o controlador dos agentes denominado Test Controller. Abaixo é apresentada a configuração dos equipamentos que compõe o ambiente gerador de carga para os testes.

{| class="wikitable"
!colspan="6"|Ambiente padrão de teste
|-
|colspan="2"|ARR
|Estão configurados com DFS entre os arquivos de sistema. Cada um tem 4 núcleos, 4GB de RAM e disco de 200GB dinâmico.
|-
|colspan="2"|HOST
|É um Xeon 2.3 Ghz com 48 núcleos de 384GBde RAM.
|-
|colspan="2"|Servidores Web
|Possuem 8 núcleos cada, 6GB de RAM e disco de 100GB dinâmico. O acesso ao site é através de uma pasta compartilhada no servidor hospedeiro, utilizando o parâmetro caspol do .NET 32 e 64 bits v3.5 e 4 com opção fulltrust.
|-
|colspan="2"|Servidor SQL
|O SQL Server está na versão 2014 Standard e o servidor tem 16 GB de RAM, 16 núcleos, 100GB de disco para dados, 1TB de disco para bancos e 500 GB de disco de backup. Os discos de bancos e backup são volumes diretos na storage, utilizando conexão iSCSI.
|-
|colspan="2"|Test Controller
|Possuem 8 núcleos e 8 GB de RAM, com disdo de 200GB para SO.
|-
|colspan="2"|Test Agent
|Os slaves do JMeter possuem 8 núcleos e 8 GB de RAM com disco de 200GB para SO cada.
|-
|}

=== Ferramentas utilizadas ===

*'''Ferramenta de teste''' (JMeter)
*'''Web Debugging Proxy''' (Fiddler)
*'''Resource and Performance Monitor''' (Perfmon) / Em estudo uso do Zabbix

== Resultado da verificação de segurança e desempenho ==

Como resultado da verificação de segurança e desempenho será enviado um relatório aos responsáveis do produto contendo as vulnerabilidades e itens de melhorias que deverão ser inseridas na '''Product Backlog''' e analisadas em conjunto com a equipe e responsáveis pelas verificações. Este resultado também será disponibilizado no menu "Produtos" [[https://wiki.mstech.com.br/index.php/Produtos Plataforma de Produtos MSTECH]].

{| class="wikitable"
!colspan="6"|Produtos verificados
|-
|colspan="2"|Transporte Escolar
|[[Transporte 1.1.1.21|Versão 1.1.1.21]]
|-
|colspan="2"|Controle Patrimonial
|[[Conpat 2.52.2.0|Versão 2.25.2.0]] em verificação
|-
|colspan="2"|Portal Construtor
|
|-
|colspan="2"|Approxima
|
|-
|colspan="2"|Avalia+
|
|-
|colspan="2"|Almoxarifado
|
|-
|colspan="2"|Atribuição de Aulas
|
|-
|colspan="2"|Biblioteca
|
|-
|colspan="2"|BlueMonitor
|
|-
|colspan="2"|BlueControlWeb
|
|-
|colspan="2"|BlueControl
|
|-
|colspan="2"|Boletim Online
|
|-
|colspan="2"|ClassPad
|
|-
|colspan="2"|Censo Escolar
|
|-
|colspan="2"|Central de Projetos
|
|-
|colspan="2"|CoreSSO
|
|-
|colspan="2"|Coreedu
|
|-
|colspan="2"|Certificados
|
|-
|colspan="2"|Controle de Obras
|
|-
|colspan="2"|Controle Financeiro de Repasses
|
|-
|colspan="2"|Dupla Regência
|
|-
|colspan="2"|Educopédia
|
|-
|colspan="2"|Fiscalização e Contratos
|
|-
|colspan="2"|Fluxos DRH
|
|-
|colspan="2"|Gestão Acadêmica
|
|-
|colspan="2"|Gestão Escolar / SGP
|
|-
|colspan="2"|Gestão Privado
|
|-
|colspan="2"|Gestão de Metas
|
|-
|colspan="2"|Loomi
|
|-
|colspan="2"|Mapa de Indicadores
|
|-
|colspan="2"|OpenId
|
|-
|colspan="2"|Portal Institucional
|
|-
|colspan="2"|Quadro de Horários
|
|-
|colspan="2"|Remoção
|
|-
|colspan="2"|Repositório OA
|
|-
|colspan="2"|Sala de Gestão
|
|}

Transporte 1.1.1.21

2016-06-27T18:15:06Z

Lucimara.maiorali: /* Resultados dos Testes */

== Sistemas Verificados ==

*Transporte Escolar, versão 1.1.1.21
*Transporte Escolar Api, versão 1.0.0.0

== Verificação de Segurança ==

=== Testes Realizados ===

{| class="wikitable"
!Item de Teste
!Referência OWASP
!Resultado
|-
|Review Webpage Comments and Metadata for Information Leakage
|[https://www.owasp.org/index.php/Review_webpage_comments_and_metadata_for_information_leakage_(OTG-INFO-005) OTG-INFO-005]
|OK
|-
|Test Application Platform Configuration
|[https://www.owasp.org/index.php/Test_Application_Platform_Configuration_(OTG-CONFIG-002) OTG-CONFIG-002]
|NA
|-
|Test File Extensions Handling for Sensitive Information
|[https://www.owasp.org/index.php/Test_File_Extensions_Handling_for_Sensitive_Information_(OTG-CONFIG-003) OTG-CONFIG-003]
|OK
|-
|Review Old, Backup and Unreferenced Files for Sensitive Information
|[https://www.owasp.org/index.php/Review_Old,_Backup_and_Unreferenced_Files_for_Sensitive_Information_(OTG-CONFIG-004) OTG-CONFIG-004]
|F
|-
|Test HTTP Methods
|[https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006) OTG-CONFIG-006]
|NA
|-
|Test HTTP Strict Transport Security
|[https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007) OTG-CONFIG-007]
|F
|-
|Test RIA cross domain policy
|[https://www.owasp.org/index.php/Test_RIA_cross_domain_policy_(OTG-CONFIG-008) OTG-CONFIG-008]
|NA
|-
|Test Role Definitions
|[https://www.owasp.org/index.php/Test_Role_Definitions_(OTG-IDENT-001) OTG-IDENT-001]
|NA
|-
|Test User Registration Process
|[https://www.owasp.org/index.php/Test_User_Registration_Process_(OTG-IDENT-002) OTG-IDENT-002]
|NA
|-
|Test Account Provisioning Process
|[https://www.owasp.org/index.php/Test_Account_Provisioning_Process_(OTG-IDENT-003) OTG-IDENT-003]
|NA
|-
|Testing for Account Enumeration and Guessable User Account
|[https://www.owasp.org/index.php/Testing_for_Account_Enumeration_and_Guessable_User_Account_(OTG-IDENT-004) OTG-IDENT-004]
|OK
|-
|Testing for Credentials Transported over an Encrypted Channel
|[https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001) OTG-AUTHN-001]
|F
|-
|Testing for default credentials
|[https://www.owasp.org/index.php/Testing_for_default_credentials_(OTG-AUTHN-002) OTG-AUTHN-002]
|OK
|-
|Testing for Weak lock out mechanism
|[https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) OTG-AUTHN-003]
|NA
|-
|Testing for Bypassing Authentication Schema
|[https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004) OTG-AUTHN-004]
|OK
|-
|Testing for Vulnerable Remember Password
|[https://www.owasp.org/index.php/Testing_for_Vulnerable_Remember_Password_(OTG-AUTHN-005) OTG-AUTHN-005]
|NA
|-
|Testing for Browser cache weakness
|[https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OTG-AUTHN-006) OTG-AUTHN-006]
|OK
|-
|Testing for Weak password policy
|[https://www.owasp.org/index.php?title=Testing_for_Weak_password_policy_(OTG-AUTHN-007)&setlang=en OTG-AUTHN-007]
|NA
|-
|Testing for weak password change or reset functionalities
|[https://www.owasp.org/index.php/Testing_for_weak_password_change_or_reset_functionalities_(OTG-AUTHN-009) OTG-AUTHN-009]
|NA
|-
|Testing for Weaker authentication in alternative channel
|[https://www.owasp.org/index.php/Testing_for_Weaker_authentication_in_alternative_channel_(OTG-AUTHN-010) OTG-AUTHN-010]
|NA
|-
|Testing Directory traversal/file include
|[https://www.owasp.org/index.php/Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) OTG-AUTHZ-001]
|OK
|-
|Testing for Bypassing Authorization Schema
|[https://www.owasp.org/index.php/Testing_for_Bypassing_Authorization_Schema_(OTG-AUTHZ-002) OTG-AUTHZ-002]
|F
|-
|Testing for Privilege escalation
|[https://www.owasp.org/index.php?title=Testing_for_Privilege_escalation_(OTG-AUTHZ-003)&setlang=en OTG-AUTHZ-003]
|OK
|-
|Testing for Insecure Direct Object References
|[https://www.owasp.org/index.php?title=Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)&setlang=en OTG-AUTHZ-004]
|F
|-
|Testing for Session Management Schema
|[https://www.owasp.org/index.php/Testing_for_Session_Management_Schema_(OTG-SESS-001) OTG-SESS-001]
|F
|-
|Testing for cookies attributes
|[https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002) OTG-SESS-002]
|OK
|-
|Testing for Session Fixation
|[https://www.owasp.org/index.php/Testing_for_Session_Fixation_(OTG-SESS-003) OTG-SESS-003]
|OK
|-
|Testing for Exposed Session Variables
|[https://www.owasp.org/index.php/Testing_for_Exposed_Session_Variables_(OTG-SESS-004) OTG-SESS-004]
|OK
|-
|Testing for CSRF
|[https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005) OTG-SESS-005]
|F
|-
|Testing for logout functionality
|[https://www.owasp.org/index.php/Testing_for_logout_functionality_(OTG-SESS-006) OTG-SESS-006]
|F
|-
|Testing for Session Timeout
|[https://www.owasp.org/index.php?title=Test_Session_Timeout_(OTG-SESS-007)&setlang=en OTG-SESS-007]
|OK
|-
|Testing for Session puzzling
|[https://www.owasp.org/index.php/Testing_for_Session_puzzling_(OTG-SESS-008) OTG-SESS-008]
|OK
|-
|Testing for Reflected Cross site scripting
|[https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001) OTG-INPVAL-001]
|OK
|-
|Testing for Stored Cross site scripting
|[https://www.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002) OTG-INPVAL-002]
|OK
|-
|Testing for HTTP Verb Tampering
|[https://www.owasp.org/index.php?title=Testing_for_HTTP_Verb_Tampering_(OTG-INPVAL-003)&setlang=en OTG-INPVAL-003]
|NA
|-
|Testing for HTTP Parameter pollution
|[https://www.owasp.org/index.php/Testing_for_HTTP_Parameter_pollution_(OTG-INPVAL-004) OTG-INPVAL-004]
|OK
|-
|Testing for SQL Injection
|[https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) OTG-INPVAL-005]
|OK
|-
|Testing for LDAP Injection
|[https://www.owasp.org/index.php/Testing_for_LDAP_Injection_(OTG-INPVAL-006) OTG-INPVAL-006]
|NA
|-
|Testing for XML Injection
|[https://www.owasp.org/index.php?title=Testing_for_XML_Injection_(OTG-INPVAL-008)&setlang=en OTG-INPVAL-008]
|NA
|-
|Testing for SSI Injection
|[https://www.owasp.org/index.php?title=Testing_for_SSI_Injection_(OTG-INPVAL-009)&setlang=en OTG-INPVAL-009]
|NA
|-
|Testing for XPath Injection
|[https://www.owasp.org/index.php?title=Testing_for_XPath_Injection_(OTG-INPVAL-010)&setlang=en OTG-INPVAL-010]
|NA
|-
|Testing for IMAP/SMTP Injection
|[https://www.owasp.org/index.php/Testing_for_IMAP/SMTP_Injection_(OTG-INPVAL-011) OTG-INPVAL-011]
|NA
|-
|Testing for Code Injection
|[https://www.owasp.org/index.php?title=Testing_for_Code_Injection_(OTG-INPVAL-012)&setlang=en OTG-INPVAL-012]
|OK
|-
|Testing for Command Injection
|[https://www.owasp.org/index.php?title=Testing_for_Command_Injection_(OTG-INPVAL-013)&setlang=en OTG-INPVAL-013]
|OK
|-
|Testing for Buffer Overflow
|[https://www.owasp.org/index.php/Testing_for_Buffer_Overflow_(OTG-INPVAL-014) OTG-INPVAL-014]
|NA
|-
|Testing for Incubated Vulnerability
|[https://www.owasp.org/index.php?title=Testing_for_Incubated_Vulnerability_(OTG-INPVAL-015)&setlang=en OTG-INPVAL-015]
|OK
|-
|Testing for HTTP Splitting/Smuggling
|[https://www.owasp.org/index.php?title=Testing_for_HTTP_Splitting/Smuggling_(OTG-INPVAL-016)&setlang=en OTG-INPVAL-016]
|OK
|-
|Testing for Information Disclosure
|[https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) OTG-ERR-001], [https://www.owasp.org/index.php/Testing_for_Stack_Traces_(OTG-ERR-002) OTG-ERR-002]
|OK
|-
|Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection
|[https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001) OTG-CRYPST-001]
|NA
|-
|Testing for Padding Oracle
|[https://www.owasp.org/index.php?title=Testing_for_Padding_Oracle_(OTG-CRYPST-002)&setlang=en OTG-CRYPST-002]
|NA
|-
|Testing for Sensitive information sent via unencrypted channels
|[https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)&setlang=en OTG-CRYPST-003]
|NA
|-
|Tests of business logic
|[https://www.owasp.org/index.php/Testing_for_business_logic OTG-BUSLOGIC-001..009]
|OK
|-
|Testing for DOM-based Cross site scripting
|[https://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_(OTG-CLIENT-001) OTG-CLIENT-001]
|OK
|-
|Testing for JavaScript Execution
|[https://www.owasp.org/index.php/Testing_for_JavaScript_Execution_(OTG-CLIENT-002) OTG-CLIENT-002]
|OK
|-
|Testing for HTML Injection
|[https://www.owasp.org/index.php/Testing_for_HTML_Injection_(OTG-CLIENT-003) OTG-CLIENT-003]
|OK
|-
|Testing for Client Side URL Redirect
|[https://www.owasp.org/index.php/Testing_for_Client_Side_URL_Redirect_(OTG-CLIENT-004) OTG-CLIENT-004]
|F
|-
|Testing for CSS Injection
|[https://www.owasp.org/index.php/Testing_for_CSS_Injection_(OTG-CLIENT-005) OTG-CLIENT-005]
|OK
|-
|Testing for Client Side Resource Manipulation
|[https://www.owasp.org/index.php/Testing_for_Client_Side_Resource_Manipulation_(OTG-CLIENT-006) OTG-CLIENT-006]
|OK
|-
|Test Cross Origin Resource Sharing
|[https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007) OTG-CLIENT-007]
|OK
|-
|Testing for Cross site flashing
|[https://www.owasp.org/index.php?title=Testing_for_Cross_site_flashing_(OTG-CLIENT-008)&setlang=en OTG-CLIENT-008]
|OK
|-
|Testing for Clickjacking
|[https://www.owasp.org/index.php/Testing_for_Clickjacking_(OTG-CLIENT-009) OTG-CLIENT-009]
|OK
|-
|Testing WebSockets
|[https://www.owasp.org/index.php?title=Testing_WebSockets_(OTG-CLIENT-010)&setlang=en OTG-CLIENT-010]
|NA
|-
|Test Web Messaging
|[https://www.owasp.org/index.php?title=Test_Web_Messaging_(OTG-CLIENT-011)&setlang=en OTG-CLIENT-011]
|NA
|-
|Test Local Storage
|[https://www.owasp.org/index.php?title=Test_Local_Storage_(OTG-CLIENT-012)&setlang=en OTG-CLIENT-012]
|NA
|}

:OK (Nenhum problema encontrado); F (Teste falhou, verificar os resultados); NA (Teste não aplicado)


=== Resultados dos Testes ===

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-AUTHZ-002, OTG-AUTHZ-004
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|O handler "fileHandler.ashx" não possui controle de acesso, podendo ser acessado diretamente por um usuário não autenticado. Assim ele permite o download de qualquer arquivo disponível através do seu id, que é um número sequencial e portanto de fácil previsão.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.3_Controle_de_acesso|"3.3 Controle de acesso"]], [[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.9_Arquivos_e_recursos|"3.9 Arquivos e recursos"]]
|-
|'''Sugestões'''
|
*Implementar um controle de acesso para o fileHandler e para os arquivos em si, de forma que apenas os usuários com a devida permissão consigam realizar o download dos arquivos.
*Utilizar identificadores aleatórios e não previsíveis para dificultar o acesso aos arquivos diretamente.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-CONFIG-007, OTG-AUTHN-001
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|As informações enviados para e pelo sistema não são criptografadas, susceptíveis a interceptações e alterações entre o cliente e o servidor.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.8_Seguran.C3.A7a_nas_comunica.C3.A7.C3.B5es|"3.8 Segurança nas comunicações"]]
|-
|'''Sugestões'''
|
*Implementar o protocolo TLS seguindo as orientações de boas práticas.
*Utilizar em ambientes de produção certificados gerados por autoridades certificadores confiáveis. Em ambientes de teste e homologação podem ser utilizados certificados auto-assinados.
|-
|'''Referências'''
|
*https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-CONFIG-004
|-
|'''Severidade'''
|Baixa
|-
|'''Descrição'''
|O diretório do site no servidor possui arquivos de código fonte (.cs).
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.7_Prote.C3.A7.C3.A3o_de_dados|"3.7 Proteção de dados"]]
|-
|'''Sugestões'''
|
*Em produção, deve-se procurar manter apenas os arquivos compilados e necessários para o funcionamento do sistema.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-AUTHZ-002
|-
|'''Severidade'''
|Baixa
|-
|'''Descrição'''
|A api do sistema e o WS "SvcTransporteEscolar" não possuem controle de acesso, podendo ser acessados diretamente por um usuário não autenticado.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.11_Web_Services_e_API.C2.B4s|"3.11 Web Services e API´s"]]
|-
|'''Sugestões'''
|
*Implementar mecanismos de autenticação e autorização para as APIs e Webservices.
|-
|'''Referências'''
|
*http://www.asp.net/web-api/overview/security/authentication-andauthorization-in-aspnet-web-api
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-SESS-005
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|O sistema não implementa um mecanismo anti-CSRF, e permite que as páginas sejam renderizadas a partir de outros domínios (em um frame, iframe ou object).
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.12.1_Configura.C3.A7.C3.B5es_para_servidor_web|"3.12.1 Configurações para servidor web"]], [[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.4_Gerenciamento_de_sess.C3.A3o|"3.4 Gerenciamento de sessão"]]
|-
|'''Sugestões'''
|
*Implementar um token anti-CSRF para prevenir ataques desse tipo.
*Verificar os cabeçalhos "Origin" e/ou "Referer" para identificar a origem do request.
*Setar o cabeçalho "X-Frame-Options" para "sameorigin" ou "deny".
|-
|'''Referências'''
|
*https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
*https://www.owasp.org/index.php/Anti_CSRF_Tokens_ASP.NET
*https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-SESS-001, OTG-SESS-006
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|Ao realizar o logout o cookie de autenticação não é invalidado no servidor, apenas excluido no lado cliente. Assim, forçando o navegador a utilizar o valor antigo do cookie o usuário consegue novamente acesso ao sistema sem realizar o login.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.4_Gerenciamento_de_sess.C3.A3o|"3.4 Gerenciamento de sessão"]]
|-
|'''Sugestões'''
|
*Invalidar o cookie de autenticação no lado servidor quando o usuário realiza o logout.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-SESS-001
|-
|'''Severidade'''
|Média
|-
|'''Descrição'''
|Ao realizar a primeira requisição para o sistema o usuário recebe um cookie de sessão, e assim que realiza o login com sucesso ele recebe um cookie de autenticação. No entanto o sistema não faz a validação de ambos os cookies, podendo o usuário depois de autenticado continuar navegando apenas com o cookie de sessão ou de autenticação (nesse caso recebendo uma nova sessão).
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.4_Gerenciamento_de_sess.C3.A3o|"3.4 Gerenciamento de sessão"]]
|-
|'''Sugestões'''
|
*Sempre verificar no lado servidor a validade de ambos os cookies, e caso algum cookie esteja ausente ou alterado realizar o logout da sessão do usuário, invalidando ambos os cookies.
|-
|'''Referências'''
|
|}

{| style="width: 100%" class="wikitable"
|-
| style="width: 15%"|
'''Teste falhou'''
|OTG-CLIENT-004
|-
|'''Severidade'''
|Baixa
|-
|'''Descrição'''
|O sistema faz o redirecionamento do usuário para outros domínios quando o parâmentro "relaystate" da página "Login.ashx" é alterado para uma url qualquer.
|-
|'''Política de segurança'''
|[[Pol%C3%ADtica_de_Seguran%C3%A7a_da_Informa%C3%A7%C3%A3o_para_o_Desenvolvimento_MSTECH#3.1_Valida.C3.A7.C3.A3o_dos_dados|"3.1 Validação dos dados"]]
|-
|'''Sugestões'''
|
*Fazer a validação do valor do relaystate antes de redirecionar o usuário, para previnir o redirecionamento para outros domínios no caso da requisição ter sido alterada ou forjada.
|-
|'''Referências'''
|
|}

== Verificação de Desempenho ==

=== Observações sobre o teste ===
O CoreSSO utilizado inicialmente para os testes foi o indicado pela equipe do Transportes, copiado do TS-IIS02 e TS-BD. Contudo, o CoreSSO, apresentou problemas, dentre eles o não cadastro da tabela de layout padrão, gerando diversos erros. Desta forma, substituímos o banco e o site por outra versão indicada pela equipe do CoreSSO na época.

Vale ressaltar que o sistema conforme indicação da equipe do Transportes suportaria, em seu limite, o acesso simultâneo de 200 usuários com uma alta taxa de erro no momento de acesso ao sistema Transporte Escolar, tornando necessário a verificação e ajuste do SAML.

=== Cenário de uso ===

{| class="wikitable"
!colspan="6"|Cenário de uso #1
|-
|colspan="2"| Ação realizada || Think Time (segundos)
|-
|colspan="2"|1 - Acessar tela de login || style="text-align: center; | 3
|-
|colspan="2"|1 - Realizar login || style="text-align: center; |7
|-
|colspan="2"|1 - Selecionar sistema Transporte Escolar || style="text-align: center; |5
|-
|colspan="2"|2 - Acessar tela de consulta de veículos || style="text-align: center; |5
|-
|colspan="2"|2 - Preencher aba "Documentação" || style="text-align: center; |20
|-
|colspan="2"|2 - Preencher aba "Aquisição" || style="text-align: center; |7
|-
|colspan="2"|2 - Preencher aba "Condutor" || style="text-align: center; |38
|-
|colspan="2"|2 - Preencher aba "Peças e acessórios" || style="text-align: center; |25
|-
|colspan="2"|2 - Preencher aba "Despesas" || style="text-align: center; |15
|-
|colspan="2"|2 - Salvar cadastro || style="text-align: center; |5
|-
|colspan="2"|3 - Logout || style="text-align: center; |5
|}

=== Resultado dos testes ===
Nesta seção serão apresentados os resultados obtidos da execução dos testes.

*'''Porcentagem de tempo do processador'''
: Descrição: Mede a saturação do processador e mostra a quantidade de tempo despendida para processar as threads por todas as CPUs.
: Limite recomendado: Abaixo de 75 %.

:::::: [[Arquivo:2016-06-21 TransporteEscolar TempoDeProcessador.png]]

*'''Porcentagem de memória utilizada'''
: Descrição: Indica a porcentagem de memória utilizada para uso dos processos.
: Limite recomendado: Abaixo de 75 %.

:::::: [[Arquivo:2016-06-21_TransporteEscolar_MemoriaUtilizada.png]]

*'''Kbytes totais pela interface de rede'''
: Descrição: Indica quantos Bbytes foram enviados e recebidos a cada segundo pela interface de rede.
: Limite recomendado: Menor que 5 Mbytes para uma rede de 100Mbps, menor que 50 Mbytes para uma rede de 1000 Mbps. (Quanto menor melhor)

:::::: [[Arquivo:2016-06-21_TransporteEscolar_NetworkTotal.png]]

*'''Tempo médio de resposta das requisições'''
: Descrição: Indica o tempo médio de resposta das requisições.
: Limite recomendado: 5 segundos.

:::::: [[Arquivo:2016-06-21_TransporteEscolar_ResponseTime.png]]

*'''Tempo de vazão'''
: Descrição: Indica a quantidade total de request por segundo.
: Limite recomendado: Quanto maior melhor.

:::::: [[Arquivo:2016-06-22 13-37-47.png]]