terça-feira, 7 de outubro de 2008
XP - Programação Extrema
O método de Programação Extrema (XP, do inglês extreming programing) : é uma proposta de desenvolvimento ágil e iterativa com a entrega constante de pequenas partes da funcionalidade do software. As partes devem ser incrementadas e requerem a melhoria constante do código (re-trabalho).
Uma das carcteristicas do XP : é que não existe um processo de design tradicional com a elaboração de modelos da arquitetura de spftware. O sistema é concebido a partir de uma metáfora e são descritos em estóriasdo usúario. Uma metáfora é a transposição de uma conceitualização do mundo real para o sitema desenvolvido.
Ex. Os programadores de correio eletrônico foram construidos utilizando os conceitos de mensagens, caixa de entrada e de saida, cada mensagem possui remetente, destinatario, assunto e cópias carbono (cc). Este modelo conceitual reflete a formas como corrrespondencias são enviadas nos escritorios e pelo sistema de correio do Estados Unidos. A metafora passa a ser fundamental para a elaboração das estórias de úsuario.
***Vantagens e Desvantagens***
fonte : http://74.125.45.104/search?q=cache:z8UaBR6T0l8J:www.apicesoft.com/common/articles/Apice%2520Engenharia%2520de%2520Software%2520-%2520XP%2520(Extreme%2520Programming)%2520(Leonardo%2520Mello%2520Viana)%2520-%2520Fevereiro%2520de%25202008.pdf+vantagens+da+metologia+xp&hl=pt-BR&ct=clnk&cd=4&gl=br
*Vantagens
As práticas do XP são usadas pelos integrantes da equipe, para facilitar no desenvolvimento e
agregar qualidade no projeto, com isso todos do time devem estar cientes de cada fase do sistema.
Um dos benefícios que a mesma oferece é tornar o processo mais ágil e flexível. Conforme Astels,
as práticas do XP são criadas para funcionarem juntas e fornecer mais valor do que cada uma
poderia fornecer individualmente.
Análise prévia de tudo que pode acontecer durante o desenvolvimento do projeto,
oferecendo qualidade, confiança, data de entregas e custos promissores.
O XP é ideal para ser usada em projetos em que o cliente não sabe exatamente o que
deseja e pode mudar muito de opinião durante o desenvolvimento do projeto. Com
Page 4
feedback constante, é possível adaptar rapidamente eventuais mudanças nos requisitos.
Estas alterações nos requisitos são muitas vezes críticas nas metodologias tradicionais,
que não apresentam meios de se adaptar rapidamente às mudanças.
Um outro ponto positivo das metodologias ágeis são as entregas constantes de partes
operacionais do software. Desta forma, o cliente não precisa esperar muito para ver o
software funcionando, como nas metodologias tradicionais.
*Desvantagens
É freqüente acontecer bugs em todos os projetos de desenvolvimento de software, e no XP
não é diferente. Existem pontos fracos no uso dessa metodologia, como:
Não existe uma avaliação de riscos, devendo, portanto implementar uma análise e
estratégias que buscam diminuir os erros.
A análise de requisitos é informal e com isso pode não ser bem vista pelos clientes, que
poderão se sentir inseguros quanto ao bom funcionamento do sistema.
Refatoração do código pode ser vista como irresponsabilidade e incompetência, pois, não
existe uma preocupação formal na utilização do código.
A falta de documentação é característica do processo XP, pois, o mesmo não dá muita
ênfase em burocracias (documentos, formulários, processos, controles rígidos, etc.).
Sendo, portanto, importante a elaboração de documentos e diagramas que facilitem no
entendimento e identificação do problema.
Além dessas desvantagens, existem algumas situações em que não é indicado o uso do XP
conforme apresentado a seguir:
A maior barreira para o sucesso de um projeto XP é a cultura empresarial. Qualquer
negócio que gerencie projetos tentando apontar o carro para a direção certa logo de cara
terá conflitos com o time que insiste em ir acertando a direção continuamente.
Outra cultura que não contribui para o XP é aquela na qual você é requisitado a trabalhar
horas e mais horas para provar o seu “comprometimento com a empresa”. Você não
consegue executar o XP se estiver cansado. Se aquilo que o seu time produz trabalhando
em velocidade máxima não é suficiente para a sua empresa então o XP não é a solução.
Uma outra barreira tecnológica para o XP é um ambiente no qual é necessário um longo
tempo para se obter feedback. Por exemplo, se o seu sistema leva 24 horas para compilar
e linkar, será difícil integrar, compilar e testar várias vezes ao dia
FDD FEATURE-DRIVEN DEVELOPMENT
- conceito:
- É um pequeno conjunto de processos orientado a modelo e com poucas e curtas interacões. A ideia é sempre gerar "produto úteis aos olhos do cliente" em ciclo rápidos de duas semanas, tanto quanto possivel.Como o ciclo é curto e orientado a caracteristica do sistema, o processo é facilmente moldável a volatividade do negócio.
- Caracteristicas:
- .Fornece a estrutura suficiente para equipes maiores.
.Enfatiza a produçao de software de qualidade. - .Entrega resultados frequentes,tangíveis e funcionais.
- .Realiza trabalho significativo desde o inicio,antes de torna-se altamente interativos.
- .Fornece informaçao de estado e progresso de formas simples e compreensivel.
- .Agrada a cliente, gerentes e desenvolvedores.
O livro de referência é "A Practical Guide to Feature-Driven Development", por Stephen Palmer e John Mac Felsing, publicado em 2002 pela Prentice-Hall, compondo uma série editada pelo próprio Peter Coad.
Referências: das vantagens e desvantagens.
The FDD Portal
http://www.featuredrivendevelopment.com/
Vantagens:
Uma metodologia ágil para aplicações críticas?
Como FDD possui fases muito fortes de análise, se comparada com outras metodologias ágeis, seus autores a recomendam para qualquer tipo de desenvolvimento, incluindo crítico.
Foco em "características de valor para o cliente" (cliente-valued features)
FDD prioriza aquilo que o cliente prioriza. Na medida em que há participação ativa do mesmo no projeto e um entendimento profundo dos requisitos do sistema, os resultados produzido têm bastante e rápida visibilidade.
Desvantagens:
Pesquisa
O caso inicial de aplicação de FDD foi no desenvolvimento de uma aplicação bancária. Entretanto, relatos confiáveis de uso bem-sucedido ainda não são encontráveis, questionando a eficácia/aplicabilidade de FDD.
Escalabilidade do time
Há controvérsias sobre o tamanho mínimo de um time FDD
Manutenção
Ainda que FDD pressuponha um ciclo completo de documentação, a especificação original da metodologia não comenta sobre sua aplicabilidade à manutenção de sistemas.
- curiosidades:
FDD POSSUI REQUISITOS MAIS FORMAIS E MAIS PASSOS QUE XP, ALÉM DE POSSUIR UM MECANISMOMAIS PRECISO PARA ACOMPANHAMENTO DO PROJETO.
Desenvolver um Modelo Abrangente: pode envolver desenvolvimento de requisitos, análise orientada por objetos, modelagem lógica de dados e outras técnicas para entendimento do domínio de negócio em questão. O resultado é um modelo de objetos (e/ou de dados) de alto nível, que guiará a equipe durante os ciclos de construção.
Construir uma Lista de Funcionalidades: decomposição funcional do modelo do domínio, em três camadas típicas: áreas de negócio, atividades de negócio e passos automatizados da atividade (funcionalidades). O resultado é uma hierarquia de funcionalidades que representa o produto a ser construído (também chamado de product backlog, ou lista de espera do produto).
Planejar por Funcionalidade: abrange a estimativa de complexidade e dependência das funcionalidades, também levando em consideração a prioridade e valor para o negócio/cliente. O resultado é um plano de desenvolvimento, com os pacotes de trabalho na seqüência apropriada para a construção.
Detalhar por Funcionalidade: já dentro de uma iteração de construção, a equipe detalha os requisitos e outros artefatos para a codificação de cada funcionalidade, incluindo os testes. O projeto para as funcionalidades é inspecionado. O resultado é o modelo de domínio mais detalhado e os esqueletos de código prontos para serem preenchidos.
Construir por Funcionalidade: cada esqueleto de código é preenchido, testado e inspecionado. O resultado é um incremento do produto integrado ao repositório principal de código, com qualidade e potencial para ser usado pelo cliente/usuário
bibliografias:
Wikipédia, a enciclopédia livre.
http://pt.wikipedia.org/wiki/Feature_Driven_Development
The FDD Portal
http://www.featuredrivendevelopment.com/
FDD Processes
DeLuca, J. – Nebulon Pty.
FDD Overview
Nebulon Pty.
The New Methodology – Martin Fowler
http://martinfowler.com/articles/newMethodology.html#N102CC
terça-feira, 9 de setembro de 2008
Paradigmas de Engenharia de Software - Protótipo
Propotização Porque?
Um bom protótipo não serve para evitar mudanças e sim para encoraja-las.
A prototipação foi escolhida pois agrega em seu paradigma a criação do protótipo do projeto final e isso possibilita uma interação com o cliente antes da conclusão final do projeto, onde o protótipo vira projeto.
Sendo um protótipo, a equipe desenvolvedora do mesmo, pode interagir com o cliente apresentando o protótipo e esse protótipo vai ser analisado por ambas as parte para ser gerado, assim, o projeto final.
Hoje em dia, na área de sistema de informação, o protótipo é a maquete do projeto a ser realizado, assim como na engenharia as maquetes são os protótipos da construções, na área de desenvolvimento, e principalmente ainda mais na área de desenvolvimento ágil, seria realmente útil construir esse protótipo, essa 'maquete' que facilita a localização de falhas e de areas dentro do projeto que podem ser melhoradas.
IMPORTÂNCIA DA PROTOTIPAÇÃO
Um protótipo em papel ou baseado em PC retratando aspectos da interação homem-máquina, mostrando assim ao usuário o nível de interação que será atingido;
Um protótipo de trabalho que implementa algum subconjunto da função exigida do software desejado;
Um sistema que executa parte ou toda a função do software desejado, tendo outras características que serão melhoradas em um outro esforço de implementação.
• Melhora a qualidade da especificação do software a ser desenvolvido, contribuindo para uma queda nos custos de desenvolvimento e manutenção.
terça-feira, 26 de agosto de 2008
Conceito de Engenharia de Software
Engenharia de software é uma área do conhecimento da informática voltada para a especificação, desenvolvimento e manutenção de sistemas de software aplicando tecnologias e práticas de ciência da computação, gerência de projetos e outras disciplinas, objetivando organização, produtividade e qualidade.
Atualmente, essas tecnologias e práticas englobam linguagens de programação, bases de dados, ferramentas, plataformas, bibliotecas, padrões, processos e a questão da Qualidade de Software.
Os fundamentos científicos para a engenharia de software envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e garantindo suas qualidades. Além disso, a engenharia de software deve oferecer mecanismos para se planejar e gerenciar o processo de desenvolvimento de um sistema de informação.