O que é Design Patterns ?

Design Patterns

Design Patterns

Os Design Patterns ou Padrões de Projeto, como são conhecidos, são conceitos ou modelos orientados a objetos visando solucionar problemas no desenvolvimento de softwares. Estes padrões possuem finalidades particulares que podem ser aplicadas para controlar a estrutura, a criação e o comportamento das classes e dos objetos em uma aplicação. Dependendo da situação em que esses projetos forem aplicados, é possível notar uma redução considerável na complexidade do software em virtude da reutilização de código-fonte e de componentes.

Apesar de existir 23 padrões de projeto, é praticamente inviável implementar todos eles em uma única solução, afinal, utilizar padrões de projeto sem um propósito é uma má prática. É preciso haver um motivo real para a implementação, ou seja, uma situação em que se pode comprovar de que o padrão de projeto será uma solução adequada para o problema. Caso contrário, a implementação pode aumentar a complexidade do programa e afetar também o desempenho da aplicação.

Uma das dúvidas mais frequentes relacionadas a padrões de projeto é saber onde, quando e como utilizá-los. Em primeiro lugar, o engenheiro de software deve ter sólidos conhecimentos em Programação Orientada a Objetos e um bom nível de abstração, ou seja, a Orientação a Objetos é a base essencial para compreender os padrões de projeto. Em segundo lugar, é necessário conhecer o objetivo principal de cada padrão de projeto para que seja possível fazer um estudo da viabilidade para solucionar um problema no software. No entanto, mesmo com esse conhecimento técnico, é comum alguns engenheiros não conseguirem identificar as situações ou os módulos que devem receber a implementação dos padrões. Portanto, em terceiro lugar, o profissional também deve ter um domínio satisfatório da regra de negócio do cliente. A consolidação de todas essas experiências é o que permite a seleção e a aplicação consciente dos padrões de projeto no desenvolvimento do software.

Fonte: Profissionais TI

Anúncios

Desenvolvimento de Software AD HOC

Quem gerencia projetos, ou já contratou empresas para executar projetos, sabe que uma das maneiras de se diminuir custos e prazos de entrega é diminuir a qualidade do produto, não utilizar processos definidos, não gerar documentação, não executar fases previstas no desenvolvimento de software e não planejar e executar testes apropriados.

É justamente aqui que se está se armando uma grande armadilha. Os envolvidos podem não estar cientes das consequências geradas da entrega do sistema desenvolvido sem ter sido dada a devida atenção à qualidade. Todo numerário economizado no desenvolvimento poderá e será gasto na geração de novas versões corrigidas que deverão ser entregues ao cliente, além de termos um custo imensurável ligado a imagem do produto e da própria empresa.

Outro efeito da falta da utilização de processos definidos e da engenharia de software é a geração de sistemas não amigáveis para uso, apresentando informações consideradas não fidedignas e com erros de funcionamento. Neste cenário, nenhum usuário se interessará em utilizar o sistema desenvolvido, fazendo que o projeto fracasse e que seja perdido todo o investimento realizado.

Imagine o cenário de um sistema de cobrança bancária, para o qual você poderia estar participando de um processo de manutenção corretiva, sem ter documentação do sistema e sem ter conhecimento das regras de negócio implementadas. Imagine também que está manutenção está relacionada à correção de informações, que estão sendo geradas incorretamente. Agora, para finalizar, imagine que o sistema possui milhares de linhas de código e você é novo na equipe, sendo que os programadores que implementaram o sistema não estão mais na empresa.

Por mais que este cenário seja assustador, podemos encontrá-lo neste exato momento em diversos lugares, enquanto você lê este artigo.

O que faltou no projeto de desenvolvimento deste tipo de sistema?

Tecnicamente, poderia citar:

  • Engenharia de Software e utilização de processos definidos
  • Utilização de metodologia de desenvolvimento de sistema alinhado ao paradigma associado ao projeto
  • Utilização de Design Patterns quando apropriado
  • Documentação adequada
  • Planejamento e execução de testes adequados

