Trabalho de Formatura Aluno: André Thomas Kowaltowski
Supervisor (IME): Prof. Siang Wun Song
Responsável (PCA): Sergio Custódio
MAC 499 - Trabalho de Formatura Supervisionado

Parte I - Análise Técnica

Introdução

A PCA foi fundada em 1992, como uma empresa de consultoria em sistemas de informação. Algumas especialidades da empresa incluem redes, servidores de bancos de dados, sistemas operacionais, software para desenvolvimento de aplicações e aplicações propriamente ditas.

Para atender a demanda de clientes, a PCA passou, a partir de 1994, a desenvolver software sob encomenda, sobre as mais diferentes plataformas. Esta constitui o segundo pilar dos negócios da PCA até hoje.

Em 1997, a empresa passa a prestar serviços de suporte a redes, sistemas operacionais e servidores de bancos de dados. Este é o terceiro grupo de negócios da PCA.

Finalmente, a partir de 1998, foi implantado então um servidor de aplicações Internet que fecha o ciclo de prestação de serviços para a solução total de sistemas de informação para seus clientes. Este quarto pilar de serviços permite que o cliente se dedique exclusivamente a suas atividades centrais, deixando para a PCA a responsabilidade integral de planejamento, desenvolvimento, manutenção e operação de seus sistemas de informação.

O Cápere é um sistema integrado de gestão de assinantes (SMS - Subscriber Management System). Desenvolvido de forma modular, ele pode ser customizado para trabalhar com as regras de negócio das mais diversas áreas. Seus principais módulos são o Atendimento, Comercial, Financeiro e Técnico, sendo este último o mais independente e customizado de acordo com o cliente.

Nesta monografia são descritas: a estrutra do sistema Cápere; a forma como este foi desenvolvido; e os conceitos de engenharia de software e arquitetura de sistemas envolvidos neste projeto.

A engenharia de software tem se destacado cada vez mais como base importante para o desenvolvimento de sistemas comerciais. O não uso de metodologias em projetos de software tende a causar atrasos em cronogramas, perda de qualidade no produto final e difícil manutenção.

O desenvolvimento de sistemas com arquitetura mal estruturada leva a dificuldades de obtenção das funcionalidades necessárias e pouca modularidade implicando em manutenção árdua e constante.

A importância dos conceitos de engenharia de software e arquitetura de sistemas se mostrou clara ao longo do desenvolvimento de um sistema de grande porte. Esses tópicos são discutidos nas seções subseqüentes abordando questões teóricas, técnicas e organizacionais.

Conceitos e Tecnologias Estudadas

Ferramentas, Linguagens e Tecnologias

O uso de ferramentas auxiliares (além de um editor e um compilador/interpretador) no desenvolvimento de sistemas está diretamente ligado ao aumento de produtividade e qualidade do produto desenvolvido. Estas propriedades são alcançadas devido à metodologia que as ferramentas "moldam" em torno da execução do projeto. Sem o uso destas, projetos não-triviais costumam quebrar regras de arquitetura (repetição de código e falta de modularidade) e causar atrasos no cronograma de desenvolvimento.

Nos parágrafos a seguir estão descritos os usos de boa parte das ferramentas empregadas no desenvolvimento do Cápere. Os primeiros aplicativos descritos são os mais centrais ao desenvolvimento do projeto (i.e., de mais uso mais freqüente), contudo, algumas das ferramentas de uso esporádico se revelaram de suma importância na qualidade do produto final.

.NET é um framework desenvolvido pela Microsoft para executar aplicações escritas em diferentes linguagens, transparentemente, umas para as outras. Este arcabouço permite que qualquer aplicação seja executada de qualquer lugar do mundo, em qualquer dispositivo. A plataforma .NET, é executada sobre uma CLR (Common Language Runtime - Linguagem Comum de Tempo de Execução) interagindo com uma coleção de bibliotecas unificadas, que juntas são o próprio framework.

