[quote=Edufa]@MatHeuZ
Este é o problema, existem dezenas de maneiras de fazer a mesma coisa, algumas mais certas [mais rápidas, seguras, bonitas] do que outras.
Por mais que eu ache errado desenvolver usando cascata hoje em dia, eu acharia ridiculo que uma lei impedisse, da mesma forma que impedisse desenvolvimento ágil.
A mesma coisa acho básico desenvolver com testes, mas terá o que na lei, limite de cobertura ? E se os testes forem criados depois por algum gerador automático, qual a validade ? É a mesma coisa que uma lei dizendo que quadros devem ser pintados com uma proporção de vermelho maior que 53%.
Leis podem ser boas para validar a construção de uma ponte e obrigar a obedecer parametros, mas em software muito disso é subjetivo.
Um mesmo software para um cliente pode ser perfeito e para outro pode ser horrível.
Aí criam um conselho cheio de pessoas que não acreditam em testes unitários [e existem muitas pessoas assim] e aí como fica ? Ou alguem no suposto conselho acha que ponha sua linguagem preferida aqui é inutil, ruim, não oferece segurança, é lenta, etc.
Teremos uma frente de resistencia ao conselho de informática?
Para que complicar, deixa do jeito que está.[/quote]
O foco dos comentários está no desenvolvimento de software e programação (pessoal falando em POG, buffer overflow, …). É fácil distinguir quem tem e quem não tem formação. Analise de sistemas vai muito além de programar, desenvolver e criar site.
Metodologias de analise (cascata, estruturada, OO, incremental, espiral, …), técnicas de documentação modelagem, levantamento de requisitos, design e desenho de solução, gerencia de configuração, gerencia de riscos, gerencia de mudanças, impacto em ambiente e processos, infra-estrutura, topologias de redes (estrela, anel, barramento), teleprocessamento, protocolos e modelo ISO/OSI, 7 camadas, modelagem e simulação, sistemas operacionais, integração, API, barramento (SOA, Vitria), EntireX, midware, internet, ethernet, wi-fi, LAN, WAN, VLAN, virtualização, linguagem compilada, linguagem interpretada, linguagem de script, XML, DTD, cabeamento estruturado, fluxograma, algoritmo, auditoria, log, trilha de auditoria, fluxo de dados, grafico de gantt, segurança (SSH, SSL), active directory, COM, OLE, UML, caso de uso, estados e atividades, workflow, sequencia, MER, DFD, formas normais, infra-estrutura, datacenter, risc, cisc, plataforma micro, mainframe, BBS, memória ROM e RAM … e por aí vai.
Analista de sistemas que se prese, deve conhecer no mínimo tudo isso aí acima (mesmo que só conceitualmente, pq não dá p o cara se especializar em tudo).
Daí vem uns micreiros que aprendem a programar em vídeo no YouTube se dizer analista da sistemas ???
Acho que a regulamentação da profissão não vai definir piso nem restringir o mercado. Vai apenas distinguir o micreiro do analista. O cliente que contrate quem ele quer e pode ($$). Mesmo pq existe um mercado enorme para os micreiros. Mas se não é analista de sistemas, seja ético, honesto e se assuma como micreiro. E se o micreiro é bom mesmo, ele vai se dar bem na faculdade e vai tirar de letra.
Alimentando a comparação: Conheço muito pedreiro bom de serviço e caprichoso, o cara bate uma laje com tanta paciência e dedicação que dá até p/ ficar no concreto aparente. Agora será que esse pedreiro está habilitado para elaborar, planejar, executar, acompanhar e gerenciar toda uma edificação ?? Assim como ocorre com ótimos programadores sem formação que tem no mercado. O cara é bom, cauteloso, dedicado e não faz gambiarra. Mas será que ele está apto a elaborar, planejar, executar, acompanhar e gerenciar todo um projeto (projeto pq não é necessariamente software, pode ser um projeto de infra-estrutura onde deverá ser feito o trabalho desde “passar” cabeamento e fibra ótica até como programar switches e roteadores).