Do lado humano, poderia citar:

  • Participação no projeto de profissionais com conhecimento dos itens técnicos acima relacionados
  • Falta de percepção do patrocinador do projeto, do valor e benefícios de se utilizar os itens acima relacionados
  • Falta de conhecimento dos envolvidos no projeto, das melhores práticas de mercado para desenvolvimento de software e de seus benefícios

Já tive a oportunidade de presenciar de empresários e executivos, o seguinte comentário:

Prefiro o desenvolvimento de software sem utilizar Orientação a Objetos e processos de desenvolvimento, pois é mais barato e mais rápido de se disponibilizar o sistema para os usuários.

Desenvolver código baseado nesta ideia pode gerar as seguintes consequências:

  • Implantação de sistemas cheios de erros, constantemente entrando em manutenção;
  • Sistemas que podem não atender às expectativas dos Stakeholders;
  • Softwares com alto custo de manutenção;
  • Softwares difíceis de serem utilizados, não atendendo às necessidades dos StakeHolders;
  • Grande insatisfação dos usuários;
  • Fracasso do projeto.

O desenvolvimento de sistema sem utilizar processos, AD HOC, acaba custando muito mais caro, gerando insatisfação.

Já presenciei várias vezes, pessoas que simplesmente não queriam e não utilizavam sistemas disponibilizados pela empresa, por pelo menos um dos seguintes motivos:

  • Não confiavam nos dados por eles apresentados
  • Porque não atendiam a suas expectativas e necessidades do dia a dia
  • Porque tinham usabilidade ruim
  • Porque viviam apresentando problemas de funcionamento

O detalhe mais triste é que as empresas onde estas pessoas trabalhavam, investiram dinheiro e tentaram disponibilizar sistemas para melhorar a produtividade e diminuir custos das mesmas. O resultado foi exatamente o contrário, além de não diminuir custos, nem aumentar a produtividade, as empresas perderam todo o investimento realizado e o sistema caiu em desuso, literalmente, sendo jogado fora.

Bibliografia

Artigo Retirado de Profissionais TI

 

RUP – Rational Unified Process (Processo Unificado Rational)

Resumindo:
RUP é um framework para desenvolvimento de software criado pela 
empresa Rational, na década de 90. 
Tem como objetivo oferecer um processo de desenvolvimento 
“bem definido” e “bem gerido”

Desenvolvimento InterativoMas afinal o que é o RUP ?

RUP é um processo da engenharia de software que fornece uma abordagem disciplinada para assumir tarefas e responsabilidades dentro de uma organização de desenvolvimento, cujo objetivo é assegurar a produção de software de alta qualidade dentro de prazos e orçamentos previsíveis (Kruchten 2003, pág. 14). Derivado dos trabalhos sobre UML e do Processo Unificado de Desenvolvimento de Software, ele traz elementos de todos os modelos genéricos de processo, apoia a iteração e ilustra boas práticas de especificação e projeto (Sommervillie 2007, pág. 54). Ele captura seis das melhores práticas no desenvolvimento de software de forma satisfatória para uma grande faixa de projetos e organizações (Krutchten 2003, pág. 14).

As melhores práticas abordadas são as seguintes (Sommerville 2007, pág. 56):

1. Desenvolver o software iterativamente: planejar os incrementos de software com base nas prioridades do cliente, desenvolver e entregar o mais cedo possível às características de sistema de maior prioridade no processo de desenvolvimento.

2. Gerenciar Requisitos: documentar explicitamente os requisitos do cliente e manter o acompanhamento das mudanças desses requisitos. Analisar o impacto das mudanças no sistema antes de aceitá-las.

3. Usar arquiteturas baseadas em componentes: Estruturar a arquitetura do sistema com componentes, reduzindo a quantidade de software a ser desenvolvido e, consequentemente, reduzir custos e riscos.

