Apresentação Executiva

1.491 visualizações

Publicada em

Apresentação Executiva.

Publicada em: Tecnologia, Educação
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.491
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
22
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Video – Poder da Visão.
  • Apresentação Executiva

    1. 1. Apresentação Executiva Justino Diretor Comercial
    2. 2. Timeline • 2002 – Início do desenvolvimento • 2003 – Lançamento da versão 1.0 • 2003 – Aporte BNDES – 1.2 Milhões de Reais • 2003 – Lançamento da versão 1.5 • 2005 – Lançamento da versão 3.0 • 2007 – Lançamento da versão 5.0 • 2007 – MPS.BR Nível F com metodologia Scrum • 2009 – Lançamento da versão 5.5 • 2010 – MPS.BR Nível C com metodologia Scrum • 2010 – Lançamento versão “6.0 Preview” • 2010 – Aporte BNDES – 2.4 Milhões de Reais
    3. 3. O jCompany em números • Um framework estável com 7 anos de mercado. • Atualizado tecnologicamente (Up-to-Date). • Em 7 anos, mais de 26 lançamentos de versões e releases. • Mais de 1.500 subscrições. • Mais de 200 clientes corporativos e órgãos públicos. • Mais de 1.100 projetos em produção. • Mais de 180.000 Pontos de Função desenvolvidos. • 3.421 profissionais treinados. • 111 profissionais certificados. • 54.736 horas de treinamento já realizados. • 164.208 horas de mentorias já realizadas.
    4. 4. O Futuro • Investimento para 2011/2012 de 3,4 Milhões de Reais • 2,4 Milhões Prosoft – BNDES. • 1 Milhão em recursos próprios. • Java EE 6 (2010) • Suporte às novas APIs Java EE 6: CDI 1.0, JAX-RS 1.1, JAX-WS 2.1, Bean Validation 1.0, JSF 2.0 (Facelets incluído) e JPA 2.0. • Web 2.0 (2011) • Arquitetura MVP com uso do SOFEA/SOUI. • HTML5.
    5. 5. Presença Nacional • Rede de canais altamente especializada, dentro de um rigoroso processo de certificação e capacitação. • Presente em 80% das capitais brasileiras. • Presente em 23 estados brasileiros. • Fábricas de software homologadas e certificadas em todas as regiões do país. • Padrão de desenvolvimento Java EE nos Estados de Minas Gerais, Espírito Santo e Rondônia.
    6. 6. Presença no Judiciário • Tribunal de Justiça do Rio Grande do Sul • Tribunal de Justiça de Rondônia • Ministério Público de Rondônia • Ministério Público de Minas Gerais • Tribunal de Contas do Piauí • Tribunal de Contas do Maranhão • Tribunal Regional Eleitoral do Maranhão • Justiça Federal de Santa Catarina • Tribunal Superior do Trabalho • 24 Tribunais Regionais do Trabalho • IPRAJ
    7. 7. Presença – Setor Público • BNDES • Prodemge • Prodabel • Prodaub • Prodest • Seplan de Rondônia • Marinha do Brasil • Capes • BHtrans • Cepel • Ipsemg • CBMES • CEFET • CEPEL • CETEM • Dataci • DER-MG • HSE-RJ • IPM • Jucemg • Prefeitura Municipal da Serra • Sefaz-AL
    8. 8. Presença – Setor Privado • Drogaria Araujo • Tacom • Datapuc • Pague Menos • Qualicorp • Sal Cisne • Santana Têxtil • Têxtil Bezerra de Menezes • Carol • Edusoft • Fundação Sidertube • Cenibra • Grupo Multi • Hermes Pardini • J.Macêdo • JP Industria Farmacêutica • Magnesita • Medisoft • Mestra • MicroUniverso • Nortel • Softplan • Unimed Maceió • Command Perfect
    9. 9. O negócio da sua organização é desenvolver framework de integração Java EE?
    10. 10. O Nosso Negócio é • Equipes distintas em cada etapa do processo. • Gerência de P&D - Equipe dedicada e especializada com mais de 20 engenheiros de software para a realização de pesquisa e desenvolvimento em Java EE. • Gerência de Mentoria - Equipe especializada formada por profissionais da empresa e por profissionais certificados de parceiros para a realização de treinamento e mentoria de alto nível. • Gerência de Suporte - Equipe dedicada de suporte de 1° e 2° níveis. • Gerência de Pré-vendas – Equipe responsável pelo apoio comercial, realizações de apresentações, prova de conceito e projeto piloto.
    11. 11. • Equipes distintas em cada etapa do processo. • Gerência de P&D - Equipe dedicada e especializada com mais de 30 engenheiros de software para a realização de pesquisa e desenvolvimento em Java EE. • Gerência de Mentoria - Equipe especializada formada por profissionais da empresa e por profissionais certificados de parceiros para a realização de treinamento e mentoria de alto nível. • Gerencia de Suporte - Equipe de suporte de 1° e 2° níveis dedicada. • Gerencia de Pré-vendas – Equipe responsável pelo apoio comercial, realizações de apresentações, prova de conceito e projeto piloto. O Nosso Negócio é
    12. 12. Por que ter uma arquitetura ou framework de integração em Java EE?
    13. 13. • Uma arquitetura ou framework de integração é importante para garantir um padrão de desenvolvimento e aumentar a produtividade. • Seria praticamente impossível o desenvolvimento de projetos em Java sem utilizar as bibliotecas (frameworks) de base; a produtividade seria próxima a zero. • Felizmente nos últimos anos surgiram várias iniciativas e, sem dúvida, o movimento de Software Livre e a Internet tiveram um papel importantíssimo. • Há várias iniciativas acadêmicas, autônomas e empresariais. • A grande questão é como trazer estas iniciativas para o mundo corporativo.
    14. 14. Desenvolver um framework integrador interno é a melhor opção?
    15. 15. Antes de Começar, Responda: • Qual o conhecimento real da equipe? • Quantos da equipe já desenvolveram ou participaram do desenvolvimento de um framework que teve projetos em produção? Há quanto tempo? • Por quanto tempo os profissionais mais qualificados estarão envolvidos neste trabalho? • O orçamento deste projeto contempla todos os custos de P&D, testes, homologação, desenvolvimento, documentação, treinamento, consultoria externa, repasse de conhecimento para equipe? • Quantos projetos de negócio da empresa deixarão de ser feitos durante este período? • E se o arquiteto líder sair deste projeto?
    16. 16. Se todas as respostas foram satisfatórias, quais os passos para se desenvolver um framework interno?
    17. 17. Passos para Framework Interno • Definir a arquitetura: MVC? MVP (SOFEA)? Other? • Requisitos não funcionais • Compatibilidade entre browsers • Compatibilidade entre servidores de aplicação • Portabilidade de Banco de Dados • Segurança das aplicações a serem desenvolvidas • Performance e capacidade de escalar para projetos corporativos • O que deve ser generalizado para incluir no framework, evitando redundância de código dos desenvolvedores? • Como garantir um padrão de codificação evitando possíveis problemas pelo nivelamento de conhecimento da equipe?
    18. 18. Passos para Framework Interno • Qual o framework de base (agnóstico) será usado: • Spring x jBoss Seam x GWT x Weld x Struts x ADF x Struts 2. • Esta escolha normalmente é feita tomando como base a experiência pessoal dos arquitetos. • Que outros frameworks serão usados para complementar a arquitetura, tais como: • Visão: RichFaces x Myface x Trinidad x Tomahawk... • Leiaute: Tiles x Facelets. • Persistência: Hibernate, JPA (e/ou EJB3), iBatis?. • Outras para: Buid & Deploy, Teste unitário, SOA, BPM, repositório, integração contínua, JavaScript, validação, relatórios, gráficos, Ajax, CSS, XHTML, etc.
    19. 19. Passos para Framework Interno • Desenhar a arquitetura integrada • Desenvolver e integrar os diversos frameworks de base • Congelar uma linha de base das tecnologias • Desenvolver um projeto piloto para validar • Qual o tamanho ideal do projeto piloto? • Como validar a segurança e performance? • A arquitetura ficou robusta para sustentar os aplicativos? Quais os seus limites? • Quais os requisitos de hardware? • Desenvolver a documentação (parte chata que nenhum arquiteto gosta) • Desenvolver material de treinamento para equipe
    20. 20. Passos para Framework Interno • A equipe interna não possui experiência; contrata-se uma consultoria externa. Ótimo, para a consultoria externa. • Em quais etapas do processo a consultoria irá atuar? • Na definição da arquitetura, na implementação, na documentação, no projeto piloto, no material de treinamento, no suporte, no repasse para toda a equipe, na atualização e evolução do ambiente? Por quanto tempo? • Normalmente o consultor envia um excelente/experiente arquiteto que apóia a equipe interna no desenvolvimento da arquitetura e sua implementação básica. O restante das atividades, quando feitas, são responsabilidade da empresa. • A consultoria conclui o trabalho e vai embora fazer o mesmo trabalho em outra empresa, sem repassar ganhos de escala.
    21. 21. Passos para Framework Interno • Ufa! Acabou a primeira versão. Hora de medir. • Qual o resultado estratégico ou de negócio alcançado ao se concluir o framework interno? • Quanto tempo levou? • Quanto efetivamente custou? • Durante este período, todos os frameworks de base tiveram versões novas, novas tecnologias. O que fazer? • Como se trata de um framework interno, quem irá dar apoio ou suportar? E se apresentar um erro em produção com suspeita de ser no framework interno? • Seguramente, se usou uma consultoria externa, o arquiteto que apoiou este trabalho estará envolvido em outra empresa.
    22. 22. A organização possui um framework interno
    23. 23. Quanto Custa Manter e Evoluir? • Meça o nível de gestão da sua arquitetura: • Qual a versão do framerwork interno? Existe apenas uma ou uma salada de versões é fornecida? • Quanto efetivamente custou o seu desenvolvimento? • Quanto vai custar para mantê-lo/atualizá-lo? • Qual o seu nível de documentação? • Qual o nível de dependência das pessoas que a desenvolveram? • Se a corporação não tem boas respostas para as perguntas acima, é sinal de que algo não vai bem.
    24. 24. A minha organização não se preocupa com uma Arquitetura e contrata fábrica de software
    25. 25. Fábrica de Software • Se os sistemas fossem produtos descartáveis a preocupação na manutenção evolutiva e adaptativa não seria importante. • Os sistemas são ativos da organização, desenvolvidos para serem capazes de evoluírem e mudarem segundo as necessidades da organização. • Sem uma arquitetura própria a organização que contrata fábrica de software fica refém do fornecedor e, o que é pior, em muitos casos de um arquiteto do fornecedor. • As equipes internas não conseguem dar manutenção nos sistemas produzidos desta forma e nem repassar para outras fábricas de software.
    26. 26. Fábrica de Software • Normalmente as fábricas de software possuem seu framework proprietário interno e repassam sem custos para os projetos. Excelente, desde que: • Repasse toda a documentação e os códigos fontes • Repasse o material de treinamento do framework • Assuma a responsabilidade de suporte no framework • Assuma a responsabilidade de atualização • Garanta a compatibilidade com novas versões • Fora deste contexto, fique atento: o barato sai muito caro. • Se uma organização possui 3 fábricas de software, terá 3 arquiteturas ou frameworks para aprender e manter.
    27. 27. Fábrica de Software • O modelo de fábrica de software se inspirou no modelo de fábrica de outros setores. Entretanto, nestes setores a responsabilidade das definições estruturais e de qualidade do produto é de quem contrata. • Como garantir um padrão de desenvolvimento? • Como garantir a qualidade do sistema? • Como garantir que foram usadas as melhores práticas? • Como garantir a qualidade do código? • A inspeção de código somente, é inviável e onerosa; a solução é a automação de testes, sendo este um dos recursos básicos de um framework de integração.
    28. 28. Minha organização não se preocupa com que o framework possua uma Arquitetura de Referência
    29. 29. Arquitetura de Referência • Quando se diz uma arquitetura de referência, espera-se uma arquitetura completamente documentada, com material de referência, material de treinamento, projeto piloto desenvolvido e prova de certificação? • Ou aceita-se apenas uma lista de frameworks de base a serem utilizados? • A composição molecular de uma pedra de carvão e de um diamante é a mesma. Porém, com estruturas moleculares totalmente diferentes. • As combinações possíveis em um cenário com essa liberalidade aceita resultados completamente diferentes para problemas similares. Ou seja, não há um padrão de fato.
    30. 30. Arquitetura de Referência • O produto retornado por uma fábrica de software em uma arquitetura fraca de referência não tem o que se validar em termos de arquitetura, porque qualquer tipo de implementação deve ser aceita e não há o que possa ser questionado. • O que não pode ser medido, não pode ser gerenciado. • É um modelo totalmente Laissez faire, literalmente "deixai fazer, deixai ir, deixai passar“.
    31. 31. O que a minha organização ganha em utilizar o jCompany Suite?
    32. 32. O Que Ganho com o jCompany? • O jCompany não é a bala de prata ou a caixa de Pandora. É um ambiente de referência pronto para ser estendido e adaptado às necessidades de negócios. • O nível de discussão dos arquitetos altera da escovação de bit-byte de frameworks de base para as necessidades de negócios da organização. • Garantia de escalabilidade das aplicações desenvolvidas. • Garantia de compatibilidade com os principais Browsers. • Garantia de portabilidade para os principais servidores de aplicação, sendo: Tomcat, JBoss, WebSphere, Weblogic... • Garantia de portabilidade para os principais servidores de banco de dados.
    33. 33. O Que Ganho com o jCompany? • Aderência imediata a padrões de mercado • Segurança (controle de acesso) dos aplicativos • Redução da curva de aprendizado • Padronização de fato, em nível de código • Automação de testes, possível em todos os níveis • Gerência de configuração • Governança de arquitetura • Transferência total do conhecimento para organização • Liberdade na contratação de fábricas de software • Foco da organização nas necessidades do negócio
    34. 34. • Um framework padrão de mercado, de fato • Uma arquitetura com 7 anos de maturidade • Acesso ilimitado aos código fontes • Suporte dedicado e formal • Atualização continuada nas tecnologias • Treinamentos formais e padronizados • Documentação completa em português • Vasto material de referência e de pesquisa • Inúmeras implementações de referência • Processo formal de certificação de profissionais O Que Ganho com o jCompany?
    35. 35. • Acesso ao comitê de arquitetura para definir Backlogs e prioridades • Indicação de arquiteto para participar de Release Planning e Release Review • Acesso a Diretoria de Tecnologia • Garantia contratual de compatibilidade entre as versões • Responsabilidade com a base instalada Os Ganhos Institucionais
    36. 36. 7 anos de jCompany Developer • Nestes 7 anos do lançamento do jCompany Developer vimos o surgimento e ocaso de vários frameworks de base. Entretanto, o mercado está cada vez mais maduro e a prova disso é o lançamento dos padrão Java EE 6 e MVP/SOFEA no jCompany Suite 6.0. • O maior desafio não é fazer um framework, é mantê-lo atualizado ao longo dos anos. • Cada vez mais as organizações buscam focar nas suas atividades fins, repassando riscos, minimizados custos e maximizando resultados.
    37. 37. Algumas Lições Aprendidas • Muitas ‘sopas de letrinhas’ surgiram nos últimos anos. Porém, o que importa de fato são sistemas rodando em produção sobre padrões práticos. • O sistemas são Ativos de Software das organizações, bem como sua arquitetura, separadamente. • Cada vez mais a governança corporativa e a segurança da informação são vitais para as organizações. • Se de um lado temos a dependência e o alto custo dos softwares proprietários, de outro temos a liberdade sem compromisso do software livre; o que se deve buscar é o equilíbrio dos lados. • Liberdade com responsabilidade.
    38. 38. Últimas Considerações • Ao se definir por adquirir uma arquitetura corporativa de um fornecedor, é importante destacar alguns aspectos de negócios: • Quão importante é a sua organização para o fornecedor escolhido? • A sua organização consegue acesso a todos os níveis de decisão do fornecedor? • A sua organização consegue voz ativa na definição das próximas versões ou fica a mercê de um ‘grupo de gurus’? • Existe um contrato formal que garanta a compatibilidade das novas versões e que preserve o investimento realizado?
    39. 39. A decisão cabe a você EXECUTIVO! Obrigado. Justino (31) 9313-4910 justino@powerlogic.com.br

    ×