uma comparação entre os modelos de ciclo de vida cascata e incremental, aplicados ao processo...
DESCRIPTION
TRANSCRIPT
Uma Comparação entre os Modelos de Ciclo de Vida
Cascata e Incremental, Aplicados ao Processo Unificado Rational
Dissertação apresentada como requisito à obtenção do Bacharelado em Ciência da Computação. Instituto Baiano de Ensino Superior. Orientador: Professora: Ana Célia Rocha Mascarenhas.
SALVADOR - BA, 2009
JONAS BONFIM DE OMENA
Uma Comparação entre os Modelos de Ciclo de Vida Ca scata e Incremental, Aplicados ao Processo Unificado Ration al
JONAS BONFIM DE OMENA
Dissertação apresentada como requisito à obtenção do Bacharelado em Ciência da Computação do Instituto Baiano de Ensino Superior.
RESUMO
A área de Engenharia de Software é extensa, porém ela tem a
responsabilidade de produzir produtos de software através das necessidades
expressas por seus clientes. O software atualmente tem sido um produto utilizado
em todos os lugares a todo instante, o problema é a forma como esses produtos são
desenvolvidos e se esses produtos atendem às necessidades de seus clientes e/ou
usuários.
Numa sociedade onde o desenvolvimento econômico e social é
predominante, ninguém poderia prever que o software (Programas de computador
que quando executados realizam as funções e desempenhos desejados) estaria
embutido em sistemas de toda espécie a exemplo de transporte, médico,
telecomunicações, militar, indústria, entretenimento, máquinas de escritório, a lista é
quase sem fim. Hoje, as pessoas confiam suas vidas nos softwares produzidos,
alimentando esses sistemas com seus dados pessoais, entre outras informações
que podem ser vistas por todos, ou de modo confidencial. A questão é: como esses
produtos são desenvolvidos e se proporciona qualidade e confiabilidade.
Neste trabalho serão abordados alguns aspectos de como são desenvolvidos
esses produtos de software, através do modelo cascata e incremental, no qual será
realizada uma comparação entre esses modelos de desenvolvimento de ciclo de
vida, aplicados no processo Rational Unified Process (RUP), mostrando como está
sendo a utilização destes modelos, bem como suas vantagens e desvantagens,
respeitando os demais modelos de ciclo de vida e enfatizando a importância da
comunicação nessas atividades.
ABSTRACT The area of Software Engineering is extensive, but it has a responsibility to produce software products through the needs expressed by their customers. The software currently has one product everywhere at every moment, the problem is the way that these products are developed and whether these products meet the needs of their customers and / or users. In a society where economic and social development is prevalent, no one could predict that the software (computer programs that when executed perform the desired functions and performance) would be embedded in systems of all kinds such as transportation, medical, telecommunications, military, industry, entertainment, office machinery, the list is almost endless. People trust their lives today in software produced by feeding these systems with personal data and other information that may be viewed by all or on a confidential, the question is: Since these products are developed and that provides quality and reliability. This work will address some aspects of these products are developed by software, through the waterfall model and incremental, where a comparison is made between these models of development life cycle, implemented in Rational Unified Process (RUP), showing how is the use of models and their advantages and disadvantages with all types of life cycle and emphasizing the importance of communication in these activities.
AGRADECIMENTOS
Á Deus, por permitir as oportunidades e oferecer - me a cada manhã um dia a mais para traçar meus sonhos e objetivos. À minha mãe Eunice, que me orientou em que caminho seguir. À minha esposa Grasiela, presente em todos os momentos da minha vida e sempre ao meu lado, vencendo as barreiras e dificuldades. À Minha amada filha Anna Luísa, que Deus me presenteou, sendo uma das minhas maiores motivações na conquista dos meus objetivos. Á Manoel Evangelista e Ivete Teixeira, que sempre me ajudaram em todos os aspectos. Á João Werther e Ana Célia, sempre ajudando, fazendo o possível para que eu pudesse desenvolver um bom trabalho. Á Djalma e Suely, que me orientaram a optar por esse curso há alguns anos atrás. Á Carlos Henrique, que me ajudou a desenvolver um tema para o trabalho de conclusão do curso.
INDÍCE INTRODUÇÃO ____________________________________________________________ 1
ENGENHARIA DE SOFTWARE _____________________________________________ 2
A Engenharia de Software _____________________________________________________ 2
Software ______________________________________________________________________ 2
Ciclo de vida do software ______________________________________________________ 3
MODELOS DE CICLO DE VIDA ____________________________________________ 3
Modelo Cascata (Clássico) _____________________________________________________ 3
Modelo Incremental __________________________________________________________ 12
PROCESSO BASE PARA A ESCOLHA DOS MODELOS _____________________ 15
Processo Unificado Rational __________________________________________________ 15
Abordagem Cascata __________________________________________________________ 19
Abordagem Incremental ______________________________________________________ 21
O USO DOS MODELOS E PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE NAS SECRETARIAS DO ESTADO DA BAHIA __________________ 22
COMPARAÇÃO DOS MODELOS DE CICLO DE VIDA MAIS UTILIZ ADOS _____ 26
Cascata x Incremental ________________________________________________________ 26
Reflexão _____________________________________________________________________ 29
PROBLEMAS COMUNS ENCONTRADOS NOS MODELOS __________________ 29
SUGESTÕES DE TRABALHOS FUTUROS _________________________________ 30
CONCLUSÃO ___________________________________________________________ 31
Reflexão _____________________________________________________________________ 33
REFERÊNCIA BIBLIOGRÁFICA ___________________________________________ 34
ANEXOS ________________________________________________________________ 37
Anexo A ________________________________________________________________ 38
Anexo B ________________________________________________________________ 40
TABELAS
Tabela 1. Principais Fatores que tornam um projeto crítico. ____________________ 11 Tabela 2. Comparação das Disciplinas de Cinco Processos ____________________ 18 Tabela 3. Comparação entre os modelos de ciclo de vida. _____________________ 28 Tabela 4. Siglas e nomes dos orgão pesquisados. ___________________________ 38 Tabela 5. Uma Amostra do uso dos modelos e processos utilizado nas Secretarias do Estado da Bahia. ______________________________________________________ 40
FIGURAS Ilustração 1. Cascata Sequencial ____________________________________________ 4 Ilustração 2. Cascata Revisto _______________________________________________ 5 Ilustração 3. Custo de diversas tarefas do processo de desenvolvimento de software ________________________________________________________________________ 10 Ilustração 4. Incremental __________________________________________________ 12 Ilustração 5. Identificação e Prevenção de Defeitos. ___________________________ 14 Ilustração 6. Modelo de desenvolvimento iterativo e incremental. _______________ 17 Ilustração 7. Gráfico do RUP – estrutura organizada em duas dimensões. _______ 17 Ilustração 8. Resultados sobre o uso dos modelos nas Secretarias do Estado da Bahia ___________________________________________________________________ 23 Ilustração 9. Resultado sobre o uso dos processos nas Secretarias do Estado da Bahia ___________________________________________________________________ 24 Ilustração 10. Resultado sobre o grau de satisfação ao usar um determinado modelo nas Secretarias do Estado da Bahia. ________________________________________ 25 Ilustração 11. Resultados sobre a nota de avaliação ao usar um determinado modelo nas Secretarias do Estado da Bahia. ________________________________________ 26
1
INTRODUÇÃO
Hoje quando se fala em software logo se relaciona com computadores e, ao
entrarmos nesse assunto, vemos que é uma área extensa que abrange vários
aspectos da informática.
Mas o objetivo do profissional de informática que trabalha com
desenvolvimento é entender como é formado um software e qual a sua finalidade,
aplicando um determinado modelo, sendo criteriosa a observação quanto aos
problemas que possam surgir durante o desenvolvimento de um software.
O software é o meio que permite ao homem organizar suas informações de
maneira simples e eficazes e, para obter um software de qualidade é necessária
uma análise dos requisitos no qual possibilite avaliar possibilidades ao que se
solicita e viabilizar o mesmo, trazendo por fim um produto final, mediante ao
documento de especificação de requisitos.
Portanto, a Engenharia de Software tenta criar modelos para atender às
necessidades desses sistemas desde o levantamento de requisitos até a sua
conclusão.
O objetivo deste trabalho é permitir ao leitor fazer uma análise objetiva,
observando as características dos modelos cascata e incremental, podendo escolher
um destes mediante ao problema apresentado e ter sucesso no seu
desenvolvimento, como também a facilidade na escolha do modelo certo para obter
no final um produto de software de qualidade, utilizando o que há de melhor
permitido pela prática da engenharia de software.
Ao compararmos os modelos devemos observar que os demais não são
descartáveis e os são utilizados pela adaptação, visando à satisfação dos clientes
com os produtos de software desenvolvidos.
Os modelos podem trazer inúmeros benefícios se aplicados de maneira
correta nos requisitos especificados, mas não podemos esquecer que todo projeto é
iniciado pela comunicação e entendimento, onde é possível compreender e
apreender tudo que fora necessário para pôr em prática os recursos disponíveis e
indispensáveis para desenvolver o produto final.
2
ENGENHARIA DE SOFTWARE
A Engenharia de Software
A Engenharia de software tem por objetivo auxiliar quanto ao processo de
produção de software, preocupando–se com um produto satisfatório que tenha
qualidade e baixo custo.
A Engenharia de Software há muito tempo vem enfrentando problemas relativos
a atrasos nas entregas de projetos, orçamento extrapolado, insatisfação de clientes
e usuários, além de conflitos e desgastes entre analistas e clientes. Segundo
Carvalho, (2001):
“A Engenharia de Software é uma disciplina que reúne metodologias, métodos e ferramentas a ser utilizados, desde a percepção do problema até o momento em que o sistema desenvolvido deixa de ser operacional, visando resolver problemas inerentes ao processo de desenvolvimento e ao produto de software”. (Pág.25).
Seguindo metodologias e ferramentas automatizadas, englobando as atividades
no processo de produção de software, a Engenharia de Software se torna a base de
referência para um desenvolvimento, sendo um conjunto de funções onde é visto
todo o processo e funcionamento para a produção de software.
Software
Para desenvolver um software é necessário entender sobre o que é software e
definir suas relações a serem aplicadas.
A maior preocupação ao desenvolver um software são as falhas encontradas,
pois ao utilizarmos um software no mercado buscamos: baixo custo, benefícios,
segurança, qualidade e confiabilidade.
Software é o conjunto de instruções (Programas de Computador) que quando
executados realizam as funções e desempenhos desejados, estrutura de dados que
possibilitam manipular informações de forma desejada. E documentos que
descrevem operações e o uso de produtos.
De acordo com Pressman, (2006):
3
“Ninguém na década de 1950 poderia ter previsto que o software fosse se tornar uma tecnologia indispensável para os negócios...”
Hoje, manipulando todo o mercado e estando em todos os lugares; nos
aparelhos eletrônicos, aeronaves, automóveis, meios de comunicações (celulares,
Palm, notebooks), navios, entre outros; é a representação de um mundo em avanço
a todo vapor, produzindo com rapidez e segurança meios para obter respostas
coerentes ao que se tem por tecnologia.
Ciclo de vida do software
Comparando ao hardware (conjunto dos componentes eletrônicos de um
computador a exemplo de placas, monitores, periféricos), o software não é
suscetível aos males do ambiente, levando–o ao desgaste, mas se deteriora.
As conseqüências que levam ao software deteriorar–se são devido à introdução
de novas mudanças, seja para corrigir erros descobertos após a entrega do produto
sejam na adaptação de novas tecnologias de software e hardware, ou ainda a
inclusão de novos requisitos, novos erros a serem introduzidos.
MODELOS DE CICLO DE VIDA
Modelo Cascata (Clássico)
O Modelo idealizado por Royce em 1970, também conhecido como abordagem
‘top-down’, tem como principal característica a sequência de atividades onde cada
fase transcorre completamente e seus produtos são vistos como entrada para uma
nova fase.
A modelagem em cascata é o mais antigo modelo de desenvolvimento utilizado
para desenvolver um software, e o ciclo de vida é uma sistemática sequencial
composta por planejamento, análise, projeto, desenvolvimento, testes e
manutenção. Como visto na figura abaixo.
4
Ilustração 1. Cascata Sequencial Treinamento Prático em UML, 2006. FONTE: RAMOS, 2006. (Pg.40)
Estas características fazem do modelo cascata é uma base para todos os outros
modelos. Suas características são de processos contínuos, no qual o produto é
finalizado após todos os processos sequenciais realizados. Os modelos posteriores
na verdade apresenta as melhorias realizadas de forma criteriosa, sobre os
paradigmas de desenvolvimento. O modelo cascata só pode dar continuidade
quando a anterior estiver concluída.
“... ciclo de desenvolvimento é dividido em fases que devem ser executadas seqüencialmente: cada fase gera uma série de produtos que alimentam a próxima fase, até a obtenção do produto final. O modelo prevê a propagação de alterações decorrentes em uma fase para as fases anteriores”.
MELNIKOFF, 1992. (Pág. 3).
No entanto, o modelo cascata por não voltar atrás quando se inicia o projeto de
desenvolvimento, que pode acabar perdendo os modelos e as tarefas anteriores,
torna-se normal as perdas das ideias sobre o sistema em que não sejam
aproveitadas posteriormente para dar continuidade ao processo, desencorajando
todos os envolvidos no projeto ao longo do desenvolvimento. Para isso é aplicado o
modelo cascata revisto onde é possível eliminar esse problema, possibilitando o
regresso de qualquer tarefa no ciclo, sendo funcionais ou técnicas.
Segundo Ramos, 2006 (pág. 40) existem os riscos:
“O risco dessa abordagem é que, na ausência de um processo de gerenciamento do projeto e de um controle das alterações bem definido, podemos passar o tempo num ciclo sem fim, sem nunca atingir o objetivo final...”
5
Ilustração 2. Cascata Revisto Treinamento Prático em UML, 2006. FONTE: Ramos, Ricardo Argenton. (2006). (Pg.41)
Existem os riscos em retornar uma fase, mas há possibilidade de ser realizado,
exigindo experiência por parte de quem faz.
“... cascata permite a correção de erros cometidos nas fases anteriores, com uma equipe experiente, é uma grande vantagem para projetos em cascata” GIBBS, 2006.
O momento para se aplicar o modelo é quando o cliente conhece o produto que
deseja desenvolver junto ao analista, participando de todo o processo de
desenvolvimento, deixando a comunicação compreendida de forma linear do produto
de software a ser desenvolvido, é necessária a participação ativa do cliente no
desenvolvimento do projeto. Este modelo pressupõe que o cliente sabe muito bem o
que quer.
Pelo simples fato de um projeto como esse ser extenso do início à sua entrega,
é permitida a criação de um protótipo rápido, que permita ao cliente ter uma noção
do produto a ser desenvolvido. Segundo Ramos, 2006. (Pág.41):
“Uma solução encontrada parcialmente para resolver esse problema consiste na aplicação de técnicas de prototipagem rápida. Não elimina a necessidade de todas as tarefas, mas permite que o cliente veja e valide um modelo de interface (e das funcionalidades) que terá disponível, reduzindo também, os problemas de comunicação.”
6
O motivo pelo qual se aplica um protótipo no modelo cascata é apenas para linear
a comunicação dos interessados, para dar continuidade com as atividades
sequenciais, pois o protótipo neste caso é para que o cliente tenha noção do produto
que será produzido e, para que ele possa estabelecer a mesma linguagem de
comunicação do analista.
“Apesar de a prototipagem poder ser usada como um modelo independente, ela é mais comumente usada como uma técnica que pode ser implementada dentro do contexto de qualquer um dos modelos de processo...”. PRESSMAN, 2006, (Pág. 42).
Vamos abordar todo o plano para desenvolver através do modelo cascata.
Primeiro temos a parte de extrema importância para o desenvolvimento do software
em qualquer uso de paradigma de desenvolvimento do planejamento.
Todo projeto que se preze, seja em qualquer área, é necessário realizar um
planejamento no qual será avaliado se a necessidade do cliente pode ser aplicada e,
para isso é necessário entender a missão e organização da empresa, definir o
contexto do sistema, elaborar uma descrição de alto nível do problema, identificar
restrições, problemas e riscos do projeto, entre outros aspectos, para poder justificar
a viabilidade do produto que deseja ser adquirido através do desenvolvimento.
Ramos, Argenton (2006). (Pg.31 - 32) cita alguns tópicos essências de planejamento
como:
1. Introdução (Contexto e próposito do documento, Objetivos do projeto, Funções relevantes,
Questões de performance, Restrições técnicas e de gerenciamento).
2. Contexto do Projeto (Visão estrátégica do negócio, Descrição de funções).
3. Especificação de Alto nível dos requisitos.
4. Estimativa do projeto (Dados históricos utilizados nas estimativas, Técnicas para realizar a
estimativa).
5. Risco do projeto (Análise de risco: Identificação, Estimação, Avaliação e Gerenciamento do
risco: Opções para evitar riscos, Procedimentos de monitoria de riscos).
6. Recursos do projeto (Pessoas, Estrutura da equipe, Hardware, Software, Outros).
7. Mecanismo de acompanhamento e controle.
8. Análise de custo e benefícios.
9. Análise alternativas.
7
Então, podemos afirmar que para obter um bom desenvolvimento devemos ter
uma ampla visão sobre o projeto a ser desenvolvido, portanto a análise de requisitos
torna-se essencial.
A análise é responsável pelo levantamento de requisitos e especificação através
da comunicação, onde se realiza a coleta de informações do produto a ser
desenvolvido nesse momento o analista irá verificar se há possibilidades de
desenvolver o produto desejado pelo cliente, O levantamento de requisitos é muito
difícil de ser elaborado, pois o cliente tem que expressar todos os objetivos do
sistema que será desenvolvido de forma clara e coerente.
“A comunicação efetiva (entre pares técnicos, com o cliente e outros interessados e com os gerentes de projetos) está entre as atividades mais desafiadoras com as quais se confronta um engenheiro de software. Nesse contexto, discutimos como os princípios e conceitos de comunicação se aplicam à comunicação com o cliente. No entanto, muitos dos princípios aplicam – se igualmente a todas as formas de comunicação que ocorrem dentro de um projeto de software”. Pressman, (2006).
Ou seja, podemos então afirmar que a comunicação é fundamental para o sucesso
de qualquer desenvolvimento, e está presente em qualquer modelo de aplicação
para poder estabelecer o vínculo de relacionamento e chegar ao denominador
comum a cerca do produto final. Mas para uma comunicação por mais simples que
seja é necessário alguns princípios veja abaixo:
� Princípio nº 1 : Escute.
� Princípio nº 2 : Prepare – se antes de se comunicar.
� Princípio nº 3 : Alguém deve facilitar a atividade.
� Princípio nº 4 : Comunicação face – a – face é melhor.
� Princípio nº 5 : Faça anotações e documente as decisões.
� Princípio nº 6 : Busque colaboração.
� Princípio nº 7 : Conserve – se enfocado, modularize sua discussão.
� Princípio nº 8 : Se algo não estiver claro, desenhe uma figura.
� Princípio nº 9 : (a) Quando você concordar com algo, prossiga; (b) Se você não concordar
com algo, prossiga; (c) Se uma característica ou função não está clara e não pode ser
esclarecida no momento, prossiga.
� Princípio nº 10 : Negociação não é um concurso ou jogo. Funciona quando ambas as partes
ganham.
PRESSMAN, 2006 (Pág. 82)
8
Dando continuidade à nossa reflexão, o levantamento de requisitos será
estabelecido através da comunicação entre os interessados de como o sistema irá
funcionar mediante o que fora citado no momento da entrevista, com o objetivo de
documentar. Por isso a comunicação é tão importante, mas para isso é necessário
observar alguns princípios que podem ajudar para uma boa comunicação.
“Um requisito é uma funcionalidade ou condição que o sistema deve possuir. Para identificá-los adequadamente, é aplicado um conjunto de técnicas para obter a percepção detalhada daquilo que o sistema deve efetuar.” RAMOS, 2006. (Pág.32).
Através de reuniões com as pessoas interessadas, stackholders, analistas de
sistemas e funcionários da empresa, é que podemos realizar o levantamento das
necessidades, conhecendo as dificuldades e levando–os ao confronto de ideias para
se adquirir um denominador comum.
A especificação de requisitos é a soma de toda a comunicação retratada com
cliente através do levantamento de requisitos em forma de documento válido, para
que se possa acordar as atividades entre ambos os lados cliente / desenvolvedor.
“Especificação de requisitos – É o produto final produzido pelo engenheiro de requisitos. Ele serve como fundamento das atividades de engenharia de software subsequentes. Ele descreve a função e o desempenho de um sistema baseado em computador e as restrições que governaram o seu desenvolvimento.” Pressman, 2006 (Pág 120).
Na fase do projeto, tudo que fora citado em reuniões e entrevistas através da
análise será implementado e otimizado. Nesse tópico está incluído: Infra – estrutura,
arquitetura de computadores, Tecnologias de banco de dados, Sistemas de
execução de agentes, Infra – estrutura de objetos ou de componentes, dentre
outros.
É uma fase de vários passos que se centraliza em:
• Projeto Arquitetural - Deve descrever a estrutura de nível mais alto da
aplicação e identificar seus principais componentes.
• Projeto Detalhado – É o detalhamento do projeto do software para todos os
componentes identificado na etapa anterior. Os componentes de software
devem ser sucessivamente refinados em níveis de maior detalhamento, até
que possam ser codificados e testados.
9
• Projeto Interface - Layouts e mecanismos de interação homem-máquina.
O processo do projeto representa os requisitos de uma forma que permite a
codificação do produto (é uma prévia etapa de codificação). Da mesma maneira que
a análise dos requisitos, o projeto é documentado e transforma-se em uma parte do
software.
“... o projeto é a fase da especificação técnica, pois nela são os componentes da aplicação (objetos, módulos, e programas). tecnológicos (redes, máquinas e outros servidores) e os dados estrutura de arquivos ou de banco de dados e servidores que serão utilizados).” Ramos, Argenton, (2006). (Pág.34).
Concluída a codificação, começa a fase de teste do sistema. O processo de
teste está centrado em dois pontos principais: as lógicas internas do software e as
funcionalidades externas. Esta fase decide se foram solucionados erros de
“comportamento” do software e assegura que as entradas definidas produzam
resultados reais que coincidam com os requisitos especificados.
“A verificação consiste na confirmação de que a códificação/implementação do sistema está de acordo com a especificação técnica produzida na fase do projeto, que por sua vez resulta dos requisitos especificados em análise”. RAMOS, 2006. (Pág.35).
A etapa da manutenção consiste na correção de erros que não foram
previamente detectados, em melhorias funcionais e de preferência e outros tipos de
suporte. A etapa de manutenção e a parte do ciclo de vida do produto de software
não pertencem restritamente ao seu desenvolvimento.
A manutenção é constante, já que o software não se desgasta, mas se deteriora
o maior índice gasto de tempo é na manutenção do software com índices altos. Em
1970 chegou com 67% de custo no processo de desenvolvimento.
No gráfico abaixo veja os índices em 1970 no processo de desenvolvimento:
10
Ilustração 3. Custo de diversas tarefas do processo de desenvolvimento de software Treinamento Prático em UML, 2006. FONTE: RAMOS. 2006. (Pág.28)
“Com relação a formalismo, o ciclo de vida cascata para modelos de desenvolvimento de software é o mais antigo e, em função deste fato, também chamado de modelo clássico; porém, tem – se constatado que o desenvolvimento de sistemas não se realiza atráves de um fluxo sequencial, conforme proposto por este ciclo de vida. Além disso, verifica – se que a busca de requisitos não ocorre somente em um momento inicial do projeto, sendo na maioria das vezes impossíveis conseguir–se a totalidade de requisitos como exigência antecipada de um ciclo de vida, e omitindo-se a possibilidade de não retornar mais a eles”. TONSIG. (Pág. 83).
Então, podemos afirmar que o modelo cascata é o modelo mais antigo para
utilizar no desenvolvimento, porém ele não é descartável, na verdade é base de
evolução de outros modelos de desenvolvimento. O que implica é que nos dias
atuais é necessária uma iteratividade, devido às necessidades de realizar alterações
nas fases. É importante verificar que existem pontos críticos que podem prejudicar
todo o projeto, e esses pontos são voltados à especificação de requisitos onde em
uma amostra na figura abaixo, você verá que aproximadamente 12,8% dos
problemas são resultantes da falta de especificação do usuário e, que por esses
motivos, faz-se necessário fazer tais alterações e onde o modelo cascata permite
alterações posteriores, mas com um determinado custo. O problema dessa falta de
especificação é por conta da comunicação. Se não houver sucesso na comunicação,
em qualquer atividade produzida haverá conflitos e, justamente por utilizar um
modelo seqüencial, podemos ter problemas posteriores quanto ao documento de
especificação, levando em conta que qualquer modelo é apto para ser utilizado em
qualquer circunstância de desenvolvimento.
11
Nº Fatores que tornam um projeto Crítico % de Respostas 1 Falta de Especificação do Usuário 12,8% 2 Requisitos Incompletos 12,3% 3 Mudança de Requisitos 11,8% 4 Falta de Apoio Executivo 7,5% 5 Tecnologia Imatura 7,0% 6 Falta de Recursos 6,4% 7 Expectativas Irreais 5,9% 8 Objetivos Obscuros 5,3% 9 Tempo Irreal 4,3% 10 Tecnologia Nova 3,7% 11 Outros 23,0%
Tabela 1. Principais Fatores que tornam um projeto crítico. Um modelo de avaliação de requisitos no processo de desenvolvimento de software Fonte: RODRIGUES, 2006 (Pág. 2).
Considerando os fatores acima citados, podemos ver que um conjunto de
atividades é necessário para que se aplique um determinado modelo de
desenvolvimento e no final possa ter sucesso no produto de software, visando uma
qualidade, onde o software possa ter a aplicação do modelo de desenvolvimento de
acordo com o que fora citado e disponibilizado no momento da especificação dos
requisitos. Para aplicar o modelo, o desenvolvedor deve ter uma percepção do
problema e utilizando os recursos que ele tem disponível para iniciar o projeto e
verificar a viabilidade a cerca do que será produzido, visando o cronograma, o custo,
os prazos, recursos, investimento dentre outros. Enfim, existem vários critérios para
se avaliar um desenvolvimento e determinar qual o modelo a ser utilizado.
Ao observar o modelo cascata vimos sua importância para todo o projeto que
envolve o desenvolvimento de software, nele encontramos atividades indispensáveis
a serem aplicadas e que vemos em qualquer outro modelo de software a ser
utilizado, apenas o que difere são algumas melhorias que dão a importância da
participação do maior interessado, que é o cliente. Percebemos que o modelo de
desenvolvimento deve ser usado como instrumento para produção de um produto
eficiente e aceito por quem o necessita e que atenda suas necessidades expostas.
Para dar continuidade à avaliação, vamos abordar o modelo de
desenvolvimento através do incremental e perceber os seus benefícios e
dificuldades.
12
Modelo Incremental
“O modelo incremental combina elementos do modelo em cascata aplicado de maneira iterativa. O modelo incremental aplica sequências lineares de uma forma racional à medida que o tempo passa. Cada sequência linear produz incrementos do software passiveis de serem entregues.” (Pressman, 2006) (Pág. 40).
O modelo de ciclo de vida incremental e iterativo foi proposto como uma res-
posta aos problemas encontrados no modelo em cascata.
Um processo de desenvolvimento segundo essa abordagem, divide o
desenvolvimento de um produto de software em ciclos e em cada ciclo de
desenvolvimento, podem ser identificadas as fases de análise, projeto,
implementação, e testes, como mostra a figura abaixo:
Ilustração 4. Incremental Engenharia de Software, 2006. FONTE: PRESSMAN, R.S. (2006). (Pág.40)
Cada ciclo considera um subconjunto de requisitos. Os requisitos são
desenvolvidos, uma vez que sejam alocados a um ciclo de desenvolvimento. No
próximo ciclo, outro subconjunto dos requisitos é considerado para ser desenvolvido,
13
o que produz um novo incremento do sistema que contém extensões e refinamentos
sobre o incremento anterior.
Assim, o desenvolvimento evolui em versões, através da construção incremental
e iterativa de novas funcionalidades até que o sistema completo esteja construído.
Na verdade, um modelo de ciclo de vida iterativo e incremental pode ser visto como
uma generalização da abordagem em cascata: o software é desenvolvido em
incrementos e cada incremento é desenvolvido em cascata.
Um momento para aplicar o incremento é justamente quando há uma
necessidade de projetar por módulos as atividades de desenvolvimento ou quando
não há mão–de–obra disponível.
“Desenvolver um sistema de forma incremental traz vantagens ao projeto. Ao se construir gradualmente o sistema, os próprios desenvolvedores aprendem sobre o mesmo, possibilitando a localização de futuros problemas em fases iniciais. Outra vantagem de se construir um sistema gradualmente é a inata acomodação para mudanças, dado que o “todo” não é desenvolvido em apenas uma etapa”. VASCO (Pág. 2)
O modelo incremental busca permitir que cada fase possa ser visualizada em
todos os momentos e permite realizar alterações posteriores, evitando trazer
prejuizos ao desenvolvimento, realizando, gerenciando aos riscos, e permite que os
envolvidos no projeto tenham entusiasmo principalmente os desenvolvedores.
“É grande o número de projetos de desenvolvimento de software que falham. Sistemas que não atendem às necessidades do usuário, mal documentados, softwares de baixa qualidade, difíceis de manter e integrar com outros sistemas são alguns dos diversos problemas que ocasionam o fracasso de um projeto de desenvolvimento de software”. MASSONI apud FARIAS, 2006 (Pág. 13).
Com o modelo incremental, os desenvolvedores visualizam os problemas
inerentes ao projeto descobrindo os erros e corrigindo as falhas, visando qualidade
do produto de software de forma iterativa reduzindo os riscos e evitando problemas
posteriores em cada novo incremento. No gráfico abaixo é possível observar o custo
da descoberta tardia de um defeito ou falha.
14
Ilustração 5. Identificação e Prevenção de Defeitos . Um modelo de avaliação de requisitos no processo de desenvolvimento de software Fonte: Rodrigues, 2006 (Pág. 9).
O modelo incremental é baseado, de forma seqüencial, no modelo cascata onde
se pode fragmentar as atividades e obter um sucesso maior ao analisarmos os
erros, riscos, possibilitando mudanças ao longo do desenvolvimento, permitindo
revisões e alterações em suas fases. Ao aplicar o modelo incremental, pode-se
iteragir melhor com o desenvolvimento fazendo a equipe de desenvolvedores
participantes de forma ativa de modo que possa aprender e crescer no decorrer das
mudanças, no qual podemos acomodar os dados e ao mesmo tempo entregar
partes desse incremento ao cliente, se assim desejar. Porém, é necessário um
grande esforço por parte de seus estágios, sendo bem planejados e, esse
planejamento deve ser feito com um bom gerenciamento, sempre buscando
identificar possiveis erros e riscos para produzir um software confiável dentro do
cronograma.
Da mesma forma que o modelo cascata, a comunicação é essencial para o sucesso
do desenvolvimento do modelo incremental.
15
PROCESSO BASE PARA A ESCOLHA DOS MODELOS
Processo Unificado Rational
“Hoje em dia, o Processo Unificado e a UML são amplamente usados em projetos O.O. de todas as naturezas. O modelo iterativo e incremental proposto pelo PU pode, e deve ser adaptado para satisfazer às necessidades específicas do projeto”. PRESSMAN, 2006 (pág. 52).
A Orientação Objeto (O.O.) atualmente é um diferencial da área de informática.
Onde tem obtido espaço no mercado, e permitido mais um avanço em termos de
tecnologia.
“Um dos grandes diferenciais da programação orientada a objetos em relação a outros paradigmas de programação que também permitem a definição de estruturas, e operações sobre essas estruturas está no conceito de herança, mecanismo através do qual as definições existentes podem ser facilmente estendidas.” RICARTE, 2001.
Para tanto, a cada dia surgem novas tecnologias para a utilização, focando
melhorias e qualidades na área de desenvolvimento de software. Entre elas está o
Rational Unified Process (RUP), que se baseia na UML para a análise.
“A UML (Unified Modeling Language) é uma linguagem-padrão para elaboração da estrutura de projetos de software. Ela poderá ser empregada para a visualização, a especificação, a construção e a documentação de artefatos quem façam uso de sistemas complexos de software.” SILVA 2005 (pág. 13)
A UML é apenas uma linguagem que facilita a comunicação onde pode ser
empregada para visualização, a especificação, a construção, e a documentação de
artefatos, portanto é uma parte do processo no desenvolvimento.
“A UML é amplamente independente de processo, significando que é possível utiliza-lá com vários processos de engenharia de software. O Rational Unified Process, Processo Racional Unificado, consiste em uma abordagem desse ciclo de vida, especialmente adequado à UML.” SILVA, 2005 (pág. 443)
O que nos leva a uma comparação baseada no RUP é o fato de ser um
processo que visa qualidade do produto final, tendo em vista a satisfação do cliente.
Como afirma SILVA, 2005.
16
“A meta do Rational Unified Process é permitir a produção de software da mais alta qualidade que atenda as necessidades do usuário final de acordo com planejamento e orçamento previsivéis.”
O RUP possui as melhores práticas da engenharia de software e dentro dessas
práticas que está atribuido: segurança, qualidade, gerência de riscos, respeito ao
cronograma, participação dos interessados, iteratividade, e um produto que atende
às necessidades de acordo com a especificação dos requisitos expressas pelo
cliente, facilitando uma compreensão do sistema e tendo condições de acomodar
novos requisitos, se necessário, ou mudanças em sua estrutura. Seu
desenvolvimento é baseado na compreensão completa do comportamento e sua
utilização.
Como foi dito anteriormente, o RUP se baseia em seis boas práticas de
desenvolvimento de software para garantir o sucesso dos projetos que utilizam este
processo. Essas boas práticas são abordagens comprovadas comercialmente que,
quando combinadas, atacam a origem dos principais problemas que ocasionam o
fracasso de um projeto de software, evitando que os problemas ocorram ou,
antecipando-os de forma que o projeto possa ser reavaliado.
As práticas adotadas pelo processo RUP são:
- Desenvolver software iterativamente.
- Gerenciar requisitos
- Utilizar arquiteturas baseadas em componentes
- Modelar o software visualmente
- Verificar a qualidade do software de forma contínua
- Controle das mudanças do software
17
Ilustração 6. Modelo de desenvolvimento iterativo e incremental. Aplicação de padrões ao processo de desenvolvimento de software RUP Fonte: FARIAS, 2006 (Pág. 14).
“O Rational Unified Process (RUP) é o processo de desenvolvimento de software mais utilizado na indústria de software atualmente”. ZUZER apud FARIAS, 2006 (Pág. 9).
A estrutura do RUP é organizada em duas dimensões: o eixo vertical que é a
parte estática do processo e o eixo horizontal que se refere à parte dinâmica do
processo, referindo–se ao tempo, e os aspectos do ciclo de vida do processo.
Conforme mostra a figura abaixo:
Ilustração 7. Gráfico do RUP – estrutura organizada em duas dimensões. Aplicação de padrões ao processo de desenvolvimento de software RUP Fonte: FARIAS, 2006 (Pág. 14).
18
Ao realizar uma pesquisa sobre processos de desenvolvimento para saber um
pouco mais, encontramos uma tabela que nos mostra as disciplinas de alguns
processos de forma comparativa. Dessa forma, podemos constatar o RUP é o
processo mais completo dentre as demais. Como pode ser observado na tabela
abaixo:
PR
OC
ESSO
S
MO
DEL
AÇ
ÃO
DO
NEG
ÓC
IO
REQ
UIS
ITO
S
AN
ÁLI
SE
DES
ENH
O
IMP
LEM
ENTA
ÇÃ
O
TEST
E
ISN
TALA
ÇÃ
O
GES
TÃO
DE
CO
NFI
GU
RA
ÇÕ
ES E
ALT
ERA
ÇÕ
ES
GES
TÃO
DE
PR
OJE
TO
GES
TÃO
DO
AM
BIE
NTE
RUP V V V V V V V V V V
XP V V V V V
MSF V V V V V V V V
SSADM V V V
Tabela 2. Comparação das Disciplinas de Cinco Proce ssos Comparação de Metamodelos de Processos de Desenvolv imento de Software Fonte: MARTINS, 2007 (Pág. 7) Por ser um processo completo, suas características visam melhorias e toda
abordagem do projeto de desenvolvimento de software consegue ter uma qualidade
significativa, mas respeita os demais processos, aplicando algumas caracterísiticas de
forma adaptativa.
“O Rational Unified Process captura algumas das melhores práticas atuais de desenvolvimento de software de forma que pode ser adaptado a uma ampla variedade de projetos e empresas.” SILVA (pág 443)
O RUP pode ser ajustado e redimensionado para atender às necessidades de
um projeto com pequenas equipes até grandes empresas de desenvolvimentos sem
nenhum problema e, por ser um processo adaptativo, os resultados são observados
com maior facilidade proporcionando maior percepção de acerca de todo o projeto,
gerenciando-os com qualidade e maior eficiência.
Foi visto foi apenas uma demonstração sobre o processo de desenvolvimento de
software, para que possamos diagnosticar todos os problemas, a fim de chegarmos
à conclusão de forma objetiva a respeito de um modelo utilizado dentro de um
processo de desenvolvimento de software e, ressaltar que O RUP é um processo
que pode e deve ser adaptado para satisfazer às necessidades do cliente.
19
O RUP é apenas uma referência para o trabalho que podemos verificar suas
atividades e mostrar onde estão os modelos de paradigmas de desenvolvimento
inseridos, além de perceber que o processo de desenvolvimento possui várias
formas de serem aplicadas, e seu objetivo é atender às necessidades e respeitar os
prazos, beneficiando a todos, trazendo qualidade e satisfação para com o produto
de software a ser desenvolvido.
Logo mais veremos como o modelo cascata e o modelo incremental é utilizado
dentro do RUP.
Abordagem Cascata
O modelo cascata, por ser um modelo de uma única sequência linear é um
modelo completo por si. Ele tem as características necessárias para um excelente
desenvolvimento de software, uma vez que mantém todas as fases funcionais a
cada etapa concluída de forma ordenada e, caso haja alguma dúvida a cerca do que
será desenvolvido, o analista pode aplicar protótipos ou até mesmo realizar um
desenho para manter estabelecida a comunicação e retomar o curso contínuo do
projeto de forma linear.
“... o projeto é considerado como um tipo de empreendimento, esforço ou atividade, que tem começo e fim predeterminados, e que se compõe de uma seqüência de etapas logicamente ordenadas, dirigidas por pessoas com a finalidade de cumprir metas estabelecidas dentro de certos parâmetros tais como custo, qualidade, tempo e recursos.” CABEL, 1999.
O modelo cascata é um modelo de uma seqüência linear, por isto ele deve ter os
requisitos bem definidos [13], antes de se passar a uma próxima etapa, seja ele
projeto técnico ou codificação. Com isto o escopo do produto fica definido desde
cedo e, por isso, o dimensionamento do projeto de desenvolvimento, bem como
suas estimativas de custos e prazos do projeto ficam mais sólidas desde cedo [3],
contanto que os requisitos não sofram alterações consideráveis ao longo do projeto,
o que torna muito mais atrativo aos responsáveis pelo controle de custos do projeto.
A indústria de software deverá escolher o modelo que mais se adapte às
características da organização e neste caso que os requisitos estão bem definidos, o
20
recomendado é o modelo cascata visando à satisfação do produto que será
produzido.
“Existem muitas razões pelas quais pode ser necessário inserir o RUP em um ciclo de vida cascata: Para igualar a sua abordagem do desenvolvimento do software para o desenvolvimento de uma abordagem maior do sistema, para cumprir as normas impostas externamente, especialmente em uma licitação e contratação e situação em que etapas intermediárias estão relacionadas com a entrega de artefatos específicos em ordem seqüencial, para lidar com situações simples, como a manutenção de ciclos...” KRUCHTEN, 2004.
Como vimos anteriormente, podemos utilizar o modelo cascata no RUP sem
nenhum problema, uma vez salvo pelo simples fato de ser um processo adaptativo.
Como podemos ver logo abaixo, o ciclo de vida são abordagens e o que difere no
uso são as práticas de cada um. O RUP é uma organização e seu foco são as
melhores práticas da engenharia e dentre essas práticas, ele possibilita tal uso em
suas atividades.
“Uma organização pode adotar as práticas do RUP dentro de ciclo de vida cascata.” KRUCHTEN, 2004.
Outra questão que enfatiza o uso do modelo cascata no RUP, é justamente o
domínio e o conhecimento do produto a ser desenvolvido e a experiência, ou seja, a
depender do produto a ser desenvolvido, podemos aplicar tranquilamente o modelo
cascata em um projeto pequeno, sem utilizar incrementos, mas com uma base
sólida acerca do que será produzido.
“O cascata como abordagem é a maior probabilidade de êxito se o projeto: tem um pequeno número de incógnitas e riscos - ou seja, se tem um conhecido domínio, a equipe é experiente no atua processo e tecnologia, não há novas tecnologias, existe uma base preexistente arquitetura, é de curta duração (dois a três meses), é uma evolução de um sistema existente.” KRUCHTEN, 2004.
O modelo cascata é muito eficiente. Se usada da maneira correta, proporcionará
um produto confiável e satisfatório e sem nenhum prejuízo, além de permitir o uso
no RUP. Mesmos tendo todos esses benefícios, através do modelo cascata, não
podemos deixar de abordar o RUP, no modelo incremental, que permite a
flexibilidade no seu uso. Tal assertiva pode ser vista logo mais.
21
Abordagem Incremental Como foi visto anteriormente, o modelo cascata pode ser aplicado tranquilamente no
RUP, mas a base do RUP é a iteratividade e o incremento. Mesmo observando que
pode ser um sucesso o desenvolvimento de software de forma seqüencial não se
pode descartar a utilização das demais práticas da engenharia de software que
podem contribuir com o desenvolvimento e uma alternativa seria o incremento onde
essa abordagem permite uma gestão com possibilidades de alterações táticas, além
de facilitar a reutilização, permitindo identificar todos os pontos do projeto e diminuir
os riscos desde o início do ciclo de vida.
“Se o seqüencial ou cascata é uma abordagem razoável e até mesmo bem sucedida em projetos curtos ou com uma pequena quantidade de novidade ou de risco por que não quebram o ciclo de vida de um grande projeto em uma sucessão de pequenos projetos cascata? Desta forma, você pode abordar alguns requisitos e alguns riscos, desenha um pouco, aplicar um pouco, validá-lo e, em seguida, assumir mais requisitos, desenha um pouco mais, construir mais alguns, validar, e assim por diante, até que esteja terminado. Esta é a abordagem iterativa”. KRUCHTEN, 2000.
O RUP é um processo iterativo e requer uma compreensão do problema por
meio de melhorias sucessivas e, o desenvolvimento incremental é uma solução para
cada ciclo de desenvolvimento apto para mudanças.
As várias formas sequenciais do modelo incremental é a solução para avaliar um
projeto complexo. Geralmente esses projetos de grande porte necessitam de uma
iteratividade devido à quantidade de riscos, mesmo levando em conta essas
observações para se abordar um projeto utilizando incrementos, deve-se lembrar do
gerenciamento, há uma extrema necessidade de que haja experiência por parte do
gerente para se gerenciar um projeto como este e para que o desenvolvimento
atenda às necessidades e possa tornar-se adaptativo e acomodar as novas
mudanças e torna-se um produto passível de ser entregue.
“A Rational Corporation criou um produto comercial baseado no Processo Unificado chamado Rational Unified Process, RUP. O processo unificado estar fundamentado em três princípios básicos: Desenvolvimento de software iterativo e incremental: é a idéia mais importante do PU. O
22
desenvolvimento é organizado em uma série de miniprojetos, de duração fixa chamada iterações; o produto de cada iteração é um sistema testado, integrado e executável. Sendo assim o sistema cresce incrementalmente ao longo do tempo, iteração por iteração. A abordagem iterativa permite que as mudanças nos requerimentos e nas características do software tornem-se mais fáceis”. LARMAN apud MOURA, 2006 (pág. 36).
Quando o desenvolvimento é através do modelo incremental é possível obter uma
iteratividade que permite uma arquitetura robusta e que satisfaça os requisitos a
todo instante, permite evoluções de cada incremento e, por ser dividido em
incrementos, é possível trabalhar as fases no RUP.
Gerenciar todo o projeto não é uma tarefa fácil, exige muito e existem vários
riscos no projeto e, esses riscos podem ser ligeiramente diminuídos com atividades
em incrementos. Não há como realizar essas atividades sem riscos, e ao utilizar o
modelo incremental podemos apenas diminuir esses riscos e com as falhas em um
determinado ciclo de vida pode-se evitá-las em outros, e produzir um produto com
maior segurança.
A iteratividade e o incremento no RUP possuem a flexibilidade de tomadas de
decisões e justamente por esse motivo o RUP, tem a forma de gerenciamento mais
detalhada, no qual as fases podem ser alteradas e alternadas onde essa dinâmica
permite maior percepção dos problemas futuros.
O USO DOS MODELOS E PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE NAS SECRETARIAS DO ESTADO DA BAHIA
Atualmente existem 20 Secretarias no Estado da Bahia todas elas possuem uma
unidade de Tecnologia ou Desenvolvimento. Quanto aos dados, ficam sobre a
responsabilidade da PRODEB – Processamento de Dados do Estado da Bahia. Ao
realizar uma pesquisa nessas Secretarias, chegamos a alguns resultados que
permitem uma noção sobre o uso de Modelos e Processos nessas unidades
atualmente.
Essas unidades visam a questões de segurança e qualidade quando se trata de
desenvolvimento e armazenamento de dados, e suas mudanças são constantes tanto
de informações como de novas tecnologias para suprir as demandas. Quando se fala
de mudanças temos como exemplo: a SEPLAN – Secretaria de Planejamento, onde
23
realiza alterações constantemente e, por isso essas alterações implicam em todos os
aspectos sejam nos desenvolvimentos ou informações que devem ser transformada
em catálagos disponíveis num sistema através do auxilio da PRODEB.
O fato é que as Secretarias do Estado possui muitas informações que exige
extrema segurança e rapidez em disponibilizar essas informações em sistemas
atuais, ou novos sistemas desenvolvidos.
Existem algumas falhas e insatisfações ao usar esses modelos de
desenvolvimento, como também satisfação e ótimos resultados, a questão é a forma
de como são utilizadas por essas Secretarias os modelos como também os processos
e que fazem a diferença entre uma unidade e outra sobre os resultados, também
temos notas de avaliação que se encontram no anexo B, sobre esses modelos de
desenvolvimento.
Veja abaixo o gráfico sobre o uso dos modelos:
USO DOS MODELOS
CASCATA20%
INCREMENTAL35%
PROTÓTIPO5%
ESPIRAL0%
NÃO DESENVOLVE10%
NÃO INFORMADO25%
OUTROS5%
CASCATA
INCREMENTAL
PROTÓTIPO
ESPIRAL
NÃO DESENVOLVE
NÃO INFORMADO
OUTROS
Ilustração 8. Resultados sobre o uso dos modelos na s Secretarias do Estado da Bahia
Dessa maneira, nota-se que o maior indíce estão relacionados ao modelo cascata e
o incremental. Os números nos mostram que 20% referem-se ao uso do modelo
24
cascata e 35% são referentes ao uso do modelo incremental, quanto aos 25% não
informados, dão-se por conta do sigilo de algumas Secretarias do Estado, a exemplo
de: a SEFAZ – Secretaria da Fazenda e por não obter sucesso na comunicação com
alguns setores de informática dessas Secretarias. Mas são notáveis os resultados
obtidos nessa pesquisa que nos mostra o uso atual desses modelos nas Secretarias
do Estado da Bahia.
Dando continuidade à nossa pesquisa, encontramos outros resultados relativos ao
uso de processos onde foi apresentado um número de 43% do uso do Processo
Rational Unified Process.
Veja abaixo os resultados obtidos de acordo com o anexo B:
USO DOS PROCESSOS
RUP43%
OUTROS 7%
NÃO DESENVOLVE14%
NÃO INFORMADO36%
RUP
OUTROS
NÃO DESENVOLVE
NÃO INFORMADO
Ilustração 9. Resultado sobre o uso dos processos n as Secretarias do Estado da Bahia
Apesar de não termos alguns indíces maiores, por falta de comunicação com as
unidades podemos, perceber claramente o percentual do uso dos processos.
Consoante nos mostra as pesquisas.
25
Dando continuidade ao nosso estudo, devemos nos preocupar, também, com os
resultados de satisfação ao utilizar um determinado modelo, observando que também
temos informações sobre nota de avaliação e respeito ao cronograma, logo abaixo
existe um gráfico que nos mostra o grau de satisfação de utilizar um modelo de
desenvolvimento.
GRAU DE SATISFAÇÃO DO USO DOS MODELOS
RUIM RUIM RUIM RUIM RUIM
BOM BOM
BOM
BOM BOM
EXCELENTE
EXCELENTE
EXCELENTE EXCELENTE
EXCELENTE
0
0,5
1
1,5
2
2,5
3
3,5
4
4,5
CASCATA INCREMENTAL PROTÓTIPO ESPIRAL OUTROS
RUIM
BOM
EXCELENTE
Ilustração 10. Resultado sobre o grau de satisfação ao usar um determinado modelo nas Secretarias do Estado da Bahia.
Continuando com a pesquisa, ressalta-se que foi perguntado aos entrevistados qual
seria a nota de avaliação que eles dariam ao modelo de desenvolvimento utilizado.
Veja a seguir os seguintes resultados:
26
Cascata
Cascata Incremental
Incremental
Protótipo Incremental Outros Cascata Incremental
0
0,5
1
1,5
2
2,5
3
Nota 5.0 Nota 6.0 Nota 7.0 Nota 8.0 Nota 9.0 Nota 10.0
Nota de Avaliação dos Modelos
Cascata
Incremental
Espiral
Protótipo
Outros
Ilustração 11. Resultados sobre a nota de avaliação ao usar um determinado modelo nas Secretarias do Estado da Bahia.
Os gráficos gerados acima, estão baseados nas informações que se encontram
no Anexo B, e nos dá uma visão da amostra quanto ao uso dos processos e
modelos utilizados atualmente. Como mostra neste trabalho.
COMPARAÇÃO DOS MODELOS DE CICLO DE VIDA MAIS UTILIZADOS
Cascata x Incremental
Seguindo o critério das pesquisas realizadas nas Secretarias do Estado da
Bahia, abaixo será realizada uma comparação desses modelos de ciclo de vida
utilizados atualmente, e conheceremos um pouco mais sobre cada um, faremos uma
comparação entre seus benefícios para entender melhor a satisfação dos
desenvolvedores ao utilizar esses modelos de ciclo de vida.
As qualidades entre as aplicações dos modelos, de acordo com o desenvolvimento
do trabalho notável são demonstradas na tabela abaixo:
27
Nº CASCATA INCREMENTAL OBSERVAÇÕES 1 São intuitivas as atividades devem
ser realizadas a um determinado ponto no tempo.
Combina características do modelo cascata (linear seqüencial) e da prototipagem.
Há medida que o cliente começa a expressar suas necessidades ambos os modelos iniciam o projeto e o que difere é: O modelo cascata uma única seqüência e o incremental vários incrementos (seqüências) de acordo com a necessidade.
2 Como resultado, é um modelo fácil de aprender.
Os desenvolvedores aprendem mais à medida que desenvolve gradualmente
Ambos os desenvolvedores aprendem tanto no modelo cascata como no incremental a diferença é que o desenvolvedor interage no modelo cascata uma única seqüência e no incremental ele está agindo em vários problemas que são inerentes ao projeto.
3 È fácil determinar necessidades de pessoal, pois cada fase requer uma habilidade específica do conjunto durante um período de tempo.
Necessita de um excelente gerenciamento para realizar as alterações sobre os incrementos
O modelo cascata requer uma maior atenção por ser linear e continuo, num entanto é necessário um excelente gerenciamento para o incremental para que não haja prejuízos e maiores riscos tanto no projeto como no cronograma.
4 É fácil realizar agendamento. Permite realizar alterações posteriores.
5 Os riscos são identificados no início do projeto.
O gerenciamento dos riscos é realizado em cada incremento.
Qualquer projeto que se faça haverá riscos, neste caso a diferença é como são observados, no modelo cascata é identificado no início, quanto ao modelo incremental em cada incremento.
6 Os requisitos podem ser implementados utilizando as tecnologias a serem utilizadas para o projeto.
Em contato com o sistema, o cliente esclarece seus requisitos e suas prioridades para os próximos incrementos.
Os requisitos no modelo cascata permitem o uso de tecnologias nas fases e no modelo incremental você pode realizar essas mudanças e priorizar atividades nos próximos incrementos.
7 As tecnologias utilizadas no projeto não mudam ao longo da duração do projeto.
Abrange as atividades de desenvolvimento que conduzem à liberação de um produto ou versão do produto estável e executável, passível de ser entregue.
Apenas por ser uma única seqüência é que o modelo cascata não se pode alterar ao longo do projeto onde no modelo incremental permite o produto ser entregue por várias seqüências (incrementos) produzidas.
8 A equipe montada tem que ter o domínio e a familiarização por parte dos envolvidos.
Permite por parte dos interessados a ter “hands-on” tempo com o pedido bem antes da data de término do projeto. Assim utilizáveis comentários podem ser obtidos no início, permitindo o desenvolvimento organização para se ajustar a reações negativas.
Se tiver uma equipe com vasta experiência e conhecimento acerca do que será produzida ao utilizar o modelo cascata será um sucesso, da mesma forma que no modelo incremental a diferença neste caso são as possibilidades de alterações à medida que o comentário seja negativo.
9 A comunicação é o maior desafio para os desenvolvedores.
Mesmo com falhas na comunicação alterações posteriores virão a cada iteração no incremento.
Ambos precisam de uma comunicação definida, pois é a especificação de requisitos que será a expressão do cliente quanto as suas necessidades.
10 O modelo impõe que todos os requisitos sejam completamente especificados antes do
É mais adaptáveis as mudanças nas exigências do que o modelo cascata. Os requisitos são
Mesmo havendo dificuldades na comunicação através do uso do modelo cascata é permitido o uso de protótipos
28
prosseguimento das etapas seguintes;
congelados apenas para a duração de uma única iteração e somente os requisitos que afetam iterações são congelados.
para dar continuidade e no modelo incremental apenas as acomodações quanto às mudanças são trabalhadas.
Tabela 3. Comparação entre os modelos de ciclo de v ida. Project Management with the IBM Rational Unified Pr ocess: lessons from the trenches Fonte: GIBBS, 2006.
Estas são algumas comparações apresentadas de acordo com as observações
apresentadas para se tomar uma decisão.
Como pode ser visto na tabela, ao usar o modelo cascata, os riscos são
identificados no início do projeto; é esta a forma como o modelo pode avaliar o
projeto por ser um único ciclo de vida, ao contrário do modelo incremental que
possui vários ciclos de vida que podem alternar entre si, e que torna a avaliação dos
riscos com maior detalhe, porém mais trabalhosa.
Ainda na tabela, encontramos outra comparação muito interessante quanto aos
requisitos, os modelos comparados realmente tem reações diferentes quando
aplicados e no modelo cascata por ser um ciclo que a fase só pode dar continuidade
quando a anterior for concluída e precisa ter os requisitos bem definidos para não ter
problemas posteriores.
O modelo incremental por possuir a flexibilidade, realizar alterações, e
acomodações posteriores com facilidade, os requisitos não tem esse problema.
A diferença entre o modelo cascata e o modelo incremental é a quantidade de
ciclos de vida, ciclos estes com as mesmas características apenas com reações
diferentes quanto ao seu uso.
Lembre-se que os modelos comparados podem ser aplicados em qualquer
circunstância, apenas podem trazer resultados diferentes quanto a sua aplicação no
produto desenvolvido.
Ambos os modelo necessitam de atenção quanto aos requisitos que são
expressos pelo cliente para iniciar as atividades e sem contar que ambos estarão
sujeitos aos riscos que deve ter maior atenção quanto ao projeto, ao observar todos
esses critérios podemos então entender que a maior atenção deve ser dada na
comunicação, onde se estabelece o início de todo o projeto e que com certeza
apresentará as decisões que devem ser tomadas no decorrer do desenvolvimento e
moldar os evolvidos de acordo com as atividades que serão atribuídas mediante ao
que fora pedido.
29
Outra questão é quanto o cliente pretende investir; esses modelos estão de
acordo com as necessidades expressas pelo cliente e pela tomada de decisão do
analista quando utiliza-las, mas pode existir que situações pede por exemplo: o
modelo incremental e o cliente só tem recursos para investir no modelo cascata seja
por questões financeiras ou por tempo disponível, também existe situações que as
atividades expressas requer algo simples que um modelo cascata resolveria
rapidamente e a má comunicação entre desenvolvedor e cliente os levou a tomar
outra decisão, que acabou tendo que perder tempo e recursos com algo simples de
resolver, são inúmeras situações que podem ocorrer mediante a decisão dos
envolvidos além dos problemas apresentados.
Existem outras características que beneficiam e limitam cada um desses e
outros modelos, mas o importante é entender como reage cada modelo mediante os
problemas apresentados.
Reflexão
Se observado o modelo cascata, perceber-se-á que ele permite o uso de
protótipo, bem como o regresso de uma fase, se tiver uma experiência sobre seu
uso. Ademais, se aplicado de maneira correta, ter-se- á um produto de qualidade e
de baixo custo no menor tempo possível. Quanto ao uso do modelo incremental, ter-
se-á a forma linear do modelo cascata em vários incrementos, a flexibilidade e
acomodação de novas mudanças e o gerenciamento dos riscos em cada ciclo.
São modelos suficientes para produzir um software de alta qualidade e que
permite o uso de características de outros modelos de ciclo de vida onde respeitam
suas limitações, mas apresentam seus benefícios, quando bem utilizados e, podem
ser enquadrados para o sucesso do produto final.
PROBLEMAS COMUNS ENCONTRADOS NOS MODELOS
Alguns problemas identificados são:
− Falhas na comunicação entre desenvolvedor e cliente.
− Tempo insuficiente para o projeto.
30
− Expectativas Irreais.
− Falta de Recursos.
− Rejeição do produto de software por parte dos usuários.
Esses são alguns dos problemas encontrados ao realizar uma atividade de
desenvolvimento de software, como descrito anteriormente, há vários fatores que
implicam no produto de software, e não há como fugir dos riscos, onde o maior
problema, neste caso, é a comunicação exercida pelos interessados, para que o
desenvolvedor decida qual modelo irá utilizar e onde uma decisão pode acarretar em
vários fatores envolvendo este produto.
Quanto às necessidades expressas pelo cliente, e quanto aos recursos resta
esperar que o software esteja de acordo com a especificação de requisitos, no qual
o produto final vai ser avaliado pelo maior interessado que é o cliente, e esse
produto final atenda as expectativas. Observando algumas características na tabela
3, podemos perceber os benefícios e um pouco da capacidade de cada um dos
modelos de desenvolvimento abordado, comparando as vantangens e desvantagens
de um deles.
SUGESTÕES DE TRABALHOS FUTUROS
Seria interessante iniciar um trabalho focado no uso de processos de
desenvolvimento nas Secretarias, e no que leva por parte dos desenvolvedores essa
segurança no desenvolvimento, uma vez que existem inúmeros problemas aos
produtos de softwares depois de desenvolvidos, onde a maioria desses problemas
se dá pela insatisfação do usuário e pelas próprias mudanças nos requisitos no
decorrer do desenvolvimento nessas secretarias, a exemplo: Secretaria de
Planejamento - SEPLAN, que é uma das unidades que realizam mudanças
constantes em seus produtos desenvolvidos.
Há também outras unidades independentes no estado como: o CENTRO DE
ESTUDOS E DESENVOLVIMENTO DE TECNOLOGIAS PARA AUDITORIA –
CEDASC, uma autarquia do governo vinculada ao TRIBUNAL DE CONTAS DO
ESTADO DA BAHIA – TCE/BA, responsável por desenvolver sistemas para
auditorias tributárias no Estado da Bahia, que utiliza o modelo Incremental em seus
projetos de desenvolvimento, mas não utiliza processos nas suas atividades.
31
CONCLUSÃO
De acordo com o trabalho desenvolvido, não existe um modelo de
desenvolvimento de software certo ou errado, o que podemos afirmar é que: O
modelo cascata (clássico), que age de forma sequencial e linear e o modelo
incremental, que possui vários incrementos passíveis de serem entregues a
qualquer momento, juntamente ao processo RUP.
Podemos aplicar qualquer modelo de ciclo de vida em qualquer projeto de
desenvolvimento de qualquer tamanho; ao utilizar um determinado modelo o que é
válido é como ele será aplicado, levando em consideração os riscos e o cronograma.
O modelo cascata comparado ao modelo incremental, utiliza menos tempo e
menos recursos [7] que o modelo incremental, a começar pela quantidade de
pessoas envolvidas no projeto [3]. Também temos o tempo que é utilizado para a
especificação de requisitos, que uma vez bem definido, pode dar início à prática na
fase de desenvolvimento tranquilamente sem maiores surpresas [3], entre outros
aspectos.
Quanto ao modelo incremental, apesar de ser um modelo iterativo que gerencia
seus recursos com maior critério de avaliação, é um modelo que necessita de um
tempo maior para atingir as mesmas expectativas, além de um custo maior, onde no
final, ambos terão o mesmo foco que é chegar a um produto de software de
qualidade.
Estes modelos e o processo citado são completos em suas características e,
seus produtos finais de software, são de qualidade, segurança e eficiência,
procurando respeitar os prazos e estando de acordo com a documentação de
específicação de requisitos expressos pelo cliente. Requisitos estes, que são
adquiridos através de uma comunicação clara e concisa, no qual a comunicação é a
base para qualquer planejamento, para dar início e continuidade às atividades de
desenvolvimento, onde o produto de software final esteja de acordo com a
comunicação compreendida e firmada em documentos relativos ao projeto.
O modelo cascata e incremental os modelos mais utilizados atualmente, mas não
descartam os demais modelos, lembrando que os modelos e processos têm como
principal finalidade entregar produtos de software e a não concorrência de melhor
aplicação, sem falar da possibilidade de usarem algumas características aleatórias
uns dos outros. Porém, há alguns modelos que se destacam no seu uso e isso é
32
compreensível, uma vez que o objetivo é o desenvolvimento com qualidade e
respeito ao prazo que fora definido.
Ao desenvolver esses produtos de software, encontramos vários desafios, entre
esses estão: especificação de requisitos que chega a 12,8% de falhas [17] e a
manutenção [15], que alcança 67%. Não há como evitar esses problemas, mas tem
como reduzir e, para isso é que devemos ter maior atenção quando nos
comunicarmos. Como fora dito anteriormente, pois ela é a maior responsável quanto
às decisões tomadas pelos analistas de sistemas e, que leva a decisão de um
determinado modelo ou processo de desenvolvimento, e o desenvolvimento deve
ser como uma arte e, esses produtos devem atender às necessidades de quem o
solicita, e proporcionar confiança, e qualidade.
Ao comparar os modelos, percebemos as qualidades de ambos onde a diferença
é o conhecimento e a experiência de quem aplica os modelos e os processos.
Mesmo quando procuramos evitar erros e riscos, podemos observar que os erros
e os riscos são inevitáveis, pois há apenas como diminuí-los e é desta forma que os
modelos têm suas características para contribuir com a solução destes problemas e
salientar que existem outras características benéficas que ajudam quanto às
mudanças e melhorias na adaptação de um projeto de software.
O melhor seria o analista aperfeiçoar sua comunicação, e saber extrair tudo aquilo
que for necessário para somar ao que fora desenvolvido sem, perder o foco. Como
fora dito na comparação, um dos maiores desafios é a comunicação e a
comunicação é justamente a chave para o resultado.
As decisões que o analista irá tomar é que refletirá sobre os seus ombros, a
decisão e alguns aspectos como: custo, benefícios, viabilização do desenvolvimento,
tempo, pessoal, analise, aceitação por parte dos usuários, entre outros.
O importante é o software estar de acordo com a especificação de requisitos,
tenha sido produzido com o mínimo de falhas possíveis para que a correção tenha
respeitado o cronograma e seja aceito por parte do usuário.
Sem esses critérios não pode haver satisfação por ambas as partes, e por esse
motivo podemos ver alguns resultados sobre a satisfação do uso desses modelos e
do processo no trabalho desenvolvido, mas o importante é a atenção quanto ao
desenvolvimento do software solicitado.
O desenvolvimento de software é um trabalho que exige muita atenção, pois há
decisões que podem causar solução ou prejuízo, por isso é necessário entender
33
todos esses critérios para se ter uma base a respeito do conhecimento, onde a
diferença se dará com o tempo e a experiência do analista para se produzir um
software de qualidade e seguro.
Reflexão
Mesmo os modelos tendo as mesmas características, um projeto de software terá
reações diferentes.
A diferença entre os modelos comparados se dá devido ao fato de um modelo
possuir um ciclo de vida e o outro, vários ciclos de vida, que trazem resultados
diferentes. Por isso, ao realizar a escolha de um modelo, preste bem atenção nas
reações de cada um desses deles, pois é importante para realização de atividades
posteriores.
34
REFERÊNCIA BIBLIOGRÁFICA
[0] CABEL, Gabriela B, et al, Gerenciando um Projeto de Desenvolvimento de Software, 1999, [Consulta 28/06/2009] Disponível em: http://www.abepro.org.br/biblioteca/ENEGEP1999_A0284.PDF
[1] CARVALHO, A.M.B.R. Introdução à Engenharia de Software, (Série Títulos em
Engenharia de Software), Editora da Unicamp, 2001 – Campinas – SP.
[2] FARIAS, Tiago M.M., Aplicação de padrões ao processo de desenvolvimento de software
RUP, 2006 [Consulta 12/05/2009] Disponivel em:
http://dsc.upe.br/~tcc/20062/Monografia_TiagoMoraes.pdf
[3] GIBBS, R. D., Project management with the IBM Rational Unified Process: lessons from
The trenches, Data, July 2006 – Crawfordsville.
[4] HUMPHREY, Watts S., Gerenciando o Processo de Software. Publicação Addison –
Wesley – Massachussets, 1990.
[5] KRUCHTEN, Philippe, the Rational Unified Process an Introduction, Second Edition - Addison Wesley Massachusetts, July 2000. [6] KRUCHTEN, Philippe, IBM, Going Over the Waterfall with the RUP, 2004 [Consulta 13/06/2009] Disponivel em: http://www.ibm.com/developerworks/rational/library/4626.html [7] KRUCHTEN, Philippe, IBM, Aligning the Traditional Waterfall Review Sequence with the Iterative Approach, 2004 [Consulta 13/06/2009] Disponivel em: http://www.ibm.com/developerworks/rational/library/4625.html
[8] MARTINS, Paula Ventura,et al, Comparação de Metamodelos de Processos de Desenvolvimento de Software, 2004 [Consulta 12/05/2009] Disponível em: http://isg.inesc-id.pt/alb/static/papers/2004/n13-pv-quatic2004.pdf [9] MELNIKOFF, Selma S. S. Engenharia de Software e Metodologia de Programação Modelos de Processos de Desenvolvimento de Software, Julho 1992. [Consulta 11/11/2008] Disponivel em: http://www.pcs.usp.br/~pcs0409/pdfs/processoSw.PDF
35
[10] MOURA, Marcelle Cristina, et. al, Estudo e propostas iniciais para a definição de um processo de desenvolvimentos para software científico, 2006 [Consulta 12/05/2009] Disponível em: http://www.mmc.cefetmg.br/info/downloads/D016-MarcelleCristinaMouradeSouza.pdf [11] PARREIRAS, F. S., OLIVEIRA, G. S. Análise comparativa de processos de desenvolvimento de software sob a luz da gestão do conhecimento: um estudo de caso de empresas mineiras. In: SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE, 3, 2004, Brasília. Anais... , 2004.[Acessado 11/11/2008] Disponível em: http://www.fernando.parreiras.nom.br/publicacoes/WGC_Parreiras04.pdf.
[12] PRESSMAN, R.S. Engenharia de Software, 4º Edição Makron Books do Brasil, São
Paulo 1995.
[13] PRESSMAN, R.S. Engenharia de Software, 6º Edição McGraw-Hill, São Paulo 2006.
[14] PRESSMAN, R. S., Software engineering: A practitioner’s approach. 4th. Ed. McGraw –
Hill, 1997.
[15] RAMOS, Ricardo Argenton. Treinamento Prático em UML, Digerati Books – São Paulo
2006.
[16] RICARTE, Ivan Luiz Marques, Programação Orientada a Objetos:Uma Abordagem com Java, 2001[Consulta 10/06/2009] Disponível em: http://camilolopes.files.wordpress.com/2008/09/poojava_-_unicamp.pdf
[17] RODRIGUES, Luiz Gustavo Mendes, Um modelo de avaliação de requisitos no
processo de desenvolvimento de software, Fevereiro 2006 [Consulta 12/05/2009] Disponível
em: http://libdigi.unicamp.br/document/?code=vtls000388272
36
[18] SCHWARTZ, J.I., Construction of Software. In: Practical Strategies for Developing
Large Systems. Menlo Park: Addison – Wesley, 1st. Ed., 1975.
[19] SILVA, Fábio Freitas, et al, UML guia do usuário, Segunda edição, Elsevier – Rio de
Janeiro, 2005.
[20] SOMMERVILLE, I. Software engineering. 5th. Ed. Addison – Wesley, 1995.
[21] TONSIG, Sérgio Luiz, Engenharia de Software - Análise e Projeto de Sistemas - 2ª ed.
Rio de Janeiro, 2008.
[22] VASCO, Carlos G., et al, Comparação entre Metodologias RUP e XP [Consulta
12/05/2009] Disponível em:
http://www.ppgia.pucpr.br/~alcides/Teaching/mestrado/FundamentosEngenhariaSoftware/arti
gos/ResumosApresentacoes/RUPvsXP_draft.pdf
37
ANEXOS
A) Pesquisa do uso de modelos e processos nas Secretarias do Estado
da Bahia.
B) Planilha de pesquisa do uso dos modelos e processos nas Secretarias do Estado da Bahia
SALVADOR - BA, 2009
38
Anexo A
Uma Comparação entre os Modelos de Ciclo de Vida Ca scata e Incremental, Aplicados ao Processo Unificado Ration al
PESQUISA DO USO DE MODELOS E PROCESSOS NAS SECRETARIAS DO ESTADO DA BAHIA
Com o apoio de Davi Santos Silva (Cordenador de Help Desk), lotado no CENTRO DE
ESTUDOS E DESENVOLVIMENTO DE TECNOLOGIAS PARA AUDITORIA-CEDASC, orgão vinculado ao TCE/BA e Antônio Luis Carneiro (Gerente de Auditoria), lotado no TRIBUNAL DE CONTAS DO ESTADO DA BAHIA – TCE-BA, onde foram realizadas ligações telefônicas para todas as Secretarias do Estado da Bahia, no período de 27 a 29 de Maio de 2009 e existem no total de 20 unidades (órgãos) em funcionamento, obtendo informações com Analístas e Coordenadores de Desenvolvimento de Sistemas, com o objetivo contribuir com a pesquisa.
SIGLA ORGÃO
SAEB SECRETARIA DE ADMINISTRAÇÃO
SEAGRI SECRETARIA DE AGRICULTURA, IRRIGAÇÃO E REFORMA AGRÁRIA
SEC SECRETARIA DE EDUCAÇÃO
SECULT SECRETARIA DE CULTURA DA BAHIA
SECTI SECRETARIA DE CIÊNCIA, TECNOLOGIA E INOVAÇÃO
SEDES SECRETARIA DE DESENVOLVIMENTO SOCIAL, E COMBATE À POBREZA
SEDIR SECRETARIA DE DESENVOLVIMENTO E INTEGRAÇÃO REGIONAL
SEDUR SECRETARIA DE DESENVOLVIMENTO URBANO
SEFAZ SECRETARIA DA FAZENDA
SEINFRA SECRETARIA DE INFRA-ESTRUTURA
SEMARH SECRETARIA DE MEIO AMBIENTE E RECURSOS HÍDRICOS
SEPLAN SECRETARIA DO PLANEJAMENTO
SEPROMI SECRETARIA DE PROMOÇÃO DE IGUALDADE
SERIN SECRETARIA DE RELAÇÕES INSTITUCIONAIS
SESAB SECRETARIA DE SAÚDE
SETRE SECRETARIA DO TRABALHO, EMPREGO, RENDA E ESPORTE
SETUR SECRETARIA DO TURISMO
SJCDH SECRETARIA DA JUSTIÇA, CIDADANIA E DIREITOS HUMANOS
SSP SECRETARIA DE SEGURANÇA PÚBLICA
SICM SECRETARIA DA INDÚSTRIA, COMÉRCIO E MINERAÇÃO Tabela 4. Siglas e nomes dos orgão pesquisados.
SALVADOR - BA, 2009
39
GERAL Abaixo estão as perguntas que irão gerar os gráficos apresentados na monografia. Perguntas realizadas: 1. Qual é o modelo de desenvolvimento utilizado nesta unidade?
2. Qual o processo de desenvolvimento utilizado?
3. O modelo de desenvolvimento respeita o cronograma estabelecido?
4. Qual nota você daria ao modelo de desenvolvimento utilizado?
5. De acordo com a reação qual é o grau de satisfação por parte dos desenvolvedores ao
utilizar o modelo?
Respostas relativas às pesquisas seguem em uma planilha no Anexo B.
SALVADOR - BA, 2009
40
Anexo B
Uma Comparação entre os Modelos de Ciclo de Vida Ca scata e Incremental, Aplicados ao Processo Unificado Ration al
PLANILHA DE PESQUISA DO USO DOS MODELOS E PROCESSOS NAS SECRETARIAS DO ESTADO DA BAHIA
Nº
Orgão
Responsável / Analísta / Unidade
Telefone
Modelo Utilizado
Na Secretaria
Grau de Satisfação
do modelo
Processo
Desenvolvimento
Respeitou o Cronograma
Nota de
Avaliação
1 SAEB ARLEYS PEREIRA 3115-1623 INCREMENTAL EXCELENTE NÃO SIM 10.0
2 SEAGRI NÃO INFORMADO 3115-2802 - - - - -
3 SEC NÃO INFORMADO 3115-1443 - - - - -
4 SECULT MAGNO BARBOSA 3116-4000 NÃO DESENVOLVE - NÃO - -
5 SECTI ADRIANO FIRMO 3117-3731 INCREMENTAL EXCELENTE XP SIM 8.0
6 SEDES ROBER 3115-3853 CASCATA EXCELENTE NÃO SIM 10.0
7 SEDIR SEPLAN 3115-3550 CASCATA BOM NÃO NÃO 6.0
8 SEDUR ARNALDO BISPO 3116-5700 MVC EXCELENTE RUP SIM 9.0
9 SEFAZ NÃO INFORMADO 0800-071-0071 - - - - -
10 SEINFRA RICARDO ALMEIDA 3115-2125 INCREMENTAL EXCELENTE RUP NÃO 7.0
11 SEMARH RODOLFO NETO 3115-6288 INCREMENTAL EXCELENTE RUP SIM 9.0
12 SEPLAN WALNEY ALMEIDA 3115-3596 CASCATA BOM NÃO NÃO 6.0
13 SEPROMI ELZA 3115-5113 NÃO DESENVOLVE - NÃO - -
14 SERIN NÃO INFORMADO 3371-2520 - - - - -
15 SESAB PATRÍCIA PIRES 3115-4227 CASCATA BOM NÃO NÃO 5.0
16 SETRE ANTÔNIO RIOS 3115-3275 INCREMENTAL BOM RUP SIM 8.0
17 SETUR SÍLVIA MOURA 3116-4186 PROTÓTIPO BOM NÃO SIM 8.0
18 SJCDH ERICK DE SOUZA 3115-4146 INCREMENTAL BOM RUP SIM 8.0
19 SSP KATIÚCIA FERREIRA
3116-1913 INCREMENTAL BOM RUP SIM 7.0
20 SICM NÃO INFORMADO 3370-7862 - - - - -
Tabela 5. Uma Amostra do uso dos modelos e processo s utilizado nas Secretarias do Estado da Bahia.
SALVADOR - BA, 2009