A idealização do Cápere como um sistema altamente modular, que pudesse sofrer a troca de módulos e banco de dados, direcionou a etapa de modelagem para a plataforma .NET. Em conjunto com esta escolha também veio o uso do Visual Studio .NET como ambiente de desenvolvimento. Esta segunda escolha é trivial pois é a ferramenta desenvolvida em torno do framework .NET e que claramente já possui todas as funcionalidades necessárias para tal desenvolvimento.

O Cápere foi construído pensando na independência do tipo de banco de dados, i.e., pode ser integrado com qualquer banco de dados amplamente usado no mercado (SQL Server, Oracle, PostgreSQL, MySQl, etc.). Contudo, como o cliente no qual o projeto esteve baseado requisitou o banco de dados SQL Server 2000, foi com as ferramentas deste banco que trabalhamos. Entre elas estão o Enterprise Manager, que faz o gerenciamento do banco de dados, e o Query Analyzer, ferramenta mais leve para execução de consultas e visualização de dados do banco. Para a modelagem do banco de dados utilizamos o ERWIN.

Para controle de versões dos arquivos utilizamos o Visual Source Safe por ser uma ferramenta já integrada ao Visual Studio. O Source Safe possui a funcionalidade de checkout exclusivo, i.e., quando uma pessoa pega o arquivo para edição, as outras podem apenas visualizar a versão do repositório; apenas quando for dado checkin é que outras pessoas podem dar checkout para editar o arquivo. A ferramenta também permite a comparação de versões de arquivos e a visualização de informações administrativas como "quem está com o arquivo exemplo.cs?".

Minha opinião pessoal a respeito do Visual Source Safe é de que as regras de funcionamento (checkout exclusivo) da ferramenta são apropriadas quando se trabalha num ambiente corporativo, com uma equipe com número médio de integrantes (superior a 4 ou 5), em que as tarefas são razoavelmente bem definidas e separadas entre os mesmos. Para ambientes de software livre obviamente esta política é inviável. Para equipes menores esta política é indiferente. Para projetos onde vários integrantes trabalham em cima do mesmo problema talvez não seja interessante este uso.

Apesar de achar a política da ferramenta adequada para o projeto, a robustez do Visual Source Safe é questionável, se não confirmadamente ruim. Devido a isto, poderia se pensar em outro tipo de repositório para projetos de mesma natureza.

Por ser uma ferramenta Web, o Cápere é acessado através do uso de browsers. O Cápere está configurado de forma a funcionar em praticamente todos os browsers padrão do mercado. O funcionamento do sistema foi extensamente testado no Firefox e Internet Explorer. Apesar do funcionamento apresentar algumas diferenças entre os browsers, não há perda de funções ou desconforto.

It's not what you know, it's how fast you can find it out. - John C. Fraraccio
No dia-a-dia de desenvolvimento de um sistema de porte considerável sempre há problemas de implementação, eficiência, layout gráfico, etc. Além da consultoria dos mais experientes no assunto, livros disponíveis e o uso da inteligência para solucionar tais problemas corriqueiros, não há como não citar como fonte de informação os mecanismos de busca de documentação. Por mais trivial que pareça, o Google é utilizado constantemente para busca de soluções, encontrar fóruns de discussão do problema a ser resolvido, trechos de código prontos para a funcionalidade desejada, etc. Por ser desenvolvido na plataforma .NET, durante o desenvolvimento do Cápere também se utilizou muito a documentação disponível no MSDN (Microsoft Developer Network).

Na seção seguinte, veremos como o uso de metodologias é importante para o desenvolvimento de sistemas. O uso de ferramentas que auxiliem nessa metodologia é essencial. Como ferramenta de análise, especificação, modelagem, casos de uso, modelagem inicial de dados e geração de código, utilizamos o Enterprise Architect. O EA, como é popularmente chamado, aumenta a produtividade ao gerar código fonte semi-pronto com as assinaturas dos métodos e parte da documentação. Além de gerar código a partir dos diagramas, ele também atualiza a especificação de acordo com mudanças feitas no código (sentido contrário da geração de código).

