1.

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS (MDS)

Conforme Meirelles (1994, pg. 502) Metodologia um conjunto de conceitos,
normas e regras destinadas a orientar um processo de trabalho. Ou seja, so utilizadas
para estabelecer ordem, definir padres e usar tcnicas j provadas no desenvolvimento
de sistemas, agilizando o processo e garantindo maior qualidade no desenvolvimento.
As metodologias para desenvolvimento de sistemas (MDS) devem acompanhar
o ciclo de vida dos sistemas atendendo as etapas de estudo, anlise, projeto,
implementao, teste, implantao e manuteno (corretiva e evolutiva).
1.1 Exemplo de MDS utilizado na Previdncia Social
A Metodologia de Desenvolvimento de Sistemas da Dataprev Orientada a
Objeto (MDS-OO Dataprev) tem por objetivo orientar na utilizao dos processos de
engenharia de software utilizados nos projetos de desenvolvimento de software que
venham a ser concebidos atravs do paradigma de Orientao a Objetos.
A MDS-OO baseada no processo RUP (Rational Unified Process). 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.
O modelo de ciclo de vida iterativo e incremental consiste em subdividir o
desenvolvimento do software em iteraes. Uma iterao abrange as atividades de
desenvolvimento que conduzem liberao de um produto. Este produto evolui
incrementalmente no transcorrer das prximas iteraes. Portanto, uma iterao a
Anlise de Negcio, Requisitos, Anlise e Projeto, Implementao, Testes e
Implantao. como um pequeno projeto cascata em si mesmo.
1.1.1

Etapas da MDS

1.1.1.1 Anlise de Negcio

Entender a estrutura e a dinmica da organizao na qual um sistema deve ser

implantado (a organizao-alvo).

Entender os problemas atuais da organizao-alvo e identificar as possibilidades de

melhoria.

Assegurar que os clientes, usurios e desenvolvedores tenham um entendimento comum

da organizao-alvo.

Derivar os requisitos de sistema necessrios para sustentar a organizao-alvo.

1.1.1.2 Requisitos

Estabelecer e manter concordncia com os clientes e outros envolvidos sobre o que o

sistema deve fazer.

Oferecer aos desenvolvedores do sistema uma compreenso melhor dos requisitos do

sistema.

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

Fornecer uma base para planejar o contedo tcnico das iteraes;

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

Definir uma interface de usurio para o sistema, focando nas necessidades e metas dos
usurios.

1.1.1.3 Anlise e Projeto

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

Desenvolver uma arquitetura capaz de acomodar todos os requisitos

do sistema;

Adaptar o

design

para que

corresponda ao ambiente

de

implementao, projetando-o para fins de desempenho.

1.1.1.4 Implementao

Definir a organizao do cdigo em termos de subsistemas de implementao

organizados em camadas;

Implementar classes e objetos em termos de componentes (arquivos-fonte, binrios,

executveis e outros);

Testar os componentes desenvolvidos como unidades;

Integrar os resultados produzidos por implementadores individuais (ou equipes) ao

sistema executvel.

1.1.1.5 Testes

Localizar e documentar defeitos na qualidade do software;

Divulgar resultados da avaliao do software;

Validar as funes do software conforme projetadas;

Verificar se os requisitos foram implementados de forma adequada.

1.1.1.6 Implantao

Planejar como ser realizada a implantao;

Realizar a instalao do sistema no ambiente do cliente;

Treinar os usurios do sistema.

1.1.2

Fases da MDS
O desenvolvimento de um projeto de software segundo a MDS-OO, passa

pelas fases de iniciao, elaborao, construo e transio. Onde se pode destacar que
o esforo demandado em cada fase do ciclo de desenvolvimento do software
normalmente segue o grfico das baleias definido no RUP:

O grfico mostra a quantidade de esforo gasto nas atividades das disciplinas

em cada fase do projeto. As fases, presente no eixo horizontal, esto associadas ao grau
de maturidade do software em produo, estando diretamente relacionadas com o tempo
do projeto. J o eixo vertical representa as disciplinas que agrupam as atividades de
acordo com sua natureza.
1.1.2.1 Fase de Iniciao
A fase de Iniciao trabalha com as atividades que iro habilitar o lanamento
do projeto. nesta fase que se justifica a necessidade do projeto, provendo um nvel de
confiana aos Stakeholders, de forma a garantir a viabilidade do sistema (econmica e
tcnica); sua necessidade; estimativas para oramentos, cronograma e retorno de
investimento. O principal objetivo da fase de Iniciao consiste em definir o escopo do
software.
Iniciao

Disciplina

