Não estariam invertendo os papeis?!

Assuntos Gerais
#81

[quote=sergiotaborda][cmoscoso][Marcio Duran] :idea: O Analista de negócio tem que se situar sobre os requisitos de sistema b[/b], quem figura tal possibilidade ao plano de modelo de processo é quem interpreta diretamente os requisitos sistemicos com o stakeholders, é o Analista de requisitos(Use Case), (…)

:shock: Voce acha benefico dividir o projeto em fase de requisitos e outra de implementacao :shock:

:?: Analista de Requisitos non ecziste. Mais alguem sabe o que é isso alem do Marcos?

:arrow: Lamento Marcos por saber que vc se denomina analista de requisitos, mas nao vejo necessidade de intermediarios entre o analista de negocio e os programadores para criacao dos casos de uso. :thumbup:

:idea: Penso sim que algumas vezes a figura de um lider tecnico PODE ser importante. Pra concentrar a comunicacao com o analista de negocio, definir a arquitetura geral, inspecionar codigo e programar claro.
[/quote]

:arrow: cmoscoso, a tecnologia esta estreitando as funcionalidades(pessoas interações) por motivos de transformaçãob[/b] mas a hearquia entre papéis tende no futuro serem pessoas que colaborem na construção da informação.

:stuck_out_tongue: Bom, Não custa tentar lembrando Marcio Duran, você não é um pseudo-SergioPcalcado né :lol: :lol:

Não sabe o que é, mas soube descreve-la.Logo o titulo existe, demonina-se Analista de Requisitos ou mesmo Engenheiro de Requisitos por entender comportamentos ao sistema(software cenário use case) e reorganizar a tempestade de idéias(stakeholders vs contratos e interesses).

O Analista de Negócios não pederia ser ? Discordo não teria como ser, mas esse estaria proximo em contato com os aspectos gerenciais de ordem de qualidade e processo, ele não é o que intera em software , ele é uma interface de exposição de resultado e pontualidade, até um Scrum Master melhor aproximando.Analista de Sistema propõe entender todo o ciclo e fase a fase no desenvolvimento (software)garantindo a viabilidade de sucesso.

:thumbup: Pensa mais simples

O conhecimento das pessoas são como copos d’água, uns estarão cheios outros na metade e outros ainda bem rasos, da onde vem a fonte são os poços à se encontrar.

#82

[quote=Marcio Duran]
O conhecimento das pessoas são como copos d’água, uns estarão cheios outros na metade e outros ainda bem rasos, da onde vem a fonte são os poços à se encontrar. [/quote]

É por esse tipo de coisa, que voce deveria tomar vergonha na cara. Ô pseudointelectualidade do inferno, viu.

#83

[quote=Sergio Figueras]
É por esse tipo de coisa, que voce deveria tomar vergonha na cara. Ô pseudointelectualidade do inferno,
viu.[/quote]

:lol: :lol: :lol: :lol: Meu como você acordou mau humorado, abaixa uns mp3 do David Bowie só pra relaxar uma musica que gosto dele é aquela Absolute Beginners… hahahah

#84

[quote=Marcio Duran][quote=Sergio Figueras]
É por esse tipo de coisa, que voce deveria tomar vergonha na cara. Ô pseudointelectualidade do inferno,
viu.[/quote]

:lol: :lol: :lol: :lol: Meu como você acordou mau humorado, abaixa uns mp3 do David Bowie só pra relaxar uma musica que gosto dele é aquela Absolute Beginners… hahahah[/quote]

Tõ me rachando de rir aqui.

Nao sou nem um pouco mal-humorado. Mas da nojo gente pseudo intelectual cara. Ah sim, baixa uma do Falcão ai pra você ficar ouvindo: “Lendis Picantis at Anus”. =)

#85

[quote=Sergio Figueras]
Nao sou nem um pouco mal-humorado. Mas da nojo gente pseudo intelectual cara. Ah sim, baixa uma do Falcão ai pra você ficar ouvindo: “Lendis Picantis at Anus”. =)[/quote]

:lol: :lol: :lol: Meu essa abelha que lhe picou, te zuou feio mesmo hein…hhhhah, já disse seja você , para com esse tipo de coisa…

Seja você e busque em você seus ideais, cultuar a um e outro mas seja discreto…aahahahahhh…cara eu não tô aguentanto de rir aahahahah

#86

[quote=cmoscoso][quote=sergiotaborda]
Veja bem, os requisitos são para o software o que as leis da física são para a física e os axiomas para a matemática. São as “verdades absolutas” que o software tem que cumprir. Através dos requisitos vc pode prever o funcionamento do software. (o inverso não é verdade)
[/quote]

