novas tendencias - aula 14/08 prof. jurandir

[wal junior >>> http://mmmeulixo.spaces.live.com]

Novas tendencias em tecnologia


APRESENTAR TRABALHO IMPRESSO

5 QUESTÕES PARA TODA A CLASSE TRAZER NO DIA DA APRESENTAÇÃO


1 – modelo catedral / bazar

2 - rup

3 - extreme programming

4 - scrum

5 – asd

6 – DSDM

7 – FDD




1- Bazar, Catedral, Engenharia de Software e Gestão de Projetos


Bazar, Catedral, Engenharia de Software e Gestão de Projetos
Ações do documento last edited 1 year ago by fjbarth
Autor: Fabrício Jailson Barth (FabricioBarth)

Veja aqui a primeira versão do trabalho

Versão em PDF (http://www.knoma.pcs.usp.br/~fabricio/mac5800/
trabalho2.pdf).

Apresentação (http://www.knoma.pcs.usp.br/~fabricio/mac5800/
apresentacao.pdf).

Introdução
Raymond em seu trabalho The Cathedral and the Bazaar (http://
www.catb.org/~esr/writings/cathedral-bazaar/) faz referência a dois
diferentes estilos de desenvolvimento de software. De um lado, comum
no desenvolvimento de aplicações comerciais, o modelo Catedral,
caracterizado por uma estrutura de planejamento e esforço centralizada
com uma equipe especializada trabalhando sobre um objetivo com um
cronograma bem estruturado. De outro lado está o modelo Bazar, onde a
forma de trabalho descentralizada e o esforço de voluntários são as
principais características. Um exemplo claro deste modelo é o projeto
Linux.

A utilização de métodos e processos definidos pela Engenharia de
Software (http://www.sei.cmu.edu/) e pela área de Gestão de Projetos
(http://www.pmi.org) no modelo Catedral são comuns. Por exemplo, é
comum a utilização de metodologias e heurísticas para administração
dos recursos humanos visando a entrega do produto no prazo, com
qualidade e sem ultrapassar os custos planejados. No entanto, no
modelo Bazar isto não acontece. Somente algumas ações estabelecidas
pela Engenharia de Software são utilizadas, i.e., controle de versões
e reutilização de código.

Tendo em vista que o objetivo do desenvolvimento de software dentro do
modelo Bazar não visa lucro, fica claro a não utilização de alguns dos
métodos e processos definidos pelas áreas de Engenharia de Software e
Gestão de Projetos. No entanto, alguns dos conceitos criados por estas
áreas são úteis para o desenvolvimento de software com qualidade.

Por que tais conceitos não são utilizados no modelo Bazar? Existe
espaço para tais conceitos dentro deste modelo? Ou seja, seria
coerente ou possível aplicar tais conceitos dentro do modelo Bazar?
Qual o impacto da aplicação destes conceitos?

Levando estas questões em consideração, o objetivo deste trabalho é
verificar a aplicabilidade das técnicas e processos da Engenharia de
Software e da Gestão de Projetos em sistemas desenvolvidos com o
método Bazar.

Catedral e Bazar
Com o objetivo de entender um pouco melhor as diferenças entre o
método Catedral e Bazar, nesta seção serão descritas as
características de cada uma enumeradas pelo autor Eric S. Raymond.

No método Catedral o software é escrito por um grupo muito pequeno, e
não está acessível a mais ninguém durante a fase de desenvolvimento.
Quando o software é liberado para a comunidade ele já possui um certo
grau de confiabilidade. Além disto, a equipe de desenvolvedores é
altamente hierarquizada e liderada por um coordenador, nomeado de
forma descendente. Geralmente, a fase de testes é feita por uma
comunidade maior. A motivação das pessoas que participam do processo é
realizada através do pagamento das suas horas de trabalho.



No método Bazar o software é escrito por uma grande comunidade de
desenvolvedores que liberam as suas versões de código a todo momento,
quase que de maneira promiscua (http://www.catb.org/~esr/writings/
cathedral-bazaar/). Os desenvolvedores são distribuídos
geograficamente, comunicando-se pela Internet. A organização é
extremamente informal. O software produzido não é pago, tão pouco as
pessoas que participam do processo recebem algum pagamento pelas horas
gastas no projeto, ou seja, o trabalho é voluntário. A motivação por
tal trabalho não é financeira mas o resultado do próprio trabalho.
Apesar do estilo quase caótico de desenvolvimento, observa-se neste
método uma capacidade de auto-organização. Uma organização que é
realizada de maneira bottom-up, ou seja, os coordenadores são eleitos
expontaneamente.



Ambos os métodos de desenvolvimento são válidos e não devem ser
ignorados, haja visto os exemplos mais expoentes: Windows e Linux.
Ambas as abordagens possuem aspectos positivos e negativos. No caso do
método Catedral, a estrutura rígida impõem limites para a criatividade
dos indivíduos e para a geração de conhecimento. No caso do método
Bazar, é difícil impor uma organização ao desenvolvimento de um
determinado produto e é difícil prever se um determinado colaborador
irá realizar determinado trabalho ou não (http://www.catb.org/~esr/
writings/cathedral-bazaar/, http://www.gnu.org/philosophy/free-sw.html,
http://www.benkler.org/CoasesPenguin.html, http://firstmonday.org/issues/issue5_3/kuwabara/).

Engenharia de Software - Métodos e Processos
A Engenharia de Software surgiu em meados dos anos 70 numa tentativa
de contornar a crise do software e dar um tratamento de engenharia
(mais sistemático e controlado) ao desenvolvimento de sistemas de
software complexos. Um sistema de software complexo se caracteriza por
um conjunto de componentes abstratos de software (estruturas de dados
e algoritmos)

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 garantido suas qualidades. Além disto, a engenharia de
software deve oferecer mecanismos para se planejar e gerenciar o
processo de desenvolvimento.

Engenharia de Software é uma tecnologia em camadas. Qualquer abordagem
de engenharia deve se apoiar num compromisso organizacional com a
qualidade (figura 1). Gestão de qualidade total e filosofias análogas
levam à cultura de um processo contínuo de aperfeiçoamento e essa
cultura, em última análise, leva ao desenvolvimento de abordagens cada
vez mais amadurecidas para a engenharia de software. A camada que dá
apoio à engenharia de software é um enfoque na qualidade (http://
www.sei.cmu.edu/).



Figura 1: Camadas da engenharia de software

O fundamento da engenharia de software é a camada de processo. O
processo de engenharia de software é o adesivo que mantém unidas as
camadas de tecnologia e permite o desenvolvimento racional e oportuno
de software para computador. O processo define uma estrutura para um
conjunto de áreas-chave de processo, que deve ser estabelecido para a
efetiva utilização da tecnologia de engenharia de software. As áreas-
chave de processo formam a base para o controle gerencial de projetos
de software e estabelecem o contexto no qual os métodos técnicos são
aplicados, os produtos de trabalho (modelos, documentos, dados,
relatórios, formulários, etc.) são produzidos, marcos são
estabelecidos, qualidade é assegurada e modificações são adequadamente
geridas.

Métodos de engenharia de software fornecem a técnica de como fazer
para construir software. Os métodos incluem um amplo conjunto de
tarefas que abrange análise de requisitos, projeto, construção de
programas, teste e manutenção. Métodos de engenharia de software
repousam num conjunto de princípios básicos, que regem cada área da
tecnologia e incluem atividades de modelagem e outras técnicas
descritivas.

Ferramentas de engenharia de software fornecem apoio automatizado ou
semi-automatizado para o processo e para os métodos. Quando
ferramentas são integradas, de modo que a informação criada por uma
ferramenta pode ser usada por outra, um sistema para o apoio ao
desenvolvimento de software, chamado engenharia de software apoiada
por computador, é estabelecido. CASE combina software, hardware e uma
base de dados de engenharia de software (um depósito que contém
informação importante sobre análise, projeto, construção de programas
e teste) para criar um ambiente de engenharia de software análogo ao
CAD/CAE (projeto/engenharia apoiada por computador) para hardware.

Gestão de Projetos
Projetos são caracterizados por serem executados por pessoas e
sofrerem restrições de recursos, prazo e custo (http://www.pmi.org/).
Em qualquer trabalho, as atividades precisam ser planejadas,
programadas e, durante a execução, precisam ser controladas.

Um projeto é definido como sendo uma empreitada temporária criada para
gerar um produto ou um serviço único (http://www.pmi.org/). Temporário
significa que cada projeto tem um começo e um fim definidos e único
significa que o produto ou o serviço é diferente, de alguma maneira,
dos produtos ou serviços similares já produzidos.

Os projetos podem ser realizados em todos os níveis da organização.
Podem envolver uma única unidade de uma organização ou podem cruzar os
limites da organização. Os projetos são freqüentemente componentes
críticos da estratégia de negócio de uma organização. Exemplos dos
projetos incluem: desenvolver um novo produto ou serviço, efetuar uma
mudança na estrutura da organização, projetar um veículo novo, entre
outros.

A gestão de projetos é a aplicação de conhecimento, habilidades,
ferramentas e técnicas sobre as atividades do projeto a fim de atender
ou exceder os requisitos do projeto. Os stakeholders do projeto são
todas as pessoas e organizações cujos interesses são afetados pelo
projeto. As ações para atender as necessidades e expectativas dos
stakeholders do projeto envolve balancear demandas competitivas entre
escopo, prazo, custo e qualidade.

A gestão de projetos é uma atividade interativa - uma ação, ou falta
de ação numa área, usualmente afeta também outras áreas. Por exemplo,
uma mudança de escopo quase sempre afeta o custo do projeto.
Entretanto, ela pode ou não afetar a moral da equipe e a qualidade do
produto.

Estas interações freqüentemente exigem balanceamento entre os
objetivos do projeto - consegue-se uma melhoria numa área somente
através do sacrifício de desempenho em outra. Balanceamentos
específicos de performance podem variar de projeto a projeto e de
organização a organização. Uma gestão de projetos satisfatória requer
uma administração efetiva dessas interações.

Para auxiliar o entendimento da natureza da integração na gestão de
projetos, e para enfatizar a importância da própria integração, o
Project Management Body of Knowledge (Pmbok) (http://www.pmi.org/)
descreve a gestão de projetos em termos de processos e de suas
interações.

Um processo é composto por uma série de ações que visam transformar um
insumo (entrada) em um produto (saída) com o auxílio de recursos,
infra-estrutura e regras de controle. Os processos dos projetos,
enquadram-se nos processos de gestão de projetos ou nos processos de
execução do projeto.

Processos da Gestão de Projetos
Os processos de gestão da gestão de projetos são processos abstratos
que dividem os projetos em várias fases visando um melhor controle
gerencial e uma ligação mais adequada de cada projeto aos seus
processos de execução (Figura 2), que por sua vez, são específicos do
domínio da aplicação. Por exemplo, os processos de execução de um
projeto na área de telecomunicações são, na sua maioria, diferentes
dos processos de execução de um projeto na área de desenvolvimento de
software, porém os processos de gestão de projetos são os mesmos para
ambas as áreas.



Figura 2: Relação entre os processos da gestão de projetos e os
processos de execução

Os processos de gestão de projetos são organizados em cinco grupos:
inicialização, planejamento, execução, controle e finalização (Figura
3).



Figura 3: Conjunto de processos da gestão de projetos

Os processos de inicialização marcam o nascimento do projeto. É neste
momento que é autorizado o início do projeto e é nomeado o Gerente do
Projeto.

O planejamento define o que deve ser feito, de uma maneira alinhada e
colaborativa. O controle consiste no acompanhamento das atividades,
com base no plano do projeto, com a finalidade de medir o progresso,
comparar o previsto com o realizado e fazer os ajustes necessários no
projeto.

Na fase de execução é quando os trabalhos são realizados, conforme
definidos no planejamento. Na finalização os resultados do projeto são
registrados, guardando a história do projeto, e o aceite formal é
obtido.

Os grupos de processos se ligam pelos resultados que produzem - o
resultado ou saída de um grupo torna-se entrada para outro. Estas
conexões são mostradas na figura 3. Além disso, os grupos de processos
da gestão de projetos não são separados ou descontínuos, nem acontecem
uma única vez durante todo o projeto; eles são formados por atividades
que se sobrepõem, ocorrendo em intensidades variáveis ao longo do
projeto.

A figura 4 ilustra como os grupos de processos se sobrepõem e variam
dentro de um projeto.



Figura 4: Sobreposição dos grupos de processos

Utilizando os conceitos da Engenharia de Software e Gestão de Projetos
no Bazar
O objetivo desta seção é tentar delinear uma forma de utilizar os
conceitos propostos nas áreas de Engenharia de Software e Gestão de
Projetos no desenvolvimento de sistemas utilizando o método Bazar. A
utilização de tais conceitos não deve de maneira alguma enrigecer o
método Bazar, fazendo com que ele se torne uma Catedral. A utilização
de tais conceitos deve estar focada na solução dos problemas
encontrados no método Bazar. Principalmente, problemas relacionados
com a falta de controle sobre a execução ou não das tarefas.

Na Gestão de Projetos o conjunto de processos responsável pelo
Controle são os Processos de Controle. Basicamente, os processos de
controle monitoram a execução do projeto levando em consideração o que
foi planejado. No entanto, no método Bazar não existe planejamento
global do projeto. O planejamento é realizado de maneira individual,
quando o desenvolvedor identifica uma necessidade, estabelece os
requisitos, planeja o seu código e libera para o caos organizado.
Depois cada agente da comunidade interessado na solução do problema
faz a sua parte contribuindo para o desenvolvimento do código ou
detecção de bugs.

Existem projetos que precisam de planejamento e controle. Geralmente,
são projetos complexos com um grande número de colaboradores. Por
exemplo, projetos da NASA, a linguagem ADA e a construção da ponte Rio-
Niterói. No entanto, o Linux é um projeto complexo com um grande
número de colaboradores que não foi planejado e que está dando certo.

Apesar da grande maioria dos projetos de código aberto são serem
planejados, existem vários serviços que permite o seu controle, pelo
menos o controle de versões. Dentro destes serviços, o serviço de
maior destaque é o Sourceforge.

Sourceforge é um serviço gratuido para desenvolvedores em Código
Aberto oferecendo fácil acesso a CVS's, listas, controle de bugs,
quadro de mensagens/fórums, gerenciador de tarefas, hospedagem,
arquivamento permanente de arquivos, backups completos, e
administração totalmente baseado na web (http://sourceforge.net/).
Atualmente conta com 92.183 projetos registrados e 971.741 usuários
registrados (números adquiridos no dia 13/12/2004).

Paralelo: Software e laboratório de pesquisa
Atualmente, na grande maioria dos casos, os laboratórios de pesquisa
funcionam sobre a coordenação de um professor (geralmente com título
de doutor). Cabe a este professor definir linhas de pesquisa e
projetos para o laboratório e para os seus orientandos. Isto acaba
gerando uma estrutura extremamente hierárquica, onde cabe ao professor
decidir o que cada orientando seu irá desenvolver dentro do escopo de
um projeto maior.

A dinâmica acima descrita possibilita ao professor uma fácil
coordenação do grupo de pesquisa. No entanto, não permite trabalho
colaborativo entre os membros deste grupo, prejudicando, por exemplo,
o processo criativo.

E se ao invés do professor optar por deixar os seus orientandos
decidirem o que fazer, mesmo podendo ter um sério problema de
coordenação?

Esta decisão depende muito do estilo do coordenador. Existem pessoas
que preferem ter tudo sob seu controle e outras não fazem questão. A
mesma coisa acontece com o software. Existe situações em que é
necessário o controle sobre os mínimos detalhes do que será produzido,
em outras situações pode-se deixar a cargo de uma comunidade decidir.

Considerações Finais
O fato de planejar, controlar e realizar todas as etapas determinadas
na Gestão de Projetos e na Engenharia de Software não faz com que o
software tenha melhor ou pior qualidade, apenas fornece ao coordenador
um maior controle sobre o desenvolvimento do produto.

Acredito que não é coerente a realização de planejamento global do
projeto dentro do método Bazar. Tanto o planejamento global como o
controle baseado no planejamento são características particulares do
método Catedral.

Referências Bibliográficas
http://www.catb.org/~esr/writings/cathedral-bazaar/

http://www.gnu.org/philosophy/free-sw.html

http://sourceforge.net/index.php

http://www.benkler.org/CoasesPenguin.html

http://firstmonday.org/issues/issue5_3/kuwabara/

http://www.pmi.org/

http://www.sei.cmu.edu/

http://en.wikipedia.org/wiki/The_Mythical_Man-Month

http://en.wikipedia.org/wiki/Software_engineer

http://en.wikipedia.org/wiki/Project_management

http://en.wikipedia.org/wiki/Fred_Brooks

http://en.wikipedia.org/wiki/Project

http://en.wikipedia.org/wiki/WikiProject

http://sourceforge.net/

























2 RUP

IBM Rational Unified Process
Origem: Wikipédia, a enciclopédia livre.
(Redirecionado de Rup)

Disciplinas de Apoio
Gerência de configuração | Documentação | Gerência de projetos

O RUP, abreviação de Rational Unified Process (ou Processo Unificado
da Rational), é um processo proprietário de Engenharia de software
criado pela Rational Software Corporation, adquirida pela IBM,
ganhando um novo nome IRUP que agora é uma abreviação de IBM Rational
Unified Process e tornando-se uma brand na área de Software,
fornecendo técnicas a serem seguidas pelos membros da equipe de
desenvolvimento de software com o objetivo de aumentar a sua
produtividade.

O RUP usa a abordagem da orientação a objetos em sua concepção e é
projetado e documentado utilizando a notação UML (Unified Modeling
Language) para ilustrar os processos em ação. Utiliza técnicas e
práticas aprovadas comercialmente.

É um processo considerado pesado e preferencialmente aplicável a
grandes equipes de desenvolvimento e a grandes projetos, porém o fato
de ser amplamente customizável torna possível que seja adaptado para
projetos de qualquer escala. Para a gerência do projeto, o RUP provê
uma solução disciplinada de como assinalar tarefas e responsabilidades
dentro de uma organização de desenvolvimento de software.

O RUP é, por si só, um produto de software. É modular e automatizado,
e toda a sua metodologia é apoiada por diversas ferramentas de
desenvolvimento integradas e vendidas pela IBM através de seus
"Rational Suites".

Métodos concorrentes no campo da engenharia de software incluem o
"Cleanroom" (considerado pesado) e os Metodos Ágeis (leves) como a
Programação Extrema (XP-Extreme Programming), Scrum, FDD e outros.

Índice [esconder]
1 Linhas mestras
1.1 Gestão de requisitos
1.2 Uso de arquitetura baseada em componentes
1.3 Uso de software de modelos visuais
1.4 Verificação da qualidade do software
1.5 Gestão e Controle de Mudanças do Software
2 Fases
2.1 A Fase de concepção
2.2 A Fase de Elaboração
2.3 A Fase de Construção
2.4 A Fase de Transição
3 Princípios e melhores praticas
3.1 Desenvolvimento iterativo
3.2 Gerenciamento de requisitos
3.3 Uso de arquitetura baseada em componentes
3.4 Modelagem visual de software
3.5 Verificar qualidade de software
3.6 Controle de alterações no software
4 Ver também
5 Ligações externas



[editar] Linhas mestras
O RUP define as seguintes linhas-mestras e esqueletos (templates) para
os membros da equipe de um ciclo de produção: parte do cliente, e uma
avaliação do progresso do projeto pela sua gerência. Além disso, ajuda
os programadores a manterem-se concentrados no projeto.


[editar] Gestão de requisitos
Uma documentação apropriada é essencial para qualquer grande projeto;
note-se que o RUP descreve como documentar a funcionalidade,
restrições de sistema, restrições de projeto e requisitos de negócio.

Os casos de uso (em inglês Use Cases) e os cenários são exemplos de
artefatos dependentes do processo, que têm sido considerados muito
mais eficazes na captura de requisitos funcionais.


[editar] Uso de arquitetura baseada em componentes
A arquitetura baseada em componentes cria um sistema que pode ser
facilmente extensível, promovendo a reutilização de software e um
entendimento intuitivo. Um componente normalmente se relaciona com um
objeto na programação orientada a objetos.

O RUP oferece uma forma sistemática para construir este tipo de
sistema, focando-se em produzir uma arquitetura executável nas fases
iniciais do projeto, ou seja, antes de comprometer recursos em larga
escala.

Estes componentes são normalmente incluidos em infraestruturas
existentes como o CORBA e o COM (Modelo de Componentes de Objectos).


[editar] Uso de software de modelos visuais
Ao abstrair a programação do seu código e representá-la utilizando
blocos de construção gráfica, o RUP consegue uma maneira efetiva de se
ter uma visão geral de uma solução. O uso de modelos visuais também
pode permitir que indíviduos de perfil menos técnico (como clientes)
tenham um melhor entendimento de um dado problema, e assim se envolvam
mais no projeto como um todo.

A línguagem de modelagem UML tornou-se um padrão industrial para
representar projetos, e é amplamente utilizada pelo RUP.


[editar] Verificação da qualidade do software
Não assegurar a qualidade do software é a falha mais comum em todos os
projetos de sistemas computacionais. Normalmente pensa-se em qualidade
de software após o término dos projetos, ou a qualidade é
responsabilidade de uma equipe diferente da equipe de desenvolvimento.
O RUP visa auxiliar no controle do planejamento da qualidade,
verificando-a na construção de todo o processo e envolvendo todos os
membros da equipe de desenvolvimento.


[editar] Gestão e Controle de Mudanças do Software
Em todos os projetos de software a existência de mudanças é
inevitável. O RUP define métodos para controlar e monitorar mudanças.
Como uma pequena mudança pode afetar aplicações de formas inteiramente
imprevisíveis, o controle de mudanças é essencial para o sucesso de um
projeto.

O RUP também define áreas de trabalho seguras, garantindo a um
programador que as mudanças efetuadas noutro sistema não afetarão o
seu sistema.


[editar] Fases
Até agora estas linhas de guia são gerais, a serem aderidas ao
percorrer do ciclo de vida de um projeto. As fases indicam a ênfase
que é dada no projeto em um dado instante. Para capturar a dimensão do
tempo de um projeto, o RUP divide o projeto em quatro fases
diferentes:

Concepção: ênfase no escopo do sistema
Elaboração: ênfase na arquitetura
Construção: ênfase no desenvolvimento
Transição: ênfase na implantação
O RUP também se baseia nos 4 P's:

Pessoas
Projeto
Produto
Processo
As fases são compostas de iterações. As iterações são janelas de
tempo; as iterações possuem prazo definido enquanto as fases são
objetivas.

Todas as fases geram artefatos. Estes serão utilizados nas próximas
fases e documentam o projeto, além de permitir melhor acompanhamento.


[editar] A Fase de concepção
A fase de concepção contém os workflows necessários que as partes
interessadas (stakeholders) concordem com os objetivos, arquitetura, e
o planejamento do projeto. Se as partes interessadas tiverem bons
conhecimentos, pouca análise será requerida então. Se não tiverem o
conhecimento necessário, mais análise será requerida.

Como cita o RUP, o ideal é que sejam feitas iterações. Porém estas
devem ser bem definidas quanto a sua quantidade e objetivos.


[editar] A Fase de Elaboração
A fase de elaboração será apenas para o projeto do sistema, buscando
complementar o levantamento / documentação dos casos de uso, voltado
para a arquitetura do sistema, revisa a modelagem do negócio para os
projetos e inicia a versão do manual do usuário. Deve-se aceitar:
Visão geral do produto (incremento + integração) está estável? ; O
plano do projeto é confiável? ; Custos são admissíveis?


[editar] A Fase de Construção
Na fase de construção, começa o desenvolvimento físico do software,
produção de códigos, testes alfa e beta. Deve-se aceitar testes, e
processos de testes estáveis, e se os códigos do sistema constituem
"baseline".


[editar] A Fase de Transição
Nesta fase ocorre a entrega ("deployment") do software, é realizado o
plano de implantação e entrega, acompanhamento e qualidade do
software. Produtos (releases, versões) devem ser entregues, e ocorrer
a satisfação do cliente.


[editar] Princípios e melhores praticas
RUP é baseado em um conjunto de princípios de desenvolvimento de
software e melhores práticas, por exemplo:

Desenvolvimento de software iterativo
Gerenciamento de requisitos
Uso de arquitetura baseada em componente
Modelagem visual de software
Verificação da qualidade do software
Controle de alteração no software

[editar] Desenvolvimento iterativo
Dado o tempo gasto para desenvolver um software grande e sofisticado,
não é possível definir o problema e construir o software em um único
passo. Os requerimentos irão freqüentemente mudar no decorrer do
desenvolvimento do projeto, devido a restrições de arquitetura,
necessidades do usuário ou a uma maior compreensão do problema
original. Alterações permitem ao projeto ser constantemente refinado,
além de assinalarem itens de alto risco do projeto como as tarefas de
maior prioridade. De forma ideal, ao término de cada iteração haverá
uma versão executável, o que ajuda a reduzir o risco de configuração
do projeto, permitindo maior retorno do usuário e ajudando ao
desenvolvedor manter-se focado.

O RUP usa desenvolvimento iterativo e incremental pelas seguintes
razões:

A integração é feita passo a passo durante o processo de
desenvolvimento, limitando-se cada passo a poucos elementos.
A integração é menos complexa, reduzindo seu custo e aumentado sua
eficiência.
Partes separadas de projeto e/ou implementação podem ser facilmente
identificadas para posterior reuso.
Mudanças de requisitos são registradas e podem ser acomodadas.
Os riscos são abordados no inicio do desenvolvimento e cada iteração
permite a verificação de riscos já percebidos bem como a identificação
de novos.
Arquitetura de software é melhorada através de um escrutino
repetitivo.
Usando iterações, um projeto terá um plano geral, como também
múltiplos planos de iteração. O envolvimento dos stakeholders é
freqüentemente encorajado a cada entrega. Desta maneira, as entregas
servem como uma forma de se obter o comprometimento dos envolvidos,
promovendo também uma constante comparação contra os requisitos e a
prontidão da organização para as pendências que surgem.


[editar] Gerenciamento de requisitos
O Gerenciamento de requisitos no RUP está concentrado em encontrar as
necessidades do usuário final pela identificação e especificação do
que ele necessita e identificando aquilo que deve ser mudado. Isto
traz como benefícios:

A correção dos requisitos gera a correção do produto, as necessidades
dos usuários são encontradas.
As características necessárias serão incluídas, reduzindo o custo de
desenvolvimentos posteriores.
RUP sugere que o gerenciamento de requisitos tem que seguir estas
actividades:

Analise o problema é concordar com o problema e criar medições que
irão provar seu valor para a organização.
Entendo as necessidades de seus stakeholders é compartilhar o problema
e valores com os stakeholders-chave e levantar quais as necessidades
que estão envolvidas na elaboração da idéia.
Definir o problema é a definição das características das necessidades
e esquematizar os casos de uso, actividades que irão facilmente
mostrar os requerimentos de alto-nível e esboçar o modelo de uso do
sistema.
Gerenciar o escopo do sistema trata das modificações de escopo que
irão ser comunicadas baseadas nos resultados do andamento e
seleccionadas na ordem na qual os fluxogramas de casos de uso são
atacados.
Refinar as definições do sistema trata do detalhamento dos fluxogramas
de caso de uso com os stakeholders de forma a criar uma especificação
de requerimentos de software que pode servir como um contrato entre o
seu grupo e o do cliente e poderá guiar as actividades de teste e
projecto.
Gerenciamento das mudanças de requisitos trata de como identificar as
chegadas das mudanças de requerimento num projeto que já começou.

[editar] Uso de arquitetura baseada em componentes
Arquitetura baseada em componentes cria um sistema que é facilmente
extensível, intuitivo e de fácil compreensão e promove a reusabilidade
de software. Um componente freqüentemente se relaciona com um conjunto
de objetos na programação orientada ao objeto.

Arquitetura de software aumenta de importância quando um sistema se
torna maior e mais complexo. RUP foca na produção da arquitetura
básica nas primeiras iterações. Esta arquitetura então se torna um
protótipo nos ciclos iniciais de desenvolvimento. A arquitetura
desenvolve-se em cada iteração para se tornar a arquitetura final do
sistema. RUP também propõem regras de projeto e restrições para
capturar regras de arquitetura. Pelo desenvolvimento iterativo é
possível identificar gradualmente componentes os quais podem então ser
desenvolvidos, comprados ou reusados. Estes componentes são
freqüentemente construídos em infra-estruturas existentes tais como
CORBA e COM, ou JavaEE, ou PHP


[editar] Modelagem visual de software
Abstraindo sua programação do seu código e representando-a usando
blocos de construção gráfica constitui-se de uma forma efetiva de
obter uma visão geral de uma solução. Usando esta representação,
recursos técnicos podem determinar a melhor forma para implementar a
dado conjunto de interdependências lógicas. Isto também constrói uma
camada intermediária entre o processo de negócio e o código necessário
através da tecnologia da informação. Um modelo neste contexto é uma
visualização e ao mesmo tempo uma simplificação de um projeto
complexo. RUP especifica quais modelos são necessários e porque.

A Linguagem modelagem unificada (UML) pode ser usada para modelagem de
Casos de Uso, diagrama de classes e outros objetos. RUP também discute
outras formas para construir estes modelos.


[editar] Verificar qualidade de software
Garantia da qualidade de software é o ponto mais comum de falha nos
projetos de software, desde que isto é freqüentemente algo que não se
pensa previamente e é algumas vezes tratado por equipes diferentes. O
RUP ajuda no planejamento do controle da qualidade e cuida da sua
construção em todo processo, envolvendo todos os membros da equipe.
Nenhuma tarefa é especificamente direcionada para a qualidade; o RUP
assume que cada membro da equipe é responsável pela qualidade durante
todo o processo. O processo foca na descoberta do nível de qualidade
esperado e provê testes nos processos para medir este nível.


[editar] Controle de alterações no software
Em todos os projetos de software, mudanças são inevitáveis. RUP define
métodos para controlar, rastrear e monitorar esta mudanças. RUP também
define espaços de trabalho seguros (do inglês secure workspaces),
garantindo que um sistema de engenharia de software não será afetado
por mudanças em outros sistemas. Este conceito é bem aderente com
arquiteturas de software baseados em componentização.


[editar] Ver também
Enterprise Unified Process


[editar] Ligações externas
Treinamento de RUP
Material completo
Página da Rational Software Corporation
Excelente descrição sobre o RUP (pdf)
Obtendo Qualidade de Software com o RUP
Obtido em "http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process"
Categorias: Engenharia de software | Gerência de projetos













Programação extrema

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
Processo de Desenvolvimento de Software
Este artigo é parte da série Processo de desenvolvimento de software

Atividade e Passos
Requisito | Arquitetura | Especificação | Implementação | Teste |
Implantação | Manutenção
Modelos
Ágil | Cleanroom | Iterativo | RAD | RUP | Espiral | Cascata | XP |

Scrum
Disciplinas de Apoio
Gerência de configuração | Documentação | Gerência de projetos
Programação Extrema (do inglês eXtreme Programming), ou simplesmente
XP, é uma metodologia ágil para equipes pequenas e médias e que irão
desenvolver software com requisitos vagos e em constante mudança. Para
isso, adota a estratégia de constante acompanhamento e realização de
vários pequenos ajustes durante o desenvolvimento de software.

Os quatro valores fundamentais da metodologia XP são: comunicação,
simplicidade, feedback e coragem. A partir desses valores, possui como
princípios básicos: feedback rápido, presumir simplicidade, mudanças
incrementais, abraçar mudanças e trabalho de qualidade.

Dentre as variáveis de controle em projetos (custo, tempo, qualidade e
escopo), há um foco explícito em escopo. Para isso, recomenda-se a
priorização de funcionalidades que representem maior valor possível
para o negócio. Desta forma, caso seja necessário a diminuição de
escopo, as funcionalidades menos valiosas serão adiadas ou canceladas.

A XP incentiva o controle da qualidade como variável do projeto, pois
o pequeno ganho de curto prazo na produtividade, ao diminuir
qualidade, não é compensado por perdas (ou até impedimentos) a médio e
longo prazo.

Índice [esconder]
1 Valores
2 Princípios Básicos
3 Práticas
4 Livros
5 Ligações externas



[editar] Valores
Comunicação
Simplicidade
Feedback
Coragem

[editar] Princípios Básicos
Feedback rápido
Presumir simplicidade
Mudanças incrementais
Abraçar mudanças
Trabalho de qualidade.

[editar] Práticas
Para aplicar os valores e princípios durante o desenvolvimento de
software, XP propõe uma série de práticas. Há uma confiança muito
grande na sinergia entre elas, os pontos fracos de cada uma são
superados pelos pontos fortes de outras.

Jogo de Planejamento (Planning Game): O desenvolvimento é feito em
iterações semanais. No início da semana, desenvolvedores e cliente
reúnem-se para priorizar as funcionalidades. Essa reunião recebe o
nome de Jogo do Planejamento. Nela, o cliente identifica prioridades e
os desenvolvedores as estimam. O cliente é essencial neste processo e
assim ele fica sabendo o que está acontecendo e o que vai acontecer no
projeto. Como o escopo é reavaliado semanalmente, o projeto é regido
por um contrato de escopo negociável, que difere significativamente
das formas tradicionais de contratação de projetos de software. Ao
final de cada semana, o cliente recebe novas funcionalidades,
completamente testadas e prontas para serem postas em produção.
Pequenas Versões (Small Releases): A liberação de pequenas versões
funcionais do projeto auxilia muito no processo de aceitação por parte
do cliente, que já pode testar uma parte do sistema que está
comprando. As versões chegam a ser ainda menores que as produzidas por
outras metodologias incrementais, como o RUP.
Metáfora (Metaphor): Procura facilitar a comunicação com o cliente,
entendendo a realidade dele. O conceito de rápido para um cliente de
um sistema jurídico é diferente para um programador experiente em
controlar comunicação em sistemas em tempo real, como controle de
tráfego aéreo. É preciso traduzir as palavras do cliente para o
significado que ele espera dentro do projeto.
Projeto Simples (Simple Design): Simplicidade é um princípio da XP.
Projeto simples significa dizer que caso o cliente tenha pedido que na
primeira versão apenas o usuário "teste" possa entrar no sistema com a
senha "123" e assim ter acesso a todo o sistema, você vai fazer o
código exato para que esta funcionalidade seja implementada, sem se
preocupar com sistemas de autenticação e restrições de acesso. Um erro
comum ao adotar essa prática é a confusão por parte dos programadores
de código simples e código fácil. Nem sempre o código mais fácil de
ser desenvolvido levará a solução mais simples por parte de projeto.
Esse entendimento é fundamental para o bom andamento do XP. Código
fácil deve ser identificado e substituído por código simples.
Time Coeso (Whole Team): A equipe de desenvolvimento é formada pelo
cliente e pela equipe de desenvolvimento.
Testes de Aceitação (Customer Tests): São testes construídos pelo
cliente e conjunto de analistas e testadores, para aceitar um
determinado requisito do sistema.
Ritmo Sustentável (Sustainable Pace): Trabalhar com qualidade,
buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/
dia), sem horas extras. Horas extras são permitidas quando trouxerem
produtividade para a execução do projeto. Outra prática que se
verifica neste processo é a prática de trabalho energizado, onde se
busca trabalho motivado sempre. Para isto o ambiente de trabalho e a
motivação da equipe devem estar sempre em harmonia.
Reuniões em pé (Stand-up Meeting): Reuniões em pé para não se perder o
foco nos assuntos, produzindo reuniões rápidas, apenas abordando
tarefas realizadas e tarefas a realizar pela equipe.
Posse Coletiva (Collective Ownership): O código fonte não tem dono e
ninguém precisa solicitar permissão para poder modificar o mesmo. O
objetivo com isto é fazer a equipe conhecer todas as partes do
sistema.
Programação em Pares (Pair Programming): é a programação em par/dupla
num único computador. Geralmente a dupla é formada por um iniciante na
liguagem e outra pessoa funcionando como um instrutor. Como é apenas
um computador, o novato é que fica à frente fazendo a codificação, e o
instrutor acompanha ajudando a desenvolver suas habilidades. Desta
forma o programa sempre é revisto por duas pessoas, evitando e
diminuindo assim a possibilidade de erros (bugs). Com isto busca-se
sempre a evolução da equipe, melhorando a qualidade do código fonte
gerado.
Padrões de Codificação (Coding Standards): A equipe de desenvolvimento
precisa estabelecer regras para programar e todos devem seguir estas
regras. Desta forma parecerá que todo o código fonte foi editado pela
mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.
Desenvolvimento Orientado a Testes (Test Driven Development): Primeiro
crie os testes unitários (unit tests) e depois crie o código para que
os testes funcionem. Esta abordagem é complexa no início, pois vai
contra o processo de desenvolvimento de muitos anos. Só que os testes
unitários são essenciais para que a qualidade do projeto seja
mantida.
Refatoração (Refactoring): É um processo que permite a melhoria
continua da programação, com o mínimo de introdução de erros e
mantendo a compatibilidade com o código já existente. Refabricar
melhora a clareza (leitura) do código, divide-o em módulos mais coesos
e de maior reaproveitamento, evitando a duplicação de código-fonte;
Integração Contínua (Continuous Integration): Sempre que produzir uma
nova funcionalidade, nunca esperar uma semana para integrar à versão
atual do sistema. Isto só aumenta a possibilidade de conflitos e a
possibilidade de erros no código fonte. Integrar de forma contínua
permite saber o status real da programação.

[editar] Livros
Extreme Programming Explained : Embrace Change (2nd Edition) (ISBN
0321278658)
Planning Extreme Programming (ISBN 0201710919)
Extreme Programming Installed (ISBN 0201708426)
Agile Software Development, Principles, Patterns, and Practices (ISBN
0135974445)

[editar] Ligações externas
Apresentando XP. Encante seus clientes com Extreme Programming
Entregue seu código com confiança utilizando desenvolvimento dirigido
a testes
Extreme Programming: A gentle introduction (em inglês)
Grupo de Usuários de Metodologias Ágeis (Rio Grande do Sul)
Introdução ao Extreme Programming
XPRio - eXtreme Programming (Rio de Janeiro)
Curso de Programação eXtrema no IME/USP
Agilcast - podcast
Obtido em "http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_extrema"
Categoria: Desenvolvimento de software


















Scrum

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
Processo de Desenvolvimento de Software
Este artigo é parte da série Processo de desenvolvimento de software
Atividade e Passos
Requisito | Arquitetura | Especificação | Implementação | Teste |
Implantação | Manutenção
Modelos
Ágil | Cleanroom | Iterativo | RAD | RUP | Espiral | Cascata | XP |
Scrum
Disciplinas de Apoio
Gerência de configuração | Documentação | Gerência de projetos
Esta página ou seção precisa de correção textual.
Ela pode conter incorreções gramaticais ou ortográficas, podendo ainda
necessitar de melhoria em termos de vocabulário ou coesão, para
atingir um nível de qualidade superior conforme o livro de estilo da
Wikipédia. Se você tem conhecimentos lingüísticos, sinta-se à vontade
para ajudar.

Scrum é um método ágil para Gerenciamento de Projetos.

Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de
projetos em empresas de fabricação de automóveis e produtos de
consumo, por Takeuchi e Nonaka no livro "The New New Product
Development Game" (Harvard Business Review, Janeiro-Fevereiro 1986).
Eles notaram que projetos usando equipes pequenas e multidisciplinares
(cross-functional) produziram os melhores resultados, e associaram
estas equipes altamente eficazes à formação do Scrum no Rugby. Jeff
Sutherland, John Scumniotales, e Jeff McKenna documentaram, conceberam
e implementaram o Scrum, como descrito abaixo, na empresa Easel
Corporation em 1993, incorporando estilos de gerenciamento observados
por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definição de
Scrum e ajudou a implantá-lo em desenvolvimento de software em todo o
mundo.

Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo
de Hirotaka Takeuchi e Ikujiro Nonaka.

A função primária do Scrum é ser utilizado para o gerenciamento de
projetos de desenvolvimento de software. Ele tem sido usado com
sucesso para isso, assim como Extreme Programming e outras
metodologias de desenvolvimento. Porém, teoricamente pode ser aplicado
em qualquer contexto no qual um grupo de pessoas necessitem trabalhar
juntas para atingir um objetivo comum, como iniciar uma escola
pequena, projetos de pesquisa científica, ou até mesmo o planejamento
de um casamento.

Mesmo que o Scrum tenha sido idealizado para ser usado em gestão de
projetos de desenvolvimento de software, ele também pode ser usado
para gerenciar equipes de manutenção, ou como uma abordagem para
gestão de programas: Scrum de Scrums.

Índice [esconder]
1 Características de Scrum
1.1 Backlog de produto e backlog de sprint
1.2 Planejamento de sprint
2 Scrum Simplificado
3 Algumas práticas de Scrum
4 Agendando discussões diárias
5 Scrum Solo
6 Ver também
7 Livros
8 Ligações externas



[editar] Características de Scrum
Cada sprint é uma iteração que segue o ciclo PDCA e entrega um
incremento de software pronto.
Um backlog é um conjunto de requisitos, priorizado pelo Product Owner
(cliente);
Há entrega de um conjunto fixo de itens do backlog em uma série de
iterações curtas ou sprints;
Uma breve reunião diária ou scrum, onde cada participante fala sobre o
progresso conseguido, o trabalho a ser realizado e/ou o que o impede
de seguir avançando (também chamado de Standup Meeting, já que os
membros do time geralmente ficam em pé).
Uma breve sessão de planejamento, na qual os itens do backlog para uma
sprint (iteração) são definidos;
Uma retrospectiva, na qual todos os membros da equipe refletem sobre a
sprint passada.
O Scrum é facilitado por um Scrum Master, que tem como função primária
remover qualquer impedimento à habilidade de uma equipe de entregar o
objetivo do sprint. O Scrum Master não é o líder da equipe (já que as
equipes são auto-organizadas) mas atua como um firewall entre a equipe
e qualquer influência desestabilizadora. Outra função extremamente
importante de um Scrum Master é o de assegurar que a equipe esteja
utilizando corretamente as práticas de Scrum, motivando-os e mantendo
o foco na meta da Sprint.

Scrum permite a criação de equipes auto-organizadas, encorajando a
comunicação verbal entre todos os membros da equipe e entre todas as
disciplinas que estão envolvidas no projeto.

Um princípio chave do Scrum é o reconhecimento de que desafios
fundamentalmente empíricos não podem ser resolvidos com sucesso
utilizando uma abordagem tradicional de "controle". Assim, o Scrum
adota uma abordagem empírica, aceitando que o problema não pode ser
totalmente entendido ou definido, focando na maximização da habilidade
da equipe de responder de forma ágil aos desafios emergentes.

Um dos grandes defeitos do Scrum, porém, é a abordagem de "receita de
bolo" do gerenciamento de projetos exemplificado no Project Management
Body of Knowledge ou Prince2, que tem como objetivos atingir qualidade
através da aplicação de uma série de processos prescritos.


[editar] Backlog de produto e backlog de sprint
Um backlog é uma lista de itens priorizados a serem desenvolvidos para
um software. O backlog de produto é mantido pelo Proprietário do
Produto e é uma lista de requisitos que tipicamente vêm do cliente. O
backlog de sprint é uma interpretação do backlog do produto e contém
tarefas concretas que serão realizadas durante o próximo sprint para
implementar alguns dos itens principais no backlog do produto. O
backlog de produto e de sprint são, então, duas coisas totalmente
diferentes, o primeiro contendo requisitos de alto-nível e o segundo
contendo informações sobre como a equipe irá implementar os
requisitos.


[editar] Planejamento de sprint
Antes de todo sprint, o Proprietário do Produto, o Scrum Master e a
Equipe decidem no que a equipe irá trabalhar durante o próximo sprint.
O Proprietário do Produto mantém uma lista priorizada de itens de
backlog, o backlog do produto, o que pode ser repriorizado durante o
planejamento do sprint. A Equipe seleciona itens do topo do backlog do
produto. Eles selecionam somente o quanto de trabalho eles podem
executar para terminar. A Equipe então planeja a arquitetura e o
design de como o backlog do produto pode ser implementado. Os itens do
backlog do produto são então destrinchados em tarefas que se tornam o
backlog do sprint.


[editar] Scrum Simplificado
Muitas organizações têm sido resistentes às metodologias introduzidas
em baixos níveis da organização. Porém, a adaptabilidade do Scrum
permite que ele seja introduzido de forma invisível ("stealth"),
usando os três passos:

Agende uma demonstração do software com seu cliente em um mês a partir
de agora;
Como equipe, tome um mês para deixar o software pronto para uma demo,
com funcionalidades prontas, não simplesmente telas;
Na demonstração, obtenha feedback e use-o para guiar o seu próximo mês
de trabalho de desenvolvimento.

[editar] Algumas práticas de Scrum
Clientes se tornam parte da equipe de desenvolvimento (os clientes
devem estar genuinamente interessados na saída);
Entregas freqüentes e intermediárias de funcionalidades 100%
desenvolvidas;
Planos freqüentes de mitigação de riscos desenvolvidos pela equipe;
Discussões diárias de status com a equipe;
A discussão diária na qual cada membro da equipe responde às seguintes
perguntas:
O que fiz desde ontem?
O que estou planejando fazer até amanhã?
Existe algo me impedindo de atingir minha meta?
Transparência no planejamento e desenvolvimento;
Reuniões freqüentes com os stakeholders (todos os envolvidos no
processo) para monitorar o progresso;
Problemas não são ignorados e ninguém é penalizado por reconhecer ou
descrever qualquer problema não visto;
Locais e horas de trabalho devem ser energizadas, no sentido de que
"trabalhar horas extras" não necessariamente significa "produzir
mais".

[editar] Agendando discussões diárias
Um momento bom para as discussões diárias é depois do almoço. Durante
a manhã pode ser complicado. Estas discussões de status não demoram e
uma forma eficiente de fazer estas reuniões seria ficar em pé e em
frente a um quadro negro. Como as pessoas tendem a ficar cansadas
depois do almoço, ter uma viva reunião em pé nessa hora permite que a
equipe mantenha a sua energia alta. Como todos estiveram trabalhando
durante a manhã, suas mentes estão focadas no trabalho e não em
questões pessoais.


[editar] Scrum Solo
Scrum é baseado em pequenas equipes. Ele permite a comunicação entre
os membros da equipe. Entretanto, há uma grande quantidade de
softwares desenvolvidos por programadores solos. Um software sendo
desenvolvido por um só programador pode ainda se beneficiar de alguns
princípios do Scrum, como: um backlog de produto, um backlog de
sprint, um sprint e uma retrospectiva de sprint. Scrum Solo é uma
versão adaptada para uso de programadores solo.


[editar] Ver também
Ken Schwaber
John Scumniotales
Jeff Sutherland

[editar] Livros
Agile Project Management with Scrum, Ken Schwaber, Microsoft Press,
January 2004, 163pp, ISBN 0-7356-1993-X

[editar] Ligações externas
Agile Software Development with Scrum by Ken Schwaber
Pagina sobre Scrum da Mountain Goat Uma boa definição de Scrum
Adaptive Project Management Using Scrum por Craig Murphy. Este artigo
provê uma overview sobre Scrum.
The New New Product Development Game por Takeuchi and Nonaka. O artigo
que início tudo.
Scrum Delivers or Scrum and the Toyota Way por Boris Gloger. Este
artigo mapeia os princípios de Toyota explicados por Liker, com as
praticas de Scrum.
Scrum and XP from the Trenches por Henrik Kniberg. Um livro de 90
paginas descrevendo em detalhe como Scrum e XP podem ser implementados
a partir de uma perspectiva pratica.
Uma série de textos de Cesar Brod sobre Scrum Incluindo uma
introdução, ferramentas, o uso do Scrum no planejamento estratégico e
User Stories
Obtido em "http://pt.wikipedia.org/wiki/Scrum"
Categoria: Gerência de projetos
Categoria oculta: !Páginas a corrigir














ASD-Desenvolvimento ágil de software
Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
Processo de Desenvolvimento de Software
Este artigo é parte da série Processo de desenvolvimento de software
Atividade e Passos
Requisito | Arquitetura | Especificação | Implementação | Teste |
Implantação | Manutenção
Modelos
Ágil | Cleanroom | Iterativo | RAD | RUP | Espiral | Cascata | XP |
Scrum
Disciplinas de Apoio
Gerência de configuração | Documentação | Gerência de projetos
Desenvolvimento ágil de software (do inglês Agile software
development) ou Método ágil é um conjunto de metodologias de
desenvolvimento de software. O desenvolvimento ágil, tal como qualquer
metodologia de software, providencia uma estrutura conceitual para
reger projetos de engenharia de software.

Índice [esconder]
1 Introdução
2 Princípios
3 História
4 Comparações com outros métodos
4.1 Comparação com o desenvolvimento iterativo
4.2 Comparação com o modelo em cascata
4.3 Comparação com a "codificação cowboy"
5 Aplicabilidade dos métodos ágeis
6 Adaptabilidade dos metodos ágeis
7 Métodos ágeis e o gerenciamento de projeto
8 Metodologias
9 Criticas
10 Referências
11 Futuras leituras
12 Ligações externas



[editar] Introdução
Existem inúmeros métodos de desenvolvimento de software rápido, cada
uma destas exposta pela The Agile Alliance. A maioria dos métodos
ágeis tenta minimizar o risco pelo desenvolvimento do software em
curtos períodos, chamados de iteração, os quais gastam tipicamente
menos de uma semana a até quatro. Cada iteração é como um projeto de
software em miniatura de seu próprio, e inclui todas as tarefas
necessárias para implantar o mini-incremento da nova funcionalidade:
planejamento, Análise de Requisitos, projeto, codificação, teste e
documentação. Enquanto em um processo convencional, cada iteração não
está necessariamente focada em adicionar um novo conjunto
significativo de funcionalidades, um projeto de software ágil busca a
capacidade de implantar uma nova versão do software ao fim de cada
iteração, etapa a qual a equipe responsável reavalia as prioridades do
projeto.

Métodos ágeis enfatizam comunicações em tempo real, preferencialmente
face a face, a documentos escritos. A maioria dos componentes de um
grupo ágil devem estar agrupados em uma sala. Isto inclui todas as
pessoas necessárias para terminar o software. No mínimo, isto inclui
os programadores e seus clientes (clientes são as pessoas que definem
o produto, eles podem ser os gerentes, analistas de negocio, ou
realmente os clientes). Nesta sala devem também se encontrar os
testadores, projetistas de iteração, redatores técnicos e gerentes.

Métodos ágeis também enfatizam trabalho no software como uma medida
primária de progresso. Combinado com a comunicação face-a-face,
métodos ágeis produzem pouca documentação em relação a outros métodos,
sendo este um de seus pontos negativos.


[editar] Princípios
Os princípios do desenvolvimento ágil valorizam:

Garantir a satisfação do consumidor entregando rapidamente e
continuamente softwares funcionais;
Softwares funcionais são entregues frequentemente (semanas, ao invés
de meses);
Softwares funcionais são a principal medida de progresso do projeto;
Até mesmo mudanças tardias de escopo no projeto são bem-vindas.
Cooperação constante entre pessoas que entendem do 'negócio' e
desenvolvedores;
Projetos surgem através de indivíduos motivados, e que deve existir
uma relação de confiança.
Design do software deve prezar pela excelência técnica;
Simplicidade
Rápida adaptação às mudanças
indivíduos e iterações ao invés de processos e ferramentas
software funcional ao invés de documentação extensa
colaboração com clientes ao invés de negociação de contratos
responder a mudanças ao invés de seguir um plano

[editar] História
As definições modernas de desenvolvimento de software ágil evoluíram a
partir da metade de 1990 como parte de uma reação contra métodos
"pesados", caracterizados por uma pesada regulamentação, regimentação
e micro gerenciamento usado o modelo em cascata para desenvolvimento.
O processo originou-se da visão de que o modelo em cascata era
burocrático, lento e contraditório a forma usual com que os
engenheiros de software sempre realizaram trabalho com eficiência.

Uma visão que levou ao desenvolvimento de métodos ágeis e iterativos
era retorno a prática de desenvolvimento vistas nos primórdios da
história do desenvolvimento de software [1].

Inicialmente, métodos ágeis eram conhecidos como métodos leves. Em
2001, membros proeminentes da comunidade se reuniram em Snowbird e
adotaram o nome métodos ágeis. Mais tarde, algumas pessoas formaram A
Agile Alliance[2], uma organização não lucrativa que promove o
desenvolvimento ágil.

Os métodos ágeis iniciais—criado a priore em 2000— incluíam
Scrum(1986), Crystal Clear, Programação extrema (1996), Adaptive
Software Development, Feature Driven Development, and Dynamic Systems
Development Method (1995).


[editar] Comparações com outros métodos
Metodos Ágeis são algumas vezes caracterizados como o oposto de
metodologias guiadas pelo planejamento ou disciplinadas. Uma distinção
mais acurada é dizer que os métodos existem em um continuo do
adaptativo até o preditivo. [1] Métodos ágeis existem do lado
adaptativo deste continuo. Métodos adaptativos buscam a adaptação
rápida a mudanças da realidade. Quando uma necessidade de um projeto
muda, uma equipe adaptativa mudará também. Um time adaptativo terá
dificuldade em descrever o que irá acontecer no futuro. O que
acontecerá em uma data futura é um item de difícil predição para um
método adaptativo. Uma equipe adaptativa pode relatar quais tarefas se
iniciarão na próxima semana. Quando perguntado a cerca de uma
implantação que ocorrerá daqui a seis meses, uma equipe adaptativa
deve ser capaz somente de relatar a instrução de missão para a
implantação, ou uma expectativa de valor versus custo.

Métodos preditivos, em contraste, colocam o planejamento do futuro em
detalhe. Uma equipe preditiva pode reportar exatamente quais aspectos
e tarefas estão planejados para toda a linha do processo de
desenvolvimento. Elas porém tem dificuldades de mudar de direção. O
plano é tipicamente otimizado para o objetivo original e mudanças de
direção podem causar a perda de todo o trabalho e determinar que seja
feito tudo novamente. Equipes preditivas freqüentemente instituem um
comitê de controle de mudança para assegurar que somente as mudanças
mais importantes sejam consideradas.

Métodos ágeis têm muito em comum com técnicas de Desenvolvimento
rápido de aplicação de 1980 como exposto por James Martin e outros.


[editar] Comparação com o desenvolvimento iterativo
A maioria dos métodos ágeis compartilha a ênfase no Desenvolvimento
iterativo e incremental para a construção de versões implantadas do
software em curtos períodos de tempo. Métodos ágeis diferem dos
métodos iterativos porque seus períodos de tempo são medidos em
semanas, ao invés de meses, e a realização é efetuada de uma maneira
altamente colaborativa.


[editar] Comparação com o modelo em cascata
O desenvolvimento ágil tem pouco em comum com o modelo em cascata. Na
visão de alguns este modelo é desacreditado, apesar de ser um modelo
de uso comum. O modelo em cascata é o um das metodologias com mais
ênfase no planejamento, seguindo seus passos através da captura dos
requisitos, análise, projeto, codificação e testes em uma seqüência
pré-planejada e restrita. O progresso é geralmente medido em termos de
entrega de artefatos—especificação de requisitos, documentos de
projeto, planos de teste, revisão do código, e outros. O modelo em
cascata resulta em uma substancial integração e esforço de teste para
alcançar o fim do ciclo de vida, um período que tipicamente se estende
por vários meses ou anos. O tamanho e dificuldade deste esforço de
integração e teste é uma das causas das falhas do projeto em cascata.
Métodos ágeis, pelo contrário, produzem um desenvolvimento completo e
teste de aspectos (mas um pequeno subconjunto do todo) num período de
poucas semanas ou meses. Enfatiza a obtenção de pequenos pedaços de
funcionalidades executáveis para agregar valor ao negócio cedo, e
continuamente agregar novas funcionalidades através do ciclo de vida
do projeto.

Algumas equipes ágeis usam o modelo em cascata em pequena escala,
repetindo o ciclo de cascata inteiro em cada iteração. Outras equipes,
mais especificamente as equipes de Programação extrema, trabalham com
atividades simultaneamente.


[editar] Comparação com a "codificação cowboy"
A codificação cowboy, também chamada de balbúrdia, é a ausência de
método de definição: os membros da equipe fazem o que eles sentem que
é correto. Os desenvolvedores ágeis freqüentemente reavaliam os
planos, enfatizam a comunicação face a face e o uso relativamente
esparso de documentos levando ocasionalmente as pessoas a confundirem
isto com codificação cowboy. Equipes ágeis, contudo, seguem o processo
definido (e freqüentemente de forma disciplinada e rigorosa).

Como em todas as metodologias, o conhecimento e a experiência dos
usuários definem o grau de sucesso e/ou fracasso de cada atividade. Os
controles mais rígidos e sistematizados aplicados em um processo
implicam em altos níveis de responsabilidade para os usuários. A
degradação de procedimentos bem-intencionados pode levar as atividades
a serem caracterizadas como codificação cowboy.


[editar] Aplicabilidade dos métodos ágeis
Embora os métodos ágeis apresentem diferenças entre suas práticas,
eles compartilham inúmeras características em comum, incluindo o
desenvolvimento iterativo, e um foco na comunicação interativa e na
redução do esforço empregado em artefatos intermediários. (Cohen et
al., 2004) [2] A aplicabilidade dos métodos ágeis em geral pode ser
examinada de múltiplas perspectivas. Da perspectiva do produto,
métodos ágeis são mais adequados quando os requisitos estão emergindo
e mudando rapidamente, embora não exista um consenso completo neste
ponto (Cohen et al., 2004).[2] De uma perspectiva organizacional, a
aplicabilidade pode ser expressa examinando três dimensões chaves da
organização: cultura, pessoal e comunicação. Em relação a estas áreas
inúmeros fatores chave do sucesso podem ser identificados (Cohen et
al., 2004)[2]:

A cultura da organização deve apoiar a negociação.
As pessoas devem ser confiantes.
Poucas pessoas, mas competentes.
A organização deve promover as decisões que os desenvolvedores tomam.
A Organização necessita ter um ambiente que facilite a rápida
comunicação entre os membros.
O fator mais importante é provavelmente o tamanho do projeto (Cohen et
al., 2004).[2] . Com o aumento do tamanho, a comunicação face a face
se torna mais difícil. Portanto, métodos ágeis são mais adequados para
projetos com pequenos times, com no máximo de 20 a 40 pessoas.

De forma a determinar a aplicabilidade de métodos ágeis específicos,
uma analise mais sofisticada é necessária. O método dinâmico para o
desenvolvimento de sistemas, por exemplo, provê o denominado 'filtro
de aplicabilidade' para este propósito. Também, a família de métodos
Crystal provê uma caracterização de quando selecionar o método para um
projeto. A seleção é baseada no tamanho do projeto, criticidade e
prioridade. Contudo, outros métodos ágeis não fornecem um instrumento
explícito para definir sua aplicabilidade a um projeto.

Alguns métodos ágeis, como DSDM e Desenvolvimento guiado por
característica, afirmam se aplicar a qualquer projeto de
desenvolvimento ágil, sem importar suas características (Abrahamsonn
et al., 2003).[3]

A comparação dos métodos ágeis irá revelar que eles suportam
diferentes fases de um ciclo de vida do software em diferentes níveis.
Estas características individuais dos métodos ágeis podem ser usadas
como um critério de seleção de sua aplicabilidade.

Desenvolvimentos ágeis vêm sendo amplamente documentados (ver
Experiências relatadas, abaixo, como também em Beck[4], e Boehm &
Turner[5] como funcionando bem para equipes pequenas (< 10
desenvolvedores). O desenvolvimento ágil é particularmente adequado
para equipes que têm que lidar com mudanças rápidas ou imprevisíveis
nos requerimentos.

A aplicabilidade do desenvolvimento ágil para os seguintes cenários é
ainda uma questão aberta:

esforços de desenvolvimento em larga escala (> 20 desenvolvedores),
embora estratégias para maiores escalas tenham sido descritas .[6]
esforços de desenvolvimenteo distribuído (equipes não co-alocadas).
Estas estratégias tem sido descritas em Bridging the Distance[7] e
Using an Agile Software Process with Offshore Development[8]
esforços críticos de missão e vida.
Companhias com uma cultura de comando e controle.
Barry Boehm e Richard Turner sugeriram que analise de risco pode ser
usada para escolher entre métodos adaptativos ("ágeis") e preditivos
("dirigidos pelo planejamento"). [5] Os autores sugerem que cada lado
deste continuo possui seu ambiente ideal"

Ambiente ideal para o desenvolvimento ágil:

Baixa criticidade
Desenvolvedores senior
Mudanças freqüente de requerimentos
Pequeno número de desenvolvedores
Cultura que tem sucesso no caos.
Ambiente ideal para o desenvolvimento direcionado ao planejamento:

Alta criticidade
Desenvolvedores Junior
Baixa mudança nos requerimentos
Grande número de desenvolvedores
Cultura que procura a ordem.

[editar] Adaptabilidade dos metodos ágeis
Um método deve ser bastante flexível para permitir ajustes durante a
execução do projeto. Há três problemas chaves relacionados ao tópico
de adaptação dos métodos ágeis: a aplicabilidade dos métodos ágeis (no
geral e no particular), e finalmente, o suporte ao gerenciamento de
projeto.


[editar] Métodos ágeis e o gerenciamento de projeto
Os métodos ágeis diferem largamente no que diz respeito a forma de
serem gerenciados. Algum métodos são suplementados com guias para
direcionar o gerenciamento do projeto, mas nem todos são aplicáveis .
[3].

PRINCE2 tem sido considerado como um sistema de gerenciamento de
projeto complementar e adequado.[9]

Uma das caracteristicas comum dos processos ágeis é a capacidade de
funcionar em ambientes muito exigentes que tem um grande numero de
incertezas e flutuações (mudanças) que podem vir de várias fontes
como: equipe em processo de formação que ainda não trabalhou junto em
outros projetos, requisitos voláteis, baixo conhecimento do dominio de
negocio pela equipe, adoção de novas tecnologias, novas ferramentas,
mudanças muito bruscas e rapidas no ambiente de negocios das empresas:
novos concorrentes, novos produtos, novos modelos de negocio.

Sistemas de gerenciamento de projetos lineares e prescritivos, neste
tipo de ambiente, falham em oferecer as caracteristicas necessárias
para responder de forma ágil as mudanças requeridas. Sua adoção pode
incrementar desnecessariamente os riscos, o custo, o prazo e baixar a
qualidade do produto gerado, desgastando a equipe e todos os
envolvidos no processo.

A abordagem Scrum, para gestão de projetos ágeis, leva em consideração
planejamento não linear, porém de maneira mais exaustiva e está focada
em agregar valor para o cliente e em gerenciar os riscos, fornecendo
um ambiente seguro. Pode ser utilizada na gestão do projeto aliada a
uma metodologia de desenvolvimento como XP, FDD, OpenUP, DSDM, Crystal
ou outras.


[editar] Metodologias
Programação extrema
Scrum
DSDM
Adaptive Software Development
Crystal
Feature-Driven Development
Pragmatic Programming
Test Driven Development

[editar] Criticas
O método de desenvolvimento ágil é algumas vezes criticados como
codificação cowboy. O inicio da Programação extrema soava como
controverso e dogmático, tal como a programação por pares e o projeto
continuo, tem sido alvo particular de críticos, tais como McBreen[10]
e Boehm e Turner.[5] Contudo, muito destas criticas tem sido vista
pelos defensores dos métodos ágeis como mal entendidos a respeito do
desenvolvimento ágil.[11]

Em particular, a Programação extrema é revista e criticada por Matt
Stephens' Extreme Programming Refactored.[12]

As criticas incluem

falta de estrutura e documentação necessárias
somente trabalhar com desenvolvedores de nível sênior.
incorpora de forma insuficiente o projeto de software
requer a adoção de muita mudança cultural.
poder levar a maiores dificuldades nas negociações contratuais

[editar] Referências
? B. Boehm. Balancing Agility and Discipline: A Guide for the
Perplexed. 2.ed. Boston,MA: Addison-Wesley, 2004. 165-194 p. ISBN
0321186125
? 2,0 2,1 2,2 2,3 Cohen, D., Lindvall, M., & Costa, P. (2004). An
introduction to agile methods. In Advances in Computers (pp. 1-66).
New York: Elsevier Science.
? 3,0 3,1 Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J.
(2003). New Directions on Agile Methods: A Comparative Analysis.
Proceedings of ICSE'03, 244-254
? ">K. Beck. Extreme Programming Explained: Embrace Change. Boston,
MA: , 1999. 157 p. ISBN 0-321-27865-8
? 5,0 5,1 5,2 B. Boehm. Balancing Agility and Discipline: A Guide for
the Perplexed. Boston, MA: Addison-Wesley, 2004. 55-57 p. ISBN
0-321-18612-5
? Supersize Me
? Bridging the Distance
? Using an Agile Software Process with Offshore Development
? Agile Alliance at http://agilealliancebeta.org/article/file/904/file.pdf:
? P. McBreen. {{{Título}}}. Boston, MA: Addison-Wesley, 2003. ISBN
0-201-84457-5
? sdmagazine
? Extreme Programming Refactored

[editar] Futuras leituras
Fowler, Martin. Is Design Dead?. Appeared in Extreme Programming
Explained, G. Succi and M. Marchesi, ed., Addison-Wesley, Boston.
2001.
Riehle, Dirk. A Comparison of the Value Systems of Adaptive Software
Development and Extreme Programming: How Methodologies May Learn From
Each Other. Appeared in Extreme Programming Explained, G. Succi and M.
Marchesi, ed., Addison-Wesley, Boston. 2001.
Tomek, Ivan. What I Learned Teaching XP. http://www.whysmalltalk.com/articles/tomek/teachingxp.htm
M. Stephens, D. Rosenberg. Extreme Programming Refactored: The Case
Against XP. Apress L.P., Berkeley, California. 2003. (ISBN
1-59059-096-1)
D. Rosenberg, M. Stephens. Agile Development with ICONIX Process.
Apress L.P., Berkeley, California. 2005. (ISBN 1-59059-464-9)
Beck, et. al., Manifesto for Agile Software Development. [3]
Larman, Craig and Basili, Victor R. Iterative and Incremental
Development:A Brief History IEEE Computer, June 2003
Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003).
New Directions on Agile Methods: A Comparative Analysis. Proceedings
of ICSE'03, 244-254.
Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile
Software Development Methods: Review and Analysis. VTT Publications
478.
Aydin, M.N., Harmsen, F., Slooten, K. v., & Stagwee, R. A. (2004). An
Agile Information Systems Development Method in use. Turk J Elec
Engin, 12(2), 127-138
Aydin, M.N., Harmsen, F., Slooten van K., & Stegwee, R.A. (2005). On
the Adaptation of An Agile Information Systems Development Method.
Journal of Database Management Special issue on Agile Analysis,
Design, and Implementation, 16(4), 20-24
Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to agile
methods. In Advances in Computers (pp. 1-66). New York: Elsevier
Science.
Karlstrom, D., & Runeson P. (2005). Combining agile methods with stage-
gate project management. IEEE Software, 22(3), 43-49

[editar] Ligações externas
(em inglês) Manifesto do Agile Software Development
(em inglês) The Agile Alliance
(em inglês) Agile Planet weblog aggregator
Agilcast (podcast sobre Desenvolvimento Ágil de Software)
Agile Alliance Brasil
Dissertação de Mestrado: Um Estudo de Caso da Adoção das Práticas e
Valores do Extreme Programming (PDF)
Obtido em "http://pt.wikipedia.org/wiki/Desenvolvimento_
%C3%A1gil_de_software"
Categoria: Desenvolvimento de software



























Processo de desenvolvimento de software
Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
Processo de Desenvolvimento de Software
Este artigo é parte da série Processo de desenvolvimento de software
Atividade e Passos
Requisito | Arquitetura | Especificação | Implementação | Teste |
Implantação | Manutenção
Modelos
Ágil | Cleanroom | Iterativo | RAD | RUP | Espiral | Cascata | XP |
Scrum
Disciplinas de Apoio
Gerência de configuração | Documentação | Gerência de projetos
Um Processo de desenvolvimento de software é um conjunto de
atividades, parcialmente ordenadas, com a finalidade de obter um
produto de software. É estudado dentro da área de Engenharia de
Software, sendo considerado um dos principais mecanismos para se obter
software de qualidade e cumprir corretamente os contratos de
desenvolvimento, sendo uma das respostas técnicas adequadas para
resolver a Crise do software.

Índice [esconder]
1 Passos/Atividades Processo
2 Padrões
3 Modelos de Processo
3.1 Processo em cascata
3.2 Processos Iterativos
3.3 Processos ágeis
3.4 Método formal
4 Veja também
4.1 Alguns métodos de desenvolvimento de software
4.2 Temas relacionados
4.3 Softwares de apoio



[editar] Passos/Atividades Processo
Análise de requisitos de software: A extração dos requisitos de um
desejado produto de software é a primeira tarefa na sua criação.
Embora o cliente, provavelmente, acredite saber o que o software deva
fazer, esta tarefa requer habilidade e experiência em engenharia de
software para reconhecer a incompletude, ambigüidade ou contradição
nos requisitos.
Especificação: A especificação é a tarefa de descrever precisamente o
software que será escrito, preferencialmente de uma forma
matematicamente rigorosa. Na prática, somente especificações mais bem
sucedidas foram escritas para aplicações bem compreendidas e afinadas
que já estavam bem desenvolvidas, embora sistemas de software de
missão crítica sejam freqüentemente bem especificados antes do
desenvolvimento da aplicação. Especificações são mais importantes para
interfaces externas que devem permanecer estáveis.
Arquitetura de Software: A arquitetura de um sistema de software
remete a uma representação abstrata daquele sistema. Arquitetura é
concernente à garantia de que o sistema de software irá ao encontro de
requisitos do produto, como também assegurar que futuros requisitos
possam ser atendidos. A etapa da arquitetura também direciona as
interfaces entre os sistemas de software e outros produtos de
software, como também com o hardware básico ou com o sistema
operacional.
Implementação (ou codificação): A transformação de um projeto para um
código dever ser a parte mais evidente do trabalho da engenharia de
software, mas não necessariamente a sua maior porção.
Teste: Teste de partes do software, especialmente onde tenha sido
codificado por dois ou mais engenheiros trabalhando juntos, é um papel
da engenharia de software.
Documentação: Uma importante tarefa é a documentação do projeto
interno do software para propósitos de futuras manutenções e
aprimoramentos. As documentações mais importantes são das interfaces
externas.
Suporte e Treinamento de Software: Uma grande porcentagem dos projetos
de software falham pelo fato de o desenvolvedor não perceber que não
importa quanto tempo a equipe de planejamento e desenvolvimento irá
gastar na criação do software se ninguém da organização irá usá-lo. As
pessoas ocasionalmente resistem à mudança e evitam aventurar-se em
áreas pouco familiares. Então, como parte da fase de desenvolvimento,
é muito importante o treinamento para os usuários de software mais
entusiasmados, alternando o treinamento entre usuários neutros e
usuários favoráveis ao software. Usuários irão ter muitas questões e
problemas de software os quais conduzirão para a próxima fase.
Manutenção: A manutenção e melhoria de software lidam com a descoberta
de novos problemas e requisitos. Ela pode tomar mais tempo que o gasto
no desenvolvimento inicial do mesmo. Não somente pode ser necessário
adicionar códigos que combinem com o projeto original, mas determinar
como o software trabalhará em algum ponto depois da manutenção estar
completa, pode requerer um significativo esforço por parte de um
engenheiro de software. Cerca de ? de todos os engenheiros de software
trabalham com a manutenção, mas estas estatísticas podem estar
enganadas. Um pequena parte destes trabalha na correção de erros. A
maioria das manutenções são para ampliar os sistemas para novas
funcionalidades, as quais, de diversas formas, podem ser consideradas
um novo trabalho. Analogamente, cerca de ? de todos os engenheiros
civis, arquitetos e construtores trabalham com manutenção de uma forma
similar.

[editar] Padrões
O processo de desenvolvimento de software tem sido objetivo de vários
padrões, que visam a certificação de empresas como possuidoras de um
processo de desenvolvimento, o que garantiria certo grau de confiança
aos seus contratantes.

Alguns padrões existentes atualmente:

CMMI (anteriormente CMM)
SPICE
ISO 12207
MPS/Br

[editar] Modelos de Processo
Há uma década, vem se tentando encontrar um processo ou metodologia
previsível e repetível que melhore a produtividade e qualidade. Alguns
tentaram sintetizar e formalizar a tarefa aparentemente incontrolável
de escrever um software. Outros aplicaram técnicas de gerenciamento de
projeto na escrita de software. Sem o gerenciamento de projeto,
projetos de software podem facilmente sofrer atraso ou estourar o
orçamento. Como um grande número de projetos de software não atendem
suas expectativas em termos de funcionalidades, custo, ou cronograma
de entrega, ainda não existe um modelo de processo perfeito para todas
aplicações.


[editar] Processo em cascata
O mais antigo e bem conhecido processo é o Modelo em cascata, onde os
desenvolvedores (a grosso modo) seguem estes passos em ordem. Eles
estabelecem os requisitos, os analisam, projetam uma abordagem para
solução, arquitetam um esboço do software, implementam o código,
testam (inicialmente os testes unitários e então os testes de
sistema), implantam e mantêm. Depois que cada passo é terminado, o
processo segue para o próximo passo, tal como construtores que não
revisam as fundações de uma casa depois que as paredes foram erguidas.
Se as iterações não são incluídas no planejamento, o processo não tem
meios para corrigir os erros nas etapas inicias (por exemplo, nos
requisitos), então o processo inteiro da engenharia de software deve
ser executado até o fim, resultando em funcionalidades de software
desnecessárias ou sem uso.Para isso tem-que-se que fazer o implemento
dos requisitos anteriormente analisados pelo programador.


[editar] Processos Iterativos
O Desenvolvimento iterativo e incremental prescreve a construção de
uma porção pequena, mas abrangente, do projeto de software para ajudar
a todos os envolvidos a descobrir cedo os problemas ou suposições,
falhas que possam a levar ao desastre. O processo iterativo é
preferido por desenvolvedores porque lhes fornece um potencial para
atingir os objetivos de projeto de um cliente que não sabe exatamente
o que quer, ou quando não se conhece bem todos os aspectos da solução.

Processos de desenvolvimento ágil de software são construídos com os
fundamentos do desenvolvimento iterativo. Os processos ágeis usam o
feedback, mais que o planejamento, como seus mecanismos de controle
primário. O feedback é produzido por testes regulares e das versões do
software desenvolvido.


[editar] Processos ágeis
Os processos ágeis parecem ser mais eficientes do que as metodologias
antigas. Utiliza menos tempo do programador no desenvolvimento de
softwares funcionais de alta qualidade, mas tem a desvantagem de ter
uma perspectiva de negocio que não provê uma capacidade de
planejamento em longo prazo. Em essência, eles provem mais
funcionalidades por custo/benefício, mas não dizem exatamente o que a
funcionalidade irá fazer.

Exitem varias metodologias que podem ser consideradas como abordagens
ágeis entre elas: Scrum, Programação extrema, FDD, Crystal Clear, DSDM
entre outras.

A Programação Extrema (XP), é o mais bem conhecido processo ágil. Em
XP, as fases são continuadas em passos extremamente pequenos (ou
contínuos) comparados aos processos antigos. O primeira passada
(iteração incompleta) através das etapas deve levar um dia ou uma
semana, ao invés de meses ou anos para cada fase completa do modelo em
cascata. Primeiramente, escreve-se um autômato de teste, que provê
objetivos concretos para o desenvolvimento. Depois é codificado (por
um par de programadores), este passo está completo quando todos os
testes se concluem, e os programadores não pensem em nada mais que
possa ser testado. Projetistas e Arquitetos executam uma refatoração
do código. O projeto é feito por pessoas que estão codificando. O
sistema incompleto mas funcional é entregue e demonstrado para os
usuários. Neste ponto, os envolvidos iniciam novamente uma nova fase
de escrita e teste para as próximas partes mais importantes do
sistema.


[editar] Método formal
Os Métodos Formais são abordagens matemáticas para resolver problemas
de software e hardware ao nível de requisito, especificação e
projetos. Exemplos de métodos formais incluem Método-B, Redes Petri,
RAISE e VDM. Várias notações de especificação formal estão
disponíveis, tais como a notação-Z. De forma mais genérica, a teoria
do autômato pode ser usada para construir e validar o comportamento da
aplicação para o projeto de um sistema de máquina de estado finito.

Máquinas de estado finito baseadas nestas metodologias permitiram
especificar software executáveis e contornar a codificação
convencional.


[editar] Veja também

[editar] Alguns métodos de desenvolvimento de software
Modelo em cascata
Modelo em espiral
Modelo desenvolvimento dirigido
Modelo baseado experiência usuario
Modelo Bottom Up
Modelo Balbúrdia
Prototipacão
Modelo Top Down
Modelo V
Programação extrema
Scrum

[editar] Temas relacionados
Modelo abstrato
Modelo IPO+S
Processo
Paradigmas de programação
Projeto
Ciclo de vida de desenvolvimento de sistema
Documentação de Software
Projeto de Sistemas
Esforço de teste
RUP
Praxis (engenharia de software)

[editar] Softwares de apoio
dotProject
Trac
Subversion
Obtido em "http://pt.wikipedia.org/wiki/
Processo_de_desenvolvimento_de_software"
Categorias: Engenharia de software | Desenvolvimento de software