Nenhuma linguagem de programação é universal. Cada linguagem tem suas vantagens e desvantagens, sua facilidade de uso, eficiência, forma de uso, plataforma, capacidades, portabilidade, rapidez de aprendizado e quantidade de documentação. Assim, no desenvolvimento de qualquer sistema, é praticamente impossível utilizar uma só linguagem de programação. A arquitetura principal do Cápere foi desenvolvida em C#.NET. Contudo, também se utilizou SQL e T-SQL para as consultas ao banco de dados e processos em batch, XML para a configuração de variáveis de ambiente, montagem de relatórios e externalização de Strings e ASPX, HTML e JavaScript para a criação das páginas e controles do sistema.

Após alguns meses de desenvolvimento, percebeu-se a necessidade do uso de alguns componentes gráficos de interface para o projeto. Havendo várias opções no mercado, optou-se pelo ComponentArt, pacote de componentes de interface Web para o desenvolvimento em .NET. Este pacote contém componentes gráficos para criação de interfaces bonitas, de uso fácil, compatíveis com vários browsers e fáceis de customizar. Dentre os diversos componentes do ComponentArt, no Cápere são usados o Menu, TreeView e TabStrip.

Arquitetura de Sistemas & Engenharia de Software: Conceitos e Aplicações

Durante a faculdade, dificilmente participamos de um projeto de porte suficiente para justificar o uso de metodologias de engenharia de software, modelagem e especificação de arquitetura de sistemas. Apesar do pouco enfoque das disciplinas do curso nestas áreas, alguns aspectos mais teóricos são abordados nas disciplinas de Engenharia de Software, Laboratório de Programação, Programação Orientada a Objetos, Tópicos de Programação Orientada a Objetos e Laboratório de Engenharia de Software. O conhecimento teórico dos conceitos de arquitetura de sistemas e engenharia de software sem dúvida auxilia na hora de aplicar metodologias específicas utilizadas no projeto. Contudo, o grau de profundidade com que se aplicam estas técnicas difere bastante entre a teoria e a prática. Este assunto será abordado com mais detalhamento na segunda parte desta monografia.

Praticamente unânime, a arquitetura em camadas é a tendência que vem evoluindo há cerca de duas décadas no desenvolvimento de sistemas de médio e grande porte. O primeiro passo desta evolução foi a criação do conceito cliente/servidor; nesta arquitetura, se separou a lógica de interface (cliente) da lógica de negócio e dados (servidor), permitindo alterações no servidor independentemente da interface do cliente. O próximo passo da evolução foi a arquitetura em três camadas, removendo os problemas de manutenção da interface devido a alterações da lógica de negócio. Atualmente, as arquiteturas mais utilizadas são as em diversas camadas, freqüentemente com uso de clientes Web based. Isto facilita na manutenção ao permitir alterações centralizadas da interface e não necessita instalação de software nos clientes.

O Cápere foi desenvolvido com uma arquitetura em várias camadas: banco de dados, camada de ferramentas de acesso ao banco de dados, camada de acesso aos dados (DAL - Data Access Layer), camada de lógica de negócio (BL - Business Layer), camada de lógica da interface e camada de interface. Há também uma camada de especificação das entidades de negócio (BE - Business Entities).

O banco de dados utilizado inicialmente foi o SQL Server 2000. Afim de permitir a troca de tipo de banco de dados, foi criada a camada de ferramentas de acesso ao banco de dados. Esta camada generaliza o acesso aos dados, conexões, transações e outras questões de encapsulamento de consultas. A camada que interage totalmente com esta última é o DAL - Data Access Layer. Esta camada é onde são criadas as transações, conexões e consultas ao banco de dados, específicas para cada entidade do negócio.

Logo acima do DAL, vem a BL - Business Layer. Esta camada centraliza a lógica de negócio, regras de funcionamento do sistema como um todo e específicas para cada cliente através de especializações e sobrecargas de métodos.