Conversa, os requisitos mudam bastante. Sao apenas uma motivacao para o software naquele instante.
[/quote]

Vc não entendeu nada da frase. OS requisitos dizem o que software é. Mas olhando o software vc não sabe os requisitos que lhe deram origem. Por exemplo, quais foram os requisitos para o Office 2007 ? Vc pdoe chutar 2 ou 3 , mas nunca todos os que o pessoal da microsoft pensou.

O ponto é que são trabalhos diferentes. Que um não pode fazer o trabalho do outro.
E além de serem diferentes não estão na mesma “linha”. Ou seja, a evolução de um programdor não é um analista.

Bom, se vc acha que casos de uso são documentos não posso fazer nada. UML não é documentação.
Quanto entender isso, entenderá o que eu quis dizer.
Por agora, o que posso lhe dizer é que está enganado.
Equipes ageis não usam casos de uso, mas utilizam user stories. No fim é a mesma coisa. São casos isolados
que exemplificam o que sistema deve fazer em certas circusntancias. Mas nem eles atendem TODAS as circunstâncias. Isso, so os requisitos podem abraçar.
Sim, vc pode criar muitos casos para uma só funcionalidade dando conta de todas as opções, mas isso é a forma errada (bad practice) de usar os casos de uso.

Leia o artigo do Rodrigo Yoshima na Mundo Java para mais detalhes de porque UML não é uma documentação e porque não se deve abusar de Casos de Uso. O ponto é: Requisitos são o fundamental para a construção do software. O resto são ferramentas. Mas não ferramentas para capturar os requisitos e sim para verificiar se eles são coerentes, fazem sentido, se conjugam uns com os outros, etc…

#87

:thumbup: Vou dar um outra idéia também leia o artigo do Rodrigo Yoshima sobre Modelagem Ágil [color=blue](Revista Mundo Java - numero 27 - Página 36).
[/color]
E presta atenção na Página 43 - Referências

Uma delas é a COCKBURN, ALISTAR http://www.alistair.cockburn.us

Abraçosss

#88

"

#89

