Olá, sou novato por aqui, e nunca trabalhei na area de programação/desenvolvimento.
Tenho algumas duvidas referentes ao andamento dentro de um estágio ou emprego normal, sei que “teoricamente” seria dado a UML para você(desenvolvedor) e você desenvolveria emcima dessa especificação.
Mas queria ter uma ideia, ou relato de quem ja passou por isso, principalmente em estágio, de como é… de como é passado, que nivel seria isso… porque não tenho conhecimento sobre isso.
Obrigado desde já, e criei o topico porque não achei nada especifico por aqui, caso alguem tenha um link, fique a vontade em compartilhar…
Tenho algumas duvidas referentes ao andamento dentro de um estágio ou emprego normal, sei que “teoricamente” seria dado a UML para você(desenvolvedor) e você desenvolveria emcima dessa especificação.
Nem teoricamente muito menos praticamente. São poucas empresas que usam diagramação como forma de comunicar requisitos ao programador, mesmo porque isso é bobagem. De fato, o que tem sido mais usado são casos de uso (e não diagramas de caso de uso, pois são coisas diferentes), user stories, casos de teste e etc. São ferramentas mais modernas e muito mais esclarecedoras.
[quote=rmendes08]Tenho algumas duvidas referentes ao andamento dentro de um estágio ou emprego normal, sei que “teoricamente” seria dado a UML para você(desenvolvedor) e você desenvolveria emcima dessa especificação.
Nem teoricamente muito menos praticamente. São poucas empresas que usam diagramação como forma de comunicar requisitos ao programador, mesmo porque isso é bobagem. De fato, o que tem sido mais usado são casos de uso (e não diagramas de caso de uso, pois são coisas diferentes), user stories, casos de teste e etc. São ferramentas mais modernas e muito mais esclarecedoras.[/quote]
Diagramação é bobagem? Bem, espero que você não inclua um MER nisso. MER é um diagrama e bem, eu acho a melhor forma de entender um sistema. A minha prática preferida e a que usamos aqui na empresa é MER + casos de tela.
Eu recebo uns requisitos feito por pessoas que entedem do negócio mas nunca escreveram requisitos na vida.
Algo do tipo “manter um cadastro de tal coisa”, mas ninguém nem imagina o que tem que ter nesse cadastro, então antes de eu começar a digitar qualquer código, eu ainda tenho um trabalho árduo de correr atrás dessas inforrmações, organizar os requisitos e completa-lo… Depois disso, eles me dão um baita “SVN” (Se vira, negão!!!), e ai eu faço do jeito que quiser, uso os diagramas que eu quiser, a documentação que eu quiser, a linguagem que eu quiser e os padrões que eu quiser.
O importante é entregar o negócio funcionando…
Sei que é totalmente diferente do que você vê na faculdade, mas é como funciona 90% das empresas…
[quote=AUser][quote=rmendes08]Tenho algumas duvidas referentes ao andamento dentro de um estágio ou emprego normal, sei que “teoricamente” seria dado a UML para você(desenvolvedor) e você desenvolveria emcima dessa especificação.
Nem teoricamente muito menos praticamente. São poucas empresas que usam diagramação como forma de comunicar requisitos ao programador, mesmo porque isso é bobagem. De fato, o que tem sido mais usado são casos de uso (e não diagramas de caso de uso, pois são coisas diferentes), user stories, casos de teste e etc. São ferramentas mais modernas e muito mais esclarecedoras.[/quote]
Diagramação é bobagem? Bem, espero que você não inclua um MER nisso. MER é um diagrama e bem, eu acho a melhor forma de entender um sistema. A minha prática preferida e a que usamos aqui na empresa é MER + casos de tela. [/quote]
diagramas sim são bobagem para passar informação. Inclusive o MER. Aliás o MER em OO é arcaico. É como usar um computador de furos em cartão. O modelo OO é muito mais relevante , mas não necessáriamente precisa haver um diagrama. Mesmo que o haja ele não deve ser usado para passar requisitos.
Como foi dito, casos de uso, user stories, ou seja TEXTO é a melhor forma de passar pedidos e instruções. É por isso que os manuais são TEXTO e não um bando de diagramas. Os diagramas podem ser utilziados para ilustrar o texto, mas não para substituir o texto.
Ainda bem que aqui onde trabalho ficamos no 90% eheheh.
Aqui vai um pessoal conversar com o cliente, o pessoal que vai é programador/analista, sabe como trabalhar.
Levantam o que o pessoal precisa, e desenvolve os casos de uso ao lado do cliente, levantado os requisitos (nunca é 100% isso, sempre vão faltar campos).
Depois dessa etapa, é modelada a base seguindo os casos de uso.
A equipe toda senta e discute as tecnologias e padrões básico a serem usados no projeto. (Sempre pode ser alterado com o projeto em desenvolvimento).
Criamos a base, e desenvolvemos uma parte do sistema. Ai começa um pedaço de Scrum.
O Cliente, ve na base de teste como esta, e faz suas criticas, alteramos conforme a necessidade, e por ai vai. Sempre o cliente vai corrigir, as vezes deduzir que 6 meses de trabalho não são mais necessarios, por que isso não atende mais .
Tomando uma conclusão precipitada apartir do que vocês disseram acima…
A forma que é passada os requisitos e a maneira que é feita em cada projeto depende exclusivamente da empresa/projeto? Pelo que “leio” apesar de existirem padrões e formas “testadas”, muitas vezes a empresa prefere seguir sua cultura/padrão que acha que funciona, correto?
Então mais uma vez, creio que tenho que “aprender” ou pelo menos “conhecer” um pouco de cada metodologia, uses cases, MER, user stories e etc?
[quote=marcio.neto]Olá, sou novato por aqui, e nunca trabalhei na area de programação/desenvolvimento.
Tenho algumas duvidas referentes ao andamento dentro de um estágio ou emprego normal, sei que “teoricamente” seria dado a UML para você(desenvolvedor) e você desenvolveria emcima dessa especificação.
Mas queria ter uma ideia, ou relato de quem ja passou por isso, principalmente em estágio, de como é… de como é passado, que nivel seria isso… porque não tenho conhecimento sobre isso.
Obrigado desde já, e criei o topico porque não achei nada especifico por aqui, caso alguem tenha um link, fique a vontade em compartilhar…
Att,
Márcio Neto[/quote]
Só pra complementar…
Acho que vc está com aquela visão de: Analista de Negócio, Analista de Sistemas e Desenvolvedor…
Onde um analista de negócios cria o documento de requisitos, o analista de sistemas cria as documentações e diagramas, e o desenvolvedor desenvolve…
Já trabalhei assim, mas só em bolsa de pesquisa na faculdade. No mercado de trabalho real, vc é o analista de sistemas e desenvolvedor, senão mais que isso…
Existir uma pessoa para criar diagramas e outra pra desenvolve-los é algo muito demorado, um desenvolvedor vai sempre corrigir muita coisa nos diagramas e vai existir muito retrabalho, então é melhor o desenvolvedor já fazer tudo… hehehe!
[quote=William Silveira][quote=marcio.neto]Tomando uma conclus? precipitada apartir do que voc? disseram acima…
A forma que ?passada os requisitos e a maneira que ?feita em cada projeto depende exclusivamente da empresa/projeto? Pelo que “leio” apesar de existirem padr?s e formas “testadas”, muitas vezes a empresa prefere seguir sua cultura/padr? que acha que funciona, correto?[/quote]
Nao se iluda , na corporacao voce pode ter todas as responsabilidades como ter responsabilidades especificas o que conta e sua formacao e entendimento na area que vc se candidatou.[/quote]
Concluindo… tudo vai “depender” de “n” fatores, né?
Não é bem ilusão, é que eu “ouço” muitos professores falarem dessa forma correta, analisar/projetar/desenvolver/testes, e ja sabia que nao funcionava assim, e quero ver pontos de vistas diferentes para me preparar.
E como você mesmo apontou, tambem acho que a melhor forma é o desenvolvedor tambem aderir a outras funções pois ele as vezes vai entender melhor o problema/solução do que quem fez os requisitos, e tem a questão do re-trabalho.
Valeu galera, acho que está dando para ter uma otima noção do que esperar.
[quote=sergiotaborda][quote=AUser][quote=rmendes08]Tenho algumas duvidas referentes ao andamento dentro de um estágio ou emprego normal, sei que “teoricamente” seria dado a UML para você(desenvolvedor) e você desenvolveria emcima dessa especificação.
Nem teoricamente muito menos praticamente. São poucas empresas que usam diagramação como forma de comunicar requisitos ao programador, mesmo porque isso é bobagem. De fato, o que tem sido mais usado são casos de uso (e não diagramas de caso de uso, pois são coisas diferentes), user stories, casos de teste e etc. São ferramentas mais modernas e muito mais esclarecedoras.[/quote]
Diagramação é bobagem? Bem, espero que você não inclua um MER nisso. MER é um diagrama e bem, eu acho a melhor forma de entender um sistema. A minha prática preferida e a que usamos aqui na empresa é MER + casos de tela. [/quote]
diagramas sim são bobagem para passar informação. Inclusive o MER. Aliás o MER em OO é arcaico. É como usar um computador de furos em cartão. O modelo OO é muito mais relevante , mas não necessáriamente precisa haver um diagrama. Mesmo que o haja ele não deve ser usado para passar requisitos.
Como foi dito, casos de uso, user stories, ou seja TEXTO é a melhor forma de passar pedidos e instruções. É por isso que os manuais são TEXTO e não um bando de diagramas. Os diagramas podem ser utilziados para ilustrar o texto, mas não para substituir o texto.[/quote]
Bom, eu prefiro usar o MER + casos de tela. Obviamente nos casos de tela tem as descrições dos passos corretos. Você pode achar isso uma bobagem, agora o que eu estou dizendo é que o MER sozinho realmente não atende, mas com casos de tela e uma descrição sempre me atenderam muito bem. Eu digo em usar o MER para entender conceitos e relacionamentos.
[quote=marcio.neto]Tomando uma conclusão precipitada apartir do que vocês disseram acima…
A forma que é passada os requisitos e a maneira que é feita em cada projeto depende exclusivamente da empresa/projeto? Pelo que “leio” apesar de existirem padrões e formas “testadas”, muitas vezes a empresa prefere seguir sua cultura/padrão que acha que funciona, correto?
[/quote]
Correto.
Não. Vc tem que saber se adaptar às circunstancias. Isso significa que vc deve saber com um software é feito e a construção do software não depender daquilo que lhe dizem que o sistema deve fazer. No final das contas vc acaba sempre com uma lista de coisas para fazer como essa sua lista é alimentada - casos de uso, user stories, etc… - é irrelevante.
[quote=AUser]
Bom, eu prefiro usar o MER + casos de tela. Obviamente nos casos de tela tem as descrições dos passos corretos. Você pode achar isso uma bobagem, agora o que eu estou dizendo é que o MER sozinho realmente não atende, mas com casos de tela e uma descrição sempre me atenderam muito bem. Eu digo em usar o MER para entender conceitos e relacionamentos.[/quote]
Em sistemas OO o MER simplesmente não faz sentido.
Se vc me dissesse que usava uma uml de entidades até que vai, mas modelar o sistema pelo banco de dados… muito fora de OO.
A mesmo é claro que vc só faça aplicações orientadas a dados. Ai tudo bem. (mas essa “tecnologia” de aplicações é literalmente do seculo passado)
[quote=sergiotaborda][quote=AUser]
Bom, eu prefiro usar o MER + casos de tela. Obviamente nos casos de tela tem as descrições dos passos corretos. Você pode achar isso uma bobagem, agora o que eu estou dizendo é que o MER sozinho realmente não atende, mas com casos de tela e uma descrição sempre me atenderam muito bem. Eu digo em usar o MER para entender conceitos e relacionamentos.[/quote]
Em sistemas OO o MER simplesmente não faz sentido.
Se vc me dissesse que usava uma uml de entidades até que vai, mas modelar o sistema pelo banco de dados… muito fora de OO.
A mesmo é claro que vc só faça aplicações orientadas a dados. Ai tudo bem. (mas essa “tecnologia” de aplicações é literalmente do seculo passado)[/quote]
Opa, não, eu não disse modelar o sistema pelo MER. Isso obviamente não faz sentido hoje em dia. O que eu disse é: entender funcionalidades e como as funcionalidades se relacionam. Ter uma visão geral.
[quote=AUser][quote=sergiotaborda][quote=AUser]
Bom, eu prefiro usar o MER + casos de tela. Obviamente nos casos de tela tem as descrições dos passos corretos. Você pode achar isso uma bobagem, agora o que eu estou dizendo é que o MER sozinho realmente não atende, mas com casos de tela e uma descrição sempre me atenderam muito bem. Eu digo em usar o MER para entender conceitos e relacionamentos.[/quote]
Em sistemas OO o MER simplesmente não faz sentido.
Se vc me dissesse que usava uma uml de entidades até que vai, mas modelar o sistema pelo banco de dados… muito fora de OO.
A mesmo é claro que vc só faça aplicações orientadas a dados. Ai tudo bem. (mas essa “tecnologia” de aplicações é literalmente do seculo passado)[/quote]
Opa, não, eu não disse modelar o sistema pelo MER. Isso obviamente não faz sentido hoje em dia. O que eu disse é: entender funcionalidades e como as funcionalidades se relacionam. Ter uma visão geral.[/quote]
MER tem algo a ver com DER?
Se sim…
Se os desenvolvedores precisam ter uma visão geral das funcionalidades e como elas se relacionam, e e fosse usado algum diagrama pra isso, o mais lógico e correto seria utilizar UML e não um MER, pois nem sempre (quase nunca) as tabelas do bd mapeiam 1 pra 1 com o modelo de domínio do sistema.
[quote=foxpv][quote=AUser][quote=sergiotaborda][quote=AUser]
Bom, eu prefiro usar o MER + casos de tela. Obviamente nos casos de tela tem as descrições dos passos corretos. Você pode achar isso uma bobagem, agora o que eu estou dizendo é que o MER sozinho realmente não atende, mas com casos de tela e uma descrição sempre me atenderam muito bem. Eu digo em usar o MER para entender conceitos e relacionamentos.[/quote]
Em sistemas OO o MER simplesmente não faz sentido.
Se vc me dissesse que usava uma uml de entidades até que vai, mas modelar o sistema pelo banco de dados… muito fora de OO.
A mesmo é claro que vc só faça aplicações orientadas a dados. Ai tudo bem. (mas essa “tecnologia” de aplicações é literalmente do seculo passado)[/quote]
Opa, não, eu não disse modelar o sistema pelo MER. Isso obviamente não faz sentido hoje em dia. O que eu disse é: entender funcionalidades e como as funcionalidades se relacionam. Ter uma visão geral.[/quote]
MER tem algo a ver com DER?
Se sim…
Se os desenvolvedores precisam ter uma visão geral das funcionalidades e como elas se relacionam, e e fosse usado algum diagrama pra isso, o mais lógico e correto seria utilizar UML e não um MER, pois nem sempre (quase nunca) as tabelas do bd mapeiam 1 pra 1 com o modelo de domínio do sistema.[/quote]
MER é Modelo Entidade-Relacionamento e DER é Diagrama Entidade-Relacionamento. Ou seja, o DER é a representação gráfica do MER, e aqui tem uma confusão. O que a maioria das pesssoas chama de DER na verdade é um esquema de relações, isso porque Modelo ER e Modelo Relacional são duas coisas diferentes. Um DER na verdade deve representar conjuntos de entidades e conjuntos de relacionamentos, diferentementemente de um esquema de relações, que representa tabelas e restrições de chave estrangeira, erroneamente chamadas de relacionamentos.
[quote=rmendes08][quote=foxpv][quote=AUser][quote=sergiotaborda][quote=AUser]
Bom, eu prefiro usar o MER + casos de tela. Obviamente nos casos de tela tem as descrições dos passos corretos. Você pode achar isso uma bobagem, agora o que eu estou dizendo é que o MER sozinho realmente não atende, mas com casos de tela e uma descrição sempre me atenderam muito bem. Eu digo em usar o MER para entender conceitos e relacionamentos.[/quote]
Em sistemas OO o MER simplesmente não faz sentido.
Se vc me dissesse que usava uma uml de entidades até que vai, mas modelar o sistema pelo banco de dados… muito fora de OO.
A mesmo é claro que vc só faça aplicações orientadas a dados. Ai tudo bem. (mas essa “tecnologia” de aplicações é literalmente do seculo passado)[/quote]
Opa, não, eu não disse modelar o sistema pelo MER. Isso obviamente não faz sentido hoje em dia. O que eu disse é: entender funcionalidades e como as funcionalidades se relacionam. Ter uma visão geral.[/quote]
MER tem algo a ver com DER?
Se sim…
Se os desenvolvedores precisam ter uma visão geral das funcionalidades e como elas se relacionam, e e fosse usado algum diagrama pra isso, o mais lógico e correto seria utilizar UML e não um MER, pois nem sempre (quase nunca) as tabelas do bd mapeiam 1 pra 1 com o modelo de domínio do sistema.[/quote]
MER é Modelo Entidade-Relacionamento e DER é Diagrama Entidade-Relacionamento. Ou seja, o DER é a representação gráfica do MER, e aqui tem uma confusão. O que a maioria das pesssoas chama de DER na verdade é um esquema de relações, isso porque Modelo ER e Modelo Relacional são duas coisas diferentes. Um DER na verdade deve representar conjuntos de entidades e conjuntos de relacionamentos, diferentementemente de um esquema de relações, que representa tabelas e restrições de chave estrangeira, erroneamente chamadas de relacionamentos. [/quote]
Estudei numa universidade onde a maioria absoluta nunca sujou os dedos num teclado de cubículo de consultoria. E ainda assim, dão pitacos sobre como seria a construção de software no mundo real.
Bom, muitos professores são inteligentíssimos, mas como eles não tem muito contato com o mercado, é bom ouvir desconfiado.
.