Figura 1: Arquitetura em Camadas

Um aspecto interessante da camada de lógica de negócio é a presença da chamada de métodos da camada de ferramentas de acesso ao banco de dados. À primeira vista, este comportamento transgride os conceitos de arquitetura em camadas por colocar aspectos de banco de dados na mesma camada da lógica de negócio. Este uso se tornou necessário e justificado à medida em que se definiu que certas operações do sistema, com grau de complexidade elevado, utilizando-se de várias entidades do negócio, precisavam ser executadas de forma atômica. Assim, tornou-se necessária a criação de objetos de transação de negócio: um objeto passado horizontalmente pela camada de negócio entre as entidades envolvidas e verticalmente para a camada de dados para efetuar as consultas/inserções/atualizações/remoções. O uso destes objetos de transação de negócio se mostrou eficiente, fácil de ser utilizado e removeu a preocupação de inconsistência de dados ao atomizar diversas operações complexas do negócio.

Em ASP.NET, a camada de interface é subdividida em duas subcamadas: a camada de lógica da interface e a camada de interface propriamente dita (layout, cores, fontes, etc). Na camada de interface fica o "desenho" da tela com código ASPX/ASCX semelhante a HTML que define a posição dos objetos, cores, fontes e dados a serem mostrados. Na camada de lógica da interface, feita em C#, ficam as definições de comportamento dos objetos da interface: inicialização dos dados, tratamento de eventos e recuperação de dados.

Uma das camadas, que talvez seja mais corretamente denominada como módulo, é a camada de Business Entities (BE). Esta camada não possui nenhuma lógica da dados, negócio ou interface. Ela é "apenas" a definição dos objetos do sistema: define os atributos e seus tipos de cada objeto.

Utilizamos como ferramenta de teste de unidade o NUnit. Esta ferramenta, em conjunto com o módulo/camada denominado NegocioTeste, verifica a criação, pesquisa, atualização e remoção dos objetos do sistema. Este módulo é todo construído em cima da lógica de negócio e por isso está "amarrado" nesta camada.

Para a execução de diversos serviços que o sistema provê, foi criado o módulo denominado NegocioServico. Este módulo contém a lógica de execução de alguns serviços instalados no servidor da aplicação. Entre estes serviços podemos enumerar vários processos de geração de arquivos para a gráfica (demonstrativo, carta de cobrança e ação especial de cobrança), arquivos de débito automático enviados aos bancos, geração de sinal para reprogramação de decoders e tratamento de arquivos de recebimento de bancos.

Cada uma das camadas descritas anteriormente está subdividida de acordo com os módulos do Cápere:

  • Administração/Geral (Cápere)
  • Comercial
  • Técnico
  • Financeiro
  • Atendimento
Além dos módulos secundários:
  • Gerencial (Relatórios)
  • Prospecção (Futuros Clientes)
  • Mediação (Serviços Medidos)
  • Provisionamento

Figura 2: Arquitetura Modular

Esta separação, quase total entre os módulos, permite a manutenção autocontida e substituição de módulos mais facilmente. Para as necessidades de comunicação entre os módulos, foram criadas fachadas para o acesso a algumas funcionalidades de cada módulo. Por exemplo, o módulo técnico, quando efetua uma transferência de endereço, precisa comunicar isto aos módulos comercial e financeiro. Isto é feito através de métodos específicos destes módulos que permitem o acesso aos dados do contrato comercial e contrato financeiro relacionado ao contrato técnico.

Atividades Realizadas

Metodologias Aplicadas no Cápere

Para conseguir criar um produto com uma arquitetura complexa como a descrita anteriormente, foi necessário o uso de metodologias de engenharia de software. Este uso proporcionou a padronização do modo de desenvolvimento, a centralização da especificação e a interação entre os diversos programadores, analistas, coordenadores e o cliente.

