Requisitos de software
06/11/2013
0
trabalhei em uma empresa em que as telas do sistema eram muito amarradas, por exemplo, ficava-se tentando adivinhar o que o usuário iria fazer de "cagada".
Por exemplo, fazia-se validações para não permitir cadastrar unidades de produtos com o mesmo nome, não deixava-se cadastrar estados com o mesmo nome, datas, eram todas validadas. Ou seja tudo que pudesse fazer o usuário fazer "besteira" era bloqueado.
O que vocês acham disso? é uma boa prática? Ou o usuário deve ser responsável pelo que faz no software?
Felipe Rosa
Post mais votado
31/07/2014
- Requisitos (Requirements) de Software
- Projeto (Design) de Software
- Construção (Construction) de Software
- Teste (Testing) de Software
- Manutenção (Maintenance) de software
- Gerência de Configuração de Software
- Gerência de Engenharia de Software
- Processos de Engenharia de Software
- Ferramentas e Métodos de Engenharia de Software
- Qualidade (Quality) de Software
Com base nessas informações, pode-se concluir que Testes de Software é uma etapa fundamental a ser executada para se obter a qualidade, pois a qualidade do produto está diretamente relacionada à qualidade do processo de desenvolvimento.
Em todos os processos do desenvolvimento existe uma etapa de verificação que consiste em analisar se etapa do processo está atendendo os requisitos de qualidade de software daquela etapa.
Marisiana Battistella
Mais Posts
06/11/2013
Fernanda Acacia
07/11/2013
Roniere Almeida
trabalhei em uma empresa em que as telas do sistema eram muito amarradas, por exemplo, ficava-se tentando adivinhar o que o usuário iria fazer de "cagada".
Por exemplo, fazia-se validações para não permitir cadastrar unidades de produtos com o mesmo nome, não deixava-se cadastrar estados com o mesmo nome, datas, eram todas validadas. Ou seja tudo que pudesse fazer o usuário fazer "besteira" era bloqueado.
O que vocês acham disso? é uma boa prática? Ou o usuário deve ser responsável pelo que faz no software?
é só não deixar passar pelo banco de dados.
14/11/2013
Felipe Rosa
14/11/2013
Felipe Rosa
14/11/2013
Marcos Oliveira
Se você não "amarrar" nada no cadastro, seu cliente terá problemas e lógico, precisará de suporte. Isso pode sobrecarregar o suporte da empresa, já que o cliente muitas vezes por ser leigo, não sabe o que está fazendo errado.
Por outro lado, se você "amarrar" muito, pode sobrecarregar a programação, uma vez que esse tipo de tratamento pode ser muito trabalhoso.
Acho que deve haver aí um meio termo, entre facilitar a vida do suporte e a vida da programação, sem esquecer de facilitar a vida do cliente.
No meu caso, eu opto por tratar tudo de forma a ficar claro pro cliente. Quanto menos ele me ligar, melhor pra mim.
Att,
Marcos
18/12/2013
Carlos Thompson
Se você não "amarrar" nada no cadastro, seu cliente terá problemas e lógico, precisará de suporte. Isso pode sobrecarregar o suporte da empresa, já que o cliente muitas vezes por ser leigo, não sabe o que está fazendo errado.
Por outro lado, se você "amarrar" muito, pode sobrecarregar a programação, uma vez que esse tipo de tratamento pode ser muito trabalhoso.
Acho que deve haver aí um meio termo, entre facilitar a vida do suporte e a vida da programação, sem esquecer de facilitar a vida do cliente.
No meu caso, eu opto por tratar tudo de forma a ficar claro pro cliente. Quanto menos ele me ligar, melhor pra mim.
Att,
Marcos
Acredito que seja como o Marcos falou, o ideal é buscar o equilíbrio e bom senso para não bloquear ou liberar demais o sistema para que o usuário venha a cometer algumas falhas de preenchimento. Algumas coisas básicas como data, campo do tipo numérico não permitir texto. Lembrando sempre que essas validações ou restrições devem vir acompanhadas de mensagens (Avisos) para que o usuário entenda o porquê da restrição.
O foco principal é atender as necessidades do cliente buscando "facilitar para ele o uso de sistema" (Usabilidade), porque se o software não facilita sua vida então é melhor usar um formulário em papel que talvez dê menos trabalho. "Esse pode ser o pensamento de um cliente".
Abraços.
18/12/2013
Alex Lekao
Concordo com o Marcos e com o Thonsom.
e o Roniere, mencionou algo que eh interessante, alguns tratamentos podem ser dados no banco de dados, com isso integrando esse tratamento feito no banco com algo no sistema, pode ficar mais tranquilo de se contornar essa questao.
Agora na minha opniao, deve-se prever o maximo possivel de problemas, desde que nao interfira no desempenho e usabilidade, como ja foi mencionado, para que o usuario nao cometa erros.
Vejo sistemas que nao tem esses bloqueios unica e exclusivamente para se esquivar da responsabilidade da culpe pelo erro, ou operacao errada no caso, ai eh mais facil deixar a cargo do usuario, assim vc nao eh "responsavel", eu particularmente nao concordo.
Se vc deixar muito aberto, vc tem que ter um Phd para trabalhar e fazer algumas operacoes, embora se vc bloquear demais eh melhor um robo para fazer o trabalho ou usar papelo como foi dito que eh menos trabalhoso.
O melhor dos dois mundo eh interessante, se ha bloqueios mas nao eh burocratico e engessado demais, pq nao?
Abraco.
Alex - Lekao
18/12/2013
Roniere Almeida
19/12/2013
Fernanda Acacia
25/07/2014
Thiago Palmeira
26/07/2014
Fernanda Acacia
26/07/2014
Thiago Palmeira
Clique aqui para fazer login e interagir na Comunidade :)