Modelagem De Sistemas Orientado à Objeto
Trabalho Universitário: Modelagem De Sistemas Orientado à Objeto. Pesquise 862.000+ trabalhos acadêmicosPor: igordipaula • 19/9/2014 • 2.149 Palavras (9 Páginas) • 622 Visualizações
Introdução
Devido à grande incidência de problemas no desenvolvimento de software, como fragilidade, alto custo, problemas com reuso, etc. começou a se estudar técnicas que diminuíssem esses “defeitos” antes da entrega do produto.
Deu-se origem então à Engenharia de Software, que padronizou a forma de criação do software, a fim de entregar um produto mais seguro, de baixo custo e de fácil manutenção.
CMM (Capability Maturity Model)
Após várias décadas de promessas não cumpridas sobre ganhos de produtividade e qualidade na aplicação de novas metodologias e tecnologias no desenvolvimento de software, organizações do governo e empresas privadas concluíram que o problema fundamental é a falta de habilidade em gerenciar os processos de construção de software.
Os benefícios dos melhores métodos e ferramentas não podem ser alcançados em ambientes de projetos caóticos. Entretanto, mesmo em organizações indisciplinadas, alguns projetos de software específicos podem até produzir resultados satisfatórios, mas sem nenhuma previsibilidade de repeti-lo. Quando projetos deste tipo obtêm sucesso, este é resultado do esforço e dedicação da equipe, ao invés da repetição de métodos gerenciais da organização.
O Modelo de Qualidade de Software CMM é um modelo de avaliação e melhoria da maturidade de Processo de Software. O CMM, ou "Modelo de Maturidade da Capacidade" é uma iniciativa do SEI (Software Engineering Institute) para avaliar e melhorar a capacitação de empresas que desenvolvem e mantém software através de seus funcionários ou de contratados terceirizados.
O CMM enfatiza a documentação dos processos, seguindo a premissa de que, para realizar alguma melhoria nos processo, é preciso primeiro conhecê-lo e entendê-lo.
O CMM é composto de cinco níveis de maturidade que indicam qual é a capacidade do processo. Cada nível é composto por áreas-chave do processo. Cada área-chave conduz ao alcance de metas de melhoria do processo e está organizada em cinco Características Comuns que determinam práticas-chave referentes a implementações (atividades) ou institucionalizações (compromissos, habilitações, medições ou verificações).
Os cinco níveis são: Nível 1 – Inicial, Nível 2 – Repetível, Nível 3 – Definido, Nível 4 – Gerenciado e Nível 5 – Otimizado.
O nível 1 é o das organizações mais imaturas, nestas, não há nenhuma metodologia implementada e tudo ocorre de forma desorganizada. No nível 5, o das organizações mais maduras, cada detalhe do processo de desenvolvimento está definido, é quantificado, acompanhado e a organização consegue até absorver mudanças no processo sem prejudicar o desenvolvimento.
Os cinco níveis de maturidade oferecem uma forma incremental de amadurecimento do processo de software. Para atingir o nível 5, é preciso antes se obter a maturidade do nível 4, que por sua vez exige a do nível 3, e assim por diante.
Os níveis de maturidade são detalhados em áreas-chave de processo, que representam o que a organização deve focar para melhorar o seu processo de desenvolvimento de software. Para que uma empresa se qualifique em um determinado nível de maturidade, deve estar realizando os processos relacionados às áreas-chave daquele nível.
As características comuns, são itens a serem observados para que se possa verificar a implementação e institucionalização de cada área-chave de processo. Elas podem indicar se a área-chave de processo é eficiente, repetível e duradoura. São cinco as características comuns no modelo CMM e cada uma possui suas práticas-chave a serem realizadas.
As práticas-chave descrevem as atividades que contribuem para atingir os objetivos de cada área-chave do processo. Em geral são descritas com frases simples, seguidas de descrições detalhadas (sub-práticas) que podem até incluir exemplos. As práticas-chave devem descrever "o que" deve ser feito e não "como" os objetivos devem ser atingidos. O modelo CMM inclui um extenso documento em separado, chamado "Práticas-chave para o CMM", que lista todas as práticas-chave e sub-práticas para cada uma das áreas-chave de processo.
Modelo SPICE (Software Process Improvement and Capability Determination)
A ISO/IEC 15504, também conhecida como SPICE, é a norma ISO/IEC que define processo de desenvolvimento de software. Ela é uma evolução da ISO/IEC 12207 mas possui níveis de capacidade para cada processo assim como o CMMI. Surgiu devido à necessidade de estabelecer um enquadramento, uma abordagem e uma linguagem comum para avaliar e aperfeiçoar os processos e para determinar a capacidade dos processos dos fornecedores de software.
Em outubro de 2003, a Norma ISO/IEC 15504 para a avaliação de processos de software foi oficialmente publicada pela ISO. A Norma ISO/IEC 15504 define um modelo bi-dimensional que tem por objetivo a realização de avaliações de processos de software com o foco da melhoria dos processos (gerando um perfil dos processos, identificando os pontos fracos e fortes, que serão utilizados para a elaboração de um plano de melhorias) e a determinação da capacidade dos processos viabilizando a avaliação de um fornecedor em potencial. Logo, a grande vantagem do modelo reside no fato de fornecer um enquadramento que pode ser personalizado de acordo com as necessidades das organizações.
O SPICE inclui um modelo de referência, que serve de base para o processo de avaliação. Este modelo define duas dimensões: Dimensão de Processo e Dimensão de Capacidade.
A Dimensão de Processo corresponde à definição de um conjunto de processos considerados universais e fundamentais para a boa prática da engenharia de software. Um modelo de referência de processo no domínio de software utilizado atualmente é a ISO 12207.
Já a Dimensão de Capacidade, é um modelo de avaliação, baseado na ISO 12207.
Nele, os processos são agrupados em cinco grandes categorias de processo: Cliente-fornecedor, Engenharia, Suporte, Gerência e Organização.
A Norma ISO/IEC 15504, ainda não passou por nenhuma revisão. Sua história decorre da seguinte forma:
• Janeiro de 1992: estudo da ISO sobre as necessidades e os requisitos de um padrão internacional
...