A principal ferramenta utilizada com intuito metodológico foi o EA, já descrito anteriormente. Nele foram criados os casos de uso iniciais para acompanhamento do fluxo geral das telas do sistema, a modelagem das tabelas do banco de dados e a modelagem das classes, objetos e métodos do sistema. Esta modelagem economizou boa parte do tempo de implementação ao gerar código-fonte com as assinaturas de métodos e documentação parcialmente preenchida.

Algumas outras metodologias mais "fracas" com relação a tratamento de pendências, divisão de responsabilidades e tarefas foram adotadas ao longo do projeto, porém com menos ênfase. A PCA está investindo atualmente para aprimorar suas metodologias: contratou recentemente alguns especialistas em diversas áreas de metodologia e está disponibilizando treinamentos diversos.

A quantidade de metodologia utilizada no projeto Cápere difere bastante da teoria vista nas disciplinas da área de Engenharia de Software. Contudo, com o investimento atual para aprimorar suas metodologias, a PCA deve atingir em breve, um nível ideal entre a falta e o excesso. A falta de metodologia leva a alguns atrasos de cronograma e dificuldades de manutenção; o excesso leva a mais atrasos e dificuldades de implementação muito fechada.

Uma técnica utilizada no Cápere que pode ser vista em parte como metodologia e em parte como arquitetural, é a validação dos dados. Esta é feita em três níveis: nas camadas de interface há a validação de campos obrigatório e tipagem de dados (que inclui tamanhos); na camada de negócio há, novamente a mesma validação de campos obrigatórios e uma validação de acordo com as regras de negócio; na camada de dados há a validação de campos obrigatórios do banco de dados. Foi adotada como regra não permitir que os dados cheguem ao banco com inconsistências e assim não gerar exceções na camada de dados. As exceções são sempre lançadas pela camada de negócio e tratadas na interface. Na interface a validação é direta e não implica em exceções.

Minhas Responsabilidades e Atividades

Pela filosofia de trabalho da PCA, não há divisão restrita de funções e responsabilidades de trabalho. Eu fui designado para o desenvolvimento do módulo financeiro do sistema junto a um coordenador. Contudo, também trabalhei nas seguintes áreas:

  • endereços
  • ocorrências (sistema de troca de mensagens entre os diversos setores da empresa para notificar problemas detectados através do atendimento a clientes)
  • alertas (sistema de notícias gerais do Cápere)
  • design gráfico da interface do sistema
  • compactação e otimização de tamanho (em kB) das páginas

Destas áreas acima, posso citar meu trabalho no encapsulamento de funcionalidades e design de vários componentes gráficos da interface a fim de agilizar o desenvolvimento e facilitar o uso do sistema (TreeView, TabStrip, Menu). Estes componentes foram aprimorados a partir dos objetos do pacote ComponentArt.

Na figura abaixo temos uma visão geral da arquitetura do módulo financeiro.


Figura 3: Visão Geral do Módulo Financeiro

No módulo financeiro minhas responsabilidades no início do projeto eram mais voltadas para o desenvolvimento. Com o tempo, passei a ajudar na modelagem de dados e objetos do sistema. No período final de desenvolvimento trabalhei bastante em cima dos relatórios:

  • títulos
  • inadimplência
  • aging list
  • provisão de devedores duvidosos
  • maiores devedores
  • devolução de receita
  • maiores dívidas
  • débito automático
  • faturamento

Participei em grande parte do desenvolvimento do módulo financeiro incluindo a maioria das interfaces, regras de negócio e consultas ao banco de dados. Também fiz a análise e versão de auditoria interna do faturamento, além das consultas e diagramação dos relatórios do módulo. Tive participação menor no desenvolimento dos serviços instalados no servidor responsáveis pela geração de arquivos de cobrança para a gráfica e processamento de arquivos de recebimento de bancos.

Após a implantação trabalhei bastante na resolução de problemas de desenvolvimento, correção de inconsistências da importação de dados do sistema anterior, análise de pendências e pedidos de melhoria e agregação de funcionalidades.