4. Modelar software visualmente: usar modelos gráficos de UML para apresentar as visões estática e dinâmica do software.

5. Verificar a qualidade do software: garantir que o software atenda aos padrões de qualidade da organização.

6. Controlar as mudanças do software: gerenciar as mudanças do software, usando um sistema de gerenciamento de mudanças, procedimentos e ferramentas de gerenciamento de configuração.

Quais são as Vantagens do Desenvolvimento Interativo

Ciclo de Vida do desenvolvimento Interativo

Ciclo de Vida do desenvolvimento Interativo

  • Os riscos são atacados mais cedo;
  • Mudanças nos requisitos não acabam com o projeto;
  • Refinamento de arquitetura;
  • Aprendizado e aprimoramento;
  • Aumento do reúso.

Arquitetura Baseada em Componentes ? Como assim ?

Arquitetura baseada em componentes descreve uma abordagem da engenharia de software para estrutura e desenvolvimento de sistemas. O foco está na decomposição da estrutura da funcionalidade individual ou componente lógico dele expondo bem definido a interface de comunicação contendo seus métodos, eventos e propriedades. Isso provê um alto nível de abstração, estrutura principal da orientação a objetos, não focando em questões de protocolos de comunicação e compartilhamento de estado.

“Decomposição da estrutura da aplicação em uma reutilização funcional ou componentes lógicos que expõe um interface de comunicação bem definida.”

As chaves principais para o uso de componentes são:

Reusabilidade: Componentes são usualmente estruturados para ser reutilizado em diferentes cenários e diferentes aplicações. Entretanto, alguns componentes precisam ser estruturados para tarefa específica.

Substituição: Componentes precisam ser facilmente substituídos por outros componentes similares.

Contexto não específico: Componentes são estruturados para operar em diferentes ambientes e contextos. Informações específicas como estado do dado, devem ser enviado para o componente em vez de serem incluídos ou acessado pelo componente.

Extensibilidade: Um componente pode ser extendido a partir de um componente para fornecer um novo comportamento.

Encapsulamento: Componentes expõe uma interface dele para os invocadores utilizar suas funcionalidades e não revelar detalhes do seu processo interno ou alguma variável interna e estado.

Independência: Componentes são estruturados para ter o mínimo de dependência com outros componentes. Por isso componentes pode ser disponibilizados dentro de um ambiente apropriado sem afetar outros componentes ou sistemas.

Tipos comuns de componentes utilizados nas aplicações inclui componente de UI, como grids, botões, assistentes e utilitários que expõe um subset específicos das funcões utilizadas em outros componentes (Componentes de UI reutilizáveis). Componentes dependem de um mecanismo dentro da plataforma que provê um ambiente em que eles podem ser executados. Exemplos desse componentes são: Component Object Model (COM), Common Object Request Broker Archicteture (CORBA) e Enterprise Server Bean (EJB) entre outros. Arquitetura de componentes gerencia o mecanismo de localização dos componentes e suas interfaces, passando as mensagens ou comandos entre entre os componentes, e em alguns casos mantendo estado.

Alguns benefícios desse modelo de arquitetura:

Fácil deploy: Compatilidade de novas versões quando disponíveis. Você pode substituir a versão existente sem impacto em outros componentes do sistema como um todo.

Redução de custo: O uso do componente de terceiros permite a redução do custo do desenvolvimento e manutenção.

Fácil desenvolvimento: Implementar componentes bem como a funcionalidade definidad pela interface, permite desenvolvimento sem impacto em outros partes do sistema.

Reutilização: A reutilização de componentes é um meio agilizar o desenvolvimento e manutenção onde agrega na redução de custo da aplicação.

Mitigação de complexidade técnica: Componentes mitigam complexidade no uso de containers de componentes e serviços. Exemplo de container de serviços inclui componente de ativação, gerenciamento de ciclo de vida, métodos de enfileiramento, eventos e transações.

