Requisitos de software

Sem dúvida!
[url]http://pt.wikipedia.org/wiki/Engenharia_de_software[/url]
[url]http://pt.wikipedia.org/wiki/Teste_de_software[/url]
[url]http://pt.wikipedia.org/wiki/Qualidade_de_Software[/url]

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.

acredito que o caminho não é esse, mas a casos e casos...um treinamento do sistema é o basico.

procura saber mais sobre permissões de usuarios.

é só não deixar passar pelo banco de dados.

Felipe, o que deseja realmente fazer com o sistema?

como ficou sua duvida amigo?

So queria saber o que vocês acham dessa prática. Acredito que o nome para isso pode ser programação defensiva

So queria saber o que vocês acham dessa prática. Acredito que o nome para isso pode ser programação defensiva

Felipe, eu penso da seguinte forma:

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.

Ola Boa tarde!!!

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

tambem concordo com o que foi escrito acima, mas não basta uma mensagem(confiar demais). deve-se existir uma politica.

muito bom mesmo o que foi escrito acima, não tinha pensado dessa forma.

Na questão da validação deve ser desenhado com o cliente como será os tratamentos, pois em um sistema qualquer pode ser tratado tanto pelo banco de dados, client side e/ou server side.

Varallo, pela sua experiencia, existe uma formula magica do que deve ser validado pelo banco, linguagem ou isso realmente depende do sistema?

Na verdade as empresas precisam ter definido um processo de desenvolvimento, pois em muitos projetos quem faz a análise é o desenvolvedor, sendo que muitos desses profissionais tem a parte técnica e não a comunicativa. Esse é um dos fatores para o projeto não ser entregue dentro do prazo e ter um alto custo.

é um erro que ainda cometem, um profissional que faz varias coisas então.

Um Severino da vida...

verdade, da arrepio só de pensar.

Não considero essas questões que descrevestes como besteiras que o usuário possa fazer.
É responsabilidade de quem fornece o produto garantir a qualidade dele. Se vc não fizer todas validações e controles necessários, vocês está deixando de cumprir regras básicas que vão interferir na qualidade dos dados que serão armazenados e isso vai ter muitas consequências quando o cliente for analisar seus dados para tomar decisões.
Essas questões não devem ser tratadas como besteira pois são questões que interferem nos resultados e dificultam a gestão empresarial devido a baixa qualidade de dados que foi armazenada.
É obrigação dos desenvolvedores garantir que os dados sejam armazenados da melhor forma possível além de realizar um bom treinamento aos usuários na entrega do produto.
Tem questões q podem ser insignificantes para um usuário que trabalha, por exemplo, no caixa da loja, mas para os gestores e tomadores de decisões são fundamentais.

Me desculpem se me exaltei no q falei...
Mas afirmo q é um inferno analisar os dados de um estrutura mal elaborada, com informações inconsistentes e com falhas nas validações de dados que deveriam ter sido tratadas por quem desenvolveu o sistema.

Marisiana, essa situação é bem complicada pois envolver pessoas, sejam da T.I ou os usuarios finais. cliente x desenvolvedor(analista) e profissional de B.I e gestores. se algo não for bem feito no inicio, logo, teremos problemas futuros.

Isso mesmo Fernanda!
Nesse sentido, muitos problemas podem ser evitados se pelo menos a TI fizer a parte dela completa.
Conforme o Thompson mencionou:

O cliente não quer saber o que os profissionais de TI devem ou não fazer ele quer que o produto final que ele vai receber seja bom e de qualidade.

Verdade, delicado demais, mas é para isso que serve um analista, para entender tudo mas tudo mesmo que o cliente quer.

Inclusive! =)
Mas a qualidade que o cliente quer ver no produto não está apenas no resultado do trabalho do analista de sistemas.
Quando se fala na qualidade do produto final envolve o resultado do trabalho de cada membro da equipe.

eu sei, mas qualidade deve começar desde o principio. rsrsrsrsrs

Exato!
É pra isso que existe uma área de conhecimento dentro da Engenharia de software que se chama "Qualidade de Software".

existe alguma relação entre qualidade de software com testes de software?

Ainda é difícil inserir um processo de desenvolvimento de qualidade nas empresas como deveria ser feito um software, pois vejo em muitos relatos que tem lugares que não tem testadores, só desenvolvedores para analisar, desenvolver e gerenciar.

Mas nesses casos, pode ser definido no processo que próprio desenvolvedores testem as aplicações...

esses pontos sao complexos demais.

temos pequenas empresas bem estruturada como grandes empresas e temo grandes e medias empresas estruturadas como pequenas.