Resultados e Produtos Obtidos

O resultado final do projeto é um sistema de gerenciamento de assinantes com controle da área técnica (modular e customizável de acordo com o negócio da empresa), financeira (incluindo faturamento, recebimento, cobrança e parte fiscal), comercial (produtos, pedidos) e atendimento. O sistema possui controle de acesso com permissão separada para cada funcionalidade do sistema em diversos graus de granularidade: desde módulos até botões e campos específicos de páginas. O Cápere é um sistema modular, permitindo a troca de banco de dados, a substituição de módulos (principalmente o técnico) e a customização de regras de negócio de todos os módulos.

Nas figuras abaixo podem ser observadas as diferenças de permissões entre os perfis "Administrador" e "SAC" (Sistema de Atendimento ao Cliente).


Figura 4: Menu de Usuário no Perfil Administrador


Figura 5: Menu de Usuário no Perfil SAC

A implantação em um grande cliente com cerca de 50 mil assinantes ativos demonstrou o sucesso do sistema. A migração de um antigo sistema divido em 3 clusters com dados inconsistentes, interface complicada e díficil manutenção para um banco de dados único, integrado ao Cápere, foi rápido e bem sucedido.

A figura abaixo demonstra a integração de acesso a informações de todos os módulos feita através da página de atendimento.


Figura 6: Atendimento ao Cliente - Integração de Dados de Diversos Módulos

O Cápere é um sistema em constante desenvolvimento. O surgimento de problemas de implementação e inconsistências de dados tem se tornado cada vez menos freqüente. Isto está possibilitando o desenvolvimento de novas funcionalidades para atender todas as necessidades previstas pelo cliente e além. Já há prospecção de diversos novos clientes com necessidades diferentes e com preferência por outros bancos de dados. O sistema continua evoluindo para atender as funcionalidades de qualquer cliente.

Conclusões

Felizmente, nunca tive a oportunidade de trabalhar no desenvolvimento de sistemas de médio ou grande porte sem o uso de uma arquitetura adequada. Talvez a característica mais importante do Cápere é sua arquitetura robusta que possibilitou um desenvolvimento sem grandes traumas, onde foi fácil incorporar requisitos e funcionalidades não previstos na análise inicial e resultou num produto de fácil manutenção corretiva e evolutiva. A arquitetura em múltiplas camadas, modularizada, independente de banco de dados, usando tecnologias de ponta levou a um sistema sólido com alta aceitação pelos usuários do primeiro cliente onde o sistema foi implantado.

O uso de ferramentas de auxílio metodológico como o Enterprise Architect, acelerou o processo de desenvolvimento, customização e implantação do Cápere. A geração automática de código-fonte remove a necessidade do programador de preencher assinaturas de métodos triviais e já cria parte da documentação, forçando os desenvolvedores a preenchê-la.

A principal conclusão que se pode tirar do projeto Cápere é de que é possível desenvolver um sistema de grande porte, modular, customizável, independente de banco de dados e com generalização de regras de negócio. Isto é possível apenas através do uso de boas regras de arquitetura (camadas, módulos) e de metodologias para garantir o desenvolvimento rápido e bem estruturado.

Bibliografia

Parte II - Análise Subjetiva

Desafios e Frustrações do Curso

No Bacharelado em Ciência da Computação do IME-USP, há um foco extremo voltado para a área acadêmica. O enfoque do curso é voltado para as partes do otimização computacional e teoria matemática. Talvez o objetivo do curso seja justamente esse: o de formar profissionais para a área acadêmica sem prepará-los para o mercado. Minha opinião pessoal é de que muitos alunos vão para a área empresarial e se encontram despreparados.

O principal motivo desta despreparação é a falta de enfoque em metodologias e arquitetura de software. Quase não há no curso disciplinas que se preocupem com prazos e cronogramas ou em criar um hábito natural de se programar de forma estruturada com arquiteturas sólidas. Acredito que a falta desses tópicos é mais evidente para quem trabalha na área empresarial onde há muita cobrança de prazos. Contudo, na área acadêmica também deveria se seguir um pouco de metodologias e cumprimento de cronogramas e prazos para não haver atrasos no desenvolvimento.

