Sie sind auf Seite 1von 57
Manual d e Desenvolvimen to para Aplica ções Web da STI/I CMC Autor: Igor V.

Manual d e Desenvolvimen to para

Aplica ções Web da STI/I CMC

Autor: Igor V. Custódio Data: 25/11/2015 Versão 1.0

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

Histórico de Versão

Histórico de Versão DATA VERSÃ O DESCRIÇÃO AUTOR 25/11/2015 1.0 Versão inicial do documento

DATA

VERSÃ O

DESCRIÇÃO

AUTOR

25/11/2015

1.0

Versão inicial do documento

Igor Vitório Custódio

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

Conteúdo

Conteúdo Histórico de Versão 2   1. Introdução 7 2. Processo 8 2.a Redmine 8 2.b

Histórico de Versão

2

 

1. Introdução

7

2. Processo

8

2.a

Redmine

8

2.b

GIT

9

2.c Controle de Versão

10

2.c.i Commits e Updates

10

2.c.ii Pacotes e Arquivos Mí nimos

11

2.d Controle de Mudanças

11

2.d.i Versões e Releases

12

2.d.ii Branchs

12

2.d.iii Não conformidades

14

2.e Documentação Externa

14

2.f Sistemas Legados

15

3. Arquitetura das Aplicações

16

3.a Diagrama

16

3.b Arquitetura de aplicações PHP para WEB

16

3.b.i Jquery / Ajax / JqueryU I

17

3.b.ii Webservices

17

3.c Modelo de Construção de Aplicações

17

3.d Frameworks PHP

18

3.d.i CodeIgniter

18

3.d.ii PEAR - PHP Extension and Application Repository

18

3.e Sistema Gerenciador de B anco de Dados (SGBD)

18

3.f Editores de texto/IDE

19

3.g Depuradores

19

3.h Navegadores

19

3.i

Tarefas agendadas

20

3.j Ambientes

20

3.j.i Ambiente de Produção

20

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

3.j.ii Ambiente de Homolog ação 20 3.j.iii Ambiente de Desenvo lvimento 21 4. Regras de

3.j.ii Ambiente de Homolog ação

20

3.j.iii Ambiente de Desenvo lvimento

21

4. Regras de codificação PHP

22

4.a Nomenclaturas

22

4.a.i Estrutura de diretórios para o projeto

22

4.a.ii Nomenclaturas

22

4.b Indentação e blocos

23

4.c Tratamento de Exceções

23

4.d

Constantes

23

4.e Views

23

4.e.i Includes

24

4.e.ii Identidade Visual

25

4.f.i Biblioteca ICMCUtil

25

4.g Cookies e Sessions

25

4.h Mecanismos de Autentica ção

25

4.h.i OAuth USP

26

4.h.ii Autenticação local

26

4.h.iii LDAP

26

4.h.iv Radius

26

4.i Otimizações

26

4.i.i Strings

26

4.i.ii Concatenação de Strin gs

27

4.i.iii Otimização em laços d e repetições

27

4.i.iv Validação de Strings e entradas

27

4.j Padrão de interoperabilida de de dados

28

4.j.i eXtensible Markup Lan guage (XML)

28

4.j.ii JavaScript Object Nota tion (JSON)

28

4.j.iii RDF Site Summary (RS S)

28

4.j.iv Arquivos textos separ ados por vírgula (CSV)

28

5. Segurança

30

5.a Nunca confiar nos usuário s

30

5.a.i Validação no cliente

30

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

5.a.i Validação no servidor   30 5.b Validação no SGBD 30 5.c Role-based access control

5.a.i Validação no servidor

 

30

5.b Validação no SGBD

30

5.c Role-based access control (RBAC)

31

5.d Captcha

 

31

5.e Atualizações

32

5.f Permissões de acesso a arq uivos

 

32

5.g Tratamento de páginas de Erro

32

5.h Criptografia de campos

32

5.i Políticas de senhas

33

5.j Cópias de Seguranças

33

5.k Parâmetros GET

33

6. Registros de Auditoria

 

34

7. Internacionalização

36

8. Acessibilidade

 

37

9. Email

38

10.

Documentação de Códigos

 

39

10.a Documentação das Class es

39

10.b Documentação de métod os em geral

40

10.c Documentação de HTML

41

11.

Programação SQL

 

42

11.a

Regras de

Modelagem

42

11.b Ferramenta de Modelage m, Análise e Documentação

42

11.c

Regras de Codificação

 

42

11.c.i Escrita dos comandos

42

11.c.ii A cláusula WHERE é

crucial

43

11.c.iii Nunca utilizar a orde m das colunas

43

11.c.iv Quanto mais restriçõ es melhor

43

11.c.v O mais simples possí vel

43

11.c.vi Visitar os dados o m enor número de vezes possível

44

11.c.vii Remoções lógicas s omente, nunca DELETE

44

11.d

Utilização de Índices

 

44

11.e Use o “Explain plain”

44

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

11.f Tipos de Dados 46 12. Licenciamento 47 13. Testes automáticos 48 Anexo A 49

11.f Tipos de Dados

46

12. Licenciamento

47

13. Testes automáticos

48

Anexo A

49

Anexo B

53

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

1. Introdução

1. Introdução O presente documento t em como objetivo descrever as principais técnic as, linguagens, processos

O presente documento t em como objetivo descrever as principais técnic as, linguagens, processos e

práticas para desenvolvimento

Instituto de Ciências Matemát icas e de Computação (ICMC), ou por tercei ros, e que venham a ser introduzidos no âmbito do ICMC .

de Sistemas Computacionais pela Seção Técni ca de Informática (STI) do

Todos os pontos aqui ab ordados são classificados segundo as palavras ch aves:

ab ordados são classificados segundo as palavras ch aves: • ser utilizado/implementado/apresentado obrig atoriamente

ser utilizado/implementado/apresentado obrig atoriamente nos sistemas

novos desenvolvido s. Quando a classificação não for explicitame nte citada, ela deverá ser considerada como M andatório;

: de c aráter não obrigatório a utilização/implementaç ão/apresentação, mas que

devem ser previst os no desenvolvimento, pois podem ser r equisitos futuros ou ser transformado em M andatório em uma próxima revisão;

que

devem ser previst os no desenvolvimento, pois podem ser r equisitos futuros ou ser

transformado em Re comendados ou Mandatórios em uma próxima

Mandatório : deve

ou Mandatórios em uma próxima Mandatório : deve • Recomendado Opcional : • de carát er

Recomendado

Opcional :
Opcional
:

de

carát er não obrigatório

a utilização/implementaçã o/apresentação, mas

revisão.

Todos os softwares leg ados, ou seja, que já tenham sido desenvolv idos e estejam recebendo manutenção pela STI/ICMC dev em ser enquadrados/adaptados para os ponto s classificados e sinalizados neste documento.

Este documento não re voga ou substituí normas ou portarias internas devem ser seguidas.

gerais da USP. Assim, elas

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

2. Processo

2. Processo Esta seção tem como ob jetivo descrever e classificar, em linhas gerais, a s

Esta seção tem como ob jetivo descrever e classificar, em linhas gerais, a s ferramentas, processos e práticas, que a STI do ICMC defin e para o Desenvolvimento de Software.

2.a Redmine

A Seção Técnica de Info rmática do ICMC disponibiliza um serviço de g estão de projetos Redmine através do endereço: https://de vel.icmc.usp.br.

realizado o registro dos projetos na plataform a, bem como de todas as

necessidades, correções (tarefas ), códigos fontes, procedimentos etc.

É

Mandatório

que seja

É Mandatório

que seja r ealizado o cadastro de pelo menos um responsá vel (Gerente) pelo projeto.

Mandatório

É

privado.

que seja certificad o que todos os projetos sob sua responsabilidad e estão configurados como

Caso algum projeto tenh a a necessidade de não ser configurado como p rivado, ou seja, configurado

projeto em questão que

de anexos, ofícios, despachos ou outra docu mentação da STI ou órgão

como público deverá haver um documente tal decisão através equivalente.

a tarefa específica registrada no Redmine do

É

Mandatório

que as pe rmissões de acesso ao projeto estejam configur adas como especificados na

Tabela 1.

TABELA 1 – PAPÉIS NO REDMINE

Papel

Atribuições

O

bservações

Gerente

Responsável geral pelo projeto

 

Desenvolvedor

Responsável pelo desenvolvimento do código e alimentação dos repositórios

 

Informante

Responsável por fornecer requisitos e testar o sistema

 

Tester

Responsável por realizar testes de funcionalidades

 

Produção

Responsável por colocar em produção o sistema, as mudanças solicitadas etc

 
 

FONTE: DO AUTOR

É Mandatório

que todos os integrantes do projeto tenham uma conta no

Redmine.

os integrantes do projeto tenham uma conta no Redmine. É Mandatório que o tít ulo do

É Mandatório

que o tít ulo do projeto seja suficiente para identificá-l o univocamente dentre os

demais projetos.

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

É Mandatório que a des crição do projeto contenha um texto informand o as características

É

Mandatório

que a des crição do projeto contenha um texto informand o as características básicas

do sistema que contenha.

o as características básicas do sistema que contenha. É Mandatório É Mandatório É Recomendado É Recomendado

É Mandatório

É Mandatório

É Recomendado

É Recomendado

que o Iden tificador do Projeto represente o nome do Proje to.

que todos os tipos de tarefas sejam incluídos no projeto.

que a P ágina do Projeto seja o mesmo que o identificad or.

que o p rojeto seja filho de um outro projeto pré-existe nte correspondente direto

ao novo projeto em questão.

É

Recomendado

que sej a realizada a ativação de todos os módulos disp oníveis na plataforma para

o novo projeto.

FIGURA 1:

EXEMPLO DE CONFIGURAÇÃO DE NOVO PROJETO DO RED MINE

1: E XEMPLO DE CONFIGURAÇÃO DE NOVO PROJETO DO R ED MINE F ONTE : D

FONTE: DO AUTOR

2.b GIT

A Seção Técnica de Inf ormática do ICMC disponibiliza integrado com Controle de Versão GIT 1 .

o Redmine o Sistema de

É

Mandatório

que

os

projetos

tenham

disponibilizado pela plataforma

Redmine do ICMC.

seus

controles

de

vers ão

gerenciados

pelo

GIT

1 Maiores informações em: https:// git-scm.com/

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

É Mandatório que os de senvolvedores definem uma senha local no sis tema Redmine para

É

Mandatório

que os de senvolvedores definem uma senha local no sis tema Redmine para prover

autenticação no repositório GIT.

É Mandatório que o Iden tificador do repositório seja o mesmo do Projet o. É
É
Mandatório
que o Iden tificador do repositório seja o mesmo do Projet o.
É
Mandatório
que
o
caminho para o repositório seja “/opt/git/XX XXX”, onde “XXXXX” é o

Identificador do projeto/reposit ório.

É

Mandatório

que esteja ativada a opção “Relatar última alteração para

arquivos e diretórios”.

FIGURA 2: EXEMPLO DE CONFIGURAÇÃO DE REPOSITÓRIO PRINCIPAL GIT NO R EDMINE ICMC

DE REPOSITÓRIO PRINCIPAL GIT NO R EDMINE ICMC F ONTE : D O A UTOR 2.c

FONTE: DO AUTOR

2.c Controle de Versão

de todo Sistema abordado neste documento d eve ser mandatoriamente

efetuado utilizando-se o GIT i ntegrado com o Redmine. Isto permite que d esenvolvedores diferentes possam trabalhar em um mes mo projeto intercambeando o mínimo possív el de arquivos e evitando conflitos de código.

do Sistema, seja arquivos documentação, bibliotecas

fontes, configurações adicionai s do sistema, modelos de banco de dados, adicionais, testes unitários etc.

O Controle de Versão

É

Mandatório

que o ve rsionamento de todos os itens que fazem parte

2.c.i Commits e Updates

O versionador GIT perm ite o desenvolvimento descentralizado e assim commits locais e globais.

Considera-se os comm its locais aqueles que o desenvolvedor real iza em seu ambiente de desenvolvimento sem submeter ao repositório mestre do projeto (GIT/Redmine) .

em seu ambiente e que é

submetido ao repositório mest re do projeto (GIT/Redmine) e que sinaliza qu e o código está testado e pronto para entrar em produçã o. Esta operação também será recebida pelos o utros desenvolvedores que estiverem trabalhando no mesm o projeto.

realizados commits locais pequenos, ou seja, co m poucas modificações. Os

comentários destes commits dev em conter indicação do que se trata a modificaç ão.

possibilita a utilização de

Considera-se os commit s globais aqueles que o desenvolvedor realiza

É

Mandatório

que sejam

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

É Recomendado que os comentários dos commits locais estejam vincula dos a um número de

É

Recomendado

que os comentários dos commits locais estejam vincula dos a um número de tarefa

no projeto específico do Redmin e e relacionado com a Hashtag (#) do número da

tarefa.

É Mandatório

que os C ommits Globais estejam vinculados a pelo me nos uma tarefa no projeto

específico do Redmine e relacion ado com a Hashtag (#) do número da tarefa. Por exemplo:

Tarefa 1555: “Não c adastra usuários”

Commit’s Locais:

o

Estudo do b ug relatado em #1555 (

)

o

Tentativa de correção do bug relatado em #1555 (

)

o

Outra tentat iva de correção do bug relatado em #1555 (

)

o

Adição de co mentário da correção do bug relatado em #155 5 (

)

Commit Global:

o Correção do bug relatado em #1555 Isto é necessário porqu e o Redmine da STI/ICMC está integrado com

o GIT e faz a referência

cruzada do comentário do Com mit com a tarefa relacionada utilizando para isto a Hashtag (#) em questão.

Isto permite uma melhor gestão e rastreabilidade das mudanças do código.

que o des envolvedor realize “checkouts”, “pull”, “push” e “commits” frequentemente

durante o desenvolvimento do s istema para receber as atualizações de código q ue outros desenvolvedores possam ter submetidos ao repos itório principal.

alterações

vinculando-as a seu usuário, por exemplo:

É

É

Mandatório

Mandatório

que

o

desenvolvedor

configure

seu

ambiente

para

registrar

suas

git config --global us er.name “Fulano da Silva”

git config --global us er.email fulano@icmc.usp.br

2.c.ii Pacotes e Arquivos Mín imos

É

Mandatório

que todo s os projetos armazenados no Repositório GIT /Redmine do ICMC devem

conter alguns arquivos/diretório s essenciais:

Pasta de Códigos F ontes “src”: Pasta contendo os fontes da apli cação e todos os arquivos necessários para exe cução, como bibliotecas etc;

o Deve ser n omeada de acordo com o nome do repositó rio, no exemplo: “projeto- documentac ao”

Pasta “docs”: Cont endo todas as documentações externas ao si stema, como: Manuais de usuário, diagramas, documentos de requisitos;

o Arquivo LEI AME.TXT: contendo informações básicas de con figurações necessárias para

descrição da instalação das

instalação, e xecução ou operação do sistema, bem como a

bibliotecas e xternas ao projeto, se for o caso.

Pasta “bd”: Conten do toda a documentação referente à model agem do sistema, como o dicionário de dados, instruções SQL, códigos de atualizações e backu ps da base de dados.

2.d Controle de Mudanças

mudança no código tenha uma tarefa corresp ondente no Redmine/ICMC

que o motive/justifique/descrev a. Como explicitado em 2 .c.i, os Commits devem referenciar mandatori amente esta tarefa com a

utilização da Hashtag com o nú

É

Mandatório

que toda

mero da tarefa.

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

2.d.i Versões e Releases

2.d.i Versões e Releases o registr o de Versões Intermediárias (Tags 2 ) do softwa re

o registr o de Versões Intermediárias (Tags 2 ) do softwa re sempre que o software

tenha sido disponibilizado p ara colocação em produção, ou seja, sem pre que um Branch de desenvolvimento tenha sido me sclado com o Branch principal (master).

É

Mandatório

Estas tags devem respeit ar mandatoriamente:

Tags “Lightweight

(leves): utilizada para indicar uma versão de

software para controle de

mudanças menores;

Tags “Annotated” (A notadas): utilizada para indicar uma versão de s oftware em produção.

As tags devem mandato riamente ter a seguinte nomenclatura “vX.Y.Z”, s endo que:

v: letra “v” em minú sculo indicando uma versão;

X: número inteiro po sitivo começando do zero e incrementado de u ma unidade sempre que um conjunto de mudan ças signiticativas e de grande importância ten ham sido implementadas e estejam em produçã o;

.: caractere “.” caso a tag X tenha alguma versão filha

Y: número inteiro p ositivo começando do zero e incrementado d e uma unidade indicando mudanças menores , agrupamento de correções de erros, ag rupamento de adição de funcionalidades men ores, agrupamento de evoluções etc;

.: caractere “.” caso a tag Y tenha alguma versão filha

Z: número inteiro

positivo começando do um e incrementado d e uma unidade indicando

mudanças menore s. Usado mandatoriamente para correçõe s de erros, adição de funcionalidades men ores, evoluções simples etc.

a utiliza ção do sufixo “-rcW”, onde “W” é um número i nteiro positivo, começando

do um e incrementado em um a unidade para agrupar mudanças que serão i ndicadas para entrada em produção na nova versão “X”.

sejam sincronizadas com o

Em GIT a utilização de repositório GTI/Redmine/ICMC

com o Em GIT a utilização de repositório GTI/Redmine/ICMC É Recomendado tags é local, assim é

É Recomendado

tags é local, assim é Mandatório que as tags

do projeto com o comando “git push origin [nom e_da_tag]”.

Exemplo cronológico de tags submetidas:

v0 (tag anotada)

v0.1 (tag leve)

v0.2 (tag leve)

v0.3 (tag leve)

v0.3.1 (tag leve)

v0.3.2 (tag leve)

v0.3.4 (tag leve)

v1-rc1 (tag leve)

v1-rc2 (tag leve)

v1 (tag anotada)

2.d.ii Branchs

É

Mandatório

que os pro jetos possuam apenas um branch principal cha

mado “master”. Este Branch

deve mandatoriamente conter a versão de código que está em produção.

2 https://git-scm.com/book/en/v2/ Git-Basics-Tagging

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

que os pr ojetos possuam apenas um B ranch desenvolvim ento. Este Branch deriva do

que os pr ojetos possuam apenas um Branch desenvolvim ento. Este Branch deriva do

branch master. Deste branch de senvolvimento devem derivar os demais branc hs das tarefas que incluirão funcionalidades/correções, etc. Este branch desenvolvim ento será mesclado (merge) com o branch mast er a fim de gerar uma nova versão de produção após os test es de integração bem sucedidos.

É

Mandatório

Mandatório

É que os de mais branchs tenham o nome prefixado em “tar” .

É que todas

Mandatório

as mudanças aplicadas no branch master deve m provir de branchs filhos.

Isto inclui a criação dos arquivos iniciais.

É

Mandatório

que cada tarefa a ser desenvolvida possua um branch co m a seguinte nomenclatura

tarXXXX, onde XXXX é o número da respectiva tarefa.

Exemplo: tarefa 1666. B ranch que conterá o desenvolvimento tar1666.

um exemplo de configuração inicial do reposit ório master, do repositório

desenvolvimento, bem como da criação de um branch para desenvolvimento de determinada tarefa.

Já no Anexo B se encont ra um exemplo de desenvolvimento a partir de um branch pré-configurado seja ele master, desenvolviment o ou algum outro de tarefas, bem como ilustra a colocação em produção. A Figura 3 exemplifica a linha de desenvolvimento utilizado no âmbito de ste manual. Nela verifica-se uma tar efa T0, a inicial, que irá gerar os branch master e desenvolvimento. Convém citar que para um projeto novo, o branch master ficará praticamente vazio, por ém ele poderá ter bastante conteúdo quando do carregame nto de aplicações legadas. Observa-se também que o branch de desenvolvimento é o que hospeda as bifurcações novas, como por exemplo, as tarefas T1 e T2. Nestas tarefas efetivame nte implementam os códigos que será adiciona dos ao projeto.

linha de desenvolvimento será mesclada (merg e) com a linha master a fim

de gerar uma nova versão de pr odução. Na imagem também est ão indicados os usos de tags para facilitar a orga nização das versões.

No Anexo A se encontra

Após a homologação, a

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

F IG URA 3: E XEMPLO DE LINHA DE DESENVOLVIMENTO GIT F ONTE : D

FIG URA 3: EXEMPLO DE LINHA DE DESENVOLVIMENTO GIT

F IG URA 3: E XEMPLO DE LINHA DE DESENVOLVIMENTO GIT F ONTE : D O

FONTE: DO AUTOR

2.d.iii Não conformidades

neste manual devem ser

considerados não conformes. Is to significa que deve ser aberta nova tarefa sin alizando como Tarefa Pai a

tarefa que se detectou a não co nformidade, com a anexação de logs, informaç ões ou relatório que ateste

tal detecção e assim a correção

Todo

software

que

nã o

esteja aderente

às

informações

contidas

deve ser providenciada.

2.e Documentação Exter na

É

Mandatório

que toda funcionalidade convertida em desenvolvimento tenha uma documentação

correspondente.

É Mandatório

que infor mações gerais sobre as solicitações/mudanças e stejam nas descrições e/ou

anexas às tarefas respectivas do Redmine ICMC.

É

Mandatório

que cópi as de emails com solicitações/autorizações/inf ormações sejam anexadas

(arquivos no formato PDF) nas r espectivas tarefas do Redmine.

É

Recomendado

que

a

cópia

da

documentação

esteja

na

pasta

subdiretórios com o nome da t arefa em questão. Por exemplo: documentação deve ser armazenada dentro do diretório “docs/1677/”.

docs do repositório, em da tarefa de número 1677

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

2.f Sistemas Legados É Mandatório que na p rimeira manutenção de qualquer sistema lega do

2.f Sistemas Legados

É

Mandatório

que na p rimeira manutenção de qualquer sistema lega do seja criado um projeto

respectivo no Redmine do ICMC .

 

Mandatório

É que seja i niciado um versionamento (GIT) dos códigos fo ntes, conforme orienta este

manual.

 

Mandatório

É que qua lquer nova mudança neste software siga as

orientações contidas neste

manual.

software siga as orientações contidas neste manual. É Recomendado que as mudanças sejam efe tuadas segundo

É Recomendado

que

as

mudanças

sejam

efe tuadas

segundo

as

orientações/diretrizes/linguagen s/arquiteturas contidas neste manual.

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

3. Arquitetura das Apli cações Esta parte do document o tem como objetivo descrever as

3. Arquitetura das Apli cações

Esta parte do document o tem como objetivo descrever as arquiteturas STI/ICMC desenvolvidas no âmb ito deste manual.

3.a Diagrama

das aplicações padrões da

Na Figura 4 está ilustrad a a arquitetura geral das aplicações da STI/ ICMC :

FIGURA 4 - ARQUITETURA GERAL DAS APLICAÇÕES

STI/ ICMC : F IGURA 4 - A RQUITETURA GERAL DAS APLICAÇÕES F ONTE : D

FONTE: DO AUTOR

seja, os clientes, utilizando

seus navegadores ou aplicações com Webservices acessam recursos do ambient e da Cloud ICMC através de

requisições (HTTP/HTTPS/XML/ SOAP/JSON/RSS) e recebem após o processam (HTTP/HTTPS/XML/SOAP/JSON/ RSS).

ento adequado respostas

Nela é possível verificar a integração básica entre os componentes. Ou

3.b Arquitetura de aplic ações PHP para WEB

É

Mandatório

ou superior.

que as ap licações desenvolvidas no âmbito do ICMC utili zem da linguagem PHP 3 5.5

É

Mandatório

que as ap licações em PHP rodem em servidores Web A pache HTTP 4 versão 2.4 ou

superior.

É

Mandatório

que as ap licações utilizem um dos Sistemas de Gerencia mento de Banco de Dados

Relacionais (SGBD) MySQL Com munity Server 5 superior.

3 https://secure.php.net/

4 http://httpd.apache.org/

5 http://dev.mysql.com/downloads /mysql/

6 http://www.postgresql.org/

versão 5.5 ou superior; ou P ostgresSQL 6

versão 9.3 ou

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

que todo s os tipos de acessos aos aplicativos desenvol vidos sejam efetuadas em ambientes

que todo s os tipos de acessos aos aplicativos desenvol vidos sejam efetuadas em

ambientes com conexões HTTP S com Certificados Digitais válidos. Neste cas o, o desenvolvedor deverá providenciar os certificados ou s inalizar a utilização dos Certificados HTTPS da ST I/ICMC.

aplicação possa ter o SGBD comutado dentre o s dois citados, com apenas

mudanças de arquivos de config urações da aplicação desenvolvida.

feito com conexões do tipo

“MySQLi”.

É

Mandatório

É Recomendado que a

É

Mandatório

que caso

seja utilizado o SGBD MySQL que o acesso seja

3.b.i Jquery / Ajax / JqueryUI

É permitida a implement ação de interações, plugins e funcionalidades qu e utilizam as bibliotecas:

Jquery 7 : versão 1.11 .3 ou superior

JqueryUI 8 : versão 1. 11.4 ou superior

É

Recomendado

que as

interações entre telas sejam efetuadas via ch amadas Ajax (Asynchronos

Javascript and XML).

É

Mandatório

que todas as entradas e chamadas Ajax sejam validadas a ntes de serem processadas

pelo servidor.

Mandatório

É

Ou seja, não

que todos os códigos/includes/funções/bibliotecas esteja

m hospedadas localmente.

é permit ido que sejam

realizados includes de códig os de fora do escopo de

hospedagem da aplicação, por e xemplo:

<script src="https://ma xcdn.bootstrapcdn.com/bootstrap/3.3.5/js/boot strap.min.js"</script>

3.b.ii Webservices

É

Mandatório

que os có digos desenvolvidos possam ser integrados com

ferramentas automáticas,

serviços existentes ou serviços d e terceiros através de consultas a Webservices q uando necessário.

3.c Modelo de Construçã o de Aplicações

É

Mandatório

que as apl icações desenvolvidas estejam no padrão Model View e Controler (MVC).

Considera-se o padrão edição (2004), conforme Figura

MVC abordado por Ian Sommerville no livro Eng enharia de Software sétima

5.

7 http://jquery.com/

8 http://jqueryui.com/

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

F IGURA 5: P ADRÃO MVC F ONTE : S OMMERVILLE , I AN (2004)

FIGURA 5: PADRÃO MVC

F IGURA 5: P ADRÃO MVC F ONTE : S OMMERVILLE , I AN (2004) 3.d

FONTE: SOMMERVILLE, IAN (2004)

3.d Frameworks PHP

É

Mandatório

que as ap licações desenvolvidas no âmbito deste manual

base nos frameworks listados.

É Mandatório

que não s ejam misturados Frameworks.

estejam estruturadas com

3.d.i CodeIgniter

É

Mandatório

que as ap licações que utilizem o framework PHP CodeIg niter 9 sejam desenvolvidas

com a versão 3.0.2 ou superior.

É Mandatório

que

sej am

seguidas

as

instruções,

especificadas pelo Framework e m questão.

boas

práticas

e

regras

de

nomenclatura

3.d.ii PEAR - PHP Extension a nd Application Repository

É

Mandatório

que as ap licações que utilizem o framework PEAR - PHP

Extension and Application

Repository (PEAR) 10 sejam desen volvidas com a versão 1.10.1 ou superior.

É Mandatório

que

sej am

seguidas

as

instruções,

especificadas pelo Framework e m questão.

boas

práticas

e

regras

de

nomenclatura

3.e Sistema Gerenciador de Banco de Dados (SGBD)

É

Mandatório

definidas no item 3.b.

que as ap licações desenvolvidas no âmbito deste manual

9 https://codeigniter.com/ 10 https://pear.php.net/

utilizem os SGBS e versões

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

É administradores. Mandatório que o ac esso ao serviço de SGBD seja efetuado com u

É

administradores.

Mandatório

que o ac esso ao serviço de SGBD seja efetuado com u suários sem permissão de

É Mandatório

que as c onfigurações de acesso ao SGBD sejam param

etrizadas em arquivos de

configuração da aplicação desen volvida.

É

Mandatório

que seja c ontrolada a finalização/fechamento das conexõe s com o SGBD tão logo elas

não sejam mais necessárias no c ódigo.

É

É

Mandatório Mandatório
Mandatório
Mandatório

É

Recomendado

É

Recomendado

É

Recomendado

que a bas e de dados esteja configurada para aceitar caract eres codificados em UTF8.

que

a

que as

que o

base

de

dados

esteja

configurada

para

que

serviço de SGBD esteja armazenado e ativo

o

container

suporte

as

propriedades ACID (Atomicidade , Consistência, Isolamento e Durabilidade).

aplicações possam utilizar e conectar a instân cia de SGBD com usuários

distintos, de acordo com a restri ção de acesso aos dados.

em um host diferente da

aplicação que o acessará.

que se ja atribuída as permissões estritamente neces sárias para a execução do

código aos usuários de conexã o ao SGBD. Por exemplo, não atribuir a poss ibilidade de criar/remover tabelas caso não seja necessário .

3.f Editores de texto/IDE

que os c ódigos fontes sejam desenvolvidos utilizando-s e arquivos com codificação

em UTF-8 sem BOM.

que na u tilização de qualquer editor do tipo Integrated Development Environment

(IDE), cujos arquivos de config uração do projeto vinculados ao aplicativo e q ue dependam dele para o desenvolvimento sejam salvas ta mbém no repositório GIT do projeto.

É

É

Mandatório

Mandatório

É

Recomendado

o des envolvimento de aplicações utilizando o Not epad++ 11 versão 6.8.5 ou

superior.

É

Recomendado

o desen volvimento utilizando o Netbeans 12 versão 8.0 o u superior.

3.g Depuradores

É

Mandatório

que a de puração de códigos PHP seja realizada utiliza ndo o depurador Xdebug 13

versão 2.3.3 ou superior.

É

Mandatório

que a a plicação tenha em arquivos de configuração a

possibilidade de ativar e

desativar informações relevante s de depuração.

É

Mandatório

que em pr odução não sejam exibidas mensagens de depur ação ao usuário.

3.h Navegadores

É

Mandatório

que as a plicações desenvolvidas no âmbito deste man ual sejam desenvolvidas e

testadas para serem utilizadas n os seguintes navegadores:

Chrome 14 : versão 45 ou superior

11 https://notepad-plus-plus.org/

12 https://netbeans.org/

13 http://xdebug.org/

14 https://www.google.com.br/chro me/browser/desktop/

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

• Firefox 1 5 : versão 41 ou superior É Recomendado que a navegadores: aplicação

Firefox 15 : versão 41

ou superior

• Firefox 1 5 : versão 41 ou superior É Recomendado que a navegadores: aplicação seja

É Recomendado que a

navegadores:

aplicação seja desenvolvida e testada para s er utilizada nos seguintes

Safari: versão 5.1 ou superior

Opera: Versão 12.1x ou superior

IE: versão 8 ou supe rior

Microsoft Edge

3.i Tarefas agendadas

É Mandatório

que

as

aplicações

desenvolvidas

no

âmbito

deste

manual

possam

ter

ações

periódicas executadas por solicit ações do serviço Cron.

É

Mandatório

que a exe cução destas tarefas sejam validadas antes de ex ecutar, evitando que sejam

ativadas fora do período específ ico ou em vezes superiores ao esperado.

3.j Ambientes

O ICMC disponibiliza par a o processo de implantação de software dois a mbientes, o de produção e

de homologação. Além disto, fic a a cargo do desenvolvedor utilizar sua máquina para desenvolvimento local.

3.j.i Ambiente de Produção

O ICMC disponibilizará u m ambiente de Produção com os requisitos co ntidos neste manual para a

execução final do sistema desen volvido.

É

Mandatório

que o a cesso a este ambiente seja realizado com u suário sem permissão de

administrador.

Mandatório

É que não s eja efetuado desenvolvimento ou testes de códig o neste ambiente.

Mandatório

É que pacot es adicionais ou configurações específicas sejam

documentadas e enviadas

aos responsáveis pelo ambiente de produção, que efetuarão a instalação.

É

Recomendado

que a

diferente do desenvolvedor.

colocação da aplicação em produção seja efe tuada por um profissional

3.j.ii Ambiente de Homologa ção

O ICMC disponibilizará

um ambiente de Homologação análogo ao

de produção, para que as

funcionalidades sejam homolog adas antes de serem colocadas em produção.

É

Mandatório

que a apli cação seja carregada no ambiente de homologa ção antes de ser carregada

no ambiente de Produção.

É

Mandatório

que a apl icação só seja carregada no ambiente de Prod ução após a certificação de

que as funcionalidades referent es à versão foram devidamente implementadas. Incluí-se neste caso os te stes e aceites dos usuários requisitantes das tar efas.

15 https://www.mozilla.org/pt-BR/fi refox/new/

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

É Recomendado que o ambiente de homologação possua volume de d ados próximo ao ambiente

É

Recomendado

que o

ambiente de homologação possua volume de d ados próximo ao ambiente

de produção.

 

É

Recomendado

que os

dados do ambiente de Homologação estejam

descaracterizados a fim de

não expor dados de usuários rea is.

3.j.iii Ambiente de Desenvolv imento

O ambiente de desenvol vimento é de responsabilidade do Desenvolvedo r.

É

Mandatório

que

o

ambiente

de

desenvolvimento

seja

arma zenado

Desenvolvedor.

na

máquina

do

É

Mandatório

que os sof twares instalados sigam as especificações do pr esente manual e contemple

os requisitos solicitados.

do pr esente manual e contemple os requisitos solicitados. É Mandatório É Mandatório que não s

É Mandatório

É Mandatório

que não s ejam carregados dados de produção no ambient e de desenvolvimento.

que o De senvolvedor mantenha o repositório GIT atuali zado conforme orientações

fornecidas pelo manual.

É

Opcional
Opcional

que o ICMC d isponibilize uma máquina virtual com configura ções análogas ao ambiente

de Homologação para que seja u tilizada como ambiente de desenvolvimento.

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

4. Regras de codificaçã o PHP Nesta seção do manual PHP no âmbito da STI/ICMC.

4. Regras de codificaçã o PHP

Nesta seção do manual

PHP no âmbito da STI/ICMC.

estão abordados pontos importantes para o des envolvimento de aplicações

Os códigos desenvolvido s devem atender aos requisitos aqui explicitad os, bem como as melhores

práticas de cada Framework util izado.

É

Mandatório

, em casos

omissos, que os códigos desenvolvidos sigam

PHP Framework Interop Group ( PHP-FIG) 16 .

4.a Nomenclaturas

os padrões propostos pelo

4.a.i Estrutura de diretórios

para o projeto

É Mandatório

do diretório “src”.

É Mandatório

mesmo diretório raiz. Por exemplo:

que todo s os códigos fontes necessários para a aplicaçã o funcionar estejam dentro

que seja m organizados os arquivos com funções/est ruturas/linguagens em um

src/imagens/: para i magens estáticas;

src/js/: códigos javas cript, bibliotecas Jquery e afins;

src/css/: códigos de estilos.

Jquery e afins; • src/css/: códigos de estilos. É Mandatório que diretó rios que recebam arquivos

É Mandatório

que diretó rios que recebam arquivos através upload sejam

dedicados exclusivamente

a esta operação.

É Mandatório

necessário.

que

os

diretórios

tenham

as

permissões

de

esc rita

quando

estritamente

É

Mandatório

que seja m separados fisicamente os arquivos de código

fonte de acordo com sua

camada no modelo MVC. Ou seja, os arquivos de

Views devem ser separados dos arquivos de Mod elos e de Controles.

4.a.ii Nomenclaturas

Mandatório

É que os no mes sejam descritivos, porém não excessivamen te grandes.

Mandatório

É caso utiliz e o Framework PHP PEAR a utilização das conve nções especificadas no site

do projeto 17 .

É Mandatório site do projeto 18 . É Mandatório É Mandatório É Mandatório
É
Mandatório
site do projeto 18 .
É Mandatório
É Mandatório
É Mandatório

caso utili ze o Framework CodeIgniter a utilização das co nvenções especificados no

que os no mes de arquivos contenham somente caracteres ASCII.

que códig os Javascript sigam as convenções especificadas para projetos JQuery 19 .

que const antes sejam sempre grafadas completamente em

maiúsculo.

16 http://www.php-fig.org/

17 http://framework.zend.com/man ual/1.12/en/coding-standard.html

18 https://ellislab.com/codeigniter/ user-guide/general/styleguide.html

19 https://contribute.jquery.org/styl e-guide/js/

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

que vet ores tenham seus nomes obedientes às regr as anteriormente citadas. Adiciona-se a possibilidade

que vet ores tenham seus nomes obedientes às regr as anteriormente citadas.

Adiciona-se a possibilidade dest e tipo poder utilizar nomes curtos, de até um c aracter para indicar índices dentro de estruturas de repetiçã o.

É

Mandatório

4.b Indentação e blocos

Mandatório

É que os có digos estejam indentados. É caso utiliz e o Framework PHP PEAR a utilização das conve nções especificadas no site

Mandatório

do projeto 20 .

É

site do projeto 21 .

É

Mandatório

Mandatório

caso utili ze o Framework CodeIgniter a utilização das co nvenções especificados no

que códig os Javascript sigam as convenções especificadas para projetos JQuery 22 .

4.c Tratamento de Exceç ões

finais.

Mandatório

É que os có digos gerenciem as exceções gerando mensag ens amigáveis aos usuários

Mandatório

É que os có digos gravem registros de auditoria das exceções geradas.

Mandatório

É que as exc eções não exibam informações internas do siste ma aos usuários, como por

exemplo: “Erro ao executar a q uery: ‘SELECT * ….’”; “Erro ao conectar ao SGB D com host=xxx.xxx.xxx.xxx db=aaaaa”.

que e xceções de segurança e de permissões de ac esso sejam sinalizadas aos

administradores do sistema, seja

É Recomendado

por email, seja por registros de auditorias espe cíficos e diferenciados.

4.d Constantes É Mandatório que a nom enclatura de constantes sejam aderentes ao ite m
4.d Constantes
É Mandatório
que a nom enclatura de constantes sejam aderentes ao ite m 4.a.ii.
É Mandatório
que as d efinições de constantes estejam especificadas
em um único arquivo para
cada linguagem.
4.e Views
É
Mandatório
que as
estejam aderentes às regras do
Views e códigos finais (respostas) recebidos p elos navegadores clientes
W3C 23 .

É

Exemplo: <meta charset ="utf-8" />

É

Mandatório

que as Vie ws estejam codificadas com caracteres UTF-8:

Recomendado

que a s Views possuam códigos de adaptação de c onteúdo automático

para

dispositivos em geral (Responsiv as), por exemplo e não restrito a:

Desktops: Resolução

Tablets: Resolução 1 024x768;

1920x1080;

20 http://framework.zend.com/man ual/1.12/en/coding-standard.html

21 https://ellislab.com/codeigniter/ user-guide/general/styleguide.html

22 https://contribute.jquery.org/styl e-guide/js/

23 http://www.w3c.br/Padroes/We bDesignAplicacoes

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

• Smartphones: Resol ução 640x480. Recomendado É a utiliza ção do Framework Bootstrap 2 4

Smartphones: Resol ução 640x480.

Recomendado

É a utiliza ção do Framework Bootstrap 24 versão 3.3.5 ou superior para a criação das

Views.

Recomendado

É que sej a possível um usuário selecionar uma resoluçã o/adaptação específica. Por

exemplo, o usuário está acess ando de um Smartphone, porém quer visuali zar o site completo como apresentado para Desktop.

que seja imp lementada a funcionalidade de temas, na qual a s interfaces são adequadas

de acordo com temas escolhidos

É

Opcional
Opcional

pelos usuários dentre os apresentados.

4.e.i Includes

que códig os comuns entre Views sejam incluídos no códi go através de “includes” de

arquivos comuns entre elas. Na Figura 6 está exempl ificado esta aplicação. No caso, duas telas visíve is ao cliente são montadas adicionando-se um arquivo com um “cabeçalho” a outros com conteúdos especí ficos diferentes gerando as visões finais.

que os arq uivos que são incluídos estejam dentro de um d iretório específico de nome

“includes” dentro do diretório d as Views.

É

Mandatório

É

Mandatório

FIGURA 6: EXEMPLO DE INCLUDE

Mandatório É Mandatório F IGURA 6: E XEMPLO DE I NCLUDE 2 4 http://getbootstrap.com/ F ONTE

24 http://getbootstrap.com/

FONTE: DO AUTOR

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

4.e.ii Identidade Visual

4.e.ii Identidade Visual C estejam aderentes aos Manuais de Identidade Corporat iva do ICMC 2 5

C estejam aderentes aos

Manuais de Identidade Corporat iva do ICMC 25 e da USP 26 .

utilizado o Bootstrap do ICMC disponibilizad o, mantido e gerido pela

STI/ICMC

Identidade

contemple a Identidade Corporativa da US P e um que contemple a

Identidade Visual dos Sistema s USP (uspdigital) a fim de ser selecionado/t rocado de acordo com as necessidades/parametrização d o ambiente.

Corporativa do ICMC, um que

É

Mandatório

que os

softwares desenvolvido no âmbito da STI/ICM

É Mandatório que seja

27 .

É

Recomendado

que

o

sistema

tenha

a

disposição

um

tema

que

contemple

a

4.f.i Biblioteca ICMCUtil

A STI/ICMC disponibiliza , mantém e gerencia uma biblioteca de funções

É

comuns.

Mandatório

que sejam utilizadas as funções disponíveis na biblioteca I CMCUtil 28 .

Assim, é importante a v isualização da documentação da biblioteca ante s de implementar códigos, pois muitas das necessidades m andatórias estão atendidas lá. Por exemplo, fun ções de auditoria, captchas, validações, etc.

4.g Cookies e Sessions

É Mandatório

que some nte sejam armazenados em Cookies dados não s ensíveis, ou seja, dados que

não permitam identificar regras de negócios, usuários ou identificadores interno s da aplicação.

É

Mandatório

das aplicações.

É

Mandatório

que seja

armazenado em Sessions somente informações

cruciais ao funcionamento

que seja e fetuada a validação de dados contidos em Cook ies e Sessions antes de toda

utilização no contexto da aplicaç ão.

É

É

Mandatório Recomendado
Mandatório
Recomendado

que ao uti lizar a função sair da aplicação todos os dados d a Session sejam excluídos.

que sej a evitado o uso de Cookies.

4.h Mecanismos de Aute nticação

É

que as apl icações possuam a funcionalidade de autenticaç ão de usuários.

É

Mandatório Opcional Opcional
Mandatório
Opcional
Opcional

que a autenti cação utilizando-se Certificados Digitais do clien te.

que a autenti cação utilizando-se serviços de Autenticação de Terceiros, como:

É

OpenID 29

Google Sign-In 30

Facebook Login 31

25 http://www.icmc.usp.br/Portal/c

26 http://www.scs.usp.br/identidad evisual/

27 http://devel.icmc.usp.br/projects

28 http://devel.icmc.usp.br/projects

29 https://developers.google.com/id entity/protocols/OpenIDConnect

30 https://developers.google.com/id entity/

31 https://developers.facebook.com /docs/facebook-login/web

onteudo/1272/388/logomarcas

/bootstrap-sti-icmc/

/icmcutil/

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

Twitter OAuth 32

• Twitter OAuth 3 2 4.h.i OAuth USP USP 3 3 . Mandatório É que as

4.h.i OAuth USP

USP 33 .

Mandatório

É que as ap licações implementem a funcionalidade de Aut enticação Unificada OAuth

Mandatório

É que a a plicação possa comutar entre os ambientes

de desenvolvimento e de

produção do OAuth USP apenas utilizando de ajustes em arquivos de configuraç ão da aplicação.

4.h.ii Autenticação local

É Mandatório

que as ap licações implementem a funcionalidade de aut enticação local de usuários,

possuam a Senha Unificada

utilizando-se uma base de usuá rios própria, permitindo que usuários que não

USP também possam usufruir do

sistema.

É

Mandatório

que o apli cativo forneça a possibilidade de cadastro de usu ários para utilização.

4.h.iii LDAP

É Recomendado que as

aplicações implementem a funcionalidade de

consultando uma base de dados LDAP.

autenticação de usuários

4.h.iv Radius

É

Recomendado

que as

consultando um servidor Radius .

aplicações implementem a funcionalidade de

autenticação de usuários

4.i Otimizações

A seguir estão especifica das algumas regras básicas de otimização.

4.i.i Strings

das algumas regras básicas de otimização. 4.i.i Strings É Mandatório que se util ize strings delimitadas

É Mandatório

que se util ize strings delimitadas por ‘ (apóstrofo) nos caso s:

Posição de vetor. Ex emplo: echo pessoa[‘nome’];

String pura e simple s. Exemplo: echo ‘Esta é uma mensagem de alert a ao usuário’;

echo ‘Esta é uma mensagem de alert a ao usuário’; É Mandatório que seja d elimitado

É Mandatório

que seja d elimitado variáveis dentro de Strings com chave s.

Exemplo: echo “Este é o valor {$variavel}”;

É

Recomendado

que se

evite o uso de String de múltiplas linhas (Heredo c 34 e Nowdoc 35 ).

32 https://dev.twitter.com/oauth/o verview

33 https://uspdigital.usp.br/adminw s/webServiceCatalogo.jsp?codmnu=3777

34 http://php.net/manual/pt_BR/la nguage.types.string.php#language.types.string.syntax .heredoc

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

4.i.ii Concatenação de String s É Mandatório que as apl icações que necessitem concatenar strings

4.i.ii Concatenação de String s

4.i.ii Concatenação de String s É Mandatório que as apl icações que necessitem concatenar strings a

É Mandatório

que as apl icações que necessitem concatenar strings a util izem conforme:

Utilizar o “,” ao invé s de “.” no comando echo. Exemplo: echo 'impri mindo algo ', $valor;

Evitar concatenar St rings com “ e ‘.Exemplo: echo “Esta é uma parte ” ,’Esta é outra’;

4.i.iii Otimização em laços de

repetições

É

Mandatório

que na i teração sobre itens de uma lista que ela seja

objeto/item/variável declarada f ora do escopo do looping. Exemplo:

$itens = array(‘1 ’,’2’,’3’); $item = ‘’; for ($i=0;$i<cou nt($itens);$i++){

$item =

echo “Va lor ”, $item;

$itens[$i];

}

É Mandatório

Exemplo:

que, se co uber, se faça utilização do laço “Foreach”.

$itens = array(‘1 ’,’2’,’3’); foreach($itens A S $item){ echo “Va lor ”, $item;

}

realizada reutilizando um

4.i.iv Validação de Strings e e ntradas

no escopo deste manual o processamento da e ntrada a fim de que o valor

recebido esteja dentro dos padr ões esperados. Isto inclui remover info rmações, caracteres, instruções, endereços (url ) e afins que possam vir a

gerar um comportamento inesp erado da aplicação.

que seja r ealizada a validação de toda String que será ent rada para alguma operação

da aplicação.

Considera-se validação

É Mandatório

Recomendado

É que sej a utilizada de expressões regulares para a validaç ão.

Recomendado

É que sej a utilizada as funções PHP strip_tags 36 , htmlen tities 37 e htmlspecialchars 38

para validação/conversão de ent radas.

35 http://php.net/manual/pt_BR/la nguage.types.string.php#language.types.string.syntax .nowdoc

36 http://php.net/manual/pt_BR/fu nction.strip-tags.php

37 http://php.net/manual/pt_BR/fu nction.htmlentities.php

38 http://php.net/manual/pt_BR/fu nction.htmlspecialchars.php

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

4.j Padrão de interopera bilidade de dados Todas as aplicações dese nvolvidas no âmbito deste

4.j Padrão de interopera bilidade de dados

Todas as aplicações dese nvolvidas no âmbito deste manual devem preve r a importação, requisição,

com as necessidades dos

usuários/aplicações/parceiros.

dados/entidades a serem

compartilhadas incluam dados s ensíveis dos usuários da USP. Neste caso, todos os ofícios, circulares e afins devem ser anexados ao projeto na pasta “docs”. Assim, antes de compart ilhar qualquer dado, consultar a aplicabilidade d a restrição.

processamento, exportação de

É

Mandatório

que seja

dados nos formatos especificados de acordo

obedecida as hierarquias burocráticas caso os

4.j.i eXtensible Markup Langu age (XML)

É Mandatório

que caso s eja necessária a interoperabilidade de dados atr avés do uso de XML que os

dados compartilhados e os arqui vos finais estejam de acordo com os padrões do W3C para XML 39 .

É

Mandatório

que seja

realizada a definição das entidades que se des ejam trocar. Esta definição

deve ser previamente definida e registrada em documentação avulsa ao projeto na pasta “docs”.

É

Mandatório

dentro do projeto.

que seja r ealizado a inclusão de arquivos de exemplos q ue sigam o padrão definido

4.j.ii JavaScript Object Notati on (JSON)

É

Mandatório

caso seja

necessária à interoperabilidade de dados atrav és do uso de JSON que os

dados compartilhados e os arqui vos finais estejam de acordo com os padrões do ECMA-404 para JSON 40 .

É

Mandatório

que seja

realizada a definição dos pares e valores qu e se desejam trocar. Esta

definição deve ser previamente definida e registrada em documentação avulsa a o projeto na pasta “docs”.

É

Mandatório

que seja

dentro do projeto.

realizada a inclusão de arquivos de exemplos q ue sigam o padrão definido

4.j.iii RDF Site Summary (RSS )

É

Mandatório

caso seja

necessária à interoperabilidade de dados atra vés do uso de RSS que os

da especificação RDF Site

dados compartilhados e os arq uivos finais estejam de acordo com os padrões Summary (RSS) 1.0 41 .

É

Mandatório

que seja

realizada a inclusão de arquivos de exemplos q ue sigam o padrão definido

dentro do projeto.

4.j.iv Arquivos textos separa dos por vírgula (CSV)

É

Mandatório

que caso

seja necessária à interoperabilidade de dados

textos separados por vírgula (CS V) que os arquivos tenham codificação em UTF-8

através do uso de Arquivos sem BOM.

39 http://www.w3.org/TR/2008/REC -xml-20081126/

40 http://www.json.org/json-pt.htm l

41 http://web.resource.org/rss/1.0/ spec

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

É Mandatório que a pri meira linha do arquivo seja um cabeçalho que defina as

É

Mandatório

que a pri meira linha do arquivo seja um cabeçalho que

defina as informações das

colunas exportadas. Exemplo: Exportação de emails. Primeira linha d o arquivo: Nomes,emails Demais linhas: f ulano,fulano@icmc.usp.br

É Mandatório que seja

realizada a definição dos conteúdos que se des ejam trocar. Esta definição

deve ser previamente definida e registrada em documentação avulsa ao projeto na pasta “docs”.

É

Mandatório

que seja

dentro do projeto.

É

Mandatório

que caso

realizada a inclusão de arquivos de exemplos q ue sigam o padrão definido

a coluna a ser exportada contenha espaços entr e os dados, que esta coluna

esteja entre aspas “ “. Exemplo: Exportação de nomes completos e emails. Primeira linha d o arquivo: ”Nome completo”,emails Demais linhas: “ fulano silva”,fulano@icmc.usp.br

É Recomendado que os dados sejam separados por vírgulas. É Recomendado caso al guma coluna
É Recomendado
que os
dados sejam separados por vírgulas.
É Recomendado
caso al guma coluna possua em seu conteúdo valores

como delimitador de campo a b arra “|” (pipe). Exemplo: Exportação de saldos. Primeira linha d o arquivo: Nomes|Saldo Demais linhas: J oaquim|245,5

contendo vírgulas, utilizar

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

5. Segurança

5. Segurança Nesta seção do manual segurança. Não se busca abordar estão abordados pontos importantes para

Nesta seção do manual segurança.

Não se busca abordar

estão abordados pontos importantes para d esenvolvimento no quesito

completamente o assunto, mas citar alguns

dos pontos principais que

requerem atenção. Convém lembrar que to do acesso aos aplicativos desenvolvidos devem conexões HTTPS com Certificado s Digitais Válidos.

ser realizados através de

5.a Nunca confiar nos us uários

considere que o usuário irá forçar um comp ortamento inesperado da

aplicação. Ou seja, trocando/força ndo parâmetros GET, desabilitando interpretaç ão Javascript, manipulando seções, injetando códigos nas en tradas (SQL Injection), forjando POST, submeten do arquivos maliciosos etc. Assim, reforça-se a impo rtância do item 4.i.iv.

É

Mandatório

que se

5.a.i Validação no cliente

É

Mandatório

que se r ealize validações no lado do cliente, utilizando

códigos JQuery/Javascript

antes da submissão de dados. Por exemplo, caso o cam po solicite um número inteiro, evitar que seja s ubmetido uma String etc.

É Recomendado

que

caso

seja

requisição/operação e alerte o u suário.

detectado

inconsistências,

int errompa-se

o

envio

da

5.a.i Validação no servidor

É

Mandatório

conforme item 4.i.iv.

que se re alize validações no lado do servidor, antes do

processamento específico,

É

Mandatório

realizada a validação do tipo de arquivo espe rado no upload através da arquivo.

que não s eja acreditada na extensão do arquivo como def inição do Tipo. Ou seja, um

que seja

consulta ao Tipo de conteúdo do

É

Mandatório

usuário poderá enviar um arquiv o com extensão “.txt”, quando na verdade é um binário etc.

que não

desativar ou burlar este tipo de

É

Mandatório

seja acreditada na validação realizada no lado

validação. caso seja detectado inconsistências, int errompa-se o envio da

do cliente, pois este pode

É Recomendado

que

requisição/operação e alerte o u suário.

5.b Validação no SGBD

É

Mandatório

que toda

entrada antes de ser utilizada no SGBD passe

pelas validações dos itens

anteriores, em especial ao item

que sejam

utilização de Strings no Banco de

É

Mandatório

4.i.iv.

utilizadas funções de adição de “escape” de a spas e apóstrofos antes da

Dados.

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

É Mandatório que seja r ealizada a validação de todos os parâmetros GET , POST,

É

Mandatório

que seja r ealizada a validação de todos os parâmetros GET , POST, SESSION e COOKIES

antes da utilização no Banco de Dados.

É Mandatório que sejam

utilizadas relações de integridades relacionais

nas tabelas com relacionamento .

(Chaves Extrangeiras, pex)

5.c Role-based access co ntrol (RBAC)

É

Mandatório

que

as

aplicações

desenvolvidas

no

âmbito

dest e

manual

implemente

a

funcionalidade de controle de ac esso baseado em usuários/grupos (Role-based a ccess control - RBAC).

em usuários/grupos ( Role-based a ccess control - RBAC). É Mandatório a distinção de três tipos

É Mandatório a distinção

de três tipos de usuários/grupos:

Público: aqueles que

Usuário registrado: a quele que participou de um processo de autent icação bem sucedido;

Administrador: aqu ele que além de ser usuário registrado está maiores.

não efetuaram login;

sinalizado com privilégios

maiores. não efetuaram login; sinalizado com privilégios É Mandatório que seja possível adicionar ou remover

É Mandatório que seja

possível adicionar ou remover usuários de

determinados grupos sem

mudança de código.

É

Mandatório

que as fun cionalidades possam diferenciar, autorizar, nega r, tratar os diferentes tipos

de usuários/grupos.

É Mandatório

que um u suário novo, após cadastro no sistema, fique b loqueado suas funções até

que seja liberado/autorizado po r um outro usuário.

É Mandatório

que

o

sistema

não

permita

acesso

a

recursos

internos

para

usuários

bloqueados/inativos/não ativad os etc.

É

usuários/grupos:

Recomendado

que s eja implementado e diferenciação do tamb ém os seguintes tipos de

Aluno de Graduação ;

Aluno de Pós Gradu ação;

Funcionário;

Visitante;

Secretária;

Docente/Professor.

• Visitante; • Secretária; • Docente/Professor. É Recomendado É Recomendado É Recomendado que sej a

É Recomendado

É Recomendado

É Recomendado

que sej a possível adicionar ou remover grupos outros se m mudança de código.

que sej a possível um usuário participar de mais de um g rupo.

que se ja possível adicionar/remover/atribuir/permiti r acesso a um grupo uma

funcionalidade do sistema sem n ecessitar mudança de código.

5.d Captcha

Captcha são mecanism os de validação que visam diferenciar entre

computadores e humanos,

evitando que softwares automat izados realizem tarefas que deveriam ser realiza das por usuários comuns.

É

Mandatório

que

as

aplicações

desenvolvidas

no

âmbito

dest e

funcionalidade de Captcha para ações, como:

Páginas de autentica ção

Formulários de cont ato

Formulários de cada stro

manual

implemente

a

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

• Formulários que usu ários não autenticados possam inserir registros, como comentários, etc. É Mandatório

Formulários que usu ários não autenticados possam inserir registros, como comentários, etc.

possam inserir registros, como comentários, etc. É Mandatório que toda deve ser gerado um registro de

É Mandatório que toda

deve ser gerado um registro de

negação de acesso a determinado registro por auditoria.

É

Recomendado

a utiliza ção do serviço de Captcha reCAPTCHA 42 .

causa de erro de Captcha

5.e Atualizações

É

Mandatório

que as a plicações desenvolvidas no âmbito deste man ual implemente sempre as

últimas versões estáveis dos cód igos/Frameworks/Bibliotecas.

É

Mandatório

que o de senvolvedor atualize os códigos a fim de adeq uá-los às novas versões de

códigos/Frameworks/Bibliotecas , bem como mantê-las atualizadas no repositóri o/projeto da aplicação.

É

Mandatório

que

códigos/Frameworks/Bibliotecas

seja efetuada a aplicação

utilizados tão logo elas sejam disponibilizadas.

de

correçõ es

de

segurança

nos

5.f Permissões de acesso

a arquivos

É

Mandatório

que o d esenvolvedor documente quais devem ser as

permissões de acesso aos

arquivos do projeto desenvolvid o.

É

Mandatório

que os ar quivos somente tenham as permissões de acess o estritamente necessárias

para seu funcionamento.

É

Mandatório

que arqu ivos que contenham informações sensíveis ao

negócio (Configurações de de clientes.

que sej a efetuada a proteção de diretórios contr a listagem de conteúdo,

conexões de Banco de Dados, pe x.) não tenham acesso a partir de navegadores

É

Mandatório

independente da configuração d o servidor de aplicação. Exemplo: Adição de res trição via .htaccess ou adição de um arquivo

vaziu.

index.html com conteúdo

5.g Tratamento de págin as de Erro

É

Mandatório

que seja

efetuado o tratamento de erros, redirecionando

gerando registros de auditoria p ara os seguintes códigos:

401: Não autorizado

403: Proibido

404: Página não loca lizada

para páginas específicas e

5.h Criptografia de camp os

É

Mandatório

que seja

efetuada a criptografia de campos utilizand o-se funções/métodos que

utilizem saltos (Salt).

É

A função crypt 43 do php é um exemplo de função que permite este tipo d e abordagem.

Mandatório

que o Salt seja definido como uma constante de pelo men os 32 caracteres.

42 https://www.google.com/recaptc ha/

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

5.i Políticas de senhas

5.i Políticas de senhas É Mandatório que a apli cação, na funcionalidade de login local (Item

É

Mandatório

que a apli cação, na funcionalidade de login local (Item 4.h .ii), desenvolvida no âmbito

deste manual contemple a políti ca de senha instituída pela Portaria USP GR/366 2 de 2006 44 .

5.j Cópias de Seguranças

É

Mandatório

que

a

documentação

contemple

os

processos,

pro cedimentos,

comandos

e

necessidades para a realização e recuperação das cópias de segurança do sistem a (Backup).

É Mandatório

automáticos.

que seja d isponibilizado scripts para a realização de tarefa s de backup e restaurações

5.k Parâmetros GET

É

Mandatório

“_”, “=” e “?”.

que os p arâmetros GET sejam somente representado p or caracteres Base64, “&”,

43 http://php.net/manual/pt_BR/fu nction.crypt.php

44 http://www.leginf.usp.br/?portar ia=portaria-gr-no-3662-de-12-janeiro-de-2006

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

6. Registros de Auditor ia É Mandatório que as aplicações desenvolvidas no âmbito dest e

6. Registros de Auditor ia

É

Mandatório

que

as

aplicações

desenvolvidas

no

âmbito

dest e

manual

implemente

a

funcionalidade de registros de a uditoria independente do sistema de registro do servidor de aplicação.

É

Mandatório

sem BOM.

É

Mandatório

que os re gistros de auditoria sejam armazenados em arq uivos com codificação UTF8

que os r egistros de auditoria contenham os dados, rep resentando o instante que

ocorreram, um registro único po r linha, separado os campos por barras “|” (Pipe ):

Data/hora no forma to: dd/mm/AAAA hh:mm:ss T, sendo:

o

dd: dia com 2 caracteres

o

mm: mês co m 2 caracteres

o

AAAA: ano c om 4 caracteres

o

hh: hora, co m 2 caracteres e representando de 00 à 24

o

mm: minuto s, com 2 caracteres

o

ss: segundos , com 2 caracteres

o

T: timezone

IP: Endereço de orig em da requisição, aceitos IPv4 ou IPv6

Nível do registro:

o

ALERTA: qua ndo necessita de correção imediata

o

CRÍTICO: qu ando necessita de análise e correção

o

ERRO: quan do gerou um erro ao usuário/sistema

o

INFORMAÇÃ O: quando necessita registrar mensagens gerais

o

DEPURAÇÃO : quando necessita registrar informação de de puração para correção ou análise post erior

Mensagem: mensag em de texto curta que explica o motivo do regist ro

Exemplos:

28/10/2015 10:53:1 2 GMT-2|143.107.231.12|INFORMAÇÃO|Usuá rio 9999999 acessou com senha unificada

27/10/2015 12:53:1 2 GMT-2|143.107.231.12|INFORMAÇÃO|Usuár io 9999999 efetuou logout do sistema

01/10/2015 00:03: 01 GMT-3|143.107.231.33|ERRO|Usuário 99 99999 tentou acessar o

sistema, mas gerou

erro de usuário ou senha inválido

o sistema, mas gerou erro de usuário ou senha inválido É Mandatório É Mandatório que não

É Mandatório

É Mandatório

que não s eja possível remover registros de auditorias atra vés da aplicação.

que as seg uintes operações sejam registradas:

Login/logout: quem, por qual mecanismo etc;

Cadastro: quem, por qual mecanismo etc;

Remoções/Desativa ções/Ativações: quem, por qual mecanismo etc;

Erros de validação:

Tentativas de muda nças de parâmetros: quem gerou, qual área, form

Tentativas de acess os a recursos cujo usuário/grupo não tenha pe rmissão: quem gerou, qual área, formulário, op eração etc;

Atribuições de perm issões: quem, qual área, formulário, operação et c.

quem gerou, qual área, formulário, operação etc ;

ulário, operação etc;

formulário, operação etc ; ulário, operação etc; É Recomendado disponível. que se ja utilizado o serviço

É Recomendado

disponível.

que se ja utilizado o serviço de registros de auditoria

do sistema Syslog quando

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

aplicação cuide para que os arquivos de reg istros de auditorias sejam frequência máxima de

aplicação cuide para que os arquivos de reg istros de auditorias sejam frequência máxima de uma semana e mantid as com vista a atender ao

Marco Civil da Internet - Lei 12 965/2014 45 , ou seja, armazenados por pelo me nos 6 meses, podendo ser ampliado.

organizados e rotacionados com

É

Recomendado

que a

É

Recomendado

que sej a possível ler os registros de auditoria através

da aplicação após processo

de autenticação/autorização.

É

Recomendado

que sej a realizado a compactação dos registros de audit oria no formato Bzip2 a fim

de manutenção de espaço em di sco no servidor, em registros superiores a 15 dia s.

É

Recomendado

que os

registros de auditoria também sejam registra dos em SGBD. Neste caso

deve-se somente permitir as açõ es de INSERT e SELECT na base para a conexão q ue irá realizar o registro.

É

Mandatório

que os reg istros sejam efetuados somente em SGBD caso

o desempenho da aplicação

esteja sendo degradado pela uti lização do Syslog ou outra forma de registro.

pela uti lização do Syslog ou outra forma de registro. É Recomendado que as operações a

É Recomendado que as

operações a seguir sejam registradas:

Parâmetros GET/PO ST recebidos

Retornos do SGBD

Informações do Nav egador/Cliente/Dispositivo

Informações de Inte roperabilidade

45 http://www.planalto.gov.br/ccivi l_03/_ato2011-2014/2014/lei/l12965.htm

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

7. Internacionalização É Mandatório que as aplicações desenvolvidas no âmbito dest e manual implemente a

7. Internacionalização

É

Mandatório

que

as

aplicações

desenvolvidas

no

âmbito

dest e

manual

implemente

a

funcionalidade Internacionalizaç ão das interfaces.

É

Mandatório

que caso a

Internacionalização não seja necessária em det erminado contexto, deverá

ser justificada a não utilização at ravés de documentação comprobatória anexa a o projeto respectivo.
ser justificada a não utilização at ravés de documentação comprobatória anexa a o projeto respectivo.
É Mandatório
que as int erfaces (Views) possam ser traduzidas/acessadas
nas línguas:
• Português;
• Espanhol;
• Inglês.
É Mandatório
que, caso não seja especificado, a língua de exibição seja o
É Mandatório
que seja p ossível inserir/editar traduções sem mudança de
É Mandatório
que o usu ário possa escolher entre uma das línguas e sua
Português.
código.
navegação a partir daquele

ponto seja com a língua escolhid a.

É Mandatório

que

a s

mensagens

de

erro,

botões

e

compo nentes

também

suporte

Internacionalização.

É

Recomendado

que se ja implementado a funcionalidade de permitir

a adição de outras línguas

sem mudança de código.

É

Recomendado

que a

Navegador/IP etc. Neste caso, caso ache necessário.

que

Internacionalização.

É

Recomendado

aplicação detecte a língua automaticamente ba seado nas informações do é importante existir mecanismos para que o us uário possa trocar a língua

os

plugins

e

bibliotecas

de

terceiros

utiliz adas

possuam

suporte

a

É

Opcional
Opcional

que a aplicaç ão possua mecanismos de tradução automática.

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

8. Acessibilidade

8. Acessibilidade Considera-se funcionali dades de acessibilidade à possibilidade de a umentar o contraste das

Considera-se funcionali dades de acessibilidade à possibilidade de a umentar o contraste das interfaces, botões e component es; aumentar o tamanho das letras etc.

que as ap licações desenvolvidas no âmbito deste manua l suporte a funcionalidades

de acessibilidade.

de

tradução/fala/explicação.

É

É

Mandatório

Recomendado

que

aplicações

que

utilizem

Captcha

tenh a

a

funcionalidade

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

9. Email

9. Email que as ap licações desenvolvidas no âmbito deste manua l suporte o envio de

que as ap licações desenvolvidas no âmbito deste manua l suporte o envio de emails

autenticados.

as mensagens de emails enviadas pelo sistem a seja através de um SMTP

com autenticação.

que as me nsagens enviadas tenham sempre um destinatá rio especificado, um título,

uma mensagem no corpo e um r emetente válido.

que a apli cação possa enviar mensagens automáticas de a cordo com os requisitos do

projeto. Por exemplo: enviar em ails aos responsáveis pelas tarefas abertas toda s as 0h do dia, informando o número e o resumo da taref a, com o título “[INTRANET] Resumo de taref as de 28/10/2015”, e cujo remetente é: sistema@icmc.usp .br.

É

Mandatório

É Mandatório que todas

É

É

Mandatório

Mandatório

É Mandatório que todas É É Mandatório Mandatório É Mandatório É Mandatório É Mandatório É Mandatório

É Mandatório

É Mandatório

É Mandatório

É Mandatório

É Mandatório

que o ema il do remetente não seja um email pessoal do d esenvolvedor.

que o ema il do remetente possa ser configurado sem mod ificação do código.

que todo

que todo

email enviado pela aplicação tenha registro de a uditoria associado.

email enviado pela aplicação possua caracteres U TF-8.

que email s enviados como ferramenta de contato pela a plicação tenham validações

(item 4.i.iv) e Captcha.

É

Recomendado

que to do email tenha em seu título uma TAG entre

colchetes que identifique

univocamente e facilmente o sis tema que gerou o email, por exemplo:

anexo.

[INSCPOS]

[INTRANET]

• [SISTEMAX] É Recomendado É Recomendado
• [SISTEMAX]
É Recomendado
É Recomendado

que est a TAG possa ser modificada sem mudança de có digo.

que to da mensagem a ser comunicada esteja no corp o da mensagem e não em

Seção Técnica de Informática Instituto de Ciênci as Matemáticas e de Computação | Universidade de São Paulo | Av. Trabalhador São-carlen se, 400 ∙ Centro ∙ São Carlos/SP ∙ CEP 13566-590 ∙ Bra sil ∙ www.icmc.usp.br

10. Documentação de Códigos que as a plicações desenvolvidas no âmbito deste ma nual tenham

10. Documentação de

Códigos

que as a plicações desenvolvidas no âmbito deste ma nual tenham seus códigos

documentados.

Considera-se documenta ção de código a adição de tags, comentários e a fins nos códigos fontes que identifiquem adequadamente a funcionalidade prevista em determinado trecho de código.

É

Mandatório

É Mandatório É Mandatório não como ela faz. É Mandatório
É Mandatório
É Mandatório
não como ela faz.
É
Mandatório

que a doc umentação de código PHP esteja no formato do phpDocumentor 46 .

que os co mentários indiquem o que a Classe, Método,

Função, Operação etc faz e

que o co mentário seja um pequeno manual de uso c orreto da Classe, Método,

Função, Operação.

É

Recomendado

que os

arquivos gerados pelo phpDocumentor sejam

armazenados no diretório

“phpdocs” dentro do diretório “ docs” do repositório.

É

Recomendado

que se documente sucintamente partes cruciais do cód igo, que possam auxiliar na

interpretação/analise do mesmo .

10.a Documentação das Classes

É

Mandatório

/**

que as cla sses contenham como documentação no mínimo

*

<p>

*