jja vivi nos dois cenarios, eh muito complicado. srsr

no processo de desenvolvimento e em seguidas os testes, por etapas ou modulos?

Mas isso na realidade é bem difícil de acontecer. Nada contra, pois também sou desenvolvedor, pois pela experiência que tenho e vejo nos estudos de profissionais consagrados, poucos são desenvolvedores que testam ...

assunto delicado pois os profissionais que estudam para ser desenvolvedor serão desenvolvedores e não testadores, o problema está na empresa e nos processos de desenvolvimento de software. problemas que envolvem profissionais e o produto, enfim é complicado demais.

Depende de como foi definido no projeto, se as entregas serão por módulos, cada módulo deve ser testado e aprovado antes de ser validado com o cliente.

Isso é verdade. Vejo muito disso...
Não estou querendo criticar ou dizer q tá tudo errado, apenas desenvolvi a discussão para se fazer uma reflexão sobre como é a realidade e como deveria ser.
Vc não acha que todo desenvolvedor deve ser também analista e testador?
Como o desenvolvedor vai garantir que a solução que ele criou é eficaz e eficiente se ele não souber analisar a situação para encontrar a melhor solução a ser utilizada e se ele não tiver testado para ver se realmente está de acordo com o q foi proposto?
De certa forma todos são, mas como nem todos param pra pensar nesses detalhes, nem todos desenvolvem as habilidades que deveriam desenvolver. Ou, então, desenvolvem, mas não distinguem e por isso deixam de fazer com excelência.

dependendo do cronograma do projeto seria interessante fazer, eu acho.

Lição básica de gerência: “Se você não pode medir, você não pode gerenciar” (Peter Drucker)

Acho que o problema poderia ser resolvido em ter algum sindicato próprio para a categoria de todos os profissionais de TI. Por exemplo, como é medido que o desenvolvedor é júnior, pleno ou sênio?????

Conheci pessoas que trabalham em empresas que não sabem nem o que cadastrar na carteira se é programador ou desenvolvedor ou técnico....huhuauahua

Acredito que com um sindicato, o profissional poderia tirar um registro como um advogado precisa fazer para começar as suas atividades e ter credibilidade. Além disso, essa ação poderia trazer para mais qualidade no desenvolvimento e entrega dos sistemas.

Só acho!

bem lembrado.

Varallo, acho interessante essa discussão, da entender que o trabalho qualificado de T.I, não importando se é desenvolvedor, DBA, analista(todos os tipos), todos serão considerados a pessoa que mexe com informatica e nada mais, sobre a questão da carteira, é triste ver situações assim.

Permitam-me uma observação...
Engenharia de software não tem nada a ver com funções, cargos e salários...
Isso que o Varallo comentou é outro caso, é uma questão organizacional e de RH.

eu sei Marisiana, mas quase sempre essas discussões fogem do foco.

Uhum... Mas de acordo com a sequência da conversa é isso que se pode entender. Apenas fiz a observação pra não deixar margem pra esse tipo de interpretação...

Obviamente que quanto mais tratamentos melhor, não podemos simplesmente deixar na "mão do usuário" e esperar que ele faça tudo conforme mandam as regras, temos que pensar que ele sempre fará pelo lado errado.

tudo certo então, entendi a sua observação.

Outra questão a ser considerada, é que o usuário que recebeu treinamento hoje, amanhã pode sair da empresa e o novo usuário não terá o mesmo treinamento que o usuário anterior teve.
Sem contar que tem usuários que "não estão nem aí" com a qualidade da informação que estão alimentando no sistema (situação bem comum em cadastros de produtos, clientes, etc.).

Também tem muitos casos em que o usuário acaba não repassando todas as regras para o analista, pois acredita que o sistema tomará o lugar dele na empresa.

Infelizmente ainda tem pessoas que pensam assim.

ja ouvi falar bastante de situações assim, nesses casos o que pode se tentar fazer para minimizar o "estrago"?

Acredito que o profissional precise já ter experiência e recursos para conseguir obter a informação. Não é fácil!

experiencia com os erros e experiencia com diversos tipos de sistema, ou seja, conhecer varios sistemas e como eles deve se comportar, o que ter e o que não ter.

O ponto importante é tentar fazer uma "pesquisa" no cliente para ver quem são as pessoas mais indicadas para repassar as informações necessárias.
Geralmente tem que ser um colaborador que esteja a mais tempo na empresa e que tenham uma boa posição (cargo), pois isso indica que é uma pessoa que tem mais compromisso com a empresa. Além de ter que ser uma pessoa que conheça os processos que são realizados na empresa.

É exatamente isso, não pode ser qualquer um.