Uma Comparação entre os Modelos de Ciclo de Vida Cascata e Incremental, Aplicados ao Processo Unificado Rational.

29,005 views
28,680 views

Published on

Published in: Education
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
29,005
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
448
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

Uma Comparação entre os Modelos de Ciclo de Vida Cascata e Incremental, Aplicados ao Processo Unificado Rational.

  1. 1. 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
  2. 2. JONAS BONFIM DE OMENA
  3. 3. Uma Comparação entre os Modelos de Ciclo de Vida Cascata e Incremental, Aplicados ao Processo Unificado Rational 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.
  4. 4. 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.
  5. 5. 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.
  6. 6. 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.
  7. 7. 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 UTILIZADOS _____ 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
  8. 8. 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
  9. 9. 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
  10. 10. 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.
  11. 11. 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):
  12. 12. 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.
  13. 13. 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...”
  14. 14. 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.”
  15. 15. 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.
  16. 16. 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)
  17. 17. 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.
  18. 18. 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:
  19. 19. 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.
  20. 20. 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.
  21. 21. 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,
  22. 22. 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.
  23. 23. 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.
  24. 24. 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.
  25. 25. 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
  26. 26. 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).
  27. 27. 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: PROCESSOS MODELAÇÃODO NEGÓCIO REQUISITOS ANÁLISE DESENHO IMPLEMENTAÇÃO TESTE ISNTALAÇÃO GESTÃODE CONFIGURAÇÕESE ALTERAÇÕES GESTÃODEPROJETO GESTÃODO AMBIENTE 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 Processos Comparação de Metamodelos de Processos de Desenvolvimento 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.
  28. 28. 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
  29. 29. 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.
  30. 30. 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
  31. 31. 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
  32. 32. 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 CASCATA 20% INCREMENTAL 35% PROTÓTIPO 5% ESPIRAL 0% NÃO DESENVOLVE 10% NÃO INFORMADO 25% OUTROS 5% CASCATA INCREMENTAL PROTÓTIPO ESPIRAL NÃO DESENVOLVE NÃO INFORMADO OUTROS Ilustração 8. Resultados sobre o uso dos modelos nas 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
  33. 33. 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 RUP 43% OUTROS 7% NÃO DESENVOLVE 14% NÃO INFORMADO 36% RUP OUTROS NÃO DESENVOLVE NÃO INFORMADO Ilustração 9. Resultado sobre o uso dos processos nas 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.
  34. 34. 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:
  35. 35. 26 Cascata Cascata Incremental Incremental Protótipo Incremental Outros CascataIncremental 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:
  36. 36. 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
  37. 37. 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 vida. Project Management with the IBM Rational Unified Process: 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.
  38. 38. 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.
  39. 39. 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.
  40. 40. 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 é
  41. 41. 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
  42. 42. 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.
  43. 43. 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
  44. 44. 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
  45. 45. 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
  46. 46. 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
  47. 47. 38 Anexo A Uma Comparação entre os Modelos de Ciclo de Vida Cascata e Incremental, Aplicados ao Processo Unificado Rational 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
  48. 48. 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
  49. 49. 40 Anexo B Uma Comparação entre os Modelos de Ciclo de Vida Cascata e Incremental, Aplicados ao Processo Unificado Rational 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 processos utilizado nas Secretarias do Estado da Bahia. SALVADOR - BA, 2009

×