Software não é Código é Requisito

Pessoal, notem que na Wikipedia tem três definições:

1º: Software, logiciel ou programa de computador é uma sequência de instruções a serem seguidas e/ou executadas, na manipulação, redirecionamento ou modificação de um dado/informação ou acontecimento.

2º: Software também é o nome dado ao comportamento exibido por essa seqüência de instruções quando executada em um computador ou máquina semelhante.

3º: Tecnicamente, Software também é o nome dado ao conjunto de produtos desenvolvidos durante o Processo de Software, o que inclui não só o programa de computador propriamente dito, mas também manuais, especificações, planos de teste, etc.

A primeira definição agrada a tuma do “Software é código”
A terceira definição agrada a tuma do “Software é requisito”

Pronto, todo mundo está certo. Fim do tópico… :roll:

Depois de ler isso tudo de respostas, fico pensando:

Se software é requisitos…
requisitos quem determina é o cliente…nós apenas os levantamos com eles…
Então pq existem programadores??
O software já está com o cliente…

Se isso tiver correto, tenho que pensar urgente em mudar de profissão…

tsc tsc

Software é o que se xinga, Hardware é o que se chuta… fim da Thread 8)

[quote=luistiagos][quote]
Como vc garante que o seu sistema tem disponibilidade de 99.99% se isso nao for especificado.
[/quote]

Bem acho que ninguem tenque fazer um documento com requisitos pedindo isto a vc… é vc que tenque fazer um codigo decente especificando isto para o processador…

a menos que vc seja um monkeycode tipos de coisas como esta e outros requisitos não funcionais não precisam ser especificados…
[/quote]

Pela sua resposta vc não sabe o que “!diponibilidade” significa. Então não vejo como vc pode argumentar que “disponibilidade” é ou não é um requisito necessário e é ou não é um requisito não-funcional.

“Disponibilidade” é um requitiso não-funcional que não se programa. Não ha codigo para isso. Não ha uma função que vc passa 99.99 e pronto. Vc tem que construir uma arquitetura um modelo e escolher tecnologias, hardware e até serviços de hosting compativeis com a disponibilidade. Se ela não for especificada pelo cliente vc chuta uma ? Vc sabe o custo que existe entre disponibilidade 99.00%, 99.90% e 99.99% ? Quem vai pagar esse custo ? O programador ?

Resumindo, vc não sabe do que está a falar. Não digo isto como critica ou para menosprezá-lo. Digo isto como fato para que vc se informe ( e todo aquele que ler isto e pensar como vc).

Depois que vc se informar vc retorna aqui e diz o que acha sobre não especificar requisitos não-funcionais. blz ? :wink:

eu entendi mal o comentario do cara… neste ponto vc esta certo…

mas ao certo este tipo de coisa a maioria do cliente sequer sabe… quem tenque levantar este tipo de requisitos somos nos… o cliente apenas “sabe” os requisitos funcionais… sendo que na maioria das vezes nem sequer isto ele sabe…

[quote=Fernando Generoso da Rosa]Depois de ler isso tudo de respostas, fico pensando:

Se software é requisitos…
requisitos quem determina é o cliente…nós apenas os levantamos com eles…
Então pq existem programadores??
O software já está com o cliente…

Se isso tiver correto, tenho que pensar urgente em mudar de profissão…

[/quote]

Software existe na forma de codigo criado por programdores.
Programadores criaram o codigo com base em requisitos ( especificados ou não, isso é outra conversa)
Logo, o Software existe devido a requisitos.

Software é requisitos, mas não é apenas requisitos.
A falácia é que estão pensando que o código pode ser criado sem requisitos. Não pode. Isso é uma impossibilidade.
Código faz algo, tem um objetivo. O objetivo é cumprir o requisito.

O programa ( não o codigo) está com o cliente, o que não estão com o cliente é o código executável. Ou seja, ele tem o algoritmo
mas ele não o executa em um computador. Passar o algoritmo do cliente ao código que o computador executa é que significa desenvolver o Software. Programadores não criam software, eles criam código e desenvolvem software. O software já foi criado no momento que o algoritmo existe na cabeça do quem o criou.