Bom, se eu adotasse a sua concepcao de “requisitos” eu diria que identifica=los é atribuicao do programador. Pelo que puder entender com sua historinha de “alma do software” [e que vc considera requisitos como uma lista de funcionalidades a serem implementadas. Voce parece nao se dar conta mas neste momento requisitos ja lhe serão historia (sem trocadilho) e vc estara entao fazendo BDUF, querendo especificar todo o seu sistema na fase inicial do projeto. Esse é TUA ideia de requisitos; e nao tem nada de ágil.

Na real, requisitos sao quais os problemas que precisam ser resolvidos e nesse sentido a melhor pessoa para responder seria o analista de negocio. (Alguem viu o analista de sistema?)

Baseado nisso eu sugiro que repense tudo que disse nessa discussao.

#90

[quote=cmoscoso][quote=sergiotaborda]
O ponto é: Requisitos são o fundamental para a construção do software. O resto são ferramentas. Mas não ferramentas para capturar os requisitos e sim para verificiar se eles são coerentes, fazem sentido, se conjugam uns com os outros, etc…
[/quote]

Bom, se eu adotasse a sua concepcao de “requisitos” eu diria que identifica=los é atribuicao do programador. Pelo que puder entender com sua historinha de “alma do software” [e que vc considera requisitos como uma lista de funcionalidades a serem implementadas. Voce parece nao se dar conta mas neste momento requisitos ja lhe serão historia (sem trocadilho) e vc estara entao fazendo BDUF, querendo especificar todo o seu sistema na fase inicial do projeto. Esse é TUA ideia de requisitos; e nao tem nada de ágil.

Na real, requisitos sao quais os problemas que precisam ser resolvidos e nesse sentido a melhor pessoa para responder seria o analista de negocio. (Alguem viu o analista de sistema?)

Baseado nisso eu sugiro que repense tudo que disse nessa discussao.[/quote]

Saber quais os requisitos o sistema tem que obedecer não é BDUF(Big Design Up Front - GRande Senho na Frente) porque por definição, levantar requisitos não é fazer design.
Requisitos não são funcionalidades. Nunca disse isso. Vc está interpretando o que eu disse, e ainda por cima da forma errada. Especificar o solução , o software é uma coisa completamente diferente de desenvolve-lo e implementá-lo. Requisitos não são apenas os problemas que tem que ser resolvidos ( isso são requisitos macro)
são todos os detalhes que envolvem o software e que o desenvolvedor não vai saber a menos que sejam especificado. Por exemplo, que todos os reports têm que ter um cabeça-lo com o logo da empresa e um rodapé com uma declaração da confidencialidade dos dados. Se isto não estiver nos requisitos não tem que ser feito.
Outro exemplo é que as senhas tenham que se encriptadas e possam espirar após 1 ano sem uso. Sem que isto esteja presente nos requisitos não será implementado. E não tem caso de uso que mostre esta funcionalidade.

Não misture as bolas: requisito não é software , não é design, não se captura em casos de uso. UML não é documentação.

#91

Voce esta dizendo com isso que requisitos consiste tb em especificar uma solucao?

IMO, a diferenca entre especificar a solucao e desenvolver é um sprint.

Se isso nao é BDUF, realmente nao sei o que dizer.

#92

[quote=cmoscoso][quote=sergiotaborda]
Especificar o solução , o software é uma coisa completamente diferente de desenvolve-lo e implementá-lo. Requisitos não são apenas os problemas que tem que ser resolvidos ( isso são requisitos macro)
[/quote]

Voce esta dizendo com isso que requisitos consiste tb em especificar uma solucao?
[/quote]

Quero dizer que apenas com a especificação de requisitos vc pode ter uma solução.
Sim, vc está especificando a solução do problema do cliente. Lembre-se que o problema do cliente é um problema de negocio e a solução é a resolução desse problema. No caso, tem um software envolvido, mas pode ser mais que isso. Pode ter hardware especifico envolvido também. Seguimento de normas. Adoção de padrões de trabalho, etc…

O designer e o arquiteto pegam esses requisitos e produzem uma arquitetura e um design. Ou seja, decidem tecnologias e como elas vão se interligar para implementar a solução proposta. Coisas como a plataforma frameworks, bancos etc… são decididos depois que se tem os requisitos. Caso contrário dá merda e o programador acaba sendo obrigado a fazer gambiarra.
Depois que se têm os requisitos , e o design, ai sim vamos à implementação. Os requisitos são agrupados em unidades de trabalho que os programdores executam. Quer chamar a isso de user stories, features … vc que sabe. O ponto é que existem essas únidades de trabalho. O ponto é não confundir essas unidades com requisitos.

Tlv do ponto de vista do programador seja tudo a mesma coisa, mas não é.

Se vc implementar as unidades com sprint ou sem sprint , se a gerencia é com scrum ou sem, se o trabalho é terceirizado ou outsourced… não importa.

BDUF signfica que o designer e o arquiteto fazem toda a modelagem antes da programação começar e não que os requisitos são levantados antes da programação começar. Como já lhe disse, Design não signficia levantamento de requisitos.

Imagine que vc vai mandar fazer um movel sob medida a um marceneiro. Vc chega-lá e pergunta:
-Amigo, quero que me faça um movel.
-Blz, qual movel ?
-Um movel para a sala.
-Qual tipo de movel ?
-Uma mesa.
-Com gavetas ?
-não.
-De jantar ?
-não.
-Explique-me exactamente como é essa mesa …

(algum tempo depois o mrceneiro faz um esboço da mesa e pergunta)

  • É mais ou menos isso ?
  • Sim. qual é o preço ?
    -Vou fazer o orçamento e lhe digo depois

A conversa continua até que o marceneiro saiba exactamente o que tem que fazer. É isso que ele vai orçar e executar.
Ha um dialogo entre os dois até que seja acordado o que será feito.

Aquele dialogo é o levantamento de requisitos. Não ha madeira nem ferramentas de marceneiro associadas a ela, embora o tema da conversa seja sobre um movel de madeira que será construido usando certas feramentas.

O levantamento de requisitos tem que acontecer antes de começar a construir, porque não ha como saber o que o cara quer sem perguntar primeiro. Claro que ha ajustes conforme a coisa vai, mas ai não é mais levantamento de requisitos, são ajustes. às vezes aparecme requisitos novos. Mas ai ha um aumento do projeto ou o cliente tem que dicidir postergar para outra versão ou abandonar outros requitios para incluir esses. Para os novos requisitos têm que haver um novo levantamento. E assim vai…

é mais claro agora?

#93

Só que desenvolver software não é a mesma coisa que levantar prédio nem fabricar móveis.

#94

Mas levantar requisitos é igual em qualquer ocasião.
Requisitos não são software. Software é uma das muitas formas de satisfazer os requisitos.
Requisitos diferentes têm formas diferentes de serem satisfeitos.

O ponto é exemplificar o que “levantar requisitos” é e como isso nada têm a ver com a fase posterior de construir as coisas.

Estão partindo de uma ideia de algo que poderiamos chamar de requisitos on-the-fly ( eu levanto quando preciso) : isso simplesmente não funciona. O que é on-the-fly são os ajustes.

Vc faz o sistema inteiro e é perfeito. Agora o cliente pergunta : como eu faço para mostrar em espanhol ?
Ups… se isso não era um requisito, não havia como prever que ele queria isso. Então vc não fez.
De quem é o erro ? Não está escrito nos requisitos que precisa, mas tb não está que não precisa. (afinal os requisitos nem estão escritos, são on-the-fly)
Repare que o seus sistema falhou ao olhos do cliente, porque ele preveu que o sistema teria isso.
Estas falhas acontencem quando os requisitos não são levantados com antecedencia.

#95

[quote=sergiotaborda]
…
Vc faz (…)
Repare que o seus sistema falhou ao olhos do cliente, porque ele preveu que o sistema teria isso.
Estas falhas acontencem quando os requisitos não são levantados com antecedencia. [/quote]

:idea: Você tem informação sobre o uso de ficha de Volere, para levamento de requisitos tecnológicos ou esse conceito de template é algo ultrapassado, entranto esse tipo de requisito deva se encaixar como elicitação de requisitos, onde envolve Template de Alta-Pressão:Kree um Ranfath

#96

[quote=Marcio Duran][quote=sergiotaborda]
…
Vc faz (…)
Repare que o seus sistema falhou ao olhos do cliente, porque ele preveu que o sistema teria isso.
Estas falhas acontencem quando os requisitos não são levantados com antecedencia. [/quote]

:idea: Você tem informação sobre o uso de [b]ficha de Volere/b
[/quote]

não, não sei o que é isso. Pelo que puder entender (http://www.systemsguild.com/GuildSite/Robs/Template.html)
é um padrão de escrita de requesitos. Se for isso, é legal, mas não é para ser abusado. É apenas um guia.
Um livro legal de padrões de requisitos que tb aborda documentação e templates é http://www.microsoft.com/MSPress/books/10808.aspx. Este livro eu acho muito bom porque chama a atenção do que precisa ser levantado em um requisito e quais outros requisitos nascem dele. Acho que todo o analista (seja do que for) precisa ler este.

#97

Tá dificil!

[quote=sergiotaborda]
O designer e o arquiteto pegam esses requisitos e produzem uma arquitetura e um design. Ou seja, decidem tecnologias e como elas vão se interligar para implementar a solução proposta. Coisas como a plataforma frameworks, bancos etc… são decididos depois que se tem os requisitos.[/quote]

Se isso é decidido depois o que consiste realmente “decidir tecnologias e sua interligacao para implementar a solucao”.

Nao era vc que estava recomendando leitura de agile ainda pouco?

A que ponto chegamos… :evil:

Me permita o cv…

#98

[quote=cmoscoso]Tá dificil!

O que é que vc não entendeu ?

Requisitos -> decisão de como implementa (aka modelo) -> implementação ( aka codigo)

A decisão vem depois dos requisitos serem sabidos.

Acho que vc está pensando e um ciclo assim:

Requisitos -> decisão de como implementa (aka modelo) -> implementação ( aka codigo) -> adiciona requisitos -> altera modelo -> altera codigo-> adiciona requisitos -> altera modelo -> altera codigo-> … etc…

Eu estou-lhe dizendo que é :

Requisitos -> modelo inicial -> unidades de trabalho -> implementação ( aka codigo) -> altera modelo -> adiciona unidades de trabalho -> altera modelo -> altera codigo -> adiciona unidades de trabalho -> altera modelo -> altera codigo -> …

Um BDUF seria

Requisitos -> modelo inicial -> unidades de trabalho -> implementação ( aka codigo) -> altera codigo -> altera codigo -> altera codigo -> …

consegue ver a diferença ?
Se não consegue desisto. Alguem que explique melhor.

#99

Ficou claro agora. Voce considera o modelo como algo que vive alem do codigo.

Requisitos sao conhecidos.

Torna requisito uma especificacao executavel -> design (aka modelo/codigo) -> Torna outro requisito uma especificacao executavel -> design (aka modelo/codigo) -> adiciona especificacao -> design (aka modelo/codigo) etc…

Nao há certificacao melhor pra agilidade do que essa. Reconhecer que vc sabe praticamente nada do sistema de UP FRONT, antes de implementa-lo.

Sim, e a segunda opcao parece tentadora. Na pratica é o que acaba acontecendo. Ou alguem ja viu por ai transformacao de modelos assim como prega o pessoal do MDA?

Se era isso que vc queria dizer com “UML não é documentação” acho que nao era essa a intencao do autor.

#100

São conhecidos ? Por quem ? Como se tornam conhecidos dessa(s) pessoa(s) ?