Modelos de inovação

Pessoal,

Uma apresentação interessante sobre o modelo de inovação aberto vs fechado apresentado no evento Open Innovation.

Arquiteto de software: atividades e responsabilidades

Pessoal,

Segue nesse post uma apresentação disponível no slideshare muito boa sobre arquitetura de solftware, com foco no papel e nas atividades que um arquiteto de software tem que desempenhar num projeto. Vale a pena ver!!

View more presentations from eros.viggiano. (tags: arquitetura software)

Se não conseguir acessar a apresentação, clique aqui.

OpenUP – Uma alternativa interessante

Pessoal,

Para quem não sabe por onde começar quando se fala de processo de desenvolvimento de software, o projeto Eclipse Process Framework – EPF, mantido pela eclipse.org, disponibiliza o processo OpenUP. O OpenUp pode ser um caminho muito interessante pois foi construído utilizando práticas e metodologias consolidadas no mercado.

O OpenUP é um Processo Unificado que aplica uma abordagem iterativa e incremental dentro de um ciclo de vida estruturado. O OpenUP abraça uma filosofia pragmática e ágil que foca na natureza colaborativa do desenvolvimento de software. É um processo independente de ferramenta e de pouca cerimônia que pode ser estendido para direcionar uma grande variedade de tipos de projeto.

Um aspecto importante do OpenUP é a forma como são suportados os seus quatro princípios fundamentais. São eles:
- Equilibrar as prioridades concorrentes para maximizar o benefício aos Stakeholders: Promover práticas que permitam aos participantes do projeto e aos Stakeholders desenvolver uma solução que maximize os benefícios para o Stakeholder, e que seja compatível com as restrições impostas ao projeto.
- Colaborar para alinhar os interesses e compartilhar o entendimento: Promover práticas que estimulem um ambiente de equipe saudável, permitam a colaboração e desenvolvam uma compreensão compartilhada do projeto.
- Focar na arquitetura, o mais cedo possível, para reduzir o risco e organizar o desenvolvimento: Promover práticas que permitam à equipe focar na arquitetura para reduzir o risco e organizar o desenvolvimento.
- Evoluir para continuamente obter feedback e promover melhorias: Promover práticas que permitam à equipe obter feedback dos Stakeholders, o mais cedo possível e de forma contínua, e demonstrar valor incremental para eles.

Vale a pena conferir!

Conceitos importantes da Orientação a Objetos

Pessoal,

Tenho trabalhado fortemente no mentoring de equipes de desenvolvimento nos últimos meses e uma das principais dificuldades dos profissionais está relacionada a falta de entendimento de conceitos fundamentais da Orientação a Objetos. Neste post apresento uma definição para cada um desses conceitos com o intuito de nivelar o entendimento. São eles:

• Reuso: Processo de se utilizar múltiplas cópias de um componente de software préexistente em vários sistemas e configurações novas. O reuso das funções providas pelo componente deve ser feito utilizandose apenas da interface deste. Em outras palavras, não deve haver modificações no código deste componente para que ele possa ser reusado. Ato ou processo de reusar um módulo ou componente com propriedade de reusabilidade.
• Reusabilidade: É o grau de facilidade ou de potencialidade que um componente possui para ser reusado. Está relacionado a alta coesão e baixo acoplamento com outros módulos.
• Coesão: Propriedade desejável e “saudável” de um componente, que demonstra coerência ou unidade conceitual no relacionamento com os outros componentes que formam um módulo ou sistema de software. A coesão depende do ocultamento de informações, ou isolamento de detalhes internos da implementação do componente. Um módulo coeso deve idealmente possuir uma única responsabilidade, que pode ser cumprida através de uma interface pública de serviços com o meio externo.
• Acoplamento: Propriedade indesejável e “patológica” de um componente, que demonstra falta de coerência conceitual e física no relacionamento com outros componentes que formam um módulo ou sistema de software. Associada à interdependência mal desenhada entre módulos.

Se vc não concorda com essas definições, coloque seu comentário e vamos nivelar o entendimento e ajudar a comunidade de desenvolvedores.

Essas definições foram retiradas da internet do site do Professor Jorge H C Fernandes. Para maiores informações, clique aqui e acesse o site.

SWEBOK – Entendendo um pouco mais…

Pessoal,

Estou fazendo o MBA em Engenharia de Software na UFRJ e tenho estudado muito sobre os conceitos fundamentais envolvidos na Engenharia de Software. Começa aqui uma série de post’s com o objetivo de compartilhar com a comunidade de desenvolvimento os conhecimentos adquiridos sobre o SWEBOK.

Para iniciarmos, é importante termos em mente que

“Engenharia de Software é a uma área de interesse (disciplina) preocupada com a criação e manutenção de aplicações de software pela aplicação de tecnologias e práticas da ciência da computação, gerência de projetos, engenharia, domínios de aplicação e outros campos”.

“Engenharia de software é uma disciplina que está em desenvolvimento e existe uma grande tendência ao aumento no seu nível de maturidade, mas não é uma disciplina legítima de engenharia, nem uma profissão reconhecida”.

O Swebok (Software Engineering Body of Knowledge) é uma iniciativa da IEEE Computer Society que tem o propósito de criar um consenso sobre as áreas de conhecimento da engenharia de software e seu escopo. Começou como uma colaboração entre IEEE CS, ACM e a Université du Québec à Montréal e contou com a participação internacional da indústria, sociedades de profissionais, academia e autores. Os objetivos do Swebok são:

• Oferecer uma visão consistente da engenharia de software no âmbito mundial
• Deixar claros os limites de planejamento de software com respeito a outras disciplinas como ciência da computação, gerência de projetos, matemática, entre outros
• Prover uma base para desenvolvimento curricular e material de licença individual

O Swebok está dividido em partes para facilitar o entendimento e possibilitar a especialização. Cada parte é chamada de Área de Conhecimento. As áreas de conhecimento definidas são:

• Requisitos de Software
• Projeto de Software
• Implementação de Software
• Testes de Software
• Manutenção de Software
• Gerência de Configuração
• Gerência de Engenharia de Software
• Processo de Engenharia de Software
• Métodos e Ferramentas de Engenharia de Software
• Qualidade de Software

Nos próximos post’s estarei detalhando as área de conhecimentos e suas aplicações.

Se vc quiser ter mais informações, segue abaixo alguns link’s interessantes:
- http://www.swebok.org/
- http://pt.wikipedia.org/wiki/Engenharia_de_software
- http://www.xexeo.org

Como definir a granularidade de serviços?

Pessoal,

Tenho passado por um problema aqui no trabalho que é muito comum nos projetos de SOA nos dias de hoje. Quando pensamos nos serviços que serão disponibilizados, vem logo a dúvida: Qual a melhor granularidade para os meus serviços?

Tem um post muito interessante feito por Breno Barros, no blog SOA Jounal, que trata deste assunto. Ele apresenta os principais conceitos e demonstra alguns pontos fundamentais para resolver essa questão. Vale a pena ler!

Para acessar o post, acesse o link
http://soa-journal.blogspot.com/2007/08/qual-atomicidade-eou-granularidade-dos.html