Se não deu para entender pense assim : Turing não tinha computadores eletrônicos, os mecânicos eram primitivos e mesmo assim ele lançou as bases do que é um programa , o que é uma máquina, etc… O pessoal da criptografia usava máquinas como as que Turing usava para executar o seus algoritmos. Qual código eles escreviam ? eles tinham um software ?
Nos anos 60 com o computador electro-mecanico programas eram executados pelo computador. Qual era o codigo escrito pelo programador ( existia programador?) ? Existia Software ( aquilo que se xinga mas não se chuta ) ?

[quote=luistiagos]eu entendi mal o comentario do cara… neste ponto vc esta certo…

mas ao certo este tipo de coisa a maioria do cliente sequer sabe… quem tenque levantar este tipo de requisitos somos nos… o cliente apenas “sabe” os requisitos funcionais… sendo que na maioria das vezes nem sequer isto ele sabe… [/quote]

Então vc entende que tem que levantar o requisito e só depois vc pode decidir como implementar o programa. Logo, a implementação depende dos requisitos , funcionais ou não, e eles devem ser conhecidos ANTES de escrever o código. O codigo não é escrito e depois injetamos os requisitos não funcionais. Isso não funciona.

Em lugar algum eu mencionei que os requisitos devem ser levantados depois de codificado… qualquer tipo de requisito funcional ou não deve ser levantado antes de qualquer funcionalidade… requisito como o proprio nome ja diz é uma necessidade para resolver um problema e o codigo e feito para resolução de tal problema implementando nele as necessidades (requisitos)…

mas isto não torna a afirmação: software == requisitos verdadeira…
o certo seria software tem requisitos…

[quote=luistiagos][quote]
O codigo não é escrito e depois injetamos os requisitos não funcionais. Isso não funciona.
[/quote]

Em lugar algum eu mencionei que os requisitos devem ser levantados depois de codificado… qualquer tipo de requisito funcional ou não deve ser levantado antes de qualquer funcionalidade… requisito como o proprio nome ja diz é uma necessidade para resolver um problema e o codigo e feito para resolução de tal problema implementando nele as necessidades (requisitos)…
[/quote]

Vc é a mesma pessoa que escreveu isto:

?

Então , requisitos não-funcionais devem, ou não devem, constar da lista de requisitos ?

primeiro dia:
E falou Marcio Duran após ler os requisitos do usuário haja sistema e houve sistema…
O Marcio Duran viu que o sistema era bom…
E falou Marcio Duran haja sistema de segurança que limite o acesso entre usuários e administrados,
e assim se fez.
E falou Marcio Duran haja banco de dados e distribuições linux de todas especie e forma, e assim se fez…
E falou Marcio e haja as consultorias para subjugar todas as especies criadas.[b]

haraaammmm achamos o culpado…

kkkkkkkkkkkkkkkkkkk

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk.

Muito bom cara.

[quote=edpipole]primeiro dia:
E falou Marcio Duran após ler os requisitos do usuário haja sistema e houve sistema…
O Marcio Duran viu que o sistema era bom…
E falou Marcio Duran haja sistema de segurança que limite o acesso entre usuários e administrados,
e assim se fez.
E falou Marcio Duran haja banco de dados e distribuições linux de todas especie e forma, e assim se fez…
E falou Marcio e haja as consultorias para subjugar todas as especies criadas.

haraaammmm achamos o culpado…

kkkkkkkkkkkkkkkkkkk[/quote]

“A critica é livre para todos,e a contribuição é passa a ser a sua interpretação ao assunto”

Bom, edpipole deve ser uma aquelas espécies rara, que alguma consultoria o contratou…

Estamos em um momento onde muitas pessoas, que estão ocupando seus cargos e especialidades tem sérias dificuldades em entender ou compreender, o que fazem e ou mesmo ser um colaborador em um projeto,(observa eu não disse a palavra programador e coloquei como colaborador).

