OOP
Antes de mais nada, abençoado Kerplunk, desejo que você eternamente faça parte do VBMania.
A OOP é já (e faz tempo) um ponto básico do desenvolvimento de sistemas. Ainda que nem todos os desenvolvedores queiram admitir, o mundo não é mais o mesmo de há dez anos, e nem será o mesmo ano que vem.
Há hoje toda uma [Ô]biosfera[Ô] em torno da OOP, o próprio conceito OOP tem suas derivações, há vários métodos e modelos distintos para aproveitar a OOP.
E essa biosfera evolui diariamente, não dá para fazer de conta que ela não existe.
No entanto, eu continuo entendendo que o ponto nevrálgico é e sempre foi a análise.
Minha ideia é iniciar um pequeno debate sobre...
Estratégia: Análise e Implementação
Quando falamos de desenvolvimento de sistemas, a análise do negócio é o passo mais importante, pois é por meio dele que serão definidas todas as entidades do negócio a ser implementado.
Ocorre que, em muitos casos, o resultado dessa análise se contrapõe ao desempenho, ou leva à uma redundância desnecessária de informações, que podem inclusive se mostrar ineficientes após a implementação.
Por qual razão isso ocorre? Muitas vezes por causa da urgência de resultados, que leva o analista a não perceber alguma estratégia mais ampla, também por uma espécie de sÃndrome do conhecimento automático por parte do cliente, que por imaginar ser notório algum ponto que para ele é básico ou natural, não o informa de forma adequada, e até mesmo por falta de atenção do analista, do cliente ou de ambas as partes.
é possÃvel exemplificar uma falha de visão de estratégia com uma situação bastante comum, onde o objetivo é o desenvolvimento de um sistema de manutenção de clientes e fornecedores, básico e bem simples, sem dados financeiros, fiscais ou tributários, sem produtos nem estoques, apenas algo que possa enviar mensagens de e-mail.
Mas para simplificar ainda mais, nós vamos descartar o fato de que todo cliente involuntariamente oculta informações relevantes, e vamos ainda supor que nosso analista fictÃcio acompanhou pessoalmente, in loco e em detalhes o processo atualmente em uso pelo cliente.
Em um levantamento inicial, ficou acordado que para cadastrar um fornecedor deve-se manter as informações:
• Data de cadastro, no formato dia/mês/ano, com geração automática
• Tipo de pessoa (fÃsica ou jurÃdica, tendo jurÃdica como padrão)
• Data de nascimento ou de abertura da empresa, opcional
• Nome fantasia ou apelido, informação obrigatória, pode se repetir
• Razão social ou nome completo, informação obrigatória, pode se repetir
• Inscrição estadual ou registro geral (RG) , informação obrigatória e que não pode se repetir
• CNPJ ou CPF, informação obrigatória e que não pode se repetir
• E-mail, informação obrigatória e que não pode se repetir
• Endereço Web, seja site, blog, página ou nenhum
• Se o fornecedor está ativo ou não
• Observações gerais, opcional, mas sem limitação de tamanho
• Um endereço, que, pertencendo a uma pessoa fÃsica, pode ser o mesmo para vários fornecedores do mesmo tipo, mas sendo de pessoa jurÃdica, precisa ser exclusivo do fornecedor
• Uma coleção de telefones que, se existirem, devem ser exclusivos do fornecedor
Nesse sistema, os fornecedores recebem pedidos de orçamentos e outras mensagens.
Nesse mesmo levantamento, definiu-se que um cadastro de cliente deverá manter os dados:
• Data de cadastro, no formato dia/mês/ano, com geração automática
• Tipo de pessoa (fÃsica ou jurÃdica, tendo fÃsica como padrão)
• Data de nascimento, opcional, que não deve ser posterior ou igual a 16 anos em relação a data de cadastro
• Nome fantasia ou apelido, obrigatória e que pode se repetir
• Razão social ou nome completo, obrigatória e que pode se repetir
• Inscrição estadual ou registro geral (RG), obrigatória e que não pode se repetir
• CNPJ ou CPF, obrigatória e que não pode se repetir
• E-mail, obrigatória e que não pode se repetir
• Endereço Web, seja site, blog, página ou nenhum
• Se o cliente está ativo ou não
• Observações gerais, não obrigatórias, mas sem limitação de tamanho
• Um endereço, que pode ser o mesmo para vários clientes
• Uma coleção de telefones, os quais, cada um deles pode pertencer a vários clientes, a menos que sejam do tipo celular
Para esse sistema, os clientes receberão mensagens promocionais, avisos em geral e outras mensagens.
Ainda, nesse levantamento, concluiu-se que as seguintes informações são necessárias para o cadastro dos endereços:
• CEP, obrigatório
• UF, obrigatório, com sigla e nome.
• Localidade (MunicÃpio, vila, povoado etc.), obrigatório
• Bairro, obrigatório
• Logradouro (avenida, rua etc.) , obrigatório
• Número (somente numérico, ou “S/N†caso não seja informado um número inteiro)
• Complemento, opcional
• Latitude, preferencialmente automático
• Longitude, preferencialmente automático
• O conjunto CEP, UF, Localidade, Bairro, Logradouro, Número e Complemento não deve se repetir.
Neste sistema, os dados de latitude e longitude dos endereços serão usados pelo aplicativo para mostrar os endereços em um mapa, e inclusive traçar rotas.
E finalizando, se obteve que o cadastro de telefones deve manter as seguintes informações:
• A operadora
• O DDI
• O DDD
• O Número com até 9 dÃgitos numéricos
• Se é fixo ou móvel
• Se tem a finalidade de fax
• Se é comercial
• Se é residencial
• Se é para recados
• O nome de um contato, opcional
Levando em conta esse primeiro levantamento, o analista detectou que existem várias semelhanças entre Fornecedores e Clientes, mas por urgência na entrega, optou por manter o conjunto com as 4 entidades que foram obtidas.
Com isso, um protótipo foi criado, testado e homologado internamente, recebeu um “banho de designâ€, e então foi apresentado ao cliente.
Durante a apresentação, o cliente apresentou algumas dúvidas:
• Onde eu posso ver quais mensagens foram enviadas e quantas delas foram lidas?
• Onde eu vejo quais fornecedores são também clientes?
• Qual opção me permite mostrar no mapa os clientes e fornecedores que farão aniversário nos próximos 5 dias?
Com isso, ficou bastante claro que o trabalho da análise não foi suficientemente bom. Faltou nele a atenção necessária ao conjunto de estratégias de cada entidade, e até mesmo essas entidades se mostraram ineficientes, pois redundam informações que, em uma certa funcionalidade, se houvesse sido desenvolvida, requereria a união de dois conjuntos de informações distintos, o que demanda mais recursos, e assim, apresenta menor desempenho (ou podemos dizer que a estratégia poderia ser otimizada, se as entidades tivessem outra estrutura).
O analista aqui poderia ter suposto que, uma vez que a aplicação teria as funções de envio de mensagens, seriam essas mensagens o núcleo da aplicação. Mas ele, por pressa talvez, se deixou influenciar pela metodologia atual do cliente, que não tem essas funcionalidades: Tudo isso é feito manualmente pelos sócios, com base em fichas cadastrais de clientes e fornecedores de outros aplicativos.
Outro analista pode ter “decifrado†o enigma ao se permitir primeiramente investigar quais eram as estratégias globais da aplicação, e então teria chegado à conclusão de que haviam modelos de dados/armazenamento (Pessoas, Telefones, Endereços e Mensagens) e modelos de visualização/validação (Clientes, Fornecedores, Mensagens e Pontos de Mapa).
Quem comenta o assunto?
A OOP é já (e faz tempo) um ponto básico do desenvolvimento de sistemas. Ainda que nem todos os desenvolvedores queiram admitir, o mundo não é mais o mesmo de há dez anos, e nem será o mesmo ano que vem.
Há hoje toda uma [Ô]biosfera[Ô] em torno da OOP, o próprio conceito OOP tem suas derivações, há vários métodos e modelos distintos para aproveitar a OOP.
E essa biosfera evolui diariamente, não dá para fazer de conta que ela não existe.
No entanto, eu continuo entendendo que o ponto nevrálgico é e sempre foi a análise.
Minha ideia é iniciar um pequeno debate sobre...
Estratégia: Análise e Implementação
Quando falamos de desenvolvimento de sistemas, a análise do negócio é o passo mais importante, pois é por meio dele que serão definidas todas as entidades do negócio a ser implementado.
Ocorre que, em muitos casos, o resultado dessa análise se contrapõe ao desempenho, ou leva à uma redundância desnecessária de informações, que podem inclusive se mostrar ineficientes após a implementação.
Por qual razão isso ocorre? Muitas vezes por causa da urgência de resultados, que leva o analista a não perceber alguma estratégia mais ampla, também por uma espécie de sÃndrome do conhecimento automático por parte do cliente, que por imaginar ser notório algum ponto que para ele é básico ou natural, não o informa de forma adequada, e até mesmo por falta de atenção do analista, do cliente ou de ambas as partes.
é possÃvel exemplificar uma falha de visão de estratégia com uma situação bastante comum, onde o objetivo é o desenvolvimento de um sistema de manutenção de clientes e fornecedores, básico e bem simples, sem dados financeiros, fiscais ou tributários, sem produtos nem estoques, apenas algo que possa enviar mensagens de e-mail.
Mas para simplificar ainda mais, nós vamos descartar o fato de que todo cliente involuntariamente oculta informações relevantes, e vamos ainda supor que nosso analista fictÃcio acompanhou pessoalmente, in loco e em detalhes o processo atualmente em uso pelo cliente.
Em um levantamento inicial, ficou acordado que para cadastrar um fornecedor deve-se manter as informações:
• Data de cadastro, no formato dia/mês/ano, com geração automática
• Tipo de pessoa (fÃsica ou jurÃdica, tendo jurÃdica como padrão)
• Data de nascimento ou de abertura da empresa, opcional
• Nome fantasia ou apelido, informação obrigatória, pode se repetir
• Razão social ou nome completo, informação obrigatória, pode se repetir
• Inscrição estadual ou registro geral (RG) , informação obrigatória e que não pode se repetir
• CNPJ ou CPF, informação obrigatória e que não pode se repetir
• E-mail, informação obrigatória e que não pode se repetir
• Endereço Web, seja site, blog, página ou nenhum
• Se o fornecedor está ativo ou não
• Observações gerais, opcional, mas sem limitação de tamanho
• Um endereço, que, pertencendo a uma pessoa fÃsica, pode ser o mesmo para vários fornecedores do mesmo tipo, mas sendo de pessoa jurÃdica, precisa ser exclusivo do fornecedor
• Uma coleção de telefones que, se existirem, devem ser exclusivos do fornecedor
Nesse sistema, os fornecedores recebem pedidos de orçamentos e outras mensagens.
Nesse mesmo levantamento, definiu-se que um cadastro de cliente deverá manter os dados:
• Data de cadastro, no formato dia/mês/ano, com geração automática
• Tipo de pessoa (fÃsica ou jurÃdica, tendo fÃsica como padrão)
• Data de nascimento, opcional, que não deve ser posterior ou igual a 16 anos em relação a data de cadastro
• Nome fantasia ou apelido, obrigatória e que pode se repetir
• Razão social ou nome completo, obrigatória e que pode se repetir
• Inscrição estadual ou registro geral (RG), obrigatória e que não pode se repetir
• CNPJ ou CPF, obrigatória e que não pode se repetir
• E-mail, obrigatória e que não pode se repetir
• Endereço Web, seja site, blog, página ou nenhum
• Se o cliente está ativo ou não
• Observações gerais, não obrigatórias, mas sem limitação de tamanho
• Um endereço, que pode ser o mesmo para vários clientes
• Uma coleção de telefones, os quais, cada um deles pode pertencer a vários clientes, a menos que sejam do tipo celular
Para esse sistema, os clientes receberão mensagens promocionais, avisos em geral e outras mensagens.
Ainda, nesse levantamento, concluiu-se que as seguintes informações são necessárias para o cadastro dos endereços:
• CEP, obrigatório
• UF, obrigatório, com sigla e nome.
• Localidade (MunicÃpio, vila, povoado etc.), obrigatório
• Bairro, obrigatório
• Logradouro (avenida, rua etc.) , obrigatório
• Número (somente numérico, ou “S/N†caso não seja informado um número inteiro)
• Complemento, opcional
• Latitude, preferencialmente automático
• Longitude, preferencialmente automático
• O conjunto CEP, UF, Localidade, Bairro, Logradouro, Número e Complemento não deve se repetir.
Neste sistema, os dados de latitude e longitude dos endereços serão usados pelo aplicativo para mostrar os endereços em um mapa, e inclusive traçar rotas.
E finalizando, se obteve que o cadastro de telefones deve manter as seguintes informações:
• A operadora
• O DDI
• O DDD
• O Número com até 9 dÃgitos numéricos
• Se é fixo ou móvel
• Se tem a finalidade de fax
• Se é comercial
• Se é residencial
• Se é para recados
• O nome de um contato, opcional
Levando em conta esse primeiro levantamento, o analista detectou que existem várias semelhanças entre Fornecedores e Clientes, mas por urgência na entrega, optou por manter o conjunto com as 4 entidades que foram obtidas.
Com isso, um protótipo foi criado, testado e homologado internamente, recebeu um “banho de designâ€, e então foi apresentado ao cliente.
Durante a apresentação, o cliente apresentou algumas dúvidas:
• Onde eu posso ver quais mensagens foram enviadas e quantas delas foram lidas?
• Onde eu vejo quais fornecedores são também clientes?
• Qual opção me permite mostrar no mapa os clientes e fornecedores que farão aniversário nos próximos 5 dias?
Com isso, ficou bastante claro que o trabalho da análise não foi suficientemente bom. Faltou nele a atenção necessária ao conjunto de estratégias de cada entidade, e até mesmo essas entidades se mostraram ineficientes, pois redundam informações que, em uma certa funcionalidade, se houvesse sido desenvolvida, requereria a união de dois conjuntos de informações distintos, o que demanda mais recursos, e assim, apresenta menor desempenho (ou podemos dizer que a estratégia poderia ser otimizada, se as entidades tivessem outra estrutura).
O analista aqui poderia ter suposto que, uma vez que a aplicação teria as funções de envio de mensagens, seriam essas mensagens o núcleo da aplicação. Mas ele, por pressa talvez, se deixou influenciar pela metodologia atual do cliente, que não tem essas funcionalidades: Tudo isso é feito manualmente pelos sócios, com base em fichas cadastrais de clientes e fornecedores de outros aplicativos.
Outro analista pode ter “decifrado†o enigma ao se permitir primeiramente investigar quais eram as estratégias globais da aplicação, e então teria chegado à conclusão de que haviam modelos de dados/armazenamento (Pessoas, Telefones, Endereços e Mensagens) e modelos de visualização/validação (Clientes, Fornecedores, Mensagens e Pontos de Mapa).
Quem comenta o assunto?
Posso comentar! rsrsrsr.
Fiz análise de sistemas. Um dos meus professores de [Ô]análise de sistemas orientada a objetos[Ô] era bem arrogante! Era um cavalo pra falar a verdade! Mas em muitos momentos não pude deixar de concordar com suas idéias.
Pra começar, a primeira coisa que se deve fazer antes de programar como você com todos os méritos comentou, é fazer a análise. Mas o que vem antes da análise??? Existe um profissional que considero muito importante pra área de desenvolvimento, e que uma empresa grande não pode deixar de ter. Ele pode não entender nada de programação, mas seu conhecimento sobre qualquer regra de negócio torna-o fundamental. é uma espécie de ponte entre o cliente e o analista. Este profissional é o consultor. Este sim irá conversar com o cliente. Vai ver com ele o que ele quer, e até ajudar o cliente a decidir o que quer! porque nem sempre eles sabem o que quer! Quando o consultor colhe as insformações necessárias, leva elas ao analista, depois ele criará um diagrama de caso de uso. Este diagrama é a única coisa que o consultor precisa entender. Depois ele leva esse diagrama novamente ao cliente, aonde o mesmo decidirá ou não se é isto mesmo de que ele precisa. Se a resposta for positiva, é feito então um contrato que o cliente deverá ler e assinar. Neste contrato terá que ser especificado as datas de prazo necessárias. E estas datas quem define é a empresa que desenvolve, não o cliente. Se a empresa tem capacidade de fazer mais rápido ou não, vai depender dela mesma.
Depois de assinado o contrato, o analista fará os diagramas de classe e entidade relacionamento do banco. AÃ que finalmente passa para o desenvolvimento.
Não sei se esses procedimentos são respeitados por todas as empresas de desenvolvimento, Mas se isso não acontecer pode dar uma dor de cabeça tremenda. Eu mesmo faço projetos pequenos pra pequenas empresas e mesmo assim tenho dificuldades em [Ô]tentar adivinhar o que eles querem[Ô]. Por mais que faça uma entrevista e coloque tudo no papel, eles sempre deixam alguma coisa escapar! E como eu nem sempre entendo as regras de negócio deles... rsrsrsrs
Se eu fosse um consultor eu seria pago pra ficar uma semana na empresa contratante pra entender mais ainda a forma como eles trabalham.
E o contrato assinado é uma excelente forma de se proteger de futuros pepinos! pois caso tenha ficado alguma coisa pra trás por parte do cliente, a empresa contratada lavaria as mãos! pois se ele assinou é porque ele concordou e autorizou o desenvolvimento! rsrsrs
No fim das contas, a culpa não seria da parte de desenvolvimento, porque eles fizeram o que o analista projetou. Nem do analista, porque o cliente autorizou! E o consultor também não teria culpa no cartório! Pois ele fez o que tinha que ser feito!
Não sei mais se fujà do assunto! kkkkkk
Só sei que numa empresa de desenvolvimento grande, entre ser analista e desenvolvedor, ainda prefiro ser desenvolvedor! kkkkkkk
Fiz análise de sistemas. Um dos meus professores de [Ô]análise de sistemas orientada a objetos[Ô] era bem arrogante! Era um cavalo pra falar a verdade! Mas em muitos momentos não pude deixar de concordar com suas idéias.
Pra começar, a primeira coisa que se deve fazer antes de programar como você com todos os méritos comentou, é fazer a análise. Mas o que vem antes da análise??? Existe um profissional que considero muito importante pra área de desenvolvimento, e que uma empresa grande não pode deixar de ter. Ele pode não entender nada de programação, mas seu conhecimento sobre qualquer regra de negócio torna-o fundamental. é uma espécie de ponte entre o cliente e o analista. Este profissional é o consultor. Este sim irá conversar com o cliente. Vai ver com ele o que ele quer, e até ajudar o cliente a decidir o que quer! porque nem sempre eles sabem o que quer! Quando o consultor colhe as insformações necessárias, leva elas ao analista, depois ele criará um diagrama de caso de uso. Este diagrama é a única coisa que o consultor precisa entender. Depois ele leva esse diagrama novamente ao cliente, aonde o mesmo decidirá ou não se é isto mesmo de que ele precisa. Se a resposta for positiva, é feito então um contrato que o cliente deverá ler e assinar. Neste contrato terá que ser especificado as datas de prazo necessárias. E estas datas quem define é a empresa que desenvolve, não o cliente. Se a empresa tem capacidade de fazer mais rápido ou não, vai depender dela mesma.
Depois de assinado o contrato, o analista fará os diagramas de classe e entidade relacionamento do banco. AÃ que finalmente passa para o desenvolvimento.
Não sei se esses procedimentos são respeitados por todas as empresas de desenvolvimento, Mas se isso não acontecer pode dar uma dor de cabeça tremenda. Eu mesmo faço projetos pequenos pra pequenas empresas e mesmo assim tenho dificuldades em [Ô]tentar adivinhar o que eles querem[Ô]. Por mais que faça uma entrevista e coloque tudo no papel, eles sempre deixam alguma coisa escapar! E como eu nem sempre entendo as regras de negócio deles... rsrsrsrs
Se eu fosse um consultor eu seria pago pra ficar uma semana na empresa contratante pra entender mais ainda a forma como eles trabalham.
E o contrato assinado é uma excelente forma de se proteger de futuros pepinos! pois caso tenha ficado alguma coisa pra trás por parte do cliente, a empresa contratada lavaria as mãos! pois se ele assinou é porque ele concordou e autorizou o desenvolvimento! rsrsrs
No fim das contas, a culpa não seria da parte de desenvolvimento, porque eles fizeram o que o analista projetou. Nem do analista, porque o cliente autorizou! E o consultor também não teria culpa no cartório! Pois ele fez o que tinha que ser feito!
Não sei mais se fujà do assunto! kkkkkk
Só sei que numa empresa de desenvolvimento grande, entre ser analista e desenvolvedor, ainda prefiro ser desenvolvedor! kkkkkkk
ACCIOLLY, agradeço seu comentário!
Bom, ACCIOLLY, sem discordar nem desmerecer, mas acredito que o que você coloca está um pouco mais para comportamento de mercado do que para metodologia ou conhecimento.
Nesse aspecto, claro, seria um paraÃso se todas as empresas de desenvolvimento de software tivessem de adotar um quadro bem escalonado de profissionais, mas aqui no Brasil não é nem em sonho viável financeiramente, em muito por conta da excelente qualidade do ensino da nossa Pátria Educadora, da tributação extorsiva, e em parte também por um ranço do coronelismo de 40/50 que ainda subsiste em muitos meios empresariais.
E mesmo em outros paÃses, acredito que a demanda ainda não amadureceu o suficiente e ainda não está preocupada com qualidade, mas apenas com prazos e preços (o que aliás explicaria o analista do exemplo inicial).
Ainda assim, o está bem claro de que a tendência é que sistemas com destino desktop sejam considerados cada vez mais obsoletos. Já são. E mesmo aplicações web, mais adiante, o serão.
O principal destino são os dispositivos portáteis, o que abrange uma gama de população muito maior. A Web será com o tempo um grande provedor de informações, via serviços, e em algum dia de um futuro bem mais próximo do que se espera, após você pagar sua fatura de serviços de internet por um aplicativo de sua TV ou de sua geladeira, vai voltar a sua reunião de negócios no mesmo dispositivo.
Para os desenvolvedores e empresas de desenvolvimento isso é bom, pois amplia e muito seu mercado potencial e consequentemente, a fonte de renda.
O problema é que quando esses aplicativos não são bem formulados, também podem dar prejuÃzo de milhões ou bilhões, não só ao mercado demandador mas também a equipe de desenvolvimento.
Para cair um pouco no óbvio, não fiz isso antes, seria interessante que cada um que ler esse tópico reservasse um pouco de seu tempo tentando resolver o problema proposto, sem postar nada, exceto talvez suas crÃticas, mas apenas para usar a pele do analista do exemplo, ou seja, sentir na carne e então refletir sobre o papel que hoje desempenha.
Bom, ACCIOLLY, sem discordar nem desmerecer, mas acredito que o que você coloca está um pouco mais para comportamento de mercado do que para metodologia ou conhecimento.
Nesse aspecto, claro, seria um paraÃso se todas as empresas de desenvolvimento de software tivessem de adotar um quadro bem escalonado de profissionais, mas aqui no Brasil não é nem em sonho viável financeiramente, em muito por conta da excelente qualidade do ensino da nossa Pátria Educadora, da tributação extorsiva, e em parte também por um ranço do coronelismo de 40/50 que ainda subsiste em muitos meios empresariais.
E mesmo em outros paÃses, acredito que a demanda ainda não amadureceu o suficiente e ainda não está preocupada com qualidade, mas apenas com prazos e preços (o que aliás explicaria o analista do exemplo inicial).
Ainda assim, o está bem claro de que a tendência é que sistemas com destino desktop sejam considerados cada vez mais obsoletos. Já são. E mesmo aplicações web, mais adiante, o serão.
O principal destino são os dispositivos portáteis, o que abrange uma gama de população muito maior. A Web será com o tempo um grande provedor de informações, via serviços, e em algum dia de um futuro bem mais próximo do que se espera, após você pagar sua fatura de serviços de internet por um aplicativo de sua TV ou de sua geladeira, vai voltar a sua reunião de negócios no mesmo dispositivo.
Para os desenvolvedores e empresas de desenvolvimento isso é bom, pois amplia e muito seu mercado potencial e consequentemente, a fonte de renda.
O problema é que quando esses aplicativos não são bem formulados, também podem dar prejuÃzo de milhões ou bilhões, não só ao mercado demandador mas também a equipe de desenvolvimento.
Para cair um pouco no óbvio, não fiz isso antes, seria interessante que cada um que ler esse tópico reservasse um pouco de seu tempo tentando resolver o problema proposto, sem postar nada, exceto talvez suas crÃticas, mas apenas para usar a pele do analista do exemplo, ou seja, sentir na carne e então refletir sobre o papel que hoje desempenha.
Colega ACCIOLLY,
Também sou Analista de Sistemas, da turma de 1994.
Versaste sobre o consultor. Também acho importante, mas com relação à esta parte...
Estais te referindo à sÃncrese? Esta parte, se é que bem entendi teu texto, também seria do Analista (sÃncrese / análise / sÃntese), sendo que no estágio final adentra a figura do programador. Mas não sei se te entendi direito. Também há que se considerar que nestes 21 para 22 anos de formação o comportamento mudou muito, e técnicas também, embora a Análise Essencial de Sistemas ainda esteja imutada.
Tudo de bom.
Também sou Analista de Sistemas, da turma de 1994.
Versaste sobre o consultor. Também acho importante, mas com relação à esta parte...
Citação:Quando o consultor colhe as insformações necessárias, leva elas ao analista, depois ele criará um diagrama de caso de uso...
Estais te referindo à sÃncrese? Esta parte, se é que bem entendi teu texto, também seria do Analista (sÃncrese / análise / sÃntese), sendo que no estágio final adentra a figura do programador. Mas não sei se te entendi direito. Também há que se considerar que nestes 21 para 22 anos de formação o comportamento mudou muito, e técnicas também, embora a Análise Essencial de Sistemas ainda esteja imutada.
Tudo de bom.
Citação:Estais te referindo à sÃncrese?
Cara me desculpe, mas é a primeira vez que vejo essa palavra! rsrsrs. Mas ao que me referi o consultor pode sim fazer essa parte que também pode ser desempenhada sem problemas pelo analista. Veja as atribuições deste cargo:
Atende os clientes com dificuldades a serem supridas no sistema, durante a implantação. Mapeia os processos das funcionalidades do sistema ERP, adequando as necessidades do cliente durante o projeto. Identifica melhorias nos processos e direciona as regras de negócios do cliente, ao processo padrão existe no sistema ERP. Mantém o cliente informado sobre o andamento do cronograma do projeto, bem como suas visitas presenciais. Ao longo do projeto repassa as documentações das fases do projeto a equipe de suporte técnico e desenvolvimento. Elabora documentos, realiza levantamentos de atividades e dos acompanhamento dos prazos dos projetos junto a equipe. Fonte: http://www.catho.com.br/profissoes/consultor-de-sistemas/
Mas como nosso colega PROFESSOR bem colocou, estamos no Brasil! Seria excelente se todas as empresas se comportassem dessa forma. Só pra você ter uma idéia só conheco pessoalmente uma empresa que contrata consultores, e acredite ou não, esta empresa paga melhor os consultores do que os programadores!
PROFESSOR
Me desculpe por ter fujido tanto do assunto! kkkkk fiquei empolgado! Mas aproveitando esse embalo acho que os sistemas web não ficarão tão pra trás dos móveis, se os mesmos forem responsivos.
Quanto a sua exemplificação do analista, quero comentar uma linha chave
Citação:Onde eu vejo quais fornecedores são também clientes?
Então, se esse analista não estivesse tão pressionado pelo tempo proposto pelo cliente, perceberia que entre fornecedor e cliente existiria uma terceira entidade chamada pessoa. Sei o quanto é difÃcil desempenhar esse papel de analista, por mais que nunca o tenha, mas estudei e isso foi o suficiente pra sentir na pele! rsrsrsrs (TCC é fogo!). E por isso que falei e repito: Entre analista e desenvolvedor, prefiro a segunda opção! Talvez por questão de ter mais experiência nisso!
Obrigado PROFESSOR! Pretendo sim ficar por aqui um bom tempo e nas palavras de um velho (nem tão) sábio: Você vão ter que me engolir!
OOP é de extrema importância, isso é FATO e não está aberto à discussão. Ela pode(e deve) ser aplicada à todas as suas aplicações, por menores que sejam. Quanto à análise, este é o calcanhar de aquiles de muitos profissionais de TI. Simplesmente por não entenderem bem do negócio do cliente e tentarem [Ô]informatizar[Ô] tudo. Informatizar no sentido de [Ô]traduzir[Ô] para um sistema, o dia a dia do cliente. Sem levar em conta, que o cliente, na esmagadora maioria das vezes, ou não sabe o que quer, ou não sabe explicar ou simplesmente os dois. Vamos à um caso real de algo que aconteceu comigo e gerou um stress gigantesco para mim:
Na empresa que trabalhava, havia um [Ô]chefe[Ô]. Um cara bacana e eficiente, mas que em matéria de TI estava atrasado no mÃnimo uns 20 anos. Era do tipo que quando se falava [Ô]XML[Ô], ele imaginava na hora um arquivo. Ele é quem fazia a análise para os sistemas novos. Bem, acontece que um desses novos projetos, era algo de complexidade moderada. Basicamente uma integração entre cliente/chamados de manutenção e técnicos. Na prática, o cliente postava um chamado de manutenção à um determinado equipamento de alta confidencialidade(um caixa eletrônico, no caso) e o chamado era processado para que escolhesse o técnico com os critérios de: Proximidade, habilitação de manutenção no modelo do equipamento chamado, agenda prévia do técnico e alguns outros fatores de menor importância. Pois bem. o design para isso apesar de parecer, não é tão simples assim. O cliente faz o chamado passando o número de identificação serial do equipamento. Com isso, poderia-se designar a localização da instalação fÃsica do equipamento. Em seguida, fazer uma verificação dos técnicos e determinar os mais próximos, pois chamados desse tipo de equipamento, possuem uma SLA(basicamente um tempo de resposta, determinado em contrato, que não pode ser inferior à X minutos). Pois bem, determinando os técnicos próximos, deve-se filtrar quais deles são habilitados para o equipamento informado. Em seguida, verificar a agenda prévia do técnico(outros chamados de manutenção na [Ô]fila[Ô] do técnico) para determinar qual o que poderia atender o chamado mais rapidamente, levando em conta a localização fÃsica do técnico. Pois nem sempre o mais próximo é o que vai estar liberado mais rapidamente. Com essas informações, determinamos o técnico capacitado que atenderá mais rapidamente o chamado e adicionamos o chamado de manutenção na [Ô]fila[Ô] do técnico. Essa [Ô]fila[Ô], deve ser consultada no celular do técnico, que fica ligado à uma impressora portátil que imprime o [Ô]recibo[Ô] do chamado. Em suma, o técnico, termina o chamado e consulta se possui outros. Então pega o próximo chamado da fila e aperta um botão na aplicação no celular, o que informa ao servidor que o técnico está ciente e à caminho do chamado. Isso já [Ô]mata[Ô] o tempo da SLA e o cliente pode consultar em um site o andamento do chamado, o técnico atribuÃdo, o tempo estimado de chegada, de manutenção e localização fÃsica do técnico, enquanto o status do chamado for [Ô]Técnico à caminho[Ô]. Quando o técnico chega ao local, ele aciona outro botão no celular, mudando o status para [Ô]In loco[Ô], esperando o cliente conduzir o técnico ao local de segurança onde se encontra o caixa eletrônico. Isso pode demorar bastante à s vezes, já vi casos do técnico esperar 4 horas para isso. A pressa é do cliente, afinal ele paga por isso. Quando o técnico enfim começava o conserto, ele acionava novamente um botão no aplicativo, mudando o status do chamado novamente, dessa vez para [Ô]em manutenção[Ô]. Ele tinha um tempo para avaliação e de acordo com a avaliação, clicava em outro botão, dizendo se o equipamento poderia ser consertado no local ou se a remoção era necessária. Seja qual fosse a conclusão do técnico, novamente era pressionado um botão no aplicativo dizendo o que deveria ser feito. Ufa! Como eu disse, complexidade moderada.
Como foi pensando pelo nosso [Ô]analista[Ô]:
O programa do técnico, deveria informar ao servidor à cada 10 segundos, a localização fÃsica de acordo com coordenadas GPS ou AGPS e status da aplicação no celular. Ou seja, pensou como um usuário pensaria que funciona esse tipo de coisa. Ele pensou que esse era o único jeito de termos dados em tempo real sobre a localização do técnico e status do chamado. MAS NÃO é. é justamente ao contrário. Quando alguém consultasse o chamado que o server envia mensagens aos clients(celulares dos técnicos), [Ô]perguntando[Ô] sua localização e o status do chamado é o que estiver NO SERVER, que é informado pelo técnico conforme a etapa de atendimento que ele está.
Foi implementado como pensado pelo analista, mesmo com fervorosos protestos de minha parte, explicando de antemão os problemas à seguir...
O resultado:
Os planos de dados dos celulares eram os [Ô]TOP[Ô], os mais caros, na base de R$ 500,00 mensais, mas as franquias de dados, se esgotavam na metade do mês para a maioria dos técnicos, fazendo-se necessário a [Ô]compra[Ô] de pacotes de dados extras quase que diariamente. No fim das contas, a conta para cada técnico era na base de R$ 1.800,00 ao mês. Eram 700 técnicos então faça as contas e chegará a conclusão que só de telefonia, estava sendo gasto mais de um milhão e duzentos mil reais por mês no total. Nota: 700 técnicos somente na capital paulista, não contando o resto do Brasil todo.
A aplicação do celular do técnico, [Ô]matava[Ô] o processador inteiro, pois à cada 10 segundos, havia uma task que consultava a posição GPS ou AGPS quando GPS não estava disponÃvel e com isso, a bateria do celular também não durava mais que 2 horas. Logo, era um parto o técnico conseguir simplesmente clicar no botão da aplicação, isso quando o celular não resetava do nada pois estava com o processador [Ô]no talo[Ô]. Com isso, chegaram à conclusão que deveriam comprar celulares [Ô]mais TOP[Ô] para os técnicos, do Brasil todo, logo, mais uns 5 milhões. Como os clients(celulares) estavam sendo sempre usados [Ô]no talo[Ô] muitas vezes acontecia de o servidor não conseguir enviar a mensagem de Push para ele, informando de um novo chamado designado para o técnico correspondente. Isso comprometia em muito a SLA, cuja a multa era MUITO salgada para a empresa e um certo número de ocorrências, poderia acarretar uma segunda multa por [Ô]reincidência[Ô] e até mesmo recisão de contrato para que outro fosse necessário ser assinado. Os valores disso não sei, pois esse tipo de informação era ALTAMENTE sigilosa, mas conversas de corredor, davam conta que giravam na casa dos 9 dÃgitos.
Não preciso dizer que o projeto não durou muito, pois simplesmente não funcionava como deveria. Simplesmente por uma péssima análise de alguém não capacitado, que gerou stress por parte de várias equipes, incluindo as dos técnicos que eram [Ô]advertidos[Ô] quando suas metas de atendimento não eram cumpridas, simplesmente por esse [Ô]elefante branco[Ô] não funcionar.
Como deveria ser feito: Mensagens push. Quando um chamado era gerado, aà sim os celulares eram [Ô]acionados[Ô] para informarem posição fÃsica e nada mais. Todo o resto, como qual o chamado sendo atendido no momento e quantos outros haviam na fila, já é conhecido no server, não precisando ser informado. Quando o cliente quisesse saber a posição fÃsica do técnico e previsão de chegada, então novamente o celular era [Ô]invocado[Ô] para informar. Sendo usado somente quando necessário. Sempre respeitando o design mais básico de aplicações distribuÃdas: O formato Client->Server.
No fim das contas, vários técnicos demitidos(pois concluÃram que eles eram os [Ô]culpados[Ô]), vários contratos quebrados, prejuÃzo no atendimento de manutenções(que deveria ser um dos setores mais lucrativos da empresa), muitos cabelos brancos novos em todo mundo, seis meses perdidos entre desenvolvimento e implementação de algo que está errado. E TUDO ISSO, por conta de alguém estar no lugar errado.
Ah, sem falar em outros problemas MUITO sérios que nem posso contar aqui, em público.
Sumarizando, programar direitinho com boas práticas, incluindo OOP é essencial, mas a análise também deve ter seu papel bem feito.
OOP é de extrema importância, isso é FATO e não está aberto à discussão. Ela pode(e deve) ser aplicada à todas as suas aplicações, por menores que sejam. Quanto à análise, este é o calcanhar de aquiles de muitos profissionais de TI. Simplesmente por não entenderem bem do negócio do cliente e tentarem [Ô]informatizar[Ô] tudo. Informatizar no sentido de [Ô]traduzir[Ô] para um sistema, o dia a dia do cliente. Sem levar em conta, que o cliente, na esmagadora maioria das vezes, ou não sabe o que quer, ou não sabe explicar ou simplesmente os dois. Vamos à um caso real de algo que aconteceu comigo e gerou um stress gigantesco para mim:
Na empresa que trabalhava, havia um [Ô]chefe[Ô]. Um cara bacana e eficiente, mas que em matéria de TI estava atrasado no mÃnimo uns 20 anos. Era do tipo que quando se falava [Ô]XML[Ô], ele imaginava na hora um arquivo. Ele é quem fazia a análise para os sistemas novos. Bem, acontece que um desses novos projetos, era algo de complexidade moderada. Basicamente uma integração entre cliente/chamados de manutenção e técnicos. Na prática, o cliente postava um chamado de manutenção à um determinado equipamento de alta confidencialidade(um caixa eletrônico, no caso) e o chamado era processado para que escolhesse o técnico com os critérios de: Proximidade, habilitação de manutenção no modelo do equipamento chamado, agenda prévia do técnico e alguns outros fatores de menor importância. Pois bem. o design para isso apesar de parecer, não é tão simples assim. O cliente faz o chamado passando o número de identificação serial do equipamento. Com isso, poderia-se designar a localização da instalação fÃsica do equipamento. Em seguida, fazer uma verificação dos técnicos e determinar os mais próximos, pois chamados desse tipo de equipamento, possuem uma SLA(basicamente um tempo de resposta, determinado em contrato, que não pode ser inferior à X minutos). Pois bem, determinando os técnicos próximos, deve-se filtrar quais deles são habilitados para o equipamento informado. Em seguida, verificar a agenda prévia do técnico(outros chamados de manutenção na [Ô]fila[Ô] do técnico) para determinar qual o que poderia atender o chamado mais rapidamente, levando em conta a localização fÃsica do técnico. Pois nem sempre o mais próximo é o que vai estar liberado mais rapidamente. Com essas informações, determinamos o técnico capacitado que atenderá mais rapidamente o chamado e adicionamos o chamado de manutenção na [Ô]fila[Ô] do técnico. Essa [Ô]fila[Ô], deve ser consultada no celular do técnico, que fica ligado à uma impressora portátil que imprime o [Ô]recibo[Ô] do chamado. Em suma, o técnico, termina o chamado e consulta se possui outros. Então pega o próximo chamado da fila e aperta um botão na aplicação no celular, o que informa ao servidor que o técnico está ciente e à caminho do chamado. Isso já [Ô]mata[Ô] o tempo da SLA e o cliente pode consultar em um site o andamento do chamado, o técnico atribuÃdo, o tempo estimado de chegada, de manutenção e localização fÃsica do técnico, enquanto o status do chamado for [Ô]Técnico à caminho[Ô]. Quando o técnico chega ao local, ele aciona outro botão no celular, mudando o status para [Ô]In loco[Ô], esperando o cliente conduzir o técnico ao local de segurança onde se encontra o caixa eletrônico. Isso pode demorar bastante à s vezes, já vi casos do técnico esperar 4 horas para isso. A pressa é do cliente, afinal ele paga por isso. Quando o técnico enfim começava o conserto, ele acionava novamente um botão no aplicativo, mudando o status do chamado novamente, dessa vez para [Ô]em manutenção[Ô]. Ele tinha um tempo para avaliação e de acordo com a avaliação, clicava em outro botão, dizendo se o equipamento poderia ser consertado no local ou se a remoção era necessária. Seja qual fosse a conclusão do técnico, novamente era pressionado um botão no aplicativo dizendo o que deveria ser feito. Ufa! Como eu disse, complexidade moderada.
Como foi pensando pelo nosso [Ô]analista[Ô]:
O programa do técnico, deveria informar ao servidor à cada 10 segundos, a localização fÃsica de acordo com coordenadas GPS ou AGPS e status da aplicação no celular. Ou seja, pensou como um usuário pensaria que funciona esse tipo de coisa. Ele pensou que esse era o único jeito de termos dados em tempo real sobre a localização do técnico e status do chamado. MAS NÃO é. é justamente ao contrário. Quando alguém consultasse o chamado que o server envia mensagens aos clients(celulares dos técnicos), [Ô]perguntando[Ô] sua localização e o status do chamado é o que estiver NO SERVER, que é informado pelo técnico conforme a etapa de atendimento que ele está.
Foi implementado como pensado pelo analista, mesmo com fervorosos protestos de minha parte, explicando de antemão os problemas à seguir...
O resultado:
Os planos de dados dos celulares eram os [Ô]TOP[Ô], os mais caros, na base de R$ 500,00 mensais, mas as franquias de dados, se esgotavam na metade do mês para a maioria dos técnicos, fazendo-se necessário a [Ô]compra[Ô] de pacotes de dados extras quase que diariamente. No fim das contas, a conta para cada técnico era na base de R$ 1.800,00 ao mês. Eram 700 técnicos então faça as contas e chegará a conclusão que só de telefonia, estava sendo gasto mais de um milhão e duzentos mil reais por mês no total. Nota: 700 técnicos somente na capital paulista, não contando o resto do Brasil todo.
A aplicação do celular do técnico, [Ô]matava[Ô] o processador inteiro, pois à cada 10 segundos, havia uma task que consultava a posição GPS ou AGPS quando GPS não estava disponÃvel e com isso, a bateria do celular também não durava mais que 2 horas. Logo, era um parto o técnico conseguir simplesmente clicar no botão da aplicação, isso quando o celular não resetava do nada pois estava com o processador [Ô]no talo[Ô]. Com isso, chegaram à conclusão que deveriam comprar celulares [Ô]mais TOP[Ô] para os técnicos, do Brasil todo, logo, mais uns 5 milhões. Como os clients(celulares) estavam sendo sempre usados [Ô]no talo[Ô] muitas vezes acontecia de o servidor não conseguir enviar a mensagem de Push para ele, informando de um novo chamado designado para o técnico correspondente. Isso comprometia em muito a SLA, cuja a multa era MUITO salgada para a empresa e um certo número de ocorrências, poderia acarretar uma segunda multa por [Ô]reincidência[Ô] e até mesmo recisão de contrato para que outro fosse necessário ser assinado. Os valores disso não sei, pois esse tipo de informação era ALTAMENTE sigilosa, mas conversas de corredor, davam conta que giravam na casa dos 9 dÃgitos.
Não preciso dizer que o projeto não durou muito, pois simplesmente não funcionava como deveria. Simplesmente por uma péssima análise de alguém não capacitado, que gerou stress por parte de várias equipes, incluindo as dos técnicos que eram [Ô]advertidos[Ô] quando suas metas de atendimento não eram cumpridas, simplesmente por esse [Ô]elefante branco[Ô] não funcionar.
Como deveria ser feito: Mensagens push. Quando um chamado era gerado, aà sim os celulares eram [Ô]acionados[Ô] para informarem posição fÃsica e nada mais. Todo o resto, como qual o chamado sendo atendido no momento e quantos outros haviam na fila, já é conhecido no server, não precisando ser informado. Quando o cliente quisesse saber a posição fÃsica do técnico e previsão de chegada, então novamente o celular era [Ô]invocado[Ô] para informar. Sendo usado somente quando necessário. Sempre respeitando o design mais básico de aplicações distribuÃdas: O formato Client->Server.
No fim das contas, vários técnicos demitidos(pois concluÃram que eles eram os [Ô]culpados[Ô]), vários contratos quebrados, prejuÃzo no atendimento de manutenções(que deveria ser um dos setores mais lucrativos da empresa), muitos cabelos brancos novos em todo mundo, seis meses perdidos entre desenvolvimento e implementação de algo que está errado. E TUDO ISSO, por conta de alguém estar no lugar errado.
Ah, sem falar em outros problemas MUITO sérios que nem posso contar aqui, em público.
Sumarizando, programar direitinho com boas práticas, incluindo OOP é essencial, mas a análise também deve ter seu papel bem feito.
Colega ACCIOLLY
São as fases da Análise de Sistemas. A sÃncrese é parte onde se ouve a argumentação dos interessados, desde o motivo pelo qual acreditam precisar de um sistema até o levantamento e encadernação dos (cópias) documentos utilizados no sistema atual.
Note-se que eu me referi a sistema atual porque, ainda que não exista um sistema informatizado, pode haver um sistema manual, por exemplo. A definição clássica de sistema é [Ô]todo conjunto de 3 ou mais elementos em que, a cada momento, ao menos 2 se comunicam[Ô]. Pode ser um sistema não informatizado, por exemplo, o SUS (Sistema Único de Saúde) ou o [Ô]sistema[Ô] tão falado no meio polÃtico para se referir ao real funcionamento da sociedade.
O Analista de Sistemas, latu senso, não trabalha com informática, trabalha com sistemas.
Contudo,nosso colega PROFESSOR precisa de outras informações que não estas. é que uma coisa levou a outra, na tentativa de ajudar eu fiz um questionamento para saber sobre o que exatamente eu iria/deveria tentar ajudar e, creio, acabei desvirtuando o motivo dos posts. Desculpe, PROFESSOR. Não voltará a acontecer.
Tudo de bom.
Citação:Citação:
Estais te referindo à sÃncrese?
Cara me desculpe, mas é a primeira vez que vejo essa palavra! rsrsrs
São as fases da Análise de Sistemas. A sÃncrese é parte onde se ouve a argumentação dos interessados, desde o motivo pelo qual acreditam precisar de um sistema até o levantamento e encadernação dos (cópias) documentos utilizados no sistema atual.
Note-se que eu me referi a sistema atual porque, ainda que não exista um sistema informatizado, pode haver um sistema manual, por exemplo. A definição clássica de sistema é [Ô]todo conjunto de 3 ou mais elementos em que, a cada momento, ao menos 2 se comunicam[Ô]. Pode ser um sistema não informatizado, por exemplo, o SUS (Sistema Único de Saúde) ou o [Ô]sistema[Ô] tão falado no meio polÃtico para se referir ao real funcionamento da sociedade.
O Analista de Sistemas, latu senso, não trabalha com informática, trabalha com sistemas.
Contudo,nosso colega PROFESSOR precisa de outras informações que não estas. é que uma coisa levou a outra, na tentativa de ajudar eu fiz um questionamento para saber sobre o que exatamente eu iria/deveria tentar ajudar e, creio, acabei desvirtuando o motivo dos posts. Desculpe, PROFESSOR. Não voltará a acontecer.
Tudo de bom.
Sinclair, infelizmente não posso aceitar suas desculpas. Não posso por não serem cabÃveis.
Aliás, agradeço sua participação oportuna. é precisamente essa definição da análise de sistemas que o profissional precisaria ter ao teorizar o sistema, e não a visão do consultor de T.I., que no meu exemplo acabou por cometer alguma gafe. Sinto apenas certa reserva quando usa o SUS como exemplo de sistema funcional, mas é outro assunto...
Kerplunk, é sempre um deleite contar com a sua participação, e desta vez, com direito a uma panorâmica do dia á dia!
Acciolly, sem essa de se desculpar. seja pelo que for, a idéia é agregar para debater.
Mas com o pouco que temos até aqui, aparentemente se está começando a delinear uma carência do mercado em geral. E isso é muito importante, pois não adianta usar antibiótico sem saber qual é a bactéria.
Aliás, agradeço sua participação oportuna. é precisamente essa definição da análise de sistemas que o profissional precisaria ter ao teorizar o sistema, e não a visão do consultor de T.I., que no meu exemplo acabou por cometer alguma gafe. Sinto apenas certa reserva quando usa o SUS como exemplo de sistema funcional, mas é outro assunto...
Kerplunk, é sempre um deleite contar com a sua participação, e desta vez, com direito a uma panorâmica do dia á dia!
Acciolly, sem essa de se desculpar. seja pelo que for, a idéia é agregar para debater.
Mas com o pouco que temos até aqui, aparentemente se está começando a delinear uma carência do mercado em geral. E isso é muito importante, pois não adianta usar antibiótico sem saber qual é a bactéria.
Colega PROFESSOR,
Obrigado pela compreensão!
Quanto a sua colocação:
é exatamente ai onde entra a sÃncrese, que comentei com o colega ACCIOLLY. SÃncrese é isto mesmo: in loco, fazer a ouvidoria e levantamento da parte documental, sendo que esta última visa não apenas a encadernação dos processos, mas também apurar as (como falaste) involuntárias ocultações de informações.
Quanto a sua colocação, na última mensagem:
Eis que ai entra o desvirtuamento da profissão, não regulamentada e exercida por profissionais de outras áreas, incluindo profissionais de Ciências Humanas (creia, meu amigo, conheço uma Assistente Social que resolveu ser Analista de Sistemas em uma grande indústria da região... o resultado vou até me abster de mencionar).
Quanto a esta outra, meu colega PROFESSOR:
Posso dizer que o SUS é, de fato, um sistema. Só que mal planejado. E voltamos à questão de ter um sistema sem apoio de um analista, considerando que por décadas foram economistas ministros da saúde e médicos ministros da fazenda.
Tudo de bom.
Obrigado pela compreensão!
Quanto a sua colocação:
Citação:Mas para simplificar ainda mais, nós vamos descartar o fato de que todo cliente involuntariamente oculta informações relevantes, e vamos ainda supor que nosso analista fictÃcio acompanhou pessoalmente, in loco e em detalhes o processo atualmente em uso pelo cliente
é exatamente ai onde entra a sÃncrese, que comentei com o colega ACCIOLLY. SÃncrese é isto mesmo: in loco, fazer a ouvidoria e levantamento da parte documental, sendo que esta última visa não apenas a encadernação dos processos, mas também apurar as (como falaste) involuntárias ocultações de informações.
Quanto a sua colocação, na última mensagem:
Citação:
é precisamente essa definição da análise de sistemas que o profissional precisaria ter ao teorizar o sistema, e não a visão do consultor de T.I.
Eis que ai entra o desvirtuamento da profissão, não regulamentada e exercida por profissionais de outras áreas, incluindo profissionais de Ciências Humanas (creia, meu amigo, conheço uma Assistente Social que resolveu ser Analista de Sistemas em uma grande indústria da região... o resultado vou até me abster de mencionar).
Quanto a esta outra, meu colega PROFESSOR:
Citação:Sinto apenas certa reserva quando usa o SUS como exemplo de sistema funcional, mas é outro assunto...
Posso dizer que o SUS é, de fato, um sistema. Só que mal planejado. E voltamos à questão de ter um sistema sem apoio de um analista, considerando que por décadas foram economistas ministros da saúde e médicos ministros da fazenda.
Tudo de bom.
é .... eu vou fazer papel de assistente ..... só vou assistir .... kkkkkk
Quero aprender com os gigantes do VBMania ...
Quero aprender com os gigantes do VBMania ...
Colega EPISCOPAL,
Estamos todos aprendendo, colega. Parabéns pela humildade. Só o vaidoso acha que tudo já sabe, não estuda e, sem estudo, fica para trás.
Colega PROFESSOR,
Seu texto:
De fato, colega. Uma empresa precisar desenvolver um sistema e não contar com o analista de sistemas, é como uma construtora ir direto para obra de engenharia sem passar pela arquitetura. Aliás, cabe dizer, o termo [Ô]Análise de Sistemas[Ô] está gradualmente em desuso, sendo substituÃdo por [Ô]Arquitetura de Software[Ô].
Ai é onde mora e reside o erro crasso. Sem a Análise de Sistemas, o máximo que se vai conseguir é informatizar o problema... mas continuará sendo um problema.
Vem então (depois da sÃncrese) a parte que evita a [Ô]informatização de problemas[Ô], que é a análise propriamente dita (sÃncrese / análise / sÃntese). é neste ponto do projeto que os erros devem ser extirpados, mudando o estado atual da técnica para o estado ideal da técnica, termos corriqueiros na Análise Essencial de Sistemas.
O Analista de Sistemas não vai se preocupar com formato do arquivo, seja XML ou TXT, se dados armazenados em Oracle ou mesmo uma aberração técnica, como usar o Bloco de Notas como SGBD. Isto não é desta fase de análise, isto é depois, na sÃntese. O que o Analista de Sistemas define é o fluxo da informação. Cabe à fase da sÃntese fazer com que o fluxo seja o mais rápido possÃvel, desde que não prejudique o próprio fluxo, prevalecendo e sendo preferÃvel a lentidão controlada aos erros (mais vale lento e certo do que rápido e errado).
A Análise de Sistemas é antiga. Lato sensu, não está diretamente relacionada com informatização, mas dado que sistemas informatizados também são sistemas, cabe a figura do Analista de Sistemas, que ficou conhecido como [Ô]o cara que mexe nas coisas de informática[Ô]. Antiga e todos praticam diariamente, mesmo sem saber. Um telefonema, por exemplo, tem um fluxo lógico de informações, portanto, é um sistema. Mas é um sistema simples, tão simples que ninguém, por menor instrução que tenha, vai falar antes de digitar o número da pessoa interlocutora (invertendo a ordem do fluxo).
Só que... na prática, meu colega PROFESSOR, é como dizes: a pressa atrapalha tudo. Não há tempo para planejar e vamos logo [Ô]ponhando[Ô]* a mão na massa (massa esta que depois desanda).
* (sim, já ouvi isto de cliente, que queria informatizar o seu negócio como se fosse preencher um ficha cadastral e, por lógico, não entende e até não aceita que há toda uma ciência a ser posta em prática).
Editando o tópico para um complemento:
Colega PROFESSOR narrou:
Pois bem: é exatamente disto que falei, ou seja, o analista informatizou o problema. E o estado atual da técnica permaneceu o mesmo, só mudou de ambiente manual para computadorizado.
Tudo de bom.
Estamos todos aprendendo, colega. Parabéns pela humildade. Só o vaidoso acha que tudo já sabe, não estuda e, sem estudo, fica para trás.
Colega PROFESSOR,
Seu texto:
Citação:Quando falamos de desenvolvimento de sistemas, a análise do negócio é o passo mais importante, pois é por meio dele que serão definidas todas as entidades do negócio a ser implementado.
De fato, colega. Uma empresa precisar desenvolver um sistema e não contar com o analista de sistemas, é como uma construtora ir direto para obra de engenharia sem passar pela arquitetura. Aliás, cabe dizer, o termo [Ô]Análise de Sistemas[Ô] está gradualmente em desuso, sendo substituÃdo por [Ô]Arquitetura de Software[Ô].
Citação:Por qual razão isso ocorre? Muitas vezes por causa da urgência de resultados, que leva o analista a não perceber alguma estratégia mais ampla, também por uma espécie de sÃndrome do conhecimento automático por parte do cliente, que por imaginar ser notório algum ponto que para ele é básico ou natural, não o informa de forma adequada, e até mesmo por falta de atenção do analista, do cliente ou de ambas as partes.
Ai é onde mora e reside o erro crasso. Sem a Análise de Sistemas, o máximo que se vai conseguir é informatizar o problema... mas continuará sendo um problema.
Vem então (depois da sÃncrese) a parte que evita a [Ô]informatização de problemas[Ô], que é a análise propriamente dita (sÃncrese / análise / sÃntese). é neste ponto do projeto que os erros devem ser extirpados, mudando o estado atual da técnica para o estado ideal da técnica, termos corriqueiros na Análise Essencial de Sistemas.
O Analista de Sistemas não vai se preocupar com formato do arquivo, seja XML ou TXT, se dados armazenados em Oracle ou mesmo uma aberração técnica, como usar o Bloco de Notas como SGBD. Isto não é desta fase de análise, isto é depois, na sÃntese. O que o Analista de Sistemas define é o fluxo da informação. Cabe à fase da sÃntese fazer com que o fluxo seja o mais rápido possÃvel, desde que não prejudique o próprio fluxo, prevalecendo e sendo preferÃvel a lentidão controlada aos erros (mais vale lento e certo do que rápido e errado).
A Análise de Sistemas é antiga. Lato sensu, não está diretamente relacionada com informatização, mas dado que sistemas informatizados também são sistemas, cabe a figura do Analista de Sistemas, que ficou conhecido como [Ô]o cara que mexe nas coisas de informática[Ô]. Antiga e todos praticam diariamente, mesmo sem saber. Um telefonema, por exemplo, tem um fluxo lógico de informações, portanto, é um sistema. Mas é um sistema simples, tão simples que ninguém, por menor instrução que tenha, vai falar antes de digitar o número da pessoa interlocutora (invertendo a ordem do fluxo).
Só que... na prática, meu colega PROFESSOR, é como dizes: a pressa atrapalha tudo. Não há tempo para planejar e vamos logo [Ô]ponhando[Ô]* a mão na massa (massa esta que depois desanda).
* (sim, já ouvi isto de cliente, que queria informatizar o seu negócio como se fosse preencher um ficha cadastral e, por lógico, não entende e até não aceita que há toda uma ciência a ser posta em prática).
Editando o tópico para um complemento:
Colega PROFESSOR narrou:
Citação:se deixou influenciar pela metodologia atual do cliente, que não tem essas funcionalidades: Tudo isso é feito manualmente pelos sócios, com base em fichas cadastrais de clientes e fornecedores de outros aplicativos.
Pois bem: é exatamente disto que falei, ou seja, o analista informatizou o problema. E o estado atual da técnica permaneceu o mesmo, só mudou de ambiente manual para computadorizado.
Tudo de bom.
Tópico encerrado , respostas não são mais permitidas