Talvez a solução ideal para as frustrações do curso sejam a quebra em duas modalidades: uma mais voltada para a pesquisa e outra para o desenvolvimento comercial. Acredito que ambas as modalidades deveriam ter a base sólida que o BCC possui hoje nas áreas mais matemáticas como cálculo, álgebra e álgebra linear além das matérias introdutórias de computação, estrutura de dados, laboratórios de programação, métodos formais, análise de algoritmos, grafos, autômatos, álgebra booleana e métodos numéricos de álgebra linear. Acredito que a disciplina de programação orientada a obejtos deveria ser obrigatória. Como segunda parte do curso, para a modalidade de pesquisa, haveria disciplinas de otimização combinatória, programação linear, etc. Para a outra modalidade haveria um enfoque maior em tópicos de programação orientada a objetos, engenharia de software e alguma disciplina mais voltada para arquitetura.

Apesar de teoricamente ser possível cursar o BCC das duas formas descritas acima nem sempre é possível fazer as disciplinas desejadas devido a conflitos de horário e não-oferecimento. Outra questão é que as disciplinas oferecidas nem sempre têm o enfoque correto por estarem sendo oferecidas para pessoas com interesses variados. Engenharia de software é uma das áreas onde as disciplinas oferecidas são superficiais e praticamente não agregam conhecimento.

Disciplinas Mais Importantes do BCC e Mais Relacionadas Com o Estágio

Como já descrito na seção anterior, algumas das disciplinas do BCC são mais importantes para pessoas que se interessam na área de pesquisa e outras para quem vai para a área de desenvolvimento comercial.

Algumas sugestões com relação a algumas disciplinas do curso:

  • MAT 213 (Álgebra 2) deveria ser dividida em duas disciplinas possibilitando um ritmo um pouco mais lento de ensino para que os alunos possam ter tempo de incorporar o conhecimento e não apenas ver uma quantidade imensa de tópicos num curso com pouco tempo
  • As disciplinas de engenharia de software, laboratórios de programação e programação orientada a objetos deveriam aumentar seu enfoque em cronogramas, metodologias e arquitetura

As disciplinas mais importantes do BCC, na forma como está, são as matérias de base matemática e formação em computação. Dentre elas podemos citar:

  • MAC 110 - Introdução à Computação
  • MAC 122 - Princípios de Desenvolvimento de Algoritmos
  • MAC 211 - Laboratório de Programação
  • MAC 239 - Métodos Formais em Programação
  • MAC 242 - Laboratório de Programação II
  • MAC 300 - Métodos Numéricos de Álgebra Linear
  • MAC 323 - Estruturas de Dados
  • MAC 328 - Algoritmos em Grafos
  • MAC 329 - Álgebra Booleana e Aplicações
  • MAC 338 - Análise de Algoritmos
  • MAC 414 - Linguagens Formais e Autômatos
  • MAC 438 - Programação Concorrente
  • MAC 441 - Programação Orientada a Objetos
Acredito que estas disciplinas, em conjunto com a base matemática e um conjunto de disciplinas com enfoque maior em metodologias, prazos e cronogramas formam um bacharelado ideal em ciência da computação.

Com relação ao estágio, não acho que há um conjunto de disciplinas mais importantes. A base teórica e o conhecimento agregado por todas as disciplinas já citadas é que possibilitou meu sucesso no estágio. Um maior enfoque em metodologias e arquitetura teria sido útil para não ter que aprender na prática estes conceitos.

Relacionamento Com Colegas de Trabalho