Software não é Código é Requisito
, isso vem a bater de frente com tudo isso pela sua falta de esclarecimento, onde esse vicio de programador digitador de sistemas, foi apresentado a você durante anos , muitos lhe fornecem todas as soluções mas não lhe dizem como fizeram. Então entra a questão sobre tudo que é antes é requisitado para termos direções necessária à compor esses contratos e interesses dos chamados stakeholders.

:arrow: “E ai, na sua empresa vem esse à ser o seu dia a dia”
“Vai codificando, amanhã eu ligo pro analista de teste, ou eu chamo na proxima semana o analista de sistema e por ai vai …girando…, quando tudo travar, agente diz que é culpa do speed ou da net virtua, e no dia seguinte todos estão demitidos”,

E ai não vai dizer o que eram os fatores criticos ? não houveram requisitos ? mas todos os requisitos foram atingidos, mas nunca se falaram neles… :shock:

Pensar em Software associando diretamente código como núcleo, é nunca ter entendido o que é Software e as razões para que foi desenvolvido.

Se for possível Márcio pode informar apartir de qual literatura você formulou esse teorema? Por que eu não achei nada ainda que podesse comprovar esse seu teorema (digo teorema pela sua insistência, pois acredito que tenha como provar).

ps. mas por favor coloque somente as fontes, nada de um monte de afirmações soutas e sem nexo, SE FOR POSSÍVEL.

[quote=rafaelglauber]…
ps. mas por favor coloque somente as fontes, nada de um monte de afirmações soutas e sem nexo, SE FOR POSSÍVEL.[/quote]
Você ainda acha isso possível? Se tivesse como basear isso sem o monte de coisas jogadas já o teria feito. Depois da resposta altamente educada do MarcioDuran ao meu post pedindo para ele ser coerente pelo menos uma vez, essa é a última vez que posto num tópico dele. Lidar com doido é pior do que lidar com criança.

Até!

[quote=maquiavelbona]
Você ainda acha isso possível? Se tivesse como basear isso sem o monte de coisas jogadas já o teria feito. Depois da resposta altamente educada do MarcioDuran ao meu post pedindo para ele ser coerente pelo menos uma vez, essa é a última vez que posto num tópico dele. Lidar com doido é pior do que lidar com criança.

Até![/quote]

Vamos lá então, então !!!

Segue uma leitura, que considero bem interessante.

Introdução à Engenharia de Software

Por
Ariadne M.B. Rizzoni Carvalho Ph.D Universidade de Reading, e livre Docente pela Unicamp
Thelma C.dos Santos Chiossi Mestre em Ciência da Computação pela USP, Ministra Curso na Unicamp

Na página 22, acho um conceito bem interessante que fala sobre Ecossistema de um inseto, em um conceito figurado, para ser mais didático possivel.

Boa leitura,
Por mim mesmo,
Colaborador
Marcio Costa Duran

Bacharel em Ciência da Computação pela Fasp
Engenheiro de Requisitos
Arquiteto de Informação
email:webfeatures@webfeatures.com.br

setMarcioDuranMode(true);

“A ideia de requisito é concebida dos medos de software de interpretação todos”

:idea: “Software não é Código é Requisito”[/i], a ideia da semana do “analista digitador de stakeholder"[i] é capaz de gerenciar a “gerencia gerenciada [b]do” gerenciamento[/i] gerencial. e que para tanto todavia o código é o "contrato necessário para” a interpretação da direção da prática dos requisitos [b]atendidos pelo codificador, de “analise de teste de contrato”. requisito não é programador “é teste” é necessária a critica do requisito para o "desenvolvimento do vicio do arquiteto.

:arrow: Software não é Código é Requisito[/i], porque o requisito é “software de requisito [i]de um programa” requisitado, isso vem a “bater de[/i] costas com tem” a testa da ilumiosidade esclarecida “onde o vicio do analista” programador interpreta codifica a questão do software “o codigo [i]stakeholder[/u] que” foi é apresentado analisadamente teste "para anos durante um requisito de razão" :shock: . Os contratos analistas “digitam programas para softwares” é, necessaria tomar a "direção [b]de código" para isso[/b] vem a bater de lado com "o teste, o ditador de software"s arquiteta a solução para teve “requisito que não dizem teste” como fizeram. “ou não”

