Metodologia de Desenvolvimento de Sofware

Geralmente o desenvolvimento de software é caótico, principalmente em pequenas empresas, onde não existem projetos e o codigo simplesmente é escrito sem controle e com poucas visões da sua principal utilidade. Sempre utilizamos formas "caseiras" para a metodologia de desenvolvimento de software. A figura do lado representa um processo "exuto" do RUP. Quando começamos a olhara para estes artefatos a serem preenchidos a primeira idéia que vem a cabeça é que: "nossa, pra que isso?". Mas conforme vamos adotando a metodologia, percebemos o quanto ela torna a tarefa mais controlada e organizada gerando um produto com no mínimo mais qualidade e com o melhor esforço.
Uma das grandes vantagens do uso deste artefatos é que eles levam você a entender porque você esta desenvolvendo o software. isso reduz muitas falhas de projeto, como não saber se o que você esta fazendo é correto ou não.

CMM - Capability Maturity Model

Modelo para avaliação da maturidade dos processos de software de uma organização e para identificação das práticas chave que são requeridas para aumentar a maturidade desses processos. O CMM prevê cinco níveis de maturidade: inicial, repetível, definido, gerenciado e otimizando. O modelo foi proposto por Watts S. Humphrey, a partir das propostas de Philip B. Crosby, e vem sendo aperfeiçoado pelo Software Engineering Institute - SEI da Carnegie Mellon University. A especificação do modelo compreende um instrumental para a averiguação do nível atual da organização e expõe os pontos de ação, ou áreas chave de processo, que servem como pontos de destaque para a promoção a um nível mais elevado de maturidade. A adoção do CMM se baseia em um processo gradual de aumento da maturidade da capacidade de desenvolvimento de software de uma organização. A maturidade desse processo pode ser traduzida como a probabilidade de entregar sistemas de software dentro do prazo, utilizando os recursos planejados e atendendo aos requerimentos para o qual foi projetado dentro dos padrões de qualidade desejados.

Li isso no fórum sobre UML e achei muito interessante. Resolvi pulicar. São as opniões de um dos membros sobre casos de uso. O nome do autor esta logo abaixo do texto.

1. Caso de uso de "cadastro" (CRUD): não é caso de uso, a não ser que teu sistema faça SÓ isto. Ponto.

2. "Caso de uso de sistema", "Caso de uso de negocio", etc.: não é caso de uso. Caso de uso é "caso de uso" e pronto.

3. Include e Extend: NÃO USE. Um dia você vai entender o porquê. E neste dia você pode começar a usar.

4. Subfluxo, fluxo de exceção, fluxo reverso, refluxo, etc.: O que não é fluxo básico, é alternativo !

5. Query SQL na descrição UC: Caso de uso NÃO É ESPECIFICAÇÃO SISTÊMICA (URGH!). Foque no "o quê". O "como" vai para o modelo de projeto.

Por fim, para saber se um caso de uso "está certo" entregue para o usuário e veja a sua reação: se ele se interessar (a sombrancelha direita inclina-se 15 graus) significa que está certo. Se ele se entediar (ele lerá o documento com uma mão e devolverá rapidamente dizendo "ok, ok!") algo está errado. Procure por termos técnicos, por um fluxo macarrônico e/ou nome de caso de uso "Manter ".
Casos de usos são MUITO simples, beirando o simplório. Além do cliente/usuário/patrocinador não ter tempo para ler algo com mais de duas páginas, ele só quer saber como o sistema vai funcionar e não como (pra mim pouco importa se dentro do caixa eletronico tem um dispensador de cédulas super moderno ou gnomos-escravos-contadores-de-cédulas).
Um sistema com um caso de uso não é uma aberração (por trás deste simples caso de uso, podem haver dez telinhas de cadastro, necessários para que o caso de uso funcione). O que importa é que TODO o foco de desenvolvimento vai estar centralizado neste único ponto que REALMENTE proporciona valor para o ator-cliente-usuário-patrocinador.

Ou seja: na dúvida, seja econômico e simples.

Rodolpho Ugolini Neto
Software Engineering Specialist
IBM Software Group

O Que São Requisitos?

Engenharia de requisitos e análise de sistemas Há sobreposição entre análise de sistemas e engenharia de requisitos. O descobridor de requisitos usa modelos de análise para auxilia-lo a encontrar os requisitos, e o analista de sistemas usa os requisitos como entrada no processo de desenho de funções e dados. No início do desenvolvimento, há muito mais engenharia de requisitos do que análise de sistemas. Esta proporção se inverte à medida em que o trabalho avança. A funcionalidade identificada na engenharia de requisitos é modelada para provar sua correção, isto é, para provar que as funções e os dados funcionarão corretamente, resultando no que o cliente espera. O produto da análise de sistemas serve como entrada para o projeto do produto, e daí para a sua construção e uso. Os requisitos evoluem a partir destas etapas, num processo impossível de prever com precisão. A engenharia de requisitos precisa levar em conta esta evolução. A técnica de análise de sistemas é bem documentada, o que não é verdade para a engenharia de requisitos.

Por que especificar requisitos?

Se não há uma especificação dos requisitos, um produto não pode ser construído. Ou, pelo menos, um produto não pode ser construído corretamente sem os requisitos corretos. Há relatos de que 60% dos erros já existem em tempo de projeto, e de que até 60% dos erros têm origem nas atividades de engenharia de requisitos e análise de sistemas. Embora os desenvolvedores tenham a oportunidade de quase eliminar a maior categoria de erros, escolhem (ou pior: seus gerentes escolhem) precipitar-se a construir o produto errado (para depois pagar muitas vezes em retrabalho o preço de uma boa análise). O que é um requisito? Um requisito é algo que um produto deve fazer, ou uma qualidade que deve ter. O primeiro caso é o de requisitos funcionais, por exemplo: "o produto deve acionar o monitor de segurança quando um cliente classe A faz um saque em horário não-comercial (no local do saque) superior à sua média mensal de retiradas". Neste caso, os clientes do produto são funcionários de um banco que precisam ser alertados sobre movimentações pouco usuais de alguns clientes do banco.

A atividade de desenvolvimento de software, devido a sua natureza impar, exige um elevado grau de entrosamento entre os interessados do produto final, stakeholders, e a equipe de desenvolvimento, no entanto, muitas das vezes esse relacionamento não ocorre como deveria, pelos mais diferentes motivos, comprometendo a qualidade e sucesso do produto final. Para auxiliar nesse relacionamento, apaziguando as diferenças, a industria de software tem evoluído através da proposição de diferentes metodologias e paradigmas, que basicamente auxiliam, mas, não garante, o sucesso do projeto,produto. É comum vislumbrarmos em um projeto de software, o direcionamento dos esforços para as fases de análise, projeto, implementação, e muito pouco para a fase de controle de qualidade (SQA), realizada de forma "séria" e planejada.
Com o objetivo de apresentar o conceito de mensuração de software ("measurement"), relatando qual a sua importância e objetivo para a atividade de desenvolvimento de software, disponibilizo o texto no formato pdf , que possibilita melhor apresentação ­