O ambiente de trabalho da PCA é descontraído o suficiente para ser acolhedor; e sério o suficiente para ser produtivo e desenvolver produtos e serviços de qualidade. Meu relacionamento com os colegas de trabalho tem sido muito aberto e de fácil acesso. Existe uma liberdade de expressão na empresa que não está escrita como regra mas pode ser sentida. Há total liberdade de abordagem de todos os estagiários e funcionários aos gerentes, diretores e ao presidente. Quase todos na PCA possuem "baias" similares e distribuídas conforme os projetos permitindo a interação maior entre os coordenadores de projetos e os outros integrantes das equipes. As exceções são apenas para os diretores e gerentes que lidam com maior freqüência com clientes ou possuem funções mais independentes: estes possuem salas/baias diferenciadas para acomodar visitas e exercer suas responsabilidades.

O termo PCA Proactive Answers, nome fantasia da empresa, representa bem o ambiente de trabalho. O plano de carreira da PCA é baseado desde o estágio, a contratação CLT até a compra de parte das ações da empresa tornando-se sócio ativo após um período de poucos anos na empresa. Esta filosofia faz com que o dia-a-dia realmente coloque em prática a pró-atividade, através da percepção de qualquer integrante das necessidades e melhorias dos produtos e serviços oferecidos.

A equipe do Cápere, atualmente com cinco integrantes, por onde já passaram outras seis pessoas já chegou a ter dez pessoas ao mesmo tempo. O relacionamento entre todos tem sido produtivo e muito amigável. A hierarquia implícita à coordenação não é imposta de forma ditatorial, apenas como divisão de responsabilidades. Coordenadores executam funções de estagiários e vice-versa sempre que necessário.

A Forma de Trabalho no Estágio e Na Faculdade

A ausência de metodologias no desenvolvimento dos exercícios-programa da faculdade se contrapõe às técnicas utilizadas no trabalho. Acredito que a moderação em metodologia é a ideal e deve se buscar um equilíbrio entre o excesso e a falta. A falta total é a que se encontra na faculdade. Na PCA ainda falta um pouco de metodologia, mas o investimento atual está direcionado a isto. Acredtio que em breve atingirá um patamar ideal. No outro extremo há a teoria de engenharia de software que tenta impor o excesso de metodologias. Minha visão pessoal é de que o excesso de metodologia pode causar atrasos em cronogramas e diminuição na qualidade dos resultados obtidos tão grandes ou maiores quanto a falta de metodologia.

Como já descrito anterioremente, a estrutura hierárquica da PCA é bem horizontal e não implica na delegação indiscriminada de funções. Contudo, as responsabilidades de cada um são claras e determinam o andamento do projeto. Na faculdade, a ausência de coordenação leva a mais conflitos de decisão e cronogramas. Acredito que minha experiência profissional foi de muita sorte numa empresa onde não há atrito hierárquico que gere atrasos e problemas de descisão.

Aplicação Prática de Conceitos Estudados no Curso

Minha filosofia com relação aos estudos universitários é de que o curso não deve ser elaborado para ensinar conceitos que serão utilizados na prática: a universidade não deve ensinar a trabalhar, deve ensinar a pensar. A vasta gama de disciplinas vistas no curso deve mostrar ao aluno diferentes formas de raciocínio que podem ser aplicadas para a resolução de problemas computacionais. Desta forma, acredito que tenho agregado através do curso, várias visões de análise de problemas da área. No estágio, sem dúvida alguma, já utilizei diversas formas de raciocínio para o desenvolvimento, correção e melhoria do sistema sendo desenvolvido. É esta a aplicação prática de conceitos estudados no curso que acredito estar presente e que tem sido útil.

Aprimoramentos Pessoais Futuros

Durante o decorrer do curso e do estágio é que pude perceber minha vocação e gosto para a área de desenvolvimento comercial. Após o término de minha formação universitária pretendo continuar meus estudos através de cursos oferecidos pela PCA de metodologia e arquitetura; cursos de alemão e espanhol; outros cursos e leitura na área de sistemas/gerenciamento e um provável mestrado profissionalizante em área relacionada à gerenciamento de projetos.

André Thomas Kowaltowski - IME/USP - PCA Proactive Answers