Segundo a enciclopédia livre
WIKIPEDIA juntamente com Givanaldo Rocha de Souza na sua publicação de Metodologias
Ágeis de Desenvolvimento de Software, é delatado na historia que na metade da
década de 1.990 foi iniciado um movimento contra métodos da época chamados
“pesados”, no qual este método era caracterizado por ter uma regulamentação
burocrática e pesada. O movimento ágil ou chamado de métodos leves originou-se
do método cascata que era tido como lento e contraditório da forma usual.
Em 2.001, Kent Beck reuniu 16 membros
proeminentes nos quais eram produtores, consultores de software e juntamente
formaram Aliança Ágil ou como é conhecido como Métodos Ágeis. Nesta junção
assinaram um Manifesto de Desenvolvimento Ágil de Software que solicitava
melhorias nas:
Ø Garantia da satisfação do consumidor
com entrega rápida e contínua de softwares funcionais.
Ø Mudanças de requisitos, mesmo no fim
do desenvolvimento, ainda são bem-vindas.
Ø Frequentemente são entregues
softwares funcionais (semanas, ao invés de meses).
Ø Desenvolvedores e pessoas
relacionadas aos negócios devem trabalhar, em conjunto, até o fim do projeto.
Ø Construir projetos com indivíduos
motivados dar-lhes ambiente e suporte necessários e confiar que farão seu
trabalho.
Ø Uma conversa face a face é o método
mais eficiente e efetivo de transmitir informações para e dentro de uma equipe
de desenvolvimento.
Ø Software em funcionamento é a
principal medida de progresso.
Ø Desenvolvimento sustentável, de modo
a manter um ritmo constante indefinidamente.
Ø Atenção contínua para com a
excelência técnica e para com bons projetos aumenta a agilidade.
Ø Simplicidade – a arte de maximizar a
quantidade de trabalho não efetuado – é essencial.
Ø As melhores arquiteturas, requisitos
e projetos emergem de equipes auto-organizáveis.
Ø Em intervalos regulares, a equipe
deve refletir sobre como se tornar mais eficiente.
Neste
período de quase quatorze anos da Aliança Ágil ouve-se melhorias nas partes de
comunicação entre desenvolvedores, comunicação entre desenvolvedores e
clientes, analise extremamente estudadas sobre a ideia do cliente e do
desenvolvedor, analise extremas de ricos de utilizar e não utilizar aplicações
e sub aplicações, melhorias na parte de documentar detalhes e sub detalhes
detalhados dentro de um resumo ou anotações, melhorias na parte de especificações
do produto a ser desenvolvido. Em resumo do que foi declarado estão
indivíduos e interações, mais do que processos e instrumentos; desenvolvimento
de software em vez de documentação exaustiva; colaboração com o cliente em vez
de negociação contratual e abertura à mudança em vez de seguir um plano rígido.
“Metodologia
é a maneira ou forma de utilizar um conjunto de métodos de forma coerente e ordenada,
atingindo assim um determinado objetivo.”
UM BREVE CONTO SOBRE ENGENHARIA DE SOFTWARE.
Segundo a enciclopédia
livre WIKIPEDIA, Engenharia de Software surgiu em meados da década de 1.960,
numa tentativa de contornar a crise do Software e submeter tratamentos de
Engenharia ao desenvolvimento de sistema de Software complexos. Neste sistema
complexo é abordado de forma abstrata estrutura de dados e algoritmo formando
um encapsulado de procedimentos nos quais agrega funções, módulos, objetos, atributos
que compõe a arquitetura do Software, que deveram ser executados em sistemas
computacionais.
Também, segundo o relato
disponível da disciplina de Engenharia de Software ministrada pelo especialista
e professor da Faculdade Anhanguera de Bauru, Eduardo José dos Santos. No
qual tem por objetivo qualidade de Software; produtividade no desenvolvimento,
operacional e manutenção de Software e controle sobre o desenvolvimento: na
parte de custos, prazos e níveis de qualidades. Com abrangência em planejamento;
especificação; desenho; implementação; validação; teste; medição; manutenção e
aprimoramento.
“Engenharia de Software é o conjunto de métodos,
técnicas e ferramentas para correta construção e manutenção do produto.”
METODOLOGIA DE DESENVOLVIMENTO DE SISTEMA
“Uma
metodologia completa constitui-se de uma abordagem organizada para atingir um
objetivo, por meio de passos preestabelecidos. É um roteiro, um processo
dinâmico e interativo para desenvolvimento estruturado de projetos, sistemas ou
software, visando à qualidade, produtividade efetividade de projetos (REZENDE, 1.997)”.
De
acordo com o autor Denis Alcides Rezende, relatando em seu livro Engenharia de
Software e Sistema de Informação, ed.3º - 2.005, Metodologia é um roteiro que
permite o uso de varias técnicas por opção dos desenvolvedores. A metodologia
auxilia o desenvolvimento de projeto, sistema ou software, de modo que os
mesmos atendam de maneira adequada as necessidades do cliente ou usuário, com
os recursos disponíveis e dentro de prazos ideal definido em conjunto com os
envolvidos. Não limitando a criatividade profissional. Cuidado, pois os limites
são dos requisitos de qualidade, produtividade e efetividade de um projeto.
Conceitos
Segundo o dicionário Aurélio “metodologia é o estudo de
métodos; caminho pelo qual se atinge um objetivo. Modo de proceder, maneira de
agir”.
No
conceito de Sidney Galeote sobre Metodologia de Desenvolvimento de Software,
relata em um resumo detalhado assim:
“O Software é um combustível
utilizado pelos negócios modernos, construir e manter Software de qualidade, de
forma repetível e previsível é difícil hoje e se tornará cada vez mais difícil.
São sintomas típicos de problemas no desenvolvimento de Software: falha no
entendimento das necessidades dos usuários; inabilidade do projeto; falta de um
processo definido para o desenvolvimento de Software. Geralmente os projetos de
desenvolvimentos de Software falham devido às seguintes causas: gerencia “por
demanda” dos requisitos; comunicação ambígua e imprecisa; arquitetura
francamente definida; complexidade subestimada; inconsistência não identificada
nos requisitos, projetos e no código e teste insuficiente. Ao tratar essas
causas, através de uma metodologia de desenvolvimento de Software, os sintomas
serão eliminados e será mais fácil desenvolver e manter um Software de
qualidade de forma previsível e que possa ser repetida”.
Também segundo o conceito de
Alessandro Ferreira Leite sobre Metodologia de Desenvolvimento de Software pode
se entender:
“[...]
como uma maneira ou forma de utilizar um conjunto coerente e coordenado de
métodos para atingir um objetivo, de modo que se evite a subjetividade na
execução do trabalho. Fornecendo um roteiro, um processo dinâmico e interativo
para desenvolvimento estruturado de projetos, sistemas ou Software, visando a
qualidade e produtividade do projeto”.
Características
No conceito
de característica de Sidney Galeote sobre Metodologia de Desenvolvimento de Software,
cita as principais características de uma metodologia
que são:
O peso da metodologia → refere-se ha quanto elemento a metodologia
especifica.
O tamanho da metodologia → refere-se ao numero de elementos de controle
da metodologia.
Na
(figura1) o escopo de uma metodologia abrange a quantidade de papeis; atividade
se os seus entregáveis.
(figura1)
Segundo a enciclopédia livre WIKIPEDIA, em relação à característica são cinco
pontos importantes.
Ø 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.
Aplicações
Segundo o relato disponível da
disciplina de Engenharia de Software ministrada pelo especialista
e professor da Universidade Paulista, Rafael
Herman Mauro.
A partir
do momento em que surge a necessidade de racionalizar o processo produtivo
referente a qualquer atividade produtiva humana, se faz necessário o emprego de
uma metodologia que vise a atender os objetivos organizacionais associados a:
Ø Padronização
(documentos, métodos, técnicas, etc.);
Ø Planejamento;
Ø Controle;
Ø Produtividade;
Ø Eficiência;
Ø Qualidade;
e etc.
Considerando aplicação sobre o Desenvolvimento de Software como um
processo de construção de sucessivos modelos de um sistema do mundo “real”,
iniciado em um nível elevado de abstração relativamente às características
“físicas” da tecnologia computacional, até chegar a um modelo de automação
final o ciclo de vida do software, contém em geral, as seguintes atividades:
Ø Especificação
de necessidades (análise de requisitos);
Ø Especificação
de Requisitos; projeto (design);
Ø Implementação
do software;
Ø Implantação
e manutenção do software; e
Ø Correção,
Verificação e Validação.
Os três princípios de uma metodologia são: eficiência por pessoa; custo do tempo do trabalho de comunicação e números de pessoas necessárias. Nas (figuras 2, 3 e 4) são descritos os breves procedimentos de cada um e seus objetivos.
Quando mais pessoas estão envolvidas num projeto, uma metodologia maior
é necessária.
(figura
2)
Um pequeno
aumento na metodologia cresce muito o custo de projeto.
(figura
3)
Relacionamento entre tamanho da metodologia x tamanho do projeto x
tamanho do problema.
(figura 4)
Vantagem e Desvantagem
Segundo
o relato de Michel dos Santos Soares, na Comparação entre Metodologias Ágeis e
Tradicionais para o Desenvolvimento de Software, ele trás um ponto
interessante.
“Quanto mais organizações usem as
metodologias ágeis, melhores serão os resultados empíricos em termos de
vantagens, desvantagens, riscos e procedimentos para sua adoção nas
organizações. Mesmo assim, o resultado inicial em termos de qualidade,
confiança, data de entrega e custo são promissores”.
Uma boa
vantagem é a interação entre desenvolvedor e cliente, o desenvolvedor irá
analisar a ideia proposta pelo cliente e destrinchará a ideia em um projeto
base que encorpará num projeto com base, estrutura ou pilares, código
detalhando os procedimentos, implementação, segurança e um help.
Uma boa desvantagem é a falta de
relação entre desenvolvedor e cliente, outra é a falta de conteúdo que o cliente
terá para utilizar o produto.
CICLO DE VIDA OU FASES DA METODOLOGIA
O desenvolvimento de
projetos, sistema ou software pode ser dividido em cinco fases. As fases são
desmembradas em subfases e cada uma destas subfases gera pelo menos um produto.
(DIAS; GAZZANEO, 1.986; REZENDE, 1.997).
De acordo com o livro Engenharia de Software e Sistemas de
Informação, ed. 3º - 2.005. As fases para o desenvolvimento de projetos,
sistema ou software são: estudo preliminar, ou anteprojeto, ou estudo inicial,
ou primeira visão; analise de sistema atual, ou reconhecimento do ambiente;
projeto lógico, ou especificação do projeto, ou design, projeto físico, ou
execução, ou implementação do projeto, ou programação; projeto de
implementação, ou projeto de disponibilização e uso.
As fases de uma metodologia também podem ser chamadas de
ciclo de vida de sistema ou processos de software.
Definição de fases de Desenvolvimento de Sistemas
Estudos Preliminares: → Elaborado para compreender a
necessidade e a estrutura do projeto, sistema ou software, contendo duas
origens: solicitação por terceiro e sugerido pelos executores.
Analise do Sistema Atual: → Elaborado para conhecer o
ambiente, observando suas vantagens e desvantagens e vistoria de analise do
produto existente.
Projetos Lógicos: → Elaborado para ter a visão detalhada
da solução dos produtos e das integrações.
Projeto Físico: → Elaborado para ter visão
sistemática do ponto de vista físico e da segurança de seus resultados.
Projeto de Implantação: → Elaborado para a total entrega do
produto, sistema ou software, com características reais da qualidade,
produtividade e continuidade.
Pessoas
Chaves
Para o desenvolvimento desta
metodologia é necessário conter
Importância
DOCUMENTAÇÃO
Segundo o minidicionário
ANTONIO OLINTO, ed. 2.000 da editora MODERNA, “Documentação é um conjunto de
documentos sobre uma questão. Comprovação por meio de documentos”.
Projetos Tradicionais
Primeiro: as necessidades
e desejos dos clientes são mapeados por um analista de requisitos que ira
definir (segundo) e documentar (terceiro) o que o software deve fazer para
atendê-los. O conjunto de toda a documentação forma a especificação de
requisitos do produto, além de definir e detalhar o que o software deve fazer.
Esse documento serve como espécie de contrato entre o cliente e o
desenvolvedor.
Depois de documentar, o
produto é entregue. Qualquer comportamento diferente do esperado é considerado
um defeito. Isso é feito para proteger o cliente, ele quer a garantia de
receber aquele aquilo que ele pediu e também para proteger o fornecedor que não
quer ser obrigado a entregar a entregar nada além daquilo que foi especificado.
A
especificação é usada também para comunicar essa definição a quem vai
desenvolver o produto. Como geralmente quem especifica não é a mesma pessoa que
desenvolve, à documentação é quem faz essa comunicação.
Num
processo tradicional o desenvolvimento é geralmente dividido em etapas
sequenciais:
1º etapa: um arquiteto de software analisa os requisitos
e a partir dessa analise define e documenta o desenho para solução em UML (Unified
Modeling Languagem).
2º etapa: essa documentação é entregue ao desenvolvedor
que irá programar usando como referencia a especificação de requisito e o
desenho ou código em UML.
3º etapa: ciclo de vida de uma documentação serve para
definir e detalhar o que será feito; para comunicar informações e para manter
uma base de conhecimento sobre o projeto para referencia futura.
Vantagem e Desvantagem de utilizar a Documentação
Vantagem:
Ø Utilizar a
documentação em escrita como meio principal de comunicação entre desenvolvedor
e cliente;
Ø A
documentação em escrita é difícil de compreender a verdadeira ideia, porém devem-se
detalhar as ideias de forma precisa de toda a documentação e os detalhes técnicos
do produto ou software no qual era definir a ideia do produto;
Ø Mais
também, se utilizarmos a documentação escrita como referencia futura isso
significa que precisará manter as ideias consistentes durante o projeto e
também durante toda a vida do projeto.
Desvantagem:
Ø Sabemos que
a linguagem escrita não é a forma eficiente de comunicar uma ideia;
Ø Se a
documentação em escrita estiver faltando à descrição dos detalhes mais e menos
preciso do produto; ocorrerá um mau entendimento da ideia ou entendimento não
pré-escrito da ideia e ocorrerá que o usuário não tendo certa compreensão da
ideia utilizará o produto ou software de forma errada;
Ø Outra
vantagem ou desvantagem de utilizar a referencia na documentação para basear-se
na ideia é que quase sempre é inevitável lhe dar com alterações, requisitos
mudam decisões de desenho ou código UML mudam cada alteração deve ser refletida
em todos os lugares e para fazer a documentação em escrito extremamente
detalhada e com segurança. Devemos recorrer a ferramentas sofisticadas para
manter a rastreabilidade entre todos eles, revisando os riscos para não deixar
para traz alguma informação inconsistente.
Projetos Ágeis
Neste caso,
a abordagem é totalmente diferente. A especificação de documentos e modelos são
apenas uma das formas possíveis de se comunicar.
Uma das
formas ágil de comunicar-se neste projeto de documentação é utilizar a
comunicação verbal, natural e direta. Neste caso, transmitir uma ideia por meio
de uma boa conversa frente a frete do que tentar expressá-la por escrito.
Por isso as
metodologias ágeis procuram incentivar essas formas mais naturais espontânea de
comunicação e reduzir ao Maximo a necessidade de documentação.
Só que esta
comunicação informal direta também tem suas limitações.
Ø Comunicação
informal e direta pode funcionar em uma equipe de ate cinco pessoas;
Ø Desenvolvimento
em pequenos incrementos;
Ø Trabalho em
grupo com relações pessoal no mesmo espaço físico;
Ø Ter pessoas
que explique de uma forma compreensiva e bem detalhada e ter uma pessoa com
lógica de gerenciamento;
Ø Abrange
detalhes específicos do product Owner;
Ø Prioriza a
colaboração com o cliente no lugar da negociação de contratos;
Ø Utilizar
pratica típicas de metodologia ágeis como desenho simples, desenvolvimento
dirigido a teste (TDD) e a refatoração juntando às tende a tornar o código mais
legível e também mais curto para documentar.
Quando Documentar
As metodologias ágeis tem um enfoque
muito pratico para definir quando vale a pena documentar. Pois é relacionado
como uma equação simples, ao documentar sempre que o beneficio (+) valor de ter
essa documentação (>) superar o custo. Porem o custo envolve criar
documentos e manter atualizado, pois todo o documento e modelos criados
precisam ser seriamente, mantidos.
Na abordagem do desenvolvimento ágil
não há documentação antes de desenvolver; geralmente é utilizados métodos de
descrições que identificam quais são os itens que devem ser desenvolvido, está
descrições são chamadas de historias de usuário.
O objetivo da historia não é
documentar é simplesmente identificar o item que ira ser desenvolvimento.
No caso da historia ser relacionada
para ser feito em uma interação. Neste caso o cliente irá necessitar de uma documentação
entregue, os desenvolvedores irão produzir e entregar não só o produto
funcionando no final da interação, mais também a documentação necessária
podendo definir critérios para aceitação tanto do produto quanto da
documentação.
Resumo
sobre Documentação
Em apenas três pontos um resumo
detalhado das rotinas de uma documentação:
Desenvolvimento ágil
reduz a necessidade de documentar.
Os métodos ágeis não são
contra a documentação, desde que ela gera um valor que justifique seu custo.
Documentação não é
tratada como insumo para desenvolvimento e sim como resultado do projeto.
Nenhum comentário:
Postar um comentário