Padrões de projetos como Injeção de Dependência ou Service Locator pode ser utilizados para gerenciar as dependências entres os componentes e promover o baixo acoplamento e reuso. Tais padrões são muitas vezes utilizados para compilar aplicações compostas combinando e reutilizando componentes entre múltiplas aplicações.

Técnicas de Levantamento de Requisitos e Identificação

Na identificação dos requisitos devemos ter compreensão do que é e de como será feito, ou seja, tendo completo domínio do assunto, identificar que são os STAKEHOLDERS e capturar os requisitos, identificando e analisando os problemas nos processos.
Haverá dificuldades no levantamento dos requisitos nos casos:
  1. Cliente não sabe o que deseja;
  2. Requisitos não realistas (com tecnologia ou economia)
  3. Mesmo requisitos de formas diferentes por stakeholders diferentes.

Técnicas para o Levantamento de Requisitos

As técnicas para o levantamento de requisitos poderá ser utilizada as seguintes opções:

  • Entrevistas e Questionário;
  • Workshop de Requisitos;
  • Brainstorming (Tempestade de ideias);
  • Cenários (exemplos práticos);
  • Estudo etnográfico (observação direta no dia a dia, neste caso o analista de sistema passo o dia observando e aprendendo como é feito as rotinas e o método de trabalho da empresa);

Referencial Bibliográfico

  • Kotonya e Sommerville (1998). Requirements Engineering: Processes and Techniques. Gerald Kotonya, Ian Sommerville. Wiley. 1998.
  • Sommervile (2001). Software Engineering. Ian Sommerville. Addison Wesley. 2001
  • Thayer e Dorfman (1993). Software Requirements Engineering. R. H. Thayer, M. Dorfman. IEE Computer Society Press. 1993.
  • Soares (2005). Introdução, Identificação e Análise em Engenharia de Requisitos. Antônio Lucas Soares. 2005.

A Engenharia de Requisitos como um processo

Engenharia de RequisitosA engenharia de Requisitos é um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo ele se encontra em paralelo com os estudos de viabilidades.

Sendo composto por:

  • Identificação;
  • Análise e Negociação;
  • Especificação e Documentação;
  • Validação
  • Gestão dos Requisitos (Inovações tecnológicas, mudança de processo e etc);

O Estudo da Viabilidade

O estudo da viabilidade é feito antes da análise detalhada de cada requisito, sendo feito para avaliar se o projeto é viável ou não. Para fazer essa avaliação é necessário entrevista com os STAKEHOLDERS levantando os seguintes aspectos:

  1. O Sistema contribui para os objetivos da organização?
  2. Se a restrições quanto a tecnologia (este deve ser vista de ambos os lados, ou seja, a empresa que está desenvolvendo o sistema possui o conhecimento necessário para fazer o projeto e o cliente possui restrições quanto a tecnologia adotada), Organização da empresa, com sua economia, política e se a empresa possui recursos disponíveis para fazer investimento necessário.
  3. Caso haja integração entre diferentes sistemas, será que esta é possível ?
  4. Se o novo sistema não fosse implementado, quais seriam as alternativas para a sua organização ?
  5. Quais são os problemas que os sistemas atuais apresentam e como é que um sistema novo irá resolver estas falhas ?

O estudo de viabilidade deverá culminar (atingir o ponto mais elevado) com a produção de um relatório e deverá determinar a continuação do desenvolvimento do projeto.

Referencial Bibliográfico

  • Kotonya e Sommerville (1998). Requirements Engineering: Processes and Techniques. Gerald Kotonya, Ian Sommerville. Wiley. 1998.
  • Sommervile (2001). Software Engineering. Ian Sommerville. Addison Wesley. 2001
  • Thayer e Dorfman (1993). Software Requirements Engineering. R. H. Thayer, M. Dorfman. IEE Computer Society Press. 1993.
  • Soares (2005). Introdução, Identificação e Análise em Engenharia de Requisitos. Antônio Lucas Soares. 2005.

