Metodologia De Desenvolvimento De Sistemas

Anexo 12

Metodologia de Desenvolvimento de Sistemas

Índice Analítico

1 Introdução 4

2 Disciplinas da MDS-OO 5

3 Fases 6

3.1 Fase de Iniciação 7

3.2 Fase de Elaboração 8

3.3 Fase de Construção 9

3.4 Fase de Transição 10

4 Artefatos 11

5 Papéis 12

6 Referências 13

1 Introdução

Este anexo é uma reprodução da Metodologia de Desenvolvimento de Sistemas Orientados a Objeto aplicada pela Dataprev e válida para a Previdência Social e deverá servir de referencia para as demandas de desenvolvimento de sistemas deste projeto.

A Metodologia de Desenvolvimento de Sistemas da Dataprev Orientada a Objeto (MDS-OO Dataprev) tem por objetivo orientar na utilização dos processos de engenharia de software utilizados nos projetos de desenvolvimento de software que venham a ser concebidos através do paradigma de Orientação a Objetos.

A MDS-OO é integrante do Processo de Desenvolvimento de Software da Dataprev (PD-DATAPREV), que contempla processos Fundamentais, processos de Apoio e processos Organizacionais. Entretanto, a MDS-OO trata apenas os procedimentos relacionados com engenharia de software (parte superior esquerda da figura). A Figura 1 ilustra a estrutura do PD-DATAPREV.

Figura 1: Estrutura do PD-DATAPREV

A MDS-OO é baseada no processo RUP (Rational Unified Process) [1]. Portanto, ela é uma metodologia iterativa e incremental, orientada a objetos, guiada por casos de uso, planejada por riscos e tem a arquitetura do software exercendo papel central. Lembrando que a linguagem para modelagem de sistemas orientados a objetos a ser utilizada pela MDS-OO é a UML 1.4.

O modelo de ciclo de vida iterativo e incremental consiste em subdividir o desenvolvimento do software em iterações. Uma iteração abrange as atividades de desenvolvimento que conduzem à liberação de um produto. Este produto evolui incrementalmente no transcorrer das próximas iterações. Portanto, uma iteração é uma passagem pelas disciplinas da MDS-OO (Análise de Negócio, Requisitos, Análise e Projeto, Implementação, Testes e Implantação). É como um pequeno projeto cascata em si mesmo.

Uma metodologia Orientada a Objetos segue o paradigma de análise, projeto e programação de sistemas de software baseado na composição e interação entre diversas unidades de software chamadas objetos.

Por ser guiada por casos de uso, a MDS-OO os utiliza como elo entre as disciplinas (ver ). Sendo assim, os casos de uso auxiliam em diversas tarefas como criação e validação da arquitetura do sistema, definição de casos e procedimentos de testes, planejamento das iterações, criação da documentação do usuário, etc.

Projetos de software estão expostos a um variado conjunto de incertezas e, desta forma, requerem um planejamento e acompanhamento dos potenciais problemas a serem enfrentados. O Planejamento por Riscos auxilia no processo de identificação, prevenção e contingência dos riscos, pois prioriza as atividades mais críticas. Durante todo o processo, os riscos devem ser continuamente identificados, atenuados e monitorados.

A definição correta da arquitetura (do software) é imprescindível para o sucesso de um projeto de software. Os riscos relacionados com a arquitetura são críticos, pois podem acarretar em descumprimento de prazo, orçamento etc. Sendo assim, a MDS-OO enfatiza a arquitetura com o intuito de prover informação suficiente para análise do sistema como um todo, para tomada de decisões e para redução de riscos.

2 Disciplinas da MDS-OO

A MDS-OO é composta por algumas disciplinas de Engenharia de Software. A seguir essas disciplinas são citadas, bem como suas principais finalidades:

• Análise de Negócio

• Entender a estrutura e a dinâmica da organização na qual um sistema deve ser implantado (a organização-alvo).

• Entender os problemas atuais da organização-alvo e identificar as possibilidades de melhoria.

• Assegurar que os clientes, usuários e desenvolvedores tenham um entendimento comum da organização-alvo.

• Derivar os requisitos de sistema necessários para sustentar a organização-alvo.

• Requisitos

• Estabelecer e manter concordância com os clientes e outros envolvidos sobre o que o sistema deve fazer.

• Oferecer aos desenvolvedores do sistema uma compreensão melhor dos requisitos do sistema.

• Definir as fronteiras do sistema (ou delimitar o sistema);

• Fornecer uma base para planejar o conteúdo técnico das iterações;

• Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema;

• Definir uma interface de usuário para o sistema, focando nas necessidades e metas dos usuários.

• Análise e Projeto

• Transformar os requisitos em um design do sistema a ser criado;

• Desenvolver uma arquitetura capaz de acomodar todo os requisitos do sistema;

• Adaptar o design para que corresponda ao ambiente de implementação, projetando-o para fins de desempenho.

• Implementação

• Definir a organização do código em termos de subsistemas de implementação organizados em camadas;

• Implementar classes e objetos em termos de componentes (arquivos-fonte, binários, executáveis e outros);

• Testar os componentes desenvolvidos como unidades;

• Integrar os resultados produzidos por implementadores individuais (ou equipes) ao sistema executável.