nfase

Anlise de Negcios

o
o
o
o
o

Entender a estrutura e a dinmica da

organizao na qual um sistema deve ser
implantado
Identificar os processos de negcio
Entender os problemas atuais da organizao e
identificar as possibilidades de melhoria
Desenvolver um modelo de domnio
Definir Glossrio de Negcio
Obter um consenso dos envolvidos sobre os
objetivos do projeto

Requisitos

Anlise

Entender o contexto do sistema e definir suas

fronteiras
o Listar requisitos ou potenciais requisitos
(funcionais e no funcionais)
o Capturar os casos de uso pertinentes
Encontrar atores e casos de uso
Priorizar casos de uso que impliquem em
riscos ou sejam relevantes para a arquitetura e
detalh-los
o

Projeto

Focar casos de uso relacionados arquitetura

candidata
o Construir uma verso preliminar da arquitetura
baseada em alguns casos de uso ou cenrios
O objetivo desta arquitetura demonstrar
sua viabilidade
Esta arquitetura no precisa ser definitiva
o

Implementao

Testes

Planejar atividades de testes

Implantao

Planejar como ser realizada a implantao

1.1.2.2 Fase de Elaborao

A fase de Elaborao objetiva capturar a maioria dos requisitos e construir a
arquitetura do sistema que deve ser executvel para demonstrar sua capacidade de
acomodar o resto do sistema. Outros objetivos da Elaborao so: produzir prottipos
que ajudem a eliminar riscos de requisitos, projeto ou viabilidade tcnica; configurar
ambiente de gesto de configurao.
Disciplina
Anlise de Negcios

nfase
o Continuar a identificao dos processos de
negcio
o Entender os problemas atuais da organizao e
identificar as possibilidades de melhoria
o Refinar o modelo de domnio
o
Incrementar Glossrio de Negcio

Requisitos

Elaborao

o
o

Levantar requisitos
Detalhar requisitos
Detalhar Casos de Uso crticos quanto a
arquitetura do software e ao planejamento do
projeto
Gerenciar requisitos

Anlise e Projeto

Analisar a arquitetura candidata definida na fase

de Iniciao
o Definir arquitetura
Contemplar
camadas
da
aplicao,
Subsistemas (mdulos) e suas interfaces, ns da rede
e suas configuraes.

Implementao

Testes

Implementar arquitetura definida

Implementar componentes, subsistemas e
classes essenciais
Distribuir elementos nos ns da rede
o
Implementar casos de uso mais crticos

Implantao

Testar
arquitetura
executvel
integrao)
Elaborar roteiros de testes

Iniciar planejamento da implantao

(unidade,

1.1.2.3 Fase de Construo

O objetivo desta fase consiste em produzir uma verso para a homologao
(incluindo implantao no ambiente do cliente e testes de homologao). Portanto, deve
ser produzido um software operacional e isto envolve anlise, projeto e implementao
dos requisitos levantados na Elaborao.
Construo Disciplina
Anlise de Negcios

nfase
o
o

Requisitos

o
o
o

Anlise e Projeto

o
o

Implementao

o
o

Testes

o
o
o
o

Refinar o modelo de domnio

Incrementar Glossrio de Negcio
Levantar Requisitos
Detalhar Requisitos
Gerenciar Requisitos
Atualizar modelos definidos anteriormente
Projetar banco de dados
Desenvolver cdigo-fonte para casos de uso identificados
Integrar classes unitrias para gerar o software funcional
Desenvolver testes unitrios para cdigo-fonte
Executar e analisar testes de integrao
Executar e analisar testes de funcionalidade
Executar e analisar testes de desempenho

Implantao

o
o
o

Desenvolver Plano de Implantao

Desenvolver Artefatos de Instalao
Desenvolver Material de Suporte

1.1.2.4 Fase de Transio

O objetivo principal da Transio finalizar o projeto com os stakeholders
satisfeitos. Esta fase deve garantir que o software estar disponvel para os usurios
finais do sistema, englobando atividades de instalao e configurao do software,
treinamento, converso dos dados e validao do sistema quanto s expectativas dos
usurios. Neste ponto, j deve existir uma confiana que o produto est apto a entrar em
produo.

Transio

Disciplina

nfase

Anlise de Negcios

Reviso dos artefatos

Requisitos

Reviso dos artefatos

Anlise e Projeto

Projetar ajustes

Implementao

Realizar correes identificadas nos testes de

homologao

Testes

Realizar Testes de Homologao

Gerenciar Testes de Homologao

Implantao

o
o

Liberar o release
Desenvolver materiais de treinamento

1.2 Anlise Crtica da MDS

Estudos e evidncias empricas mostram que, invariavelmente, os cronogramas
de implementao de projetos de sistemas de informaes subestimam o tempo total que
ser necessrio para colocar o sistema no ar. Pesquisadores ficam surpresos ao
descobrir que a estimativa inicial de durao do projeto j incorpora um tempo
ligeiramente superior ao tempo realmente gasto para concluir o ltimo projeto
semelhante, ou seja, parece que cada vez se gasta mais tempo.

O desenvolvimento de sistemas tem sido marcado por custos maiores que os

previstos, trmino aps o programado, baixa confiabilidade e insatisfao dos usurios.
O problema persiste apesar dos avanos significativos no campo da engenharia de
software que vm atacando os obstculos da produo de software sem esses problemas.
Nos ltimos anos, aspectos administrativos do desenvolvimento de software tm sido
cada vez mais reconhecidos como o centro tanto do problema como da soluo.
Muito do desconforto dos executivos com a informtica reflete a inexistncia
de uma estrutura para avaliar as opes de investimento em recursos de informtica.
Mesmo quando os benefcios competitivos so aparentes, ficou provado que
praticamente impossvel medir e quantificar antecipadamente os benefcios econmicos.
Muitos deixar de investir em informtica, pelas razes de necessidade competitiva, mas
tambm sabem que no podem deixar de ter uma clara evidncia do impacto dos
investimentos no desempenho financeiro da empresa. Um dos problemas que a
informatizao muda a estrutura de lucro da empresa, o que dificulta ainda mais a sua
avaliao econmica e a medio dos impactos e benefcios.
A economia de informao considera risco, incerteza e vantagem competitiva.
Para avaliar os projetos de SI, alm de definir o seu valor, necessrio considerar todas
as dimenses do custo. Assim, o conceito de beneficio transformado em valor da
informao e o do custo agrega risco e incerteza, os quais podem ser divididos em cinco
classes: incerteza estratgica, risco organizacional, risco com a infraestrutura de SI,
incerteza na definio do projeto e incerteza tecnolgica.
Pelo menos trs dimenses influenciam o risco inerente a um projeto: tamanho,
experincia com a tecnologia e nvel de estruturao do projeto. Dessa maneira,
combinando esses fatores pode-se avaliar o grau de risco envolvido em um determinado
projeto de sistemas.
crucial a capacidade de determinar o valor da informao ou da Tecnologia
de Informao para a organizao; com o conceito de Economia da Informao
possvel utilizar ferramentas mais poderosas para analisar e alocar recursos com vistas a
suportar estratgias e o desempenho das empresas e descobrir que o benefcio real a
mudana subjacente.

 necessrio ainda, adaptar-se as constantes mudanas dos requisitos dos

usurios. Como o processo de ciclo de vida caro e difcil de ser organizado, usurios e
o pessoal de sistemas deve procurar mtodos de:

Aumentar a vida do sistema, construindo flexveis e que podem ser mudados;

Substituir a abordagem de implementao de sistemas baseada no ciclo de vida por uma

abordagem evolutiva, mais prximo da aplicvel aos sistemas manuais;

Diminuir a dependncia do software em relao a um determinado hardware, tanto no

desenvolvimento como na portabilidade;

Melhorar o modelo do mundo real com que o projetista trabalha e no qual o sistema ter

de operar;
Projeto e desenvolvimento do custo destas etapas para permitir que sistemas que no
atendem as necessidades possam ser rapidamente descartados e substitudos por novos.
Mudar o modelo de ciclo de vida para um baseado no conceito de sistemas que podem
ser substitudos e expandidos.
As razes para desenvolver aplicativos tradicionais internamente so muitas e
conhecidas; por outro lado as vantagens dos aplicativos comerciais prontos crescem
medida que o porte da empresa diminui que a aplicao se torne comum a mais
empresas e com passar do tempo, uma vez que a cada dia mais produtos de boa
qualidade ficam disponveis no mercado.

REFERNCIAS

MEIRELLES, Fernando de Souza. Informtica: novas aplicaes

microcomputadores. 2. Ed. So Paulo: Pearson Education do Brasil, 1994.

com

Disponvel em: <http://www.efagundes.com/artigos/Como%20uma%20metodologia

%20de%20desenvolvimento%20pode%20reduzir%20e%20aumentar%20a
%20qualidade%20dos%20sistemas.htm> Acesso em 31 mar 2013.
Disponvel em:<www.mps.gov.br/arquivos/office/4_110114-105206-597.doc> Acesso
em 31 mar 2013.