Introdução a Métricas de Software

Métricas de software vêm sendo estudada há uns 20 anos ou mais. Elas têm como principal objetivo entender a importância da avaliação, garantia da qualidade do software, as principais abordagens e como as mesmas são utilizadas.  Portanto as métricas de software têm como objetivo verificar se o produto foi desenvolvido de modo correto e validar se o produto esta de acordo com a especificação de requisitos.

Estas medições têm como objetivo obter o autoconhecimento (parte interna) do software, atender a uma pressão imediata (parte externa) do software e preparar o software para o futuro (tendências).

A partir de momento surgem algumas perguntas:

  1.  Obter autoconhecimento por quê? R: Se não soubermos onde estamos não conseguiremos saber pra onde ir e nem o que será feito, portanto é de fundamental importância que devemos saber O QUE se tem (ou seja, o que esta produzindo) e AONDE se quer chegar.
  2. Como atender uma pressão imediata? R: É saber resolver (o que fazer) em uma necessidade em curto prazo.

Por exemplo: Temos um projeto no qual você faz parte e que foi aprovado na concorrência de um projeto de desenvolvimento de software, portanto é de fundamental importância saber o que deve ser feito no hoje e saber pra onde caminhar.

  • Analisar a estrutura concreta de produção, isso pra saber como serão os próximos projetos;
  • Analisar possíveis riscos;
  • Medir o software onde podemos obter informação de como controlar, gerenciar, melhorar e trabalhar; 

     3. Até onde medir? R: Até estabelecer um programa de métricas que:

  • Seja adequada;
  • Fundamentado;
  • Gradual

     4. Não medir o software mais do que é necessário.

Essas métricas podem ser divididas em três fases:

  1. Coleta;
  2. Calculo dos Dados;
  3. Análise dos Dados.

Depois de realizar essas fases podemos identificar o conjunto de dados que a ideia do processo apresenta e um entendimento do projeto. Que permite ao gerente de projeto de software aperfeiçoar, melhorar o processo de desenvolvimento do produto e por fim avaliar a qualidade do produto que esta sendo produzido.

Referências bibliográficas

Pressman, Roger. S. Engenharia de Software. Makron Books, 1995. Guia de Estudos prof.  Rodrigo

GUARIZZO, Karina. Métricas de Software monografia. Disponível em:                  <Métricas de Software> . Acessado em 06/11/11

Costa David dos Santos. Engenharia de Software: Métricas e Qualidade de software. Disponível em:<Trabalho Engenharia de Software David Costa>. Acessado em 06/11/11

Aurélio Marco Cordeiro. Métricas de Software. Disponível em: <batebyte> Acessado em 5/11/11.

Engenheiros de Software: carreira e salários em alta…

zeluisbraga

(Atualização em 05/02/2017, vejam no final da postagem).

O mercado de trabalho para a área de TI continua  disparado em alta, tanto nos EUA quanto aqui. E o desinteresse dos jovens pelos cursos e pela carreira, tanto lá quanto cá, continua em baixa e cada vez pior. O número de candidato por vaga nos vestibulares, que nos anos 90 rodava por volta de 20 candidatos/vaga, hoje caiu para 9 candidatos/vaga nas melhores universidades, comprometendo o andamento dos cursos de pós-graduação de excelência oferecidos, por falta de bons alunos para seguirem nos estudos.

Segundo artigo da Infoworld, os números nos EUA são de impressionar. As empresas estão apelando para os bônus de produtividade anuais, pagando uma média de US$8769,00 (US$12500,00 no Silicon Valley-California) em 2011, mais do que um salário mensal para a maioria das carreiras da área. São 86.731 vagas publicadas na área, no inicio de novembro, segundo pesquisas…

Ver o post original 621 mais palavras