Pensar em Software a razão do software "pensa como um [b]“programa de requisitos.” o pensamento do analista codifica o programa do[/b] software "da razão de teste.

:!: Software não é Código é Requisito Os cogumelos vermelhos analistas "são casa dos verdes duendes, do" requisitos em que o software lucy "in the sky with diamonds." a boa a [i]boa é cor de elefante codigo "cor de rosa.[/i] fumei[i] to doidao "requisito de código não é software "é cogumelo de gnomo. :!:

setMarcioDuranMode(false);

Dá pra notar que o Marcio Duran é ótimo em webdesign. Olhem o site : webfeatures.com.br , segue o padrão dos posts dele! rsrsrs

Ele só fala coisa infundada. Legal é a descrição dele que eu li por ai… Ele diz - Quem sou eu: Filósofo, matemático, inventor, arquiteto, músico, poeta, etc.

HSDHADHhsadhshdHDHAHDhasd…

Se alguém aqui ainda acha que ele fala algo embasado, pode entrar no PINEL junto com ele.

Esse tópico é tão non-sense que só serve pra sacanear mesmo.

kkkkkkkkkkkkkkkkkkkkkk

Site muito bem desenvolvido…

[quote=victorwss]setMarcioDuranMode(true);

“A ideia de requisito é concebida dos medos de software de interpretação todos”

:idea: “Software não é Código é Requisito”[/i], a ideia da semana do “analista digitador de stakeholder"[i] é capaz de gerenciar a “gerencia gerenciada [b]do” gerenciamento[/i] gerencial. e que para tanto todavia o código é o "contrato necessário para” a interpretação da direção da prática dos requisitos [b]atendidos pelo codificador, de “analise de teste de contrato”. requisito não é programador “é teste” é necessária a critica do requisito para o "desenvolvimento do vicio do arquiteto.

:arrow: Software não é Código é Requisito[/i], porque o requisito é “software de requisito [i]de um programa” requisitado, isso vem a “bater de[/i] costas com tem” a testa da ilumiosidade esclarecida “onde o vicio do analista” programador interpreta codifica a questão do software “o codigo [i]stakeholder[/u] que” foi é apresentado analisadamente teste "para anos durante um requisito de razão" :shock: . Os contratos analistas “digitam programas para softwares” é, necessaria tomar a "direção [b]de código" para isso[/b] vem a bater de lado com "o teste, o ditador de software"s arquiteta a solução para teve “requisito que não dizem teste” como fizeram. “ou não”

Pensar em Software a razão do software "pensa como um [b]“programa de requisitos.” o pensamento do analista codifica o programa do[/b] software "da razão de teste.

:!: Software não é Código é Requisito Os cogumelos vermelhos analistas "são casa dos verdes duendes, do" requisitos em que o software lucy "in the sky with diamonds." a boa a [i]boa é cor de elefante codigo "cor de rosa.[/i] fumei[i] to doidao "requisito de código não é software "é cogumelo de gnomo. :!:

setMarcioDuranMode(false);

KKKKKKKKKKKKKKKKKKKKKKK.

A galera do GUJ sabe sempre falar a verdade de um jeito um tanto quanto hilário. Parabéns pela criatividade.

KKKKKKKKKKKKKKKKKKKK

setDuranMode(true);

Ignorante é aquele :wink: :wink: :wink: que não lê Aristóteles. Porque quem não lê não sabe ler leitura assidua de livros e nem de periodicos.

E importante é ler, importante sim eu digo.
:!: :!: :!: :!: :!: :idea: :idea: :idea: :wink: :arrow:

setDuranMode(false);

Quem aqui, assim como eu - acha que o mr. Duran fez um curso de interpretação de textos e fala junto com o Mestre Yoda levanta a mão!!! :thumbup:

eu…

Oq vc eh Duran? Academico? Filosofo? Deixe esse seu modo de falar de lado e seja um pouco descontraido!