Conforme prometido, segue a palestra de Processos Colaborativos na Engenharia de Sistemas Baseada em Modelos (ESBM), proferida em maio de 2019 na Semana da Engenharia do IFSP/SJC.
Aqui o foco é mais específico, visando um público mais restrito, da área técnica, com enfoque especial para os(as) futuros engenheiros(as) da instituição - e todos docentes interessados no tópico, que trabalharam ou trabalham com o tema apresentado.
Dividi a apresentação em seis tópicos (ver vídeos abaixo). A ideia é transmitir as tendências na área de desenvolvimento de sistemas, e a partir daí explicar o trabalho desenvolvido por mim durante meus anos como estudante de Pós-graduação no INPE. Irei definir e caracterizar brevemente os modelos, para a seguir mostrar dois importantes paradigmas na representação de sistemas físicos (físico e informacional), destacando as diferenças entre ambos em termos de simbologia, fidelidade, simplicidade e resultados de simulação. Tudo isso foi feito no meu Mestrado, que consistiu em comparar as duas abordagens tendo como base um subsistema propulsivo para satélites*.
A segunda parte contextualiza o desenvolvimento colaborativo e seus processos. Irei aqui apenas esboçar a natureza desse tipo de desenvolvimento. Comento sobre o ambiente colaborativo - que viabiliza a implementação de processos colaborativos. Também destaco os requisitos de processo, exemplificando o porquê deles serem especificados durante a construção da cadeia de processo - e antes da execução da mesma.
A definição de requisitos implica em restrições. Essas são definidas pelas ferramentas, objetivos do processo e tipos de conexões. Eles permitem, dito de modo simples, a construção de uma ou mais cadeias de processo de forma orientada. Pode-se inclusive pensar numa hierarquia de funcionalidades e, dentro de uma mesma (funcionalidade), uma sub-hierarquia de eficácia. Tudo isso dependerá do grau de complexidade da rede.
No meu Doutorado estive concentrado em criar uma nova metodologia de interconexão e reuso de ferramentas computacionais, além de implementar uma análise paramétrica automatizada (e remota) de um processo colaborativo.
O que é isso?, alguns podem estar se perguntando.
Bom...tudo que envolve 'análise' pode ser lido como 'estudo'. Se estou analisando algo (ou alguém), há uma série de processos cognitivos acionados responsáveis por estabelecer mensurações, filtragens e classificações para, a partir destas, tomar uma decisão - ou dar uma resposta ao meu chefe.
'Paramétrica' é a junção dos vocábulos 'parâmetro' com 'mensuração'.:
O reuso de ferramentas depende do mapeamento do conjunto. Isso independe da cadeia de processo a ser construída. Para construí-lá (a cadeia) o grupo (conjunto de instituições, grupos, pessoas) deve não apenas se basear em seu sistema, mas num mapa (de ferramentas) que revele as possibilidades de construção. A esse mapa dei o nome de 'diagrama inter-ferramentas dinâmico '.
Por que 'inter-ferramentas'? Porque são várias, e relacionadas direta ou indiretamente entre si.
Por que 'dinâmico'? Porque percebi que ele pode adquirir diferentes configurações. Para isso é preciso compreender os tipos de conexões entre ferramentas existentes.
Segundo Deshmukh et al. (2014), existem sete tipos de relações entre modelos (que eu estendi para ferramentas, um termo mais geral):
I) "Depende de" é uma relação de necessidade. Um modelo depende de outro para ser executado. A inversa seria "é requisito para".
II) "Foi derivado de" é uma relação de criação. Um modelo parte de outro para ser construído. Sua inversa é "é um template para".
III) "É uma extensão de" é uma relação de ampliação. Um modelo tem as mesmas características de outro, além de suas próprias. A inversa é "foi estendido por".
IV) "É uma reimplementação de" é uma relação de identidade funcional. A diferença reside na executabilidade para uma plataforma de simulação distinta. Sua inversa é "foi reimplementada com".
V) "É mais complexo que" é uma relação de aumento de fidelidade em relação a outro. O modelo fornece informações que o outro é incapaz. Sua inversa é "é mais simples que".
VI) "É uma alternativa a" trata de uma relação de semelhança. A função é a mesma que de outro modelo, mas a lógica interna de funcionamento é distinta.
VII) "É compatível a" é uma relação de parceria. O modelo pode ser usado conjuntamente com outro (está adaptado a isso).
As relações são setas bi ou unidirecionais que conectam ferramentas (círculos numerados). A cor do círculo determina sua natureza (ver árvore de classificação). Assim é possível construir um diagrama que relacione todos os modelos que os grupos possuem, formando um mapa completo que dará as possibilidades de arranjos e rearranjos de suas cadeias de processo.
Após essa visão geral entro com o estudo de caso feito.
1. Histórico e tendências
parte 2
parte 3
2. Modelos e paradigmas
parte 1
parte 2
parte 1
parte 2
parte 3
parte 1
parte 2
parte 3
Dividi a apresentação em seis tópicos (ver vídeos abaixo). A ideia é transmitir as tendências na área de desenvolvimento de sistemas, e a partir daí explicar o trabalho desenvolvido por mim durante meus anos como estudante de Pós-graduação no INPE. Irei definir e caracterizar brevemente os modelos, para a seguir mostrar dois importantes paradigmas na representação de sistemas físicos (físico e informacional), destacando as diferenças entre ambos em termos de simbologia, fidelidade, simplicidade e resultados de simulação. Tudo isso foi feito no meu Mestrado, que consistiu em comparar as duas abordagens tendo como base um subsistema propulsivo para satélites*.
A segunda parte contextualiza o desenvolvimento colaborativo e seus processos. Irei aqui apenas esboçar a natureza desse tipo de desenvolvimento. Comento sobre o ambiente colaborativo - que viabiliza a implementação de processos colaborativos. Também destaco os requisitos de processo, exemplificando o porquê deles serem especificados durante a construção da cadeia de processo - e antes da execução da mesma.
A definição de requisitos implica em restrições. Essas são definidas pelas ferramentas, objetivos do processo e tipos de conexões. Eles permitem, dito de modo simples, a construção de uma ou mais cadeias de processo de forma orientada. Pode-se inclusive pensar numa hierarquia de funcionalidades e, dentro de uma mesma (funcionalidade), uma sub-hierarquia de eficácia. Tudo isso dependerá do grau de complexidade da rede.
No meu Doutorado estive concentrado em criar uma nova metodologia de interconexão e reuso de ferramentas computacionais, além de implementar uma análise paramétrica automatizada (e remota) de um processo colaborativo.
O que é isso?, alguns podem estar se perguntando.
Bom...tudo que envolve 'análise' pode ser lido como 'estudo'. Se estou analisando algo (ou alguém), há uma série de processos cognitivos acionados responsáveis por estabelecer mensurações, filtragens e classificações para, a partir destas, tomar uma decisão - ou dar uma resposta ao meu chefe.
'Paramétrica' é a junção dos vocábulos 'parâmetro' com 'mensuração'.:
parâmetro
substantivo masculino
- 1.padrão, regra, princípio etc. por intermédio do qual se estabelece uma relação ou comparação entre termos.
- 2.MATEMÁTICAvariável de caráter secundário cuja finalidade é especificar os objetos de um conjunto ou de uma família [P.ex., na família de planos ax + by + cz + d = o ; a, b, c e d são parâmetros.].
mensuração
substantivo feminino
- ato ou efeito de medir ou mensurar.
- MÚSICAm.q. MENSURA.
Dito de outra forma, 'parâmetros', em engenharia, são atributos de componentes, subsistemas ou sistemas. A massa de um eixo, por exemplo, é um parâmetro. Seu diâmetro. Os diâmetros das seções de um bocal convergente-divergente. A densidade de um combustível (se não variar com a temperatura e pressão). São grandezas que não sofrem variação ao longo do tempo de operação. No entanto, elas mudam (e muito!) ao longo da fase de projeto, em que o sistema ainda está sendo definido.
Mensurar é medir. Logo, uma 'análise paramétrica' é um estudo que visa medir parâmetros - que variam a cada ciclo - com o intuito de observar qual combinação (de parâmetros) é a mais próxima ao ideal para compor definitivamente aquele sistema (ou produto, na linguagem empresarial).
Automatizar esse processo implica em aliviar o trabalho humano, tornando o computador responsável por fazer as variações e coletar ordenadamente os dados, gerando gráficos, tabelas e até mesmo relatórios. É claro que necessário se faz setar como serão essas variações e quantos ciclos serão executados. O humano sempre está no início e no fim dos processos automáticos - cada vez mais próximo às origens e concentrado nos fins.
Ela é feita remotamente porque toda essa rede pode ser executada envolvendo diversos profissionais e grupos situados em locais geográficos distintos. Cada um tem sua ferramenta, instalada em sua máquina, construída a partir de seus modelos analíticos, usando uma linguagem e assumindo hipóteses.
Trata-se sem dúvida de algo que pode aumentar em muito a eficiência do desenvolvimento de sistemas. Em particular, na engenharia. Mas não apenas restrito a esse campo. A diminuição de ciclos (tempo), aliada à maior facilidade em obter um conjunto enorme de dados de forma ordenada (informação) permite decisões mais inteligentes. Há ainda a diminuição do custo: menos ferramentas computacionais são necessárias, o que implica em menos licenças. Os dados são distribuídos / compartilhados na rede. A memória computacional (armazenamento e execução) pode ser menor. Ganha-se agilidade dos elementos e do todo através da integração e interconexão das ferramentas num ambiente (virtual) colaborativo. Mas isso ainda não é tudo: há a questão da possibilidade de reuso.
 |
| O desenvolvimento colaborativo parte do mesmo princípio da organização de uma orquestra. Os músicos são os especialistas. Seus instrumentos, suas teorias, ferramentas e métodos. O maestro, o coordenador (ambiente). As músicas, os arranjos (processos). |
Por que 'inter-ferramentas'? Porque são várias, e relacionadas direta ou indiretamente entre si.
Por que 'dinâmico'? Porque percebi que ele pode adquirir diferentes configurações. Para isso é preciso compreender os tipos de conexões entre ferramentas existentes.
Segundo Deshmukh et al. (2014), existem sete tipos de relações entre modelos (que eu estendi para ferramentas, um termo mais geral):
I) "Depende de" é uma relação de necessidade. Um modelo depende de outro para ser executado. A inversa seria "é requisito para".
II) "Foi derivado de" é uma relação de criação. Um modelo parte de outro para ser construído. Sua inversa é "é um template para".
III) "É uma extensão de" é uma relação de ampliação. Um modelo tem as mesmas características de outro, além de suas próprias. A inversa é "foi estendido por".
IV) "É uma reimplementação de" é uma relação de identidade funcional. A diferença reside na executabilidade para uma plataforma de simulação distinta. Sua inversa é "foi reimplementada com".
V) "É mais complexo que" é uma relação de aumento de fidelidade em relação a outro. O modelo fornece informações que o outro é incapaz. Sua inversa é "é mais simples que".
VI) "É uma alternativa a" trata de uma relação de semelhança. A função é a mesma que de outro modelo, mas a lógica interna de funcionamento é distinta.
VII) "É compatível a" é uma relação de parceria. O modelo pode ser usado conjuntamente com outro (está adaptado a isso).
As relações são setas bi ou unidirecionais que conectam ferramentas (círculos numerados). A cor do círculo determina sua natureza (ver árvore de classificação). Assim é possível construir um diagrama que relacione todos os modelos que os grupos possuem, formando um mapa completo que dará as possibilidades de arranjos e rearranjos de suas cadeias de processo.
Após essa visão geral entro com o estudo de caso feito.
1. Histórico e tendências
parte 1
2. Modelos e paradigmas
3. Desenvolvimento colaborativo
4. Estudo de caso
5. Conclusões
Notas
*trata-se da Plataforma Multi-Missão, PMM, o primeiro inteiramente desenvolvido no Brasil.
Nenhum comentário:
Postar um comentário