==Introdução==

O objetivo desta seção é detalhar os tipos de atividades realizados pela equipe de Produção (POs, SMs, desenvolvedores) da MSTECH e classificá-los em termos de definições contábeis. Cada atividade realizada pode ser classificada em um dos tipos de serviço da empresa (Produto, Serviço, Desenvolvimento, Customização, Conteúdo, Demanda Interna, Bug ou Parceria).

Através de um repertório de atividades, listado abaixo, apresentamos diversos cenários para apoiar os colaboradores a tipificar corretamente cada tipo de atividade.

A importância de uma correta tipificação é permitir que o rateio e a apuração de custos da empresa seja feito de forma mais precisa, de modo que tenhamos de forma mais real o investimento realizado em cada tipo de atividade para um produto, gerando uma precificação mais apurada e mais competitiva com o mercado.

==Tipos de Atividades na Controladoria==

{| class="wikitable"
| '''Tipo'''||'''Código'''||'''Definição'''
|-
| '''PRODUTO'''||a||Atividades relacionadas à construção ou evolução de produtos para a MSTECH. Pode ser a construção de um novo produto ou uma evolução de produto existente. Pode ser realizado no escopo de um projeto, ou seja, uma demanda contém uma funcionalidade considerada relevante para o produto.
|-
| '''SERVIÇO'''||b||Ações que a execução e prestação de serviço é feita diretamente com o cliente, ou seja, o colaborador estará em contato direto com quem receberá o serviço. Pode ser Assessoria Pedagógica, Capacitação, Implantação, Suporte ou Formação.
|-
| '''DESENVOLVIMENTO'''||c||Trata-se da construção de uma ou mais funcionalidades que precisarão ser construídas do zero, ou seja, funcionalidades novas, em um projeto que não é considerado um produto para a MSTECH.
|-
| '''CUSTOMIZAÇÃO'''||d||Customização pode ser uma manutenção/evolução de uma funcionalidade de um projeto do cliente, sendo este projeto algo que não compõe o portfólio de produtos da empresa. Pode ser, também, uma personalização de um produto da MSTECH para atender determinado cliente. Customização se refere à recursos já existentes e que precisam ser alterados.
|-
| '''CONTEÚDO'''||e||Atividades de produção de conteúdos educacionais para os clientes.
|-
| '''DEMANDA INTERNA'''||f||Atividades produtivas realizadas para a MSTECH.
|-
| '''BUG'''||g||Correção de algo que a MSTECH desenvolveu e deu erro. É um "retrabalho".
|-
| '''PARCERIA'''||h||Um exemplo de atividade de parceria é a construção do login do Google no CoreSSO. Ou seja, é realizada uma atividade para atender alguma necessidade de empresa parceira. Não está relacionado a realizar uma atividade sem faturamento para um cliente ou outras conotações.
|}

Vale ressaltar um caso em particular: '''Documentação'''. Para fins de discernimento do tipo de atividade, devemos considerar a documentação de um projeto o u produto como um requisito do sistema. Dessa forma, documentação pode ser enquadrado como Produto ou Desenvolvimento, se o mesmo não existir, ou como Produto ou Customização se ele já existir e precisar sofrer alterações (o enquadramento correto deve considerar as definições da tabela acima.

==Tipos de serviço e faturamento não são correlacionados==
Em conversa com PO's da empresa, identificamos que, em geral, há uma confusão em relação entre tipo de atividade a ser realizada com ser faturado ou não. É comum, por exemplo, qualificar a inclusão de um campo em um relatório, por exemplo, como um BUG porque não será faturado. Esse é um equívoco comum.

No caso do exemplo citado acima, caso o campo tenha sido solicitado previamente e o mesmo não foi desenvolvido, será sim um BUG. Porém, caso não tenha havido uma solicitação deste campo previamente, pode se tratar de uma customização ou de uma evolução de produto, dependendo do contexto, '''que não será faturado'''.

Para classificar um item é importante entender que o que importa para fins contábeis é o tipo de ação que será realizado, não se o mesmo será faturado ou não.

==Exemplos de qualificação de tipos de serviço==
{| class="wikitable"
| Exemplo||Classificação||Explicação
|-
| Cliente solicita que MSTECH utilize seu recurso de envio de mala direta (e-mail marketing) para divulgação de um serviço à seus usuários||Serviço||MSTECH está prestando um serviço de envio de e-mails para o cliente.
|-
| Manual/Tutorial sobre como realizar determinada ação em um sistema educacional não produzido pela MSTECH (Moodle, por exemplo)||Serviço (Assessoria pedagógica)||MSTECH está construindo um manual de um produto que não é seu, para que usuários possam aprender a utilizar uma ferramenta externa.
|-
| Cliente pede um teste de configuração de player de vídeo que utiliza o CORS no conteúdo produzido por ele||Serviço||Neste contexto, o cliente construiu um conteúdo que abre link de outro domínio e, ao subir no ambiente da MSTECH, apresentou problema. A MSTECH deve prestar um serviço de modificar a configuração de ser servidor para resolver o problema (não é bug porque não há erro do sistema, apenas uma alteração na configuração)
|-
| Configuração do sistema falta ou está errada, e o sistema não oferece interface para configurar||Serviço||No caso, se tratando apenas de acertar uma configuração, será um serviço. Se a atividade for de criação de uma tela para configuração pode ser considerada "produto" (se essa tela agregar a algum produto da empresa) ou "desenvolvimento" caso seja específico de um projeto do cliente e não for entrar no portfolio da MSTECH. Agora, se a tela era prevista e não foi feita ou não está correta, é "Bug"
|-
| Gerar certificado de conclusão manualmente para um cursista||Serviço||Trata-se de uma prestação de serviço da MSTECH para o cliente
|-
| Extração de relatórios de acesso (o relatório já existe)||Serviço||Trata-se de uma prestação de serviço da MSTECH para o cliente
|-
| Troca de texto, imagem ou outros artefatos do portal||Serviço ou Customização||Caso a atividade seja feita em uma ferramenta que permitiria ao usuário fazer essa ação (como o Moodle ou o Portal Construtor, por exemplo), podemos enquadrar como um serviço. Se for necessária a alteração do código para essas alterações, aí será uma Customização
|-
| Realizar análise de aderência à atualização de ferramentas ou SO (por exemplo SQL Server ou Windows)||Serviço ou Demanda Interna|| Análise de aderência pode ser encarado como "Serviço" se o mesmo for direcionado a um cliente ou, caso seja uma análise de aderência solicitada pela MSTECH (para um edital, por exemplo), pode-se considerar como uma Demanda interna.
|-
| Realizar procedimentos de DTS como carga de usuários||Serviço|| É o desenvolvimento de um atividade que presta serviço ao cliente, evitando que o mesmo faça o recadastro de dados manualmente. Entendemos que este item é um "Serviço" prestado.
|-
| Migração de ambientes - cópia da produção para homologação, troca de servidores, liberação de espaço||Demanda interna ou serviços||Se o ambiente alvo for dentro da MSTECH, é uma demanda interna. Se for um ambiente do cliente, a MSTECH está prestando serviços ao cliente.
|-
| Manual/revisão ortográfica||Produto ou Desenvolvimento ou Customização||Produto se é evolução para o produto. Se não existir documentação de algo não produto, é desenvolvimento. Se já existir documentação de algo não produto é customização. Documentação deve ser considerado como um requisito.
|-
| Cliente pede análise de um aluno que não consegue se cadastrar ou para incluir um novo tipo de autenticação em sistema existente||Serviço||Análise de problemas em quaisquer ambientes invariavelmente é um serviço de suporte ao cliente. O resultado da análise pode indicar a necessidade de um outro tipo de atividade (Produto, Bug ou Customização, por exemplo)
|-
| Cliente reclama de problema em produção e, após análise, identifica que a causa é o uso de uma tecnologia considerada obsoleta (por exemplo Flash)||Desenvolvimento, Bug ou Customização||Caso tenha havido uma solicitação de modernização da tecnologia (por exemplo conversão para HTML5) e a mesma não foi feita ou feita incorretamente, é Bug. Caso contrário, deve ser feito um novo desenvolvimento, pois se trata de uma alteração não prevista em contrato anterior. Neste caso pode-se enquadrar ou em "Desenvolvimento" (se não se tratar de um produto) ou "Produto, caso contrário.
|-
| O cliente solicitou para verificar se é possível fazer login no portal e ao clicar em EAD o usuário aparece logado no moodle||Desenvolvimento ou Produto||Análise de adição de um novo recurso, como no exemplo, pode ser tipificado como "Desenvolvimento" se for uma funcionalidade nova em um projeto não considerado produto, ou "Produto" caso contrário
|-
| Melhoria de performance gerada depois de entregue o projeto, devido ao volume de conteúdo||Serviço inicialmente, Desenvolvimento ou Produto posteriormente||Teste de performance deve ser considerado um "Serviço". Após o teste, se necessário for inserir melhorias, pode-se enquadrar em "Produto" ou "Desenvolvimento", dependendo se o alvo da alteração for um produto da MSTECH ou não
|-
| O cliente solicitou para ordenar as revistas que aparecem no aplicativo da mais nova para a mais antiga. Não foi solicitado previamente||Produto ou Customização||Produto se a MSTECH entender que traz valor para uma evolução. Senão é customização, por ser um novo filtro em uma funcionalidade existente
|}

Definições contábeis e tipos de serviço

2016-09-06T17:22:35Z

Ricardo.agulhari: /* Tipos de Atividades */

Definições contábeis e tipos de serviço

2016-09-06T17:11:38Z

Ricardo.agulhari:

Definições contábeis e tipos de serviço

2016-09-06T15:14:54Z

Ricardo.agulhari: /* Tipos de Atividades */

Definições contábeis e tipos de serviço

2016-09-06T15:13:36Z

Ricardo.agulhari: Criou página com '==Introdução== O objetivo desta seção é detalhar os tipos de atividades realizados pela equipe de Produção (POs, SMs, desenvolvedores) da MSTECH e classificá-los em t...'

Guias de instruções

2016-09-06T12:23:06Z

Ricardo.agulhari:

[[Template do guia]]

*[[Cadastrar entregas no Redmine]]
*[[Cadastrar marcos e pontos de controle no Redmine]]
*[[Solicitar projetos contábeis]]
*[[Criar projetos no Redmine]]
*[[Criar tarefas no Redmine]]
*[[Gerar número de ordem de serviço]]
*[[Vincular tarefas do Youtrack a uma ordem de serviço]]
*[[Utilizar planilha de comparativo (transição/planejamento)]]
*[[Definições contábeis e tipos de serviço]]

Política de Versionamento e estruturação de branches

2016-09-01T17:37:45Z

Ricardo.agulhari:

== Sobre essa página ==

Essa página contém informações referentes ao modelo de estruturação de ''branches'' dos repositórios existentes no GitLab que deve ser seguido para que sejam aderentes ao Processo de Desenvolvimento de Software da MSTECH.

Da mesma forma, descrevemos como os artefatos devem ser organizados na realização de uma operação de manipulação de arquivo versionado (''commit'').

== Estruturação dos branches no GitLab ==

A imagem abaixo apresenta de forma resumida a forma de estrutura dos ''branches'' de um projeto:

[[Arquivo:Estratégia de branches.png|thumb|500px|center]]

Cada repositório contém por padrão um branch '''"Main"'''. Este branch contém o histórico do código estável do produto, sendo este a matriz de onde os demais branches serão criados.

Quando uma nova evolução deste código fonte é necessária (sendo esta por uma evolução de produto ou um novo projeto de customização, por exemplo) será criado um novo branch para este desenvolvimento. Este branch deverá ter o nome do projeto/produto aberto como identificador. Este branch deverá ser criado a partir de uma "tag" (label) registrado na Main.

O desenvolvimento das funcionalidades previstas no projeto deverão ser realizados neste branch, ficando como opcional, a critério da célula, a utilização de estratégias como branch por feature, por exemplo. As alterações realizadas deverão ser encaminhadas, invariavelmente para o branch do projeto, por meio de commit seguindo os padrões definidos pela empresa (verificar a seção "Requisitos de commit de código" nesta página).

===Baseline de Homologação===
Após o término da construção dos requisitos contidos no escopo da entrega, uma baseline de homologação deverá ser criada no branch de desenvolvimento do projeto. Essa baseline deverá gerar uma "tag" (label), indicando que a versão está pronta para a homologação. Será este label que passará pela auditoria de construção e, posteriormente, gerará o pacote para envio à homologação pelo cliente.

Caso seja necessário realizar correções ou atualizações identificadas no ambiente de Homologação, um novo branch a partir do branch de desenvolvimento deve ser criado. Consideraremos este branch como um branch "Release". Todas as atualizações para homologação deverão ser atualizadas neste branch.

===Baseline de Entrega===
Uma vez que a Homologação for finalizada, as operações de Merge deverão ser realizadas. Neste caso, deve-se observar os seguintes cenários:

* Se houve a criação de um branch "Release", deve-se fazer o merge deste branch com o branch "Main", para que seja possível fazer a baseline de entrega. Em seguida, deve-se também fazer o "merge" do branch "Release" com o branch de desenvolvimento, para atualizar este último com as alterações identificadas em Homologação;
* Se não houve a criação de um branch "Release", deve-se apenas fazer o merge deste branch com o branch "Main".

Após a realização do merge, deve ser gerado a baseline de entrega, sendo criada uma "tag" (label) para essa entrega.

===Branch de Hotfix===
Existe a possibilidade de, em algum momento, ser necessário realizar uma alteração em uma versão estável da aplicação, como uma correção de bug em um sistema de Produção, por exemplo. Neste caso, um branch do tipo "Hotfix" deve ser criado a partir do branch "Main". As alterações necessárias devem ser feitas nesse branch "Hotfix" e, uma vez finalizado, o código deve ser retornado para o branch "Main".

Caso haja um branch de desenvolvimento de projeto ativo, o código deve ser levado também para esse branch, para garantir a consistência do código entre os branches.

==Requisitos de commit de código==

Para realizar o commit em qualquer um dos branches, alguns requisitos devem ser cumpridos, sendo estes:

* Ter no Youtrack uma tarefa criada. Essa tarefa deverá obrigatoriamente ser associada, no check-in dos artefatos;
* Inserir, de forma obrigatória, um comentário no check-in descrevendo o que foi realizado de alterações nos artefatos que compõem essa operação.

Política de Versionamento e estruturação de branches

2016-09-01T14:54:54Z

Ricardo.agulhari:

== Sobre essa página ==

Essa página contém informações referentes ao modelo de estruturação de branches dos repositórios existentes no GitLab que deve ser seguido para que sejam aderentes ao Processo de Desenvolvimento de Software da MSTECH.

Da mesma forma, descrevemos como os artefatos devem ser organizados na realização de uma operação de manipulação de arquivo versionado (''commit'').

== Estruturação dos branches no GitLab ==

A imagem abaixo apresenta de forma resumida a forma de estrutura dos branches de um projeto:

[[Arquivo:Estratégia de branches.png|thumb|500px|center]]

Cada repositório contém por padrão um branch '''"Main"'''. Este branch contém o histórico do código estável do produto, sendo este a matriz de onde os demais branches serão criados.

Quando uma nova evolução deste código fonte é necessária (sendo esta por uma evolução de produto ou um novo projeto de customização, por exemplo) será criado um novo branch para este desenvolvimento. Este branch deverá ter o nome do projeto/produto aberto como identificador. Este branch deverá ser criado a partir de uma "tag" (label) registrado na Main.

O desenvolvimento das funcionalidades previstas no projeto deverão ser realizados neste branch, ficando como opcional, a critério da célula, a utilização de estratégias como branch por feature, por exemplo. As alterações realizadas deverão ser encaminhadas, invariavelmente para o branch do projeto, por meio de commit seguindo os padrões definidos pela empresa (verificar a seção "Requisitos de commit de código" nesta página).

===Baseline de Homologação===
Após o término da construção dos requisitos contidos no escopo da entrega, uma baseline de homologação deverá ser criada no branch de desenvolvimento do projeto. Essa baseline deverá gerar uma "tag" (label), indicando que a versão está pronta para a homologação. Será este label que passará pela auditoria de construção e, posteriormente, gerará o pacote para envio à homologação pelo cliente.

Caso seja necessário realizar correções ou atualizações identificadas no ambiente de Homologação, um novo branch a partir do branch de desenvolvimento deve ser criado. Consideraremos este branch como um branch "Release". Todas as atualizações para homologação deverão ser atualizadas neste branch.

===Baseline de Entrega===
Uma vez que a Homologação for finalizada, as operações de Merge deverão ser realizadas. Neste caso, deve-se observar os seguintes cenários:

* Se houve a criação de um branch "Release", deve-se fazer o merge deste branch com o branch "Main", para que seja possível fazer a baseline de entrega. Em seguida, deve-se também fazer o "merge" do branch "Release" com o branch de desenvolvimento, para atualizar este último com as alterações identificadas em Homologação;
* Se não houve a criação de um branch "Release", deve-se apenas fazer o merge deste branch com o branch "Main".

Após a realização do merge, deve ser gerado a baseline de entrega, sendo criada uma "tag" (label) para essa entrega.

===Branch de Hotfix===
Existe a possibilidade de, em algum momento, ser necessário realizar uma alteração em uma versão estável da aplicação, como uma correção de bug em um sistema de Produção, por exemplo. Neste caso, um branch do tipo "Hotfix" deve ser criado a partir do branch "Main". As alterações necessárias devem ser feitas nesse branch "Hotfix" e, uma vez finalizado, o código deve ser retornado para o branch "Main".

Caso haja um branch de desenvolvimento de projeto ativo, o código deve ser levado também para esse branch, para garantir a consistência do código entre os branches.

==Requisitos de commit de código==

Para realizar o commit em qualquer um dos branches, alguns requisitos devem ser cumpridos, sendo estes:

* Ter no Youtrack uma tarefa criada. Essa tarefa deverá obrigatoriamente ser associada, no check-in dos artefatos;
* Inserir, de forma obrigatória, um comentário no check-in descrevendo o que foi realizado de alterações nos artefatos que compõem essa operação.

Política de Versionamento e estruturação de branches

2016-09-01T13:11:09Z

Ricardo.agulhari:

== Sobre essa página ==

Essa página contém informações referentes ao modelo de estruturação de branches dos repositórios existentes no GitLab que deve ser seguido para que sejam aderentes ao Processo de Desenvolvimento de Software da MSTECH.

Da mesma forma, descrevemos como os artefatos devem ser organizados na realização de uma operação de manipulação de arquivo versionado (''commit'').

== Estruturação dos branches no GitLab ==

A imagem abaixo apresenta de forma resumida a forma de estrutura dos branches de um projeto:

[[Arquivo:Estratégia de branches.png|thumb|500px|center]]

Cada repositório contém por padrão um branch '''"Main"'''. Este branch contém o histórico do código estável do produto, sendo este a matriz de onde os demais branches serão criados.

Quando uma nova evolução deste código fonte é necessária (sendo esta por uma evolução de produto ou um novo projeto de customização, por exemplo) será criado um novo branch para este desenvolvimento. Este branch deverá ter o nome do projeto/produto aberto como identificador. Este branch deverá ser criado a partir de uma "tag" (label) registrado na Main.

O desenvolvimento das funcionalidades previstas no projeto deverão ser realizados neste branch, ficando como opcional, a critério da célula, a utilização de estratégias como branch por feature, por exemplo. As alterações realizadas deverão ser encaminhadas, invariavelmente para o branch do projeto, por meio de commit seguindo os padrões definidos pela empresa (verificar a seção "Requisitos de commit de código" nesta página).

===Baseline de Homologação===
Após o término da construção dos requisitos contidos no escopo da entrega, uma baseline de homologação deverá ser criada no branch de desenvolvimento do projeto. Essa baseline deverá gerar uma "tag" (label), indicando que a versão está pronta para a homologação. Será este label que passará pela auditoria de construção e, posteriormente, gerará o pacote para envio à homologação pelo cliente.

Caso seja necessário realizar correções ou atualizações identificadas no ambiente de Homologação, um novo branch a partir do branch de desenvolvimento deve ser criado. Consideraremos este branch como um branch "Release". Todas as atualizações para homologação deverão ser atualizadas neste branch.

===Baseline de Entrega===
Uma vez que a Homologação for finalizada, as operações de Merge deverão ser realizadas. Neste caso, deve-se observar os seguintes cenários:

* Se houve a criação de um branch "Release", deve-se fazer o merge deste branch com o branch "Main", para que seja possível fazer a baseline de entrega. Em seguida, deve-se também fazer o "merge" do branch "Release" com o branch de desenvolvimento, para atualizar este último com as alterações identificadas em Homologação;
* Se não houve a criação de um branch "Release", deve-se apenas fazer o merge deste branch com o branch "Main".

Após a realização do merge, deve ser gera

==Requisitos de commit de código==

<<PREENCHER>>

Política de Versionamento e estruturação de branches

2016-09-01T12:58:06Z

Ricardo.agulhari: /* Estruturação dos branches no GitLab */

Política de Versionamento e estruturação de branches

2016-09-01T12:48:57Z

Ricardo.agulhari: /* Estruturação dos branches no GitLab */

Política de Versionamento e estruturação de branches

2016-08-31T19:43:19Z

Ricardo.agulhari: /* Estruturação dos branches no GitLab*/

Política de Versionamento e estruturação de branches

2016-08-31T12:29:55Z

Ricardo.agulhari: Criou página com '== Sobre essa página == Essa página contém informações referentes ao modelo de estruturação de branches dos repositórios existentes no GitLab que deve ser seguido par...'

Arquivo:Estratégia de branches.png

2016-08-31T12:25:25Z

Ricardo.agulhari: Imagem que contém um esquemático da política de branches da MSTECH

Imagem que contém um esquemático da política de branches da MSTECH

Processo de desenvolvimento de Software MSTECH

2016-08-31T12:22:05Z

Ricardo.agulhari:

*[[Processo as-is - Julho de 2016]]
*[[Guias de instruções]]
*[[Regras]]
*[[Abertura de projetos e pré-projetos]]
*[[Política de Versionamento e estruturação de branches]]

Lista de Sistemas do CoreSSO

2016-08-15T14:42:59Z

Ricardo.agulhari:

{| class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Sis_id'''
| align="center" style="background:#f0f0f0;"|'''Sis_nome'''
|-
| 1||Administração do sistema
|-
| 2||Gestão Acadêmica
|-
| 6||Alimentação Escolar
|-
| 7||BlueQuestWeb
|-
| 21||Portal Viver Digital
|-
| 25||BlueControlWeb NEW NAME
|-
| 26||Inscrição Creche
|-
| 27||Controle Patrimonial
|-
| 28||Central de Serviços - Servidor GTI
|-
| 29||Administrativo - Servidor GTI
|-
| 32||Quadro de Horários
|-
| 33||Portal de integrações SME-RJ
|-
| 34||Educopédia
|-
| 36||Rio Educa
|-
| 38||MeuEspacoWeb
|-
| 39||Ponto Digital
|-
| 40||BlueCore
|-
| 41||Merenda - pct
|-
| 42||Controle Patrimonial
|-
| 43||Migração Rio
|-
| 44||ProArt
|-
| 45||Remoção
|-
| 46||Lição de Casa
|-
| 48||Educopédia_MS
|-
| 54||Gerenciamento de Pagamento
|-
| 55||Intranet
|-
| 56||Sistema de Controle de Entregas
|-
| 57||Escola do Amanha
|-
| 104||Biblioteca
|-
| 112||Central de Serviços
|-
| 113||Portal da Escola
|-
| 116||blueMonitor
|-
| 117||BlueGuardWeb
|-
| 121||Integrações Rio
|-
| 122||Dupla Regência
|-
| 123||PIC
|-
| 125||Certificados
|-
| 126||Gerenciamento de frequência
|-
| 128||Transporte Escolar
|-
| 129||Almoxarifado
|-
| 130||Workflow
|-
| 131||Sistema de Avaliação
|-
| 132||GRPAlmoxarifado
|-
| 133||GRPAdmin
|-
| 134||Sistema de Formação
|-
| 135||Sistema de Escolha
|-
| 136||Remoção de docentes
|-
| 138||DiarioClasse
|-
| 139||Treinamento Vestibular
|-
| 140||Gestão Recurso Financeiro
|-
| 141||Matrícula
|-
| 142||Quadro_de_horários
|-
| 144||BlueGestãoEscolar/Diário de classe
|-
| 145||DELL CMS
|-
| 146||Formação de Professores
|-
| 147||Diario do Supervisor
|-
| 148||GRPCompra
|-
| 149||Administração de Correio
|-
| 150||Novo VM
|-
| 151||GRPObra
|-
| 153||GRPFinanceiro
|-
| 154||GRPRH
|-
| 155||GRPFrota
|-
| 156||GRPPatrimonio
|-
| 158||GRPLicitacao
|-
| 159||GRPPlanejamento
|-
| 160||GRPPlanejamentoOrcamentario
|-
| 161||SIGA
|-
| 162||BigBlue
|-
| 163||Gestão RH MStech OLD
|-
| 164||Censo escolar
|-
| 165||GRPMobiliario
|-
| 166||Avaliação Interna
|-
| 167||Portal Institucional
|-
| 168||GerenciamentoServico
|-
| 169||Mapa de Indicadores
|-
| 170||Gestão RH MStech
|-
| 171||blueMonitorApi
|-
| 173||Gerenciamento BigBlue
|-
| 174||Boletim Online
|-
| 175||AVA SME-SP
|-
| 177||Portal Colaborativo
|-
| 178||blueMonitorApiNotificacoes
|-
| 179||BlueDesignBook
|-
| 182||BluePublishBook
|-
| 183||BlueReaderBook
|-
| 184||BlueDistributorBook
|-
| 186||BlueLMS
|-
| 187||Contratos Escolares
|-
| 200||Moodle
|-
| 201||Wiki
|-
| 203||MeuEspacoWebAPI
|-
| 204||Gestão Avaliação
|-
| 205||Plataforma Adaptativa
|-
| 206||Repositório OA
|-
| 207||Tá na Rede
|-
| 210||Educom tchê
|-
| 212||Repositório
|-
| 213||Approxima
|-
| 214||Gestão Financeira
|-
| 215||Plateia
|-
| 218||Controle Financeiro de Repasses

|-
| 300||Agenda
|-
| 301||PEI - Programa de Ensino Informatizado
|-
| 302||Gestão de campeonatos
|-
| 303||Acessa Escola API
|-
| 600||SAML Google Apps
|-
| 601||Gmail
|-
| 997||Gestão Online
|-
| 3594||Fiscalização e Contratos (PHP)
|-
| 3595||Compras (PHP)
|-
| 3596||Convênios(PHP)
|-
| 4594||Fiscalização e Contratos (PHP) - DEV
|-
|
|}

Arquitetura do produto - Pesquisa

2016-08-15T14:12:50Z

Ricardo.agulhari: Criou página com '=Informações Gerais= == Ambientes utilizados == {| class="wikitable" |- ! Ambiente ! URL de Acesso ! Credenciais Admin |- | Desenvolvimento | http://dev-mscro.mstech.com.br...'

=Informações Gerais=

== Ambientes utilizados ==
{| class="wikitable"
|-
! Ambiente
! URL de Acesso
! Credenciais Admin
|-
| Desenvolvimento
| http://dev-mscro.mstech.com.br
| admin / 123456
|-
| Testes
| http://tst-mscro.mstech.com.br
| admin / ms@cro
|-
| Testes
| http://tst-mscro.mstech.com.br
| admin / ms@cro
|-
| Homologação Externa
| http://hom-mscro.mstech.com.br
| Informação exclusiva do Devops/GTI
|-
| Produção
| http://mscro.mstech.com.br
| Informação exclusiva do Devops/GTI
|}

== Repositório de Versionamento ==
'''Ambiente:''' GITLab - Git

'''Nome:''' MSCRO

'''Caminho:''' https://gitlab.mstech.com.br/mscro/app-mscro.git

'''Estrutura dos branches:''' Código mantido no tronco, porém mantemos 2 branches para os clientes SP e RJ.

=Visão de Componentes=

Apresente um diagrama básico dos módulos do sistema, bem como suas fronteiras. Descreva sucintamente cada módulo que compõe o produto, seu objetivo e como foi construído (linguagens usadas, bancos de dados, etc.).

=Decisões de Arquitetura=
Descrever os seguintes itens:

'''Persistência de dados''': Como foi resolvida no produto a persistência? Há banco relacional e não relacional? Quais são os bancos? Como é tratamento de sessão?

'''Tecnologias de Integração:''' Quais integrações existem com o produto? Como é essa integração? Via API, Webservices trafegando XML, serviços Windows? Há trabalho manual para tráfego de dados, como importação? Descreva aqui todas as integrações que a ferramenta possui.

'''Log: ''': Como é feito o log? Está em base relacional ou não relacional? Como é feita a consulta dos dados dessa log? Qual o escopo da log (é uma log de transações, log do servidor, etc.). Na arquitetura, a log é tratada por uma camada específica do sistema ou está misturada no código?

'''Padrão de Arquitetura utilizado:''' Se houve planejamento anterior, qual o padrão utilizado? Domain Driven Design (DDD) usando a estrutura MVC? Usa Webforms com outra arquitetura? Front-end e back-end são separados?

'''Tecnologia de Front-end:''' Se houver separação, qual tecnologia/framework foi empregada para o projeto? AngularJS, VUE, JQuery, uma composição deles? Qual padrão de codificação (estrutura de pastas, camadas) está sendo usado no projeto? Quais fatores levaram à decisão do framework e arquitetura definidas?

'''Tecnologia de Back-End:''' qual tecnologia/framework foi empregada para o projeto? ASP.NET, Java, NodeJS, uma composição deles? Qual padrão de codificação (estrutura de pastas, camadas) está sendo usado no projeto? Quais fatores levaram à decisão do framework e arquitetura definidas?

'''Framework de CSS:''' Está sendo utilizada uma ferramenta SASS? Qual framework está sendo usado? Bootstrap 3, Bootstrap 4, Foundation?

'''Configurações de Otimização de deploy:''' O código é minificado? O código está com ofuscação? No ASP.NET foi habilitado o bundle no web.config? Quais configurações para otimizar o código são feitas?

'''Outros aspectos:''' Fique à vontade para descrever outras considerações, o importante é deixar as decisões tomadas e padrões adotados bem documentados!

=Fundamentações das decisões tomadas=
Nesta seção, coloque todas as considerações das tomadas de decisão realizadas para o produto. Porque foi usada tal arquitetura? Porque essa separação de componentes? Porque houve refatoração? Descreva o máximo possível nesta seção para que o histórico das decisões seja armazenado para consultas futuras.

Especificações mínimas de hardware e software - Pesquisa

2016-08-15T14:12:29Z

Ricardo.agulhari: Criou página com ''''Requisitos do Cliente''' {| class="wikitable |- | Sistema Operacional||Linux, Windows 7 ou superior |- | Memória||1 GB |- | Navegador||Internet Explorer 10.0, Google Chro...'

'''Requisitos do Cliente'''

{| class="wikitable
|-
| Sistema Operacional||Linux, Windows 7 ou superior
|-
| Memória||1 GB
|-
| Navegador||Internet Explorer 10.0, Google Chrome 50.x
|}

'''Requisitos do Servidor'''
{| class="wikitable
|-
| Processador || Intel (R) Core (TM) i7-3820 CPU @ 3.60GHz (FileServer)
|-
| Memória Server||4 (Gb) para o web, 2 Gb para o fileServer
|-
| Disco Server||1 disco de 50Gb para SO - 1 disco de 30Gb para sites
|-
| FileServer || 1 disco de 50Gb para SO - 1 disco de 50Gb para arquivos
|-
| Sistema Operacional server||Windows Server 2008 R2 Enterprise
|-
| Banco de Dados||Microsoft SQL Server 2008 Enterprise (Inglês) Service Pack 2
|-
| Softwares necessários (exemplo: iis, framework .net, etc)||Considerar 2 máquinas em cluster para servidor web e 2 máquinas em cluster para banco de dados
|-
|}

Pesquisa Institucional

2016-08-15T14:10:56Z

Ricardo.agulhari: Criou página com '==Descrição== Descrever nesta área o que é o produto, quais as necessidades de negócio pretende atender, a quem se destina. ==Funcionalidades de Ouro== Nesta seção,...'

==Descrição==

Descrever nesta área o que é o produto, quais as necessidades de negócio pretende atender, a quem se destina.

==Funcionalidades de Ouro==

Nesta seção, insira 3 ou 4 funcionalidades que '''diferenciam''' e destacam o produto. De preferência coloque apenas os nomes das funcionalidades

==Link do Product Backlog==

Nesta seção, insira o link do Product Backlog do produto

==Outras informações==
* [[Requisitos funcionais - Pesquisa]]
* [[Requisitos não funcionais - Pesquisa]]
* [[Especificações mínimas de hardware e software - Pesquisa]]
* [[Arquitetura do produto - Pesquisa]]
* [[Integrações - Pesquisa]]
* [[Manual de instalação - Pesquisa]]

Produtos

2016-08-15T14:06:35Z

Ricardo.agulhari: /* 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]]
* [[Certificados]]
* [[Classpad]]
* [[Controle Patrimonial]]
* [[CoreSSO]]
* [[Coredu]]
* [[Educopédia]]
* [[Gestão Escolar / SGP]]
* [[Gestão Privado]]
* [[Loomi]]
* [[Moodle]]
* [[OpenId]]
* [[Pesquisa Institucional]]
* [[Portal Construtor]]
* [[Repasse de recursos financeiros]]
* [[Transporte Escolar]]
* [[Updrive]]
[http://www.example.com título do link]

Especificações mínimas de hardware e software - Repasse

2016-08-15T14:05:57Z

'''Requisitos do Cliente'''

{| class="wikitable
|-
| Sistema Operacional||Linux, Windows 7 ou superior
|-
| Memória||1 GB
|-
| Navegador||Internet Explorer 10.0, Google Chrome 50.x
|}

'''Requisitos do Servidor'''
{| class="wikitable
|-
| Sistema Operacional||Microsoft Windows Server 2008 Enterprise
|-
| Banco de Dados||Microsoft SQL Server 2008 Enterprise (Inglês) Service Pack 2
|-
| Software necessário||IIS 6.2 ou superior, .NET Framework 4.6.1
|}

Arquitetura do produto - Repasse

2016-08-15T14:04:58Z

Repasse de recursos financeiros

2016-08-15T14:02:48Z

==Descrição==

Descrever nesta área o que é o produto, quais as necessidades de negócio pretende atender, a quem se destina.

==Funcionalidades de Ouro==

Nesta seção, insira 3 ou 4 funcionalidades que '''diferenciam''' e destacam o produto. De preferência coloque apenas os nomes das funcionalidades

==Link do Product Backlog==

Nesta seção, insira o link do Product Backlog do produto

==Outras informações==
* [[Requisitos funcionais - Repasse]]
* [[Requisitos não funcionais - Repasse]]
* [[Especificações mínimas de hardware e software - Repasse]]
* [[Arquitetura do produto - Repasse]]
* [[Integrações - Repasse]]
* [[Manual de instalação - Repasse]]

Produtos

2016-08-15T14:02:22Z

Ricardo.agulhari: /* 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]]
* [[Certificados]]
* [[Classpad]]
* [[Controle Patrimonial]]
* [[CoreSSO]]
* [[Coredu]]
* [[Educopédia]]
* [[Gestão Escolar / SGP]]
* [[Gestão Privado]]
* [[Loomi]]
* [[Moodle]]
* [[OpenId]]
* [[Portal Construtor]]
* [[Repasse de recursos financeiros]]
* [[Transporte Escolar]]
* [[Updrive]]
[http://www.example.com título do link]

Especificações mínimas de hardware e software - Transporte

2016-08-15T13:37:43Z

'''Requisitos do Cliente'''

{| class="wikitable
|-
| Sistema Operacional||Linux, Windows 7 ou superior
|-
| Memória||1 GB
|-
| Navegador||Internet Explorer 8.0 com Service Pack 1, ou Firefox 3.6
|}

'''Requisitos do Servidor'''
{| class="wikitable
|-
| Sistema Operacional||Microsoft Windows Server 2008 Enterprise ou superior
|-
| Banco de Dados||Microsoft SQL Server 2008 Enterprise
|-
| Software necessário||IIS 6.2 ou superior, .NET Framework 4.6.1
|}

Transporte Escolar

2016-08-15T13:36:52Z

Ricardo.agulhari:

==Descrição==

Descrever nesta área o que é o produto, quais as necessidades de negócio pretende atender, a quem se destina.

==Funcionalidades de Ouro==

Nesta seção, insira 3 ou 4 funcionalidades que '''diferenciam''' e destacam o produto. De preferência coloque apenas os nomes das funcionalidades

==Link do Product Backlog==

Nesta seção, insira o link do Product Backlog do produto

==Outras informações==
* [[Requisitos funcionais - Transporte]]
* [[Requisitos não funcionais - Transporte]]
* [[Especificações mínimas de hardware e software - Transporte]]
* [[Arquitetura do produto - Transporte]]
* [[Integrações - Transporte]]
* [[Manual de instalação - Transporte]]

== Versões testadas do Produto ==
* [[Transporte 1.1.1.21]]

Especificações mínimas de hardware e software - Certificados

2016-08-15T13:35:40Z

Ricardo.agulhari:

'''Requisitos do Cliente'''

{| class="wikitable
|-
| Sistema Operacional||Linux, Windows 7 ou superior
|-
| Memória||1 GB
|-
| Navegador||Internet Explorer 10.0, Google Chrome 50.x
|}

'''Requisitos do Servidor'''
{| class="wikitable
|-
| Sistema Operacional||Microsoft Windows Server 2008 Enterprise ou superior
|-
| Banco de Dados||Microsoft SQL Server 2008 Enterprise
|-
| Software necessário||IIS 6.2 ou superior, .NET Framework 4.6.1
|}

Especificações mínimas de hardware e software - Certificados

2016-08-15T13:34:59Z

'''Requisitos do Cliente'''

{| class="wikitable
|-
| Sistema Operacional||Linux, Windows 7 ou superior
|-
| Memória||1 GB
|-
| Navegador||Internet Explorer 10.0, Google Chrome 50.x
|}

'''Requisitos do Servidor'''
{| class="wikitable
|-
| Sistema Operacional||Microsoft Windows Server 2008 Enterprise ou superior
|-
| Banco de Dados||Microsoft SQL Server 2008 Enterprise
|-
| Software necessário||IIS 6.2 ou superior, .NET Framework 4.6.1
|-
|
|}

Arquitetura do produto - Certificados

2016-08-15T13:32:15Z

Certificados

2016-08-15T13:31:57Z

==Descrição==

Descrever nesta área o que é o produto, quais as necessidades de negócio pretende atender, a quem se destina.

==Funcionalidades de Ouro==

Nesta seção, insira 3 ou 4 funcionalidades que '''diferenciam''' e destacam o produto. De preferência coloque apenas os nomes das funcionalidades

==Link do Product Backlog==

Nesta seção, insira o link do Product Backlog do produto

==Outras informações==
* [[Requisitos funcionais - Certificados]]
* [[Requisitos não funcionais - Certificados]]
* [[Especificações mínimas de hardware e software - Certificados]]
* [[Arquitetura do produto - Certificados]]
* [[Integrações- Certificados]]
* [[Manual de instalação- Certificados]]

Produtos

2016-08-15T13:31:06Z

Ricardo.agulhari: /* 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]]
* [[Certificados]]
* [[Classpad]]
* [[Controle Patrimonial]]
* [[CoreSSO]]
* [[Coredu]]
* [[Educopédia]]
* [[Gestão Escolar / SGP]]
* [[Gestão Privado]]
* [[Loomi]]
* [[Moodle]]
* [[OpenId]]
* [[Portal Construtor]]
* [[Transporte Escolar]]
* [[Updrive]]
[http://www.example.com título do link]

Especificações mínimas de hardware e software - Moodle

2016-08-08T19:54:20Z

Ricardo.agulhari: Criou página com '{| class="wikitable" | Sistema operacional|| windows 2008 R2 ou Linux |- | Banco de dados|| MYSQL 5.5 |- | Programação|| Orientada a objeto, código open source |- | Arquite...'

{| class="wikitable"
| Sistema operacional|| windows 2008 R2 ou Linux
|-
| Banco de dados|| MYSQL 5.5
|-
| Programação|| Orientada a objeto, código open source
|-
| Arquitetura de desenvolvimento||Baseado em Framework
|-
| Linguagem de programação|| PHP
|-
| Última versão|| 3.0
|-
| Computador requerido||Memória: 1 GB - SO: Linux, Windows 7 ou superior - Browser: Internet Explorer 10.0, Google Chrome 50.x
|-
| Computador requerido (servidor)||Intel (R) Core (TM) i7-3820 CPU @ 3.60GHz (Web) - 4 (Gb) de HD
|-
| Idioma||Português
|-
| Outras informações||
|}

Moodle

2016-08-08T19:53:23Z

Ricardo.agulhari:

==Descrição==

Descrever nesta área o que é o produto, quais as necessidades de negócio pretende atender, a quem se destina.

==Funcionalidades de Ouro==

Nesta seção, insira 3 ou 4 funcionalidades que '''diferenciam''' e destacam o produto. De preferência coloque apenas os nomes das funcionalidades

==Link do Product Backlog==

Nesta seção, insira o link do Product Backlog do produto

==Outras informações==
* [[Requisitos funcionais]]
* [[Requisitos não funcionais]]
* [[Especificações mínimas de hardware e software - Moodle]]
* [[Arquitetura do produto Moodle]]
* [[Integrações Moodle]]
* [[Manual de instalação]]

== Versões testadas do produto ==
* [[Moodle 3.1.1]]