Categoria:Lições Aprendidas

De DTI Wiki

Edição de 14h18min de 11 de agosto de 2009 (ver código-fonte) Ffurst (disc | contribs) (Página substituída por 'Lições boas e ruins aprendidas durante os projetos.') ← Edição anterior		Edição de 17h23min de 25 de novembro de 2009 (ver código-fonte) Bataglin (disc | contribs) (Balcão do consumidor) Edição posterior →
Linha 1:		Linha 1:
-	Lições boas e ruins aprendidas durante os projetos.	+	Lições do projeto do BALCÃO DO CONSUMIDOR
		+
		+	1) Treinamento ministrado pela equipe de suporte não é satisfatório pois até então não há o envolvimento necessário para compreensão de todo o projeto e também por não disporem de tempo para testes nos novos sistemas.
		+
		+	2) Não realizar as lições aprendidas antes do término de todas as etapas do processo de desenvolvimento;
		+
		+	3) Melhorar/aprimorar as técnicas de levantamento de requisitos para buscar informações mais completas dos usuários, pois houve a descoberta de novos requisitos na fase de validação do sistema. Obs.: os requisitos sempre irão mudar no decorrer de projetos longos, mas o aparecimento de novos não deveria ocorrer. Melhorar a comunicação com o usuário.
		+
		+	4) Durante o treinamento dos usuários procurar deixar o instrutor explicar todo o projeto para somente ao final abrir espaço para dúvidas e questionamentos, voltando aos pontos a serem discutidos. Desta forma a sequência planejada para o curso não é 'quebrada'.
		+
		+	5) Respeitar as etapas de desenvolvimento.  Por exemplo: não treinar os usuários enquanto há fase de testes pendente, a menos que haja modularização.
		+
		+	6) Usuários não podem testar o sistema em ambiente de produção.
		+
		+	7) Falta de padronização em telas/relatórios da intranet dificultaram o desenvolvimento, pois desenvolvedores diversos criam telas muito diferentes quando não  há um padrão.
		+
		+	8) Melhorar as validações básicas dos sistemas. Os erros a serem apontados pelo desenvolvedor não deveriam estar englobados erros de oracle para o usuário, inconsistÊncias de campos, etc...
		+
		+	9) Sincronização das etapas: testador não pode receber atribuições de testes sendo que não foram compilados todos os objetos necessários na TEST.
		+
		+	10) Auditoria: revisar a auditoria dos sistemas sempre que houver alteração em tabelas da base de dados.
		+
		+	11) Antes do analista de sistemas criar a base de dados deverá dar conversar com o DBA para validar o que está sendo criado, pois pode surgir sugestões de aproveitamento de tabelas já existentes, etc.
		+
		+	6) Usuários não podem testar o sistema em ambiente de produção.

---

Edição de 17h23min de 25 de novembro de 2009

Lições do projeto do BALCÃO DO CONSUMIDOR

 1) Treinamento ministrado pela equipe de suporte não é satisfatório pois até então não há o envolvimento necessário para compreensão de todo o projeto e também por não disporem de tempo para testes nos novos sistemas. 

 2) Não realizar as lições aprendidas antes do término de todas as etapas do processo de desenvolvimento; 

 3) Melhorar/aprimorar as técnicas de levantamento de requisitos para buscar informações mais completas dos usuários, pois houve a descoberta de novos requisitos na fase de validação do sistema. Obs.: os requisitos sempre irão mudar no decorrer de projetos longos, mas o aparecimento de novos não deveria ocorrer. Melhorar a comunicação com o usuário.

 4) Durante o treinamento dos usuários procurar deixar o instrutor explicar todo o projeto para somente ao final abrir espaço para dúvidas e questionamentos, voltando aos pontos a serem discutidos. Desta forma a sequência planejada para o curso não é 'quebrada'.

 5) Respeitar as etapas de desenvolvimento.  Por exemplo: não treinar os usuários enquanto há fase de testes pendente, a menos que haja modularização.

 6) Usuários não podem testar o sistema em ambiente de produção. 

 7) Falta de padronização em telas/relatórios da intranet dificultaram o desenvolvimento, pois desenvolvedores diversos criam telas muito diferentes quando não  há um padrão.

 8) Melhorar as validações básicas dos sistemas. Os erros a serem apontados pelo desenvolvedor não deveriam estar englobados erros de oracle para o usuário, inconsistÊncias de campos, etc...

 9) Sincronização das etapas: testador não pode receber atribuições de testes sendo que não foram compilados todos os objetos necessários na TEST.

 10) Auditoria: revisar a auditoria dos sistemas sempre que houver alteração em tabelas da base de dados.

 11) Antes do analista de sistemas criar a base de dados deverá dar conversar com o DBA para validar o que está sendo criado, pois pode surgir sugestões de aproveitamento de tabelas já existentes, etc. 

 6) Usuários não podem testar o sistema em ambiente de produção.