1

FACULDADE LOURENO FILHO CINCIA DA COMPUTAO

MARIA GARDNIA FERREIRA GADELHA

UMA PROPOSTA DE PROCESSOS DE DESENVOLVIMENTO DE SISTEMAS EM UMA FBRICA DE SOFTWARE PARA CURSOS DE COMPUTAO E INFORMTICA

FORTALEZA, 2010

2

MARIA GARDNIA FERREIRA GADELHA

UMA PROPOSTA DE PROCESSOS DE DESENVOLVIMENTO DE SISTEMAS EM UMA FBRICA DE SOFTWARE PARA CURSOS DE COMPUTAO E INFORMTICA

Monografia apresentada ao curso de Cincia da Computao da Faculdade Loureno Filho como requisito parcial para obteno do grau de Bacharel em Cincia da Computao. Orientador: Prof. Ms. Jos Alzir Bruno Falco.

FORTALEZA - 2010MARIA GARDNIA FERREIRA GADELHA

3

UMA PROPOSTA DE PROCESSOS DE DESENVOLVIMENTO DE SISTEMAS EM UMA FBRICA DE SOFTWARE PARA CURSOS DE COMPUTAO E INFORMTICA

Monografia Apresentada ao curso de Bacharel em Cincias da Computao da Faculdade Loureno Filho, como parte dos requisitos necessrios para a obteno do grau de Bacharel em Cincias da Computao.

Composio da Banca Examinadora:

_______________________________________ Prof. MSc. Jos Alzir Bruno Falco (Orientador)

_______________________________________ Prof. MSc. Carlos Alberto Manso

______________________________________ Prof. MSc. Carlos Roberto Vieira Arago

4

Dedico a minha me Marli, pelo incentivo, e agradeo a Deus, todos os dias, por t-la em minha vida.

5

AGRADECIMENTOS

Agradeo primeiramente a Deus por estar sempre presente, dando-me foras para continuar. Graas a Ele tenho o que agradecer e para quem agradecer. Ao senhor Joo Chaves, por ter feito o possvel e o impossvel para me oferecer a oportunidade de estudar. Aos meus pais e ao meu noivo Flvio, pela compreenso e pacincia e todo carinho, sempre me apoiando na trajetria dessa conquista e aceitando a minha ausncia, quando necessrio. Ao meu irmo Deodoro, pela leitura zelosa de meu texto, pelas sugestes e pelo apoio. A todos os professores da Faculdade Loureno Filho, em especial ao meu orientador, Jos Alzir Bruno Falco, que sempre exigiu o melhor de mim. Muito obrigada pela imensa ajuda. As amigas, Ndia, Heliene e Juliana, pelo incentivo e pela fora. Aos funcionrios da FLF, notadamente aos que trabalham na Biblioteca, em especial o Clayton. professora Suelene, por todo apoio e carinho. Ao professor e coordenador Carlos Manso, pela compreenso de sempre. Agradeo a todas as pessoas do meu convvio que acreditaram e contriburam, mesmo que indiretamente, para a concluso deste curso.

6

V mais longe a gaivota que voa mais alto. Richard Bach

7

RESUMO

Os Cursos de Computao e Informtica exigem uma forte associao do conhecimento tcnico com sua aplicao prtica. Devido constante evoluo das tecnologias, imprescindvel que os estudantes disponham de equipamentos modernos, interligados em rede e com acesso internet. Atualmente, as instituies de ensino, em sua grande parte, no tm o espao fsico, a estrutura necessria e os profissionais de ensino disponveis para desenvolver a praticidade dos cursos citados. Alm disso, poucas so as que adotam aes para atacar a problemtica das qualificaes profissionais dos seus alunos. Para minimizar este problema, este trabalho prope um modelo implementado de uma fbrica de software para os cursos acima mencionados na Faculdade Loureno Filho sede em Fortaleza-CE. So apresentados os conceitos fundamentais associados engenharia de sistemas de software; os principais trabalhos sobre fbrica de software; e, por fim, uma proposta de adequao aos processos de uma fbrica de software para cursos de Computao e Informtica. A fbrica surge no mbito de um programa de formao complementar, com o propsito de aprimorar a formao de profissionais qualificados para o mercado de trabalho. Conclui-se, ento, que com a constante evoluo das novas tecnologias envolvidas no desenvolvimento de sistemas, as fbricas sero cada vez mais efetivas dentro de seu objetivo de produzir software de qualidade com baixo custo e em pouco tempo. Palavras-chave: Engenharia de Software. Processos de desenvolvimento de Software. Fbrica de Software.

8

ABSTRACT

Computer science and information technology degrees demand a high level of cohesion between acquiring knowledge and its practical application. Due to the constant evolution in techonology, it's vital for the students to have modern, networked, internet capable equipment available. Nowadays, the majority of the teaching institutions don't have physical space, the necessary structure and teaching professionals available to develop the pratical side of these courses, only a few institutions adopt actions to address the problem of the professional qualification of their students. To minimize this problem, this paper proposes a model of a software factory for the CS & IT courses in a small College, Faculdade Loureno Filho at Fortaleza-CE. This paper presents the fundamental concepts associated to the software engineering science; the principal academic works about software factories; and, as a conclusion, a proposal for adapting a sofware factory in a computer science and information technology courses to the necessary processes. This factory is born as a complementary course, with the purpose of enhancing the production of qualified professionals for the work market. It is then concluded that, with the constant evolution of new technologies involved in software development, software factories will be more and more effective in their objetive of producing low cost, high quality software in reduced time. Keywords: Software Engineering. Software development process. Software factory.

9

SUMRIOINTRODUO 1 PROCESSO DE DESENVOLVIMENTO DE SISTEMAS 1.1 Introduo 1.2 Conceitos bsicos 1.3 Metodologias de Desenvolvimento de Software 1.3.1 Metodologia Tradicional 1.3.2 Metodologia gil 1.4 UML 1.5 CMMI 1.6 Processos de Desenvolvimento de Software 1.6.1 Modelos de Processos de Software 1.7 Sistemas de Informao 1.7.1 Tipos de sistemas de Sistema de Informao 1.8 Fbrica de Software - (FS) 2 ORIGEM E EVOLUO DOS PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE 3 OS FUNDAMENTOS DO PROCESSO UNIFICADO 3.1 Introduo 3.2 Histricos do Processo Unificado (PU) 3.2.1 Fases e Disciplina do Processo Unificado 3.3 Diferenas entre PU E RUP 3.3.1 Prticas 3.3.2 Estruturas do Processo 3.4 Ciclos de Vida 3.5 Disciplinas 4 UMA PROPOSTA DE ADEQUAO AOS PROCESSOS DE UMA FBRICA DE SOFTWARE PARA CURSOS DE COMPUTAO E INFORMTICA 4.1 Introduo 4.2 Motivaes de uma Fbrica no Ambiente Acadmico 4.3 O Projeto da Fbrica de Software da Faculdade Loureno Filho 4.3.1 Fluxo do Processo Operacional 4.4 A Estrutura Organizacional 4.5 Estratgias de Operao 4.6 O Processo Unificado da Fbrica de Software da Faculdade Loureno Filho (FLF) 4.7 O Programa de Capacitao da FLF-FS 4.7.1 Competncias e Carreiras 4.8 Parceiros e Convnios CONCLUSO REFERNCIAS 59 59 59 59 60 61 63 70 73 75 76 77 79 12 14 14 15 17 17 18 20 20 23 24 31 31 33 38 49 49 49 51 51 52 54 55 56

10

Lista de Figuras

Figura 1: Camada da Engenharia de Software Figura 2: Nveis de Maturidade do CMMI Figura 3: Modelo Sequencial Linear ou Cascata Figura 4: Modelo Incremental Figura 5: Modelo Rad Figura 6: Desenvolvimento Evolucionrio Figura 7: Modelo de Prototipagem Figura 8: Modelo de Espiral Figura 9: Escopo de Fbrica de Software Figura 10: Ciclo de Vida do Processo Unificado Figura 11: Escopos da Fbrica de Software Figura 12: Estrutura Organizacional da FLF-FS

16 22 25 26 27 28 29 30 36 54 61 62

11

Figura 13: Ciclo de vida do Desenvolvimento de Software Figura 14: Processo de Capacitao FLF-UP

73 74

12

Lista de Tabelas

Tabela 1: Mapeamento de Processos para Fbricas de Software

42

13

INTRODUO

A formao de profissionais dos cursos de Computao e Informtica algo que exige uma forte associao do conhecimento tcnico com sua aplicao prtica. As principais razes disso so a complexidade dos sistemas de software e as novas tecnologias. As empresas produtoras de desenvolvimento de software tm reivindicado, com frequncia, melhor qualificao dos desenvolvedores recmformados. Portanto, existem fundamentos suficientes para que instituies de ensino passem a adotar aes corretivas para a problemtica da qualificao profissional dos seus alunos. Um fator grave dos cursos de Computao e Informtica a falta de oportunidade para consolidar o conhecimento adquirido. Muitos profissionais, mesmo qualificados, no conseguem desenvolver suas funes em virtude da falta de profissionais habilitados para exercer sua profisso de forma proficiente. E para que isso ocorra necessrio que as instituies de ensino disponibilizem aos alunos uma estrutura fabril, porm poucas so as que dispem de uma estrutura prpria para implantar um programa de resgate da qualidade do ensino dos cursos mencionados. Neste contexto, esta monografia desenvolve uma proposta de processos de desenvolvimento de software em uma fbrica. O objetivo geral deste trabalho mostrar a importncia de uma fbrica de software nas instituies de ensino. Os objetivos especficos so: i) apresentar trabalhos exitosos que tm como foco a implantao de fbricas de software; ii) descrever todo o processo que envolve um desenvolvimento de software, distinguindo pontos convergentes e divergentes do RUP e do Processo Unificado; iii) sugerir uma proposta de adequao aos processos de uma fbrica de software para cursos de Computao e de Informtica da Faculdade Loureno Filho, sede em Fortaleza/Ce.

14

Estima-se que a proposta da fbrica de software em instituies de ensino para os cursos de Computao e Informtica contribua tanto para os alunos como para a prpria instituio. As principais contribuies so: - Diferencial Competitivo: os alunos passam a ter experincia profissional com conhecimento tecnolgico; - Desenvolver habilidades voltadas para o mercado de trabalho na rea de Tecnologia da Informao; - Tornar o conhecimento homogneo entre os alunos, em suas atividades de pesquisa, desenvolvimento e inovao; Visando atingir aos objetivos propostos foi realizado um levantamento bibliogrfico, em obras e trabalhos acadmicos, alm de artigos na internet. Partindo das concepes apresentadas, este trabalho composto por quatro captulos, alm da Introduo, os quais esto elencados a seguir: O Captulo 1 aborda os conceitos fundamentais associados engenharia de software e os aspectos mais especficos de uma fbrica de software para Cursos de Computao e Informtica. O Captulo 2 faz uma reviso bibliogrfica, destacando os principais trabalhos j publicados sobre o tema e sua evoluo em direo aplicao em modelos de fbrica de software. O Captulo 3 evidencia uma descrio desse processo de desenvolvimento de software. O Captulo 4 apresenta uma proposta de processos de desenvolvimento de sistemas em uma fbrica de software para cursos de Computao e Informtica. Por fim h a Concluso com as principais contribuies do assunto desenvolvido, seguida das referncias bibliogrficas.

15

CAPTULO 1 PROCESSOS DE DESENVOLVIMENTO DE SISTEMAS1.1 Introduo Ns dias de hoje h, em nosso pas, uma intensa demanda por servios especializados, baseados em tecnologias e, consequentemente, uma demanda maior para contratao de profissionais qualificados. O mercado brasileiro de Tecnologias de Informao e Comunicao (TICS) no diferente, principalmente nos dias atuais, em que vivemos um momento peculiar. Com isso entendemos que a engenharia de software tem potencial para contribuir com a qualificao desses profissionais, por ser uma disciplina que rene metodologias, mtodos, processos e ferramentas a serem utilizadas, desde a percepo do problema at o momento em que o sistema desenvolvido, implantado e plenamente utilizado. Sabemos que hoje em dia o software assume um duplo papel: ele o produto e, ao mesmo tempo, o vnculo para entrega do produto. A esse vnculo chamamos de processo, que tem grande importncia no estudo da Engenharia de Software. Neste contexto, o software transformador de informaes, produzindo, gerando, adquirindo, modificando, executando ou transmitindo informaes. Com a grande demanda de desenvolvimento de software, houve a necessidade das Instituies de Ensino e Pesquisas Tecnolgicas desenvolverem maior potencial de disseminar conhecimentos na rea, atuando como capital intelectual de qualidade. Neste captulo abordaremos os conceitos fundamentais da engenharia de software, essenciais para a compreenso dos modelos de Fbricas de Software que se ajustam bem no espao acadmico, na forma de um laboratrio de prtica, envolvendo o aluno com os conceitos, com o problema e com as atividades inerentes ao processo de desenvolvimento de software.

16

1.2 Conceitos Bsicos Esta seo aborda os conceitos bsicos para o entendimento da nossa proposta. Iniciamos fazendo uma distino entre software e hardware.

a) Software Frequentemente conhecido como a parte lgica da computao, o software possua, no incio da era tecnolgica, uma importncia pequena, entretanto, com o tempo, esta importncia foi se tornando maior. Pressman (2006) define o software como sendo: a) instrues que quando executadas produzem a funo e o desempenho desejados; b) estruturas de dados que possibilitam que os programas manipulem adequadamente a informao; c) documentos que descrevem a operao e o uso dos programas. Partindo desta definio bem abrangente, o software tem se tornado um produto independente do hardware, ocasionando um crescimento da sua importncia. O software difere do hardware basicamente por uma nica palavra: fsico. O hardware possui partes fsicas, consegue-se tocar e ver o que se est construindo. Para o software, necessita-se de uma abstrao maior. A partir disto que Pressman (2006, p. 15) destaca trs caractersticas dos softwares. A primeira delas que o software desenvolvido ou projetado por engenharia, no manufaturados no sentido clssico, por se tratar de produtos completamente diferentes, apesar da interao, os seus processos de criao so diferentes. Segundo, software no se desgasta. Todo software feito sob medida Essa a terceira caracterstica, que faz do software uma pea especialmente moldada, para ser aplicada em um processo especfico ou para auxiliar na realizao de certa atividade.

b) Engenharia de Software

Grande parte de nosso software entregue depois do prazo, acima do oramento previsto e com falhas residuais, e no atende s necessidades dos clientes. A comunidade de software necessitava de algo que a ajudasse a melhorar seus processos e tcnicas de desenvolvimento, e em 1968 surgiu o termo

17

Engenharia de Software, uma disciplina criada exclusivamente para estudar e aprimorar desenvolvimento de software (SOMMERVILLE, 2007). Segundo Fritz (1969 apud PRESSMAN, 2006, p.17), a Engenharia de Software a criao e a utilizao de slidos princpios de engenharia, a fim de obter softwares econmicos que sejam confiveis e que trabalhem eficientemente em mquinas reais. De acordo com Pressman (2006, pp. 17 e 18) a engenharia de software uma tecnologia em camadas, que deve se apoiar num compromisso organizacional com a qualidade. Seus principais elementos so: mtodos, ferramentas e procedimentos. Os mtodos detalham "como fazer" para se construir o software; as ferramentas proporcionam apoio automatizado ou semi-automatizado ao mtodo; e o procedimento constitui o elo que mantm juntos os mtodos a sua ferramenta, e possibilita um processo de desenvolvimento claro, eficiente, visando garantir ao desenvolvedor e a seus clientes uma produo de qualidade. Assim sendo, a figura 1 a seguir apresenta as camadas da engenharia de software com foco na qualidade. A cada dia surgem novos mtodos, processos, linguagens e ferramentas para controlar a complexidade do software, diante das dificuldades sentidas at hoje como: projeto atrasado passvel de erros e com o oramento extrapolado. Pode-se software. dizer que a Engenharia de Software consiste no

estabelecimento de princpios cientficos e mtodos para implementao eficaz de

Figura 1: Camadas da Engenharia de software. Fonte: Pressman (2006, p. 17)

18

1.3 Metodologias de Desenvolvimento de Software Hoje em dia, muitos projetos de desenvolvimento de software so iniciados e no so terminados, outros so terminados consumindo prazos e oramento bem acima do que foi planejado no incio do projeto. Muito software desenvolvido possui um nvel muito baixo de qualidade. Por isso, torna-se necessrio o uso de uma metodologia de desenvolvimento de software para ajudar a qualificar o produto final do desenvolvimento de software. Metodologia de desenvolvimento de software um conjunto de atividades que auxiliam a produo de software. Atualmente, entre as metodologias de desenvolvimento de software, as mais conhecidas so as metodologias geis: XP, Scrum e aquelas voltadas para sistemas que requerem maior documento, como o RUP. Um exemplo desse tipo de software o sistema de controle de um avio de caa.

1.3.1 Metodologia Tradicional As metodologias tradicionais surgiram na dcada de 80, em contexto muito diferente do atual, onde a demanda por software no era to grande e o acesso tecnologia era excessivamente caro para a maioria dos usurios. Baseada apenas em mainframes e terminais burros, havia uma viso geral de que a melhor maneira de obter o melhor software era por meio de um cuidadoso e minucioso planejamento de produto. Esse tipo software era desenvolvido por equipes grandes, que por vezes trabalham para empresas diferentes, muitas vezes, separadas geograficamente, durante longos perodos. Um exemplo desse tipo de software o sistema de controle de um avio moderno, que pode levar mais de dez anos, desde a especificao inicial at sua disponibilizao (SOMMERVILLE, 2007). So repletas de burocracias e tm sua eficincia em projetos grandes que no sofram muitas alteraes sobre seus requisitos. As metodologias tradicionais tambm so chamadas de pesadas devido ao seu tamanho e dificuldade de serem implementadas. Ainda hoje elas so muito utilizadas no desenvolvimento de software. O RUP uma metodologia para

19

desenvolvimento

de

software

tradicional,

com

qualidade

que

atenda

s

necessidades do cliente.a) Rational Unified Process (RUP)

A Rational Software uma empresa especializada em solues para desenvolvimento e implantao de software. Foi constituda por trs das maiores autoridades em orientao a objetos que so Grady Booch, James Rumbaugh e Ivar Jacobson. O principal produto da Rational o RUP, um processo de engenharia de software criado e desenvolvido por ela, que consiste em atribuir tarefas e responsabilidades dentro de uma empresa de desenvolvimento de software. Segundo Kruchten (2003) seu principal objetivo assegurar uma produo de alta qualidade de software, que realize a necessidade do usurio, seguindo osprazos e o oramento.

1.3.2 Metodologia gil Metodologia gil o nome dado a um conjunto de tcnicas que pretendem conduzir o processo de desenvolvimento de software com rapidez. Essas metodologias permitem equipe de desenvolvimento concentrar-se somente no software, ao invs de seu projeto e documentao. Geralmente, contam com uma abordagem iterativa para especificao, desenvolvimento e entrega de software, e foram criadas principalmente para apoiar o desenvolvimento de aplicaes de negcios nas quais os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento (SOMMERVILLE, 2007). As metodologias geis so uma reao a metodologias tradicionais e conceituais. O surgimento dessas metodologias deu-se pelo fato de seus

idealizadores terem presenciado um grande nmero de projetos que no tiveram um retorno esperado ou que muitas vezes acabaram sendo cancelado, tentarem definir maneiras para extinguir com o caos que alguns projetos de software acabam por se tornaram. Na dcada de 90, alguns profissionais da indstria de software comearam a sugerir novos processos e desenvolvimento que fossem mais adequados para lidar com os aspectos humanos dos projetos. Em fevereiro de 2001,

20

profissionais experientes se reuniram em Otan (EUA), pela Conferncia de Engenharia de Software, para discutir suas prticas de desenvolvimento. Ns estamos descobrindo melhores modos para o desenvolvimento de software, executando e ajudando os outros a desenvolver. Por meio deste trabalho valorizase: Os indivduos e sua iterao acima de processos e ferramentas; b) Software funcionando acima de documentao abrangente; c) Colaborao do cliente acima de negociao, as melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas; Existem hoje diversos mtodos geis sendo utilizados em empresas, universidades e centros de pesquisas. Dentre os mtodos mais famosos esto o XP e o Scrum. A seguir explicaremos um pouco do XP.

b) Extreme Programming (XP) XP gil, com foco em qualidade de projetos e agilidade de equipe. voltado para projetos cujos requisitos so vagos e mudam com freqncia, aplicvel em equipes pequenas em geral, doze desenvolvedores de sistemas. XP um processo de desenvolvimento que busca assegurar que o cliente receba o mximo de valor de cada dia de trabalho da equipe de desenvolvimento e organizado em torno de um conjunto de valores e prticas que atuam de forma harmnica e coesa, para assegurar que cliente sempre recebe um alto retorno do investimento em software (TELES, 2004). XP enfatiza o desenvolvimento rpido do projeto e visa garantir a satisfao do cliente que so conduzidos por quatro valores: Feedback, Comunicao, Simplicidade e Coragem.

Feedback A finalidade do feedback manter atualizados o desenvolvedor e o cliente do andamento do projeto, podendo, assim, o cliente sugerir novas caractersticas, e evitando a barreira entre cliente, gerente e desenvolvedor.

Comunicao

21

A comunicao o principal valor da XP, a maioria das prticas est baseada nela, e se esta no for eficiente, pode causar problemas e atrasos no desenvolvimento do sistema.

Simplicidade XP aposta que melhor fazer algo simples e de desenvolvimento rpido hoje, e ter de gastar um pouco mais no futuro, se for necessrio fazer modificaes, do que implementar algo complicado hoje que talvez no venha a ser usado.

Coragem Como o sistema desenvolvido de forma incremental, o time estar sempre fazendo manuteno do software ou adicionando novas funcionalidades. Algumas vezes ser necessrio alterar algo que estava funcionando corretamente, o que poder gerar falha. XP bastante questionada quanto sua eficcia, devido a pouca documentao pregada pela metodologia.

1.4 UML A Unified Modeling Language (UML) uma linguagem padro para documentar projetos de software. Pode ser utilizada para visualizar, especificar, construir e documentar os elementos de um sistema baseado em software. A UML foi concebida para modelar sistemas dos mais variados tipos: sistemas de tempo real, sistemas distribudos baseados na web, sistemas de informao e outros. A documentao gerada com UML aborda a arquitetura do sistema e todos os seus detalhes, provendo uma linguagem para expressar os requisitos funcionais e de teste.

1.5 CMMI O CMMI um modelo abrangente de qualidade desenvolvido pelo SEI (Software Engineering Institute), que se baseia em um conjunto de capacidades da engenharia de software presentes medida que a organizao alcana diferentes

22

nveis de maturidade (PRESSMAN, 2006, p. 22). O CMMI no define como o processo deve ser implementado, mas prescreve suas caractersticas estruturais e semnticas em termos de objetivos e de grau de qualidade com que o trabalho deve ser realizado. O CMMI possui duas representaes: "contnua" ou "por estgios". Elas permitem organizao utilizar diferentes caminhos para a melhoria, de acordo com seu interesse. A contnua permite que uma organizao selecione uma rea (ou um grupo de reas) de processo e melhore os processos relacionados. A estrutura em estgios organizada em nveis de maturidade que estabelecem fundamentos sucessivos para a contnua melhoria do processo. No modelo, a maturidade de uma organizao definida por nveis de 1 a 5 no intuito de descrever recomendaes evolutivas para a organizao que pretende melhorar os processos e manter os seus produtos e servios.

Inicial No nvel de maturidade 1, faltam planejamento e controle dos processos. Frequentemente prazos, cronogramas e oramentos so excedidos, dando origem a uma grande variedade de resultados. Muitas organizaes que se encontram nesse nvel no so capazes de repetir sucessos anteriores.

Gerenciado No nvel de maturidade 2 existe uma gesto bsica de projetos. Constata-se que os requisitos so gerenciados e que os processos so planejados, executados medidos e controlados. A utilizao de projetos estruturados permite a repetio de processos anteriores.

Definido No nvel de maturidade 3, os projetos so bem caracterizados e esto

escritos em padres, procedimentos, ferramentas e mtodos. Os padres, descries de processos e procedimentos so utilizados para manter a consistncia

23

em toda empresa. Existem adaptaes em projetos para que um processo se adque a reas especficas. Nesse nvel, os projetos so descritos com mais detalhe e rigor.

Gerenciado Quantitativamente No nvel de maturidade 4, os objetivos quantitativos so baseados nas

necessidades dos clientes, dos usurios finais da organizao e dos responsveis pela implementao dos processos, esses objetivos so utilizados como critrio para o gerenciamento dos processos. Medidas detalhadas de desempenho de processos so coletadas e analisadas de forma estatstica. So identificadas causas de variaes de processos e, quando apropriado, as fontes dessas causas so corrigidas, a fim de evitar ocorrncias futuras. O nvel de previsibilidade aumenta e a variao dos resultados diminui devido ao conhecimento quantitativo dos processos.

Otimizado No nvel de maturidade 5 ocorre um aperfeioamento contnuo dos processos por meio de melhorias tecnolgicas incrementais e inovadoras. Objetivos quantitativos de melhoria de processos para a organizao so estabelecidos, continuamente revisados para refletir alteraes nos objetivos do negcio e utilizados como critrios para gerenciamento da melhoria de processos.

24

Figura 2: Nveis de Maturidade do CMMI (2002) Fonte: Adaptado de Oliveira (2006)

O CMMI possui algumas limitaes como:a) considerado como um modelo pesado e rgido; b) Indica apenas o que os

processos da organizao devem ter, no indicando o como fazer; c) No define um modelo de ciclo de vida a ser utilizado, nem um mtodo de desenvolvimento de software a ser aplicado; d) baseado na prtica de grandes organizaes, distanciando-se, portanto, da realidade de pequenas empresas.

1.6 Processos de Desenvolvimento de Software Para a criao de software confivel e de qualidade, a engenharia de software criou o conceito de processo de desenvolvimento de software. Entende-se por processo de desenvolvimento de software um conjunto de atividades, mtodos, prticas e tecnologias que as pessoas utilizam para desenvolver e manter software e produtos relacionados. De acordo com Pressman (2006, p. 24) um processo de desenvolvimento de software PDS pode ser conceituado como uma coleo de padres que definem um conjunto de atividades, aes tarefas de trabalho, produtos e/ou

25

comportamento relacionados necessrios ao desenvolvimento de softwares de computador. Uma outra definio bem clara e especfica de processo foi dada por Sommerville (2007, p. 42) que assegura: Um processo um conjunto de atividades e resultados associados que conduzem produo de um produto de software. O processo deve ter detalhes suficientemente claros para que os implementadores, engenheiros ou outros tcnicos envolvidos possam utiliz-lo consistentemente. Assim, definir processos ajuda no planejamento e na realizao da tarefa. (DELOITTE apud YOSHIDA, 2003) Processo de desenvolvimento de software tem um compromisso com a qualidade. Esse enfoque na qualidade se desenvolveu com o passar do tempo, dando surgimento a mtodos e abordagens de Engenharia de Software cada vez mais amadurecidos, gerar produtos de qualidade melhor e a menores custos com o objetivo. (SOUSA NETO, 2004). Diferentes tipos de sistemas necessitam de diferentes processos de desenvolvimento. O uso de um processo inadequado pode reduzir a qualidade ou utilidade do produto de software a ser devolvido ou aumenta o custo de produo. O principal objetivo de desenvolvimento de software garantir a qualidade do produto desenvolvimento. Sommerville (2007) elucida que h uma imensa diversidade de processos de software, e no existe um processo ideal.

1.6.1 Modelos de Processos de Software Os modelos de processo de software ou paradigmas de engenharia de software representam uma tentativa de trazer ordem para uma atividade inerentemente catica. Para Sommerville (2007), um modelo de processo de software uma representao abstrata de um processo de software. Cada modelo de processo representa um processo sob determinada perspectiva, de maneira a fornece somente informaes parciais sobre o processo. Os modelos de processo segundo Sommerville (2007) e Pressman (2006). Os mais conhecidos so: Sequencial Linear ou Cascata; Incremental; Rapid

26

Application Development; Evolucionrios; Prototipagem; Espiral; e Processo Unificado. Os referidos modelos sero detalhados a seguir.

a)

Modelo Sequencial Linear ou Cascata Segundo Pressman (2006), o modelo em cascata foi o primeiro

paradigma de desenvolvimento criado pela Engenharia de Software. Esse modelo sugere uma abordagem linear e sequencial de todas as atividades envolvidas no desenvolvimento de software. Segundo Teles (2004), o modelo sequencial linear conhecido como desenvolvimento em cascata, porque cada fase utiliza o resultado da fase anterior, ele a base para inmeros processos de desenvolvimento que vm sendo utilizado h dcadas na indstria de software. O modelo dividido em fases pr-definidas que so: a) Anlise: onde os requisitos so levantados e busca-se compreend-los detalhadamente para saber como o software deve funcionar; b) Implementao: a equipe se baseia na arquitetura da anlise para implementar o software; c) Teste: verifica se o sistema atende s necessidades do cliente a equipe faz o teste e faz as correes necessrias; d) Implantao: o sistema colocado em produo e o cliente passa a utilizado; e e) Manuteno: at o final da sua vida, o software pode sofrer alteraes, por diversos motivos, tais como novas abrangncias de novas funcionalidades. Teles (2004) afirma que apesar de o desenvolvimento em cascata ser reconhecidamente impotente, ainda o processo mais utilizado para o desenvolvimento de sistemas. Entre os problemas que so algumas vezes encontrados quando o modelo sequencial linear aplicado esto: a) projetos reais raramente seguem o fluxo sequencial que o modelo prope; b) em geral, difcil para o cliente estabelecer todos os requisitos explicitamente, este modelo exige isso e tem dificuldade de acomodar a incerteza natural que existe no comeo de vrios projetos; c) o cliente deve ter pacincia, uma verso utilizvel dos programas no vai ficar disponvel at o projeto terminar. A desvantagem do modelo em cascata leva a estados de bloqueio. Alguns componentes da equipe de projeto precisam esperar que outros membros completem as tarefas dependentes. O modelo em cascata adequado quando os requisitos so bem compreendidos, na reconstruo do sistema existente.

27

FIGURA 3 Modelo Sequencial Linear ou Cascata Fonte: Pressman (2006, p. 89).

b) Modelo Incremental Segundo Pressman (2006), o modelo incremental combina elementos do modelo cascata, aplicando-lhes de maneira interativa. Cada sequncia produz incrementos do software passveis de serem entregues, fornecendo progressivamente mais funcionalidade. O primeiro incremento deste modelo chamado ncleo do produto, pois nele estaro as principais funcionalidades do sistema, aquelas consideradas vitais. Esse modelo muito proveitoso quando a empresa no possui mo de obra disponvel para uma implantao completa dentro de um prazo estipulado. passar do tempo, e tm prazo de entrega curto. O modelo incremental utilizado em projetos longos que tendem a crescer, com

28

Figura 4: Modelo Incremental Fonte: Pressman (2006, p. 40)

c)

Modelo RAD Rapid Application Development

O Rad um modelo incremental que possui um ciclo de desenvolvimento extremamente curto, usualmente com prazo mximo de 90 dias. Rad uma adaptao de alta velocidade do modelo em cascata, no qual o desenvolvimento acelerado com o uso de uma abordagem de construo baseada em componentes. Se os requisitos forem bem compreendidos e o objetivo do projeto for restrito, o processo aceita a equipe de desenvolvimento criar um sistema plenamente funcional. O RAD, assim como outros modelos, possui desvantagens.

29

Figura 5: Modelo Rad. Fonte: Pressman ( 2006, p.41)

d) Modelos Evolucionrios

Estudos apontaram que o software, como todos os sistemas complexos, evolui durante um perodo de tempo e os requisitos do negcio e do produto mudam frequentemente medida que o desenvolvimento prossegue dificultando um caminho direto para um produto final (PRESSMAN, 2006).

30

Figura 6: Desenvolvimento Evolucionrio. Fonte: Sommerville (2006, p. 46)

e) Modelo de Prototipagem O cliente, frequentemente, define um conjunto de objetivos gerais para o software, mas no identifica detalhadamente requisitos de entrada, processamento ou sada. Em outros casos, o desenvolvedor pode estar inseguro da eficincia de um algoritmo, da adaptabilidade de um sistema operacional ou da forma que a interao homem/mquina deve assumir. Nessas e em muitas outras situaes, um paradigma de prototipagem pode oferecer a melhor abordagem (PRESMANN, 2006). O paradigma de prototipagem comea com a comunicao. Nesse modelo, a interao ocorre medida que o prottipo ajustado para agradar s necessidades do cliente, e, ao mesmo tempo, aceita ao desenvolvedor entender melhor o que precisa ser feito. Pressman (2006) enfatiza que o emprego de prottipos pode ser problemtico, pois o cliente v o que parece ser uma verso final do software, mas ignora o fato de que foi construdo na pressa de faz-lo rodar e que ningum considerou a sua qualidade global. Em alguns casos, quando

31

informamos de que o produto deve ser feito para que altos nveis de qualidade possam ser atingidos, o cliente reclama e exige alguns consertos, para transformar o prottipo num produto utilizvel.

Figura 7: Modelo de Prototipagem. Fonte: Pressman (2006, p. 43)

f) Modelo Espiral Originalmente proposto por Boehm, o modelo em espiral um modelo evolucionrio de processo de software que combina a natureza iterativa da prototipagem com os aspectos controlados e sistemticos do modelo em cascata. (PRESSMAN, 2006, p. 44). Ao utilizar o modelo espiral, o software desenvolvido numa srie de verses evolucionrias. O processo de desenvolvimento dividido em um conjunto de atividades definidas pela equipe de engenharia de software, e o risco avaliado medida que cada evoluo feita. Para Sommerville (2007), esta a principal diferena entre o modelo em espiral e os outros modelos do processo de software: o reconhecimento explcito da existncia do fator risco. Nas palavras de Pressman (2006, p.44):

32

O Modelo espiral de desenvolvimento um gerador de modelo de processo guiado por risco usando para guiar a engenharia de sistemas intensivos em software com vrios interessados concorrentes. Ele tem duas principais caractersticas distintas. A primeira uma abordagem cclica, para aumentar incrementalmente o grau de definio e implementao de um sistema enquanto diminui seu grau de risco. A outra um conjunto de marcos de ancoragem, para garantir o comprometimento dos interessados com solues exeqveis e mutuamente satisfatrias para o sistema.

Um ponto admirvel a ressaltar e uma forte caracterstica desse modelo, que o difere de outros modelos e o torna bastante utilizado pelas empresas, o fato dele seguir toda a vida do software, mesmo depois deste ser entregue ao cliente. O modelo espiral uma abordagem realista do desenvolvimento de sistemas e software de grande porte, o software evolui medida que o processo cresce.

Figura 8: Modelo de Espiral. Fonte: Pressman (2006, p. 45)

Bonow (2008) afirma que o Processo Unificado um processo iterativo e incremental, sugere que ciclos de desenvolvimento sejam utilizados para se chegar a solues adequadas e o fato de ser incremental possibilita a incluso, excluso ou

33

alterao de requisitos, mesmo aps o incio do desenvolvimento. O ciclo de vida do Processo Unificado dividido em quatro fases: concepo, elaborao, construo e transio. Cada uma dessas fases dividida em diferentes fluxos de desenvolvimento, e ao final de cada iterao produzido um artefato de software. Mas adiante, no Captulo 04, aprofundaremos o Processo Unificado.

1.7 Sistemas de Informao Sistemas de Informao so conjuntos de procedimentos que visam captar o que acontece na organizao, apresentados de forma sucinta, a cada nvel, o que lhe cabe e tendo por objetivo dar subsdio aos processos decisrios (RODRIGUES, 2008). Objetivo dos sistemas de informao disponibilizar para a organizao as informaes necessrias para que ela atue em um determinado ambiente, possui trs metas fundamentais: a) suporte ao controle e integrao dos processos de negcios e funes organizacionais; b) suporte ao processo decisrio nos diversos nveis organizacionais; e c) suporte a estratgias competitivas, propiciando a obteno de vantagens competitivas. Suas funes incluem a coleta, o processamento, o armazenamento e a distribuio dos dados que, ao serem racionados e contextualizados pelos usurios, proporcionaro as informaes necessrias para a organizao.

1.7.1 Tipos de Sistemas de Sistema de Informao H diferentes formas de classificar os sistemas de informao. Entretanto, as classificaes mais aceitas agrupam os sistemas pela finalidade principal de uso e pelo nvel organizacional.

a)

Sistemas de Processamento de Transao (SPT)

As operaes rotineiras que ocorrem em um ambiente organizacional envolvem transaes de diversos tipos: o fechamento de um pedido com um cliente,

34

a matrcula ou a baixa de uma qualidade do estoque de uma matria-prima. As transaes constituem os eventos bsicos da vida de uma organizao. Os sistemas de processamento dessas transaes (SPT) so os sistemas de informao que executam e registrem as transaes rotineiras que a organizao realiza como parte de seus processos, de negcio. Essas rotinas so realizadas pelo nvel operacional da organizao, razo pela qual esses sistemas tambm so denominados sistemas operativos ou transacionais. b) Sistema de informao Gerencial (SIG)

Segundo Cidral (2005), gerentes do nvel ttico de uma organizao tm como responsabilidade a gesto de um conjunto de operaes que dizem respeito a uma unidade organizacional, como: um setor, departamento, organizao, direo e controle de tais operaes, de forma determinadas. Alm disso, os gerentes esto preocupados com o cumprimento de determinados parmetros de qualidade. Assim, esses gerentes tm a necessidade de acompanhar periodicamente os resultados da rea sobre sua responsabilidade. Esses resultados so medidos atravs de indicadores que sintetizam certos dados das transaes realizadas na organizao em um determinado perodo. Com base nesses indicadores, os gerentes podem tomar decises sobre questes estruturadas e conhecidas antecipadamente. Os sistemas de informao gerencial sintetizam, registram e relatam a situao em que se encontram as operaes da organizao. Esses sistemas atendem, em grande parte, aos gerentes de nvel ttico da organizao na forma de relatrios que apresentam indicadores sobre o desempenho de uma determinada rea.

c)

Sistemas de Apoio Deciso (SAD) Os gerentes do nvel ttico e estratgico de uma organizao por vezes

se deparam com situaes que rapidamente se modificam, podem no se repetir e dificilmente podem ser previstas ou planejadas. Diante dessas situaes, os gerentes precisam tomar decises semiestruturadas. As decises semi-estruturadas envolvem situaes parcialmente

35

compreendidas e nas quais possvel adotar alguns procedimentos conhecidos, embora apresente um nvel superior de subjetividade, quando comparado a uma deciso. SAD so os sistemas de informao que auxiliam os gerentes de uma organizao a tomar decises semi-estruturadas, de processamento de transaes e fontes externas. Alm disso, esses sistemas disponibilizam ferramentas que permitem ao usurio realizar anlise e simulaes como forma de comparar o impacto de diferentes decises.

d)

Sistemas de informao Executiva (SIE)

Os SIE auxiliam os executivos do nvel estratgico da organizao a tomar decises no estruturadas, a partir da disponibilizao de um ambiente computacional e de comunicao que permite fcil acesso aos dados internos e externos da organizao. A partir desses dados, o sistema propicia ao executivo uma viso tanto da situao atual quanto das tendncias na rea de negcio da organizao.

1.8 Fbrica de Software (FS) No momento atual, vrios pesquisadores trabalham com o tema fbrica de software. No Brasil, uma das primeiras obras literrias para tal segmento foi desenvolvida por Fernandes e Teixeira (2004). Ambos os autores definem que uma fbrica de software pode ter vrios domnios de atuao, desde um projeto de software completo, at um projeto fsico ou escopo de um programa de computador. Ainda de acordo estes autores, uma FS :

Um processo estruturado, controlado e melhorado de forma contnua, considerando abordagens de engenharia industrial, orientado para o atendimento a mltiplas demandas de natureza e escopo distintas, visando a gerao de produtos de software, conforme os requerimentos documentados dos usurios e/ou clientes, da forma mais produtiva e econmica possvel. (FERNANDES; TEIXEIRA, 2004, p. 117).

36

Com o objetivo de ampliar a compreenso sobre o que vem a ser o modelo de fbrica de software, identificamos e detalhamos cada uma das palavraschave encontradas nesta definio: a) Processo estruturado: todos os procedimentos realizados numa fbrica de software devem estar coerentes e formalizados em um processo organizado e especfico para atender com a agilidade necessria para a operao da fbrica. b) Processo controlado: o controle sobre os procedimentos e processos executados na fbrica de software de fundamental importncia para garantir a produtividade da fbrica. Este controle deve ser realizado de forma automatizada, deve fazer parte do processo e deve ser evidenciado. c) Processo melhorado continuamente: melhoria contnua outro ponto chave para garantir que o processo evolua e se torne cada vez mais adequado para garantir a produtividade desejada. d) Engenharia industrial: provavelmente, o conceito principal numa abordagem de fbrica de software, que envolve a utilizao de tcnicas e conceitos provenientes da indstria de manufatura e linhas de produo. e) Mltiplas demandas: um dos diferenciais de um projeto de software comum a capacidade que uma fbrica de software deve ter para conduzir de forma paralela demandas com diferentes escopos. f) Demandas de natureza e escopo distintas: este um aspecto de grande importncia de toda fbrica de software. Apesar de estarmos falando em engenharia industrial, uma fbrica de software no pode ser confundida com uma linha de produo de massa, onde todos os produtos so idnticos. Numa fbrica de software as demandas so distintas entre si, o que de certa forma limita o nvel de automao que se espera chegar. Este um dos principais argumentos daqueles que consideram o termo fbrica de software inadequado. g) Produtos de software: principal produto final de toda fbrica de software. Devido a variada gama de estruturar e organizar uma fbrica, encontramos modelos que dentre seus artefatos de sada esto Modelos de Anlise e Projeto. h) Requerimentos documentados dos usurios: o produto de entrada de uma fbrica de software. Algumas fbricas incorporam atividades de levantamento e

37

documentao de requisitos junto ao cliente. Esta apenas uma dentre outras controvrsias existentes em torno da estruturao e estratgia de uma fbrica de software. i) Forma produtiva e econmica: este o objetivo motivador para o surgimento das fbricas de software, ganhos de produtividade e economia para construo de softwares. A definio de fbrica de software neste trabalho permite sugerir que aos processos possvel agregar outros elementos, como atores, produtos, recursos e qualidade, que em conjunto a definem e a estruturam. Neste sentido, uma fbrica de software pode ser vista como um ambiente que contm processos que propiciam o desenvolvimento de software com qualidade, de maneira previsvel e controlada para o uso dos cursos de Cincia da Computao e Sistemas de Informao. Ainda de acordo com Fernandes e Teixeira (2004), para que uma instituio seja qualificada como fbrica de software, ela deve atender aos seguintes requisitos: Processo definido e padro; Interao controlada com o cliente; Solicitaes de servio padronizadas; Estimativas de custos e prazos; Controle rigoroso dos recursos envolvidos em cada demanda da fbrica; Controle e armazenamento em bibliotecas de itens de software; Controle dos status e execuo das demandas; Produtos gerados de acordo com os padres estabelecidos pela organizao; Equipe treinada e capacitada nos processos organizacionais e produtivos; Controle da qualidade do produto; Processos de atendimento ao cliente; Mtricas definidas e controle dos acordos de nvel de servio definidos com o cliente.

38

O escopo de um fbrica de software pode envolver todas as atividades do processo de desenvolvimento ou estar restrito a um determinado grupo de atividade. Existem fbrica que desenvolvem todo o projeto, somente o projeto fsico, que inclui codificao e teste ou ser exclusivamente voltada para o teste de programas. A figura abaixo representa os quatros tipos de fbricas classificadas de acordo com seu escopo de atuao ao longo das fases de desenvolvimento de um projeto de software, apresentado por Fernandes e Teixeira (2004).

Figura 9: Escopo de Fbrica de Software Fonte: Fernandes (2004)

De acordo com a classificao proposta por Fernandes e Teixeira (2004), a fbrica de programas consiste na menor unidade de fbrica, e tem como objetivo principal a codificao e o teste de programas conforme um acordo de nveis de servios com o cliente e o usurio, considerando uma especificao padro critrios de qualidade e tempo de entrega. O objetivo da fbrica de projetos de software o de desenvolver e manter software conforme um acordo de nveis de servios com cliente ou usurio, considerando requisitos de prazo, custo, qualidade e escopo. Uma fbrica deste tipo pode atender trs grandes tipos de demanda: novo desenvolvimento, manuteno de sistemas ou projetos fsicos. No caso das fbricas de projetos, h necessidades do conhecimento do negcio do cliente. A fbrica de projetos ampliada engloba arquitetura de solues, ou seja, um estgio anterior conceituao do software e que se preocupa em projetar

39

uma soluo em que o software somente um dos componentes. Os outros componentes podem ser as implantaes de processos, hardware, servios e equipamentos de rede e de telecomunicaes, etc. Mesmo no estando includo na figura 9, o modelo de outsourcing de sistemas consiste na absoro total ou parcial dos sistemas aplicativos de uma empresa, para o desenvolvimento de novos sistemas e manuteno dos existentes. Na realidade, o outsourcing uma fbrica de projetos dedicada a um nico cliente. Merece destaque ainda o modelo de fbrica de componentes que o modelo onde mais intensamente se procura aplicar a idia de fbrica. Nele se pretende produzir software de qualidade garantindo a produtividade atravs de uma intensa reutilizao de componentes. fundamental que o processo de desenvolvimento passe pela verificao da existncia de um componente, antes de cri-lo. Se a fbrica perder tempo criando novamente algum componente, ou mesmo iniciar a produo deste, ela perde tempo e gera custo, uma vez que o planejamento gerou uma estimativa de custo mais alta do que seria realmente necessrio. A obsesso passa a ser utilizar cada componente o maior nmero de vezes possvel. Para muitos desenvolvedores, este seria o modelo de fbrica de software ideal. Contudo, ele proporcionalmente desafiador em sua implementao, tanto que so poucas as histrias de implementao bem sucedida deste modelo no mundo. Este captulo apresentou os principais processos de desenvolvimento de sistemas, abordamos os principais conceitos fundamentais associados engenharia de sistemas de software e os aspectos especficos de uma fbrica de software. Essas definies so importantes para dar uma direo no prximo captulo, onde ser apresentada a origem e a evoluo dos processos de desenvolvimento de software.

40

CAPTULO 2 ORIGEM E EVOLUO DOS PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE

Durante os ltimos anos, vrios pesquisadores da rea de Tecnologia e Informao e Comunicao (TIC) desenvolveram diversos estudos de casos, prottipos e avaliaes sobre Fbrica de Software (FS). Algumas tinham o foco na adoo de processos; outras priorizavam adoo de ferramentas de automao. Assim, o termo Fbrica de Software que passou um tempo esquecido, volta a ganhar espao em corporaes de bens e servios de informtica, empresas de mdio e pequeno porte. Este captulo faz uma reviso bibliogrfica, destacando os mais relevantes trabalhos j publicados sobre (FS). Apesar dessa nova retomada, o nmero de textos sobre o assunto ainda muito reduzido. Nomura (2008) cita alguns desses fatores e entre outros que esto causando esta retomada:

a) Prticas na rea de engenharia de software grande parte dos governos do

mundo j entendeu a importncia das atividades de pesquisa na rea de tecnologia da informao atravs de parcerias com empresas do mercado. O grande nmero e a qualidade das pesquisas realizadas na rea de engenharia de software nos ltimos anos tm resultados significativos, os resultados obtidos so colocados em prticas no mercado.b) Evoluo das ferramentas case as ferramentas case tm acompanhado toda

evoluo que ocorre na rea de engenharia de software.c) Facilidade de compartilhamento de conhecimento na Internet todo tipo de

conhecimento ambiente divulgado para um grande nmero de interessados em

41

quaisquer pesquisas realizadas atualmente, o primeiro procedimento a consulta atravs da internet.d) Alta competitividade no mercado alta competitividade no mercado atual exigiu

que sistemas fossem produzidos com custos cada vez mais reduzidos e com alta qualidade. A reduo de custos um diferencial na concorrncia.e) Baixo custo do hardware Nos anos 60, o hardware possua um custo muito alto

e o software, representava um custo menor. Isto se dava devido o hardware ser considerado mais importante que o software, uma vez que este era desenhado especificamente para executar determinadas tarefas, sendo a funo do software apenas unir as operaes do computador. Desde ento, os componentes de hardware tiveram, cada vez mais seus custos e assumiram funes mais genricas, transferindo sua importncia para o software. Novas tcnicas e mtodos eram necessrios para controlar a complexidade dos grandes sistemas de software. O paradigma de Fbrica de Software busca a obteno de qualidade e produtividade no desenvolvimento e manuteno de software por meio da padronizao de processos, reuso de artefatos e controle dos sistemas de produo. Um framework de Fbrica de Software pode ser abordado em diferentes ticas com foco em: segmentao das atividades, desenvolvimento baseado em componentes, linhas de produo de software e terceirizao. Nomura apud Aaem et al (1997) define Fbrica de Software como uma organizao que prov servios de desenvolvimento de software com alta qualidade, a baixo custo, de forma rpida, utilizando um processo bem definido, flexvel e utilizvel, tecnologia de ponta adequada ao padro de desenvolvimento, reutilizao de cdigo, alm de algumas formas de feedback sobre o andamento da atividade. O autor cita em seu trabalho uma compilao de estudos sobre fbrica de software encontrado na literatura. Vejamos: Em (1968) Bremer (apud Castor 2005) relata que a General Eletric criou uma fbrica de software para aumentar a produtividade no desenvolvimento de sistemas, por meio da utilizao de ferramentas padronizadas e bancos de dados com histricos para controle financeiro e gerenciamento das atividades da fbrica.

42

Em 1969 M.D Mcllroy (apud CASTOR 2005), da AT&T props novos conceitos para o desenvolvimento produtivo de software, baseados na reutilizao sistemtica de cdigo. Em 1971 Bauer (apud Castor 2005) props que o projeto e produo de software deve ser visto como uma rea da Engenharia Industrial, listando problemas de projetos de software em larga escala como: a diviso das tarefas em partes gerenciveis, a diviso do desenvolvimento em estgios distintos, acompanhamento e gerenciamento automatizado do projeto Matsumoto (2002) apresenta fbrica de software da Toshiba do Japo nos anos 1970 e 1980, reutilizando mdulos e fragmentos de cdigos existentes em diferentes aplicaes, introduzindo uso de ferramentas padro e provendo o treinamento extensivo dos profissionais. Cusumano (1991) relata nos seus estudos de Fbricas de Software (no Japo, Hitachi, Nec, Toshiba e Fugitsu e EUA da Amrica nos anos a incluso de alto grau de reutilizao de cdigo, o aumento da qualidade e da flexibilidade. Swanson (1991) props um estudo de caso da aplicao do paradigma de FS na Celite nos EUA da Amrica, concentrando esforos na introduo de qualidade nos processos de desenvolvimento e de programao. Basili et al (1992) demonstra um modelo de fbrica de projetos baseado em fbricas de experincia, representando a arquitetura da fbrica em nveis de abstrao, como fbrica de domnios e fbrica de componentes. Costa (2003), baseado em uma estrutura de fbrica de software padro, apresenta um trabalho que prope uma padronizao para a definio do servio, o uso de mtricas adequadas ao ambiente de fabricao de software, contribuindo na contratao e definio dos prazos e de custos do servio a ser prestado. Para Greenfield Short (2003) o conceito de FS fundamentado no desenvolvimento baseado em componentes, direcionado a modelos e a linhas de produto de software que caracterizam uma iniciativa de fbrica, visando a tornar a montagem de aplicaes com menor custo em conseqncia de sua demanda, possibilitando a formao de cadeias de produo.

43

Vivacqua (2009) props uma anlise sobre como as principais Instituies de Ensino nas reas de Cincia da Computao, Informtica e Engenharia de Sistemas formam profissionais adequadamente capacitados s necessidades inerentes das organizaes do tipo Fbrica de Software . Para cumprir seu objetivo especfico, o autor fez entrevistas com os professores e aplicou um questionario com os alunos em vias de concluso de curso. As entrevistas com os professores revelam que o termo Fbrica de

Software conhecido, porm o entendimento que estes tm sobre o fenmeno, embora possa ser complementar, so parciais e construdos a partir da rea de interresse ou de atuao do professor . Da mesma forma, a aplicao dos questionrios aos alunos revelou que boa parte tem um conceito formado sobre Fbrica de Software. Alguns deles, inclusive, j trabalham em organizaes dessa natureza. Com base nessas duas informaes, observa-se que os professores e alunos que participaram do levantamento compartilham uma mesma concepo sobre o conceito de FS, no que tange ao seu escopo de atuao e os processos empregados, embora possa existir um conflito entre as concepes de ambos os grupos sobre a organizao do trabalho. O autor ainda relata que as universidades no devem se transformar em centros de formao para empresas fornecedoras de tecnologias,o que limitaria a formao do aluno.As ferramentas de uso profissional devem ser obtidas atravs do estgio, de cursos extracuriculares, cadeiras optativas e cursos de especializao. Em funo dessas informaes levantadas, no possvel afirmar se as Instituies de Ensino nas reas de Cincia da Computao, Informtica e Engenharia de Sistemas formam profissionais adequadamente capacitados, pois o nmero de respostas positivas e negativas foi muito prximo. Marques et al (2003) props a experincia de criao de uma FS no ambiente acadmica. A Fbrica UM foi criada com objetivo de oferecer servios de qualidade a um baixo custo, focando na produtividade. Os princpios bsicos que guiaram tal organizao foram: simplicidade, produtividade, foco no processo de desenvolvimento de software e, uso de tcnicas estabelecidas como padro no

44

mercado. O primeiro passo baseado nestes princpios foi desenvolver um processo padronizado de desenvolvimento. O ProcessOne, como foi denominado o processo criado pela Fbrica Um, foi definido de maneira que pudesse ser instanciado de acordo com as necessidades especficas de cada projeto. Devido necessidade de ser produtivo, tendo os custos e prazos definidos no incio do projeto, o processo foi baseado na metodologia do RUP, escolhida por reunir as melhores prticas de desenvolvimento de software. Diversas lies de sucesso e insucesso puderam ser extradas a partir da experincia e da prtica dos membros da fbrica. Durante todo o desenvolvimento do processo adotado, foram apresentadas sugestes e crticas pelos integrantes da equipe nas reunies de projeto. Rocha et al (2004) prope um mapeamento dos processos de software (leves ou pesados) para fbrica de software, levando em considerao os escopos definidos por Fernando(2004,apresentado no captulo anterior A tabela a seguir ilustra o mapeamento proposto, descrito logo em seguida.

Tabela 1: Mapeamento de Processos para Fbricas de Software

Fonte: Rocha et al (2004, p. 137)

Para a fbrica de cdigo, que requer maior agilidade e pouco formalismo na documentao do produto final, os mtodos geis poderiam ser bem utilizados,

45

desde que respeitando os requisitos mnimos de documentao e gerncia exigidos para uma fbrica de software institucionalizada. A fbrica de componente tambm pode se adaptar ao pouco formalismo dos mtodos geis, optando por documentar os componentes apenas atravs de ferramentas como JavaDoc. Da mesma forma que na fbrica de cdigo, o dinamismo dos mtodos geis tambm pode ser o diferencial da fbrica. Porm, algum formalismo ou processo auxiliar deve ser definido para a catalogao. Na fbrica de projeto, que se assemelha maioria das fbricas que desenvolvem aplicaes personalizadas, a necessidade dos mtodos tradicionais aparece em maior destaque, uma vez que se faz necessrio documentar e validar formalmente com o cliente as decises de requisitos dos projetos. Por fim, o outsourcing de sistemas, que requer alm de maior formalismo, maior controle por parte do cliente dos ndices gerados pela fbrica, claramente orientado a processos tradicionais. Conforme a tabela anterior possvel verificar que os processos leves possuem iteraes curtas direcionado a pequenas equipes, orientados s pessoas e dinmicos, totalmente aplicveis a uma fbrica de cdigo e a uma fbrica de componentes. J os processos pesados trabalham com garantia de qualidade (presente na questo do planejamento) e so direcionados a grandes equipes, esto centrados em atividades bem definidas e orientados ao planejamento. Uma fbrica de projetos de software deve ser alicerada por um processo pesado, pois deve possuir um conjunto de atividades bem definidas. Diante da proposta de Rocha et al (2004) conclui-se que, para um

perfeito funcionamento das atividades de uma FS, fundamental a adoo de um processo de desenvolvimento de software que defina as tarefas, os produtos e os responsveis pelas etapas do ciclo de vida do software. Fernando e Teixeira (2004) apresentam um modelo em cinco camadas de processos genricos para FS que facilita o ajuste de modelos diferentes de gesto com processos de desenvolvimento, conforme uma aproximao engenharia de produo. So elas:

46

a) Gesto Estratgia do Processo de Software: aborda a melhoria contnua e seus alinhamentos com as normas no negcio tm em vista a entrega dos produtos de forma mais rpida e com maior qualidade possvel; b) Processo de Gesto da Operao: Visa gesto das mltiplas demandas que uma Fbrica de Software geralmente atende, estabelecendo as prioridades, alocando recursos, controlando o fluxo das diversas demandas, negociando nveis de servio da operao, administrando os ativos de software, garantindo a qualidade etc. c) Processo de Gesto de Projeto: Est relacionado com o planejamento e o controle de uma demanda especfica. Os diversos aspectos do controle envolvem o controle de mudanas, de escopo, das verses dos itens de software (denominado de controle de configurao no modelo CMMI), dos riscos, da qualidade, da comunicao e do desempenho do projeto. d) Processo de Construo do Produto de Software: Modelo de ciclo de vida do desenvolvimento. e) Processo de Suporte: agrupa as funes de apoio ao processo produtivo da fbrica, incluindo o suporte tecnolgico, metodolgico, de engenharia de processos, de help-desk, logstica de suprimento de recursos, etc. (FERNANDO; TEIXEIRA p. 75) Jorge (2006) props uma nova abordagem na estruturao das fbricas de software, denominada Modelo Hbrido. Essa nova proposta visa adequar o modelo convencional mecanicista das fbricas industriais, que so baseadas em projetos. Alguns conceitos como os de linha de produo, controle de processos, garantias da qualidade, especializao do trabalho, podem ser parcialmente aplicados com sucesso. Porm a produo de software guarda diferenas significativas em relao manufatura tradicional. Todo sistema nico, o apenas partes individuais podem aparecer repetidamente em mais de um projeto. A fbrica tem suas atividades baseadas em processos que so agrupados nas seguintes categorias: Processos Produtivos, Processos de Gesto, Processos de Suporte e Processos de Transferncia e Comunicao. Os Processos Produtivos esto relacionados s

47

etapas de desenvolvimento dos sistemas e atravs deles ocorre produo propriamente dita do software. Os Processos de Gesto destinam-se a gerenciar as atividades das unidades de produo e de suas respectivas clulas produtivas. Os Processos de Suporte garantem a infraestrutura de servios auxiliares necessria ao funcionamento da fbrica de software. Por fim, os Processos de Transferncia e Comunicao so os responsveis pela correta transferncia de informaes entre as clulas de uma mesma unidade e entre unidades produtivas distintas. Tais processos promovem uma comunicao consistente, garantindo que cada engenheiro de software tenha as informaes no nvel de detalhamento necessrio para a execuo do seu trabalho. A primeira atividade da equipe foi a elaborao do plano de projeto. Este documento contm as informaes necessrias para direcionar o desenvolvimento do sistema, com definio de requisitos, projeto arquitetural, tecnologia envolvidas, planejamento das interaes etc. O modelo citado acima guarda algumas vantagens em sua utilizao, j que pode aproveitar os elementos positivos das estruturas convencionais em fbrica de software. Uma grande vantagem do modelo a significativa reduo do esforo de troca de informaes entre os engenheiros de software. Outra vantagem do modelo a maximizao do aproveitamento da fora de trabalho especialista da organizao. O Modelo Hbrido est sendo parcialmente aplicado em uma fbrica de software em dois projetos de desenvolvimento de software. O primeiro deles trata-se de um sistema de cotao de servios via Web, o segundo refere-se a um sistema de rastreabilidade de componentes de computadores, para serem utilizados em uma montadora de microcomputadores. O modelo proposto est sendo utilizado em uma FS e os resultados at o momento so considerados satisfatrios. Acredita-se que os ganhos conseguidos com o modelo podem ser efetivamente superiores com o amadurecimento. As dificuldades encontradas na sua implantao mostram-se superveis e inerentes a quaisquer alteraes significativas na rotina de trabalho de uma organizao.

48

Brito et al (2004) abordou uma proposta de um experimento acadmico baseado no conceito de fbrica de software distribuda, utilizando um processo de desenvolvimento adaptado do modelo Open Source Software. O processo foi baseado no RUP e possui as gerncias de qualidade, configurao e projetos, sendo desempenhadas exclusivamente por membros da fbrica. Conforme o autor, Open Source Software um termo usado para indicar que o software desenvolvido e distribudo sob algum tipo de licena que garante ao seu usurio liberdade relacionado ao uso, alterao e redistribuio. Seu aspecto fundamental o fato do cdigo fonte estar livremente disponvel para ser lido, estudado ou modificado por qualquer pessoa interessada (BRITO et al, 2004) Ainda de acordo com os autores, um projeto de software livre uma organizao composta por um conjunto de pessoas que usa e desenvolve um nico software livre, contribuindo para a base comum de cdigo-fonte e conhecimento. Este grupo ter sua disposio ferramentas de comunicao e trabalho colaborativo, e um conjunto de experincia e opinies tcnicas que usam para discutir o andamento do projeto. Guidini et al (2009) props a definio de uma fbrica de software, tendo processos como a base da estrutura organizacional. A partir dos processos so agregados outros elementos que definem a fbrica de software, como as pessoas, os produtos, os recursos e a qualidade. Borsoi apud Basili et al (1992), props um framework organizacional, orientado ao reuso definindo duas estruturas: uma organizao orientada ao projeto e outra denominada fbrica de experincia. A fbrica de projeto atua com um pouco mais de abrangncia no processo de produo, englobando fases como: projeto conceitual, especificao lgica, projeto detalhado de soluo, realizao de testes de integrao e de aceitao. Dependendo da interface com o cliente, a fbrica pode se caracterizar por projeto de software ou projeto fsico, no entanto seus requisitos e caractersticas bsicas so muito semelhantes. O objetivo da fbrica de projeto desenvolver, e manter softwares de acordo com nveis de servios previamente definidos com o cliente ou usurio, considerando requisitos de prazo, custos e qualidade de escopo.

49

A fbrica de experincia uma abordagem criada para monitorar e analisar os projetos desenvolvidos, desenvolver e empacotar as experincias de reuso de diferentes tipos de experincias que a organizao possui, como conhecimentos, processos, ferramentas e produtos visando sempre utilizao desses componentes de software para aumentar a qualidade e a produtividade. Aaen et al define os lugares (1997) indica quatro estratgias de fbrica de software e do mundo onde prevalecem.Estas abordagens foram

apresentadas a partir de um estudo de quatro vises de fbrica de software bem conhecidas, para uma padronizao de operaes de desenvolvimento de software:

a) Fbrica Industrializada Abordagem japonesa baseada no conceito da fbrica de Toshiba, cuja abordagem visa a melhorar a qualidade do produto de software e aumentar a produtividade, alm de criar um ambiente em que o projeto, a programao, o teste, a instalao e a manuteno podem ser executadas de uma maneira unificada. A estratgia desta abordagem tem elementos, como projetar estruturas de suporte para as atividades deste processo, e outras iniciativas adicionais. Alm disso, a organizao desta fbrica de software determinada por ferramentas de suporte, gerncia de projeto, reusabilidade, medio de qualidade e produto.

b) Fbrica Genrica Abordagem europia financiada pelo programa Eureka, a qual tem como finalidade a criao de partes de uma arquiterura e um framework para sistema integrados de desenvolvimento de produtos de software, componentes gerais e aplicaes para reas de negcio. A estratgia desta abordagem desenvolver componentes e ambientes de produo que so partes da fbrica de software juntamente com diretrizes e padres para componentes de produtos de software. Na organizao dessa fbrica,as pessoas que so colocadas nesse contexto de trabalho fazem parte do modelo de produo de produtos de software, onde necesrio dar suporte ao

50

trabalhador individual, aumentando a previsibilidade do processo, e criar uma melhor interao entre as tarefas humanas e as computadorizadas.

c) Fbrica de Componentes baseada em Experincia Abordagem a reduo de trabalho. A estratgia dessa abordagem consiste em trs elementos-chave: melhoria no paradigma, organizao experiente e dedicada; plano de contingncia. E sua organizao , em primeiro lugar, comprometida com o aprendizado e a transferncia de tecnologia, focando no entendimento de solues e agrupando experincia para o reuso. norte-americana que foi desenvolvida no Software

Engineetring Institute (SEI) que tem o objetivo de melhorar a eficcia de processos e

d) Amadurecimento Organizacional Esta abordagem a definio de fbrica de software de acordo com o modelo Capability Madurity Model (CMM). Seu objetivo inicial foi a construo de um framework para melhoria de processos de software, visando aumentar a previsibilidade, confiabilidade e auto melhoramento do processo de software com alta qualidade. A estratgia dessa abordagem o melhoramento passo a passo da organizao da empresa baseada na adoo de processos. Tal abordagem defende que a organizao ideal aquela que tem um desenvolvimento disciplinado de planejamento e de acompanhamento dos projetos de software, onde casos de sucesso so reaproveitados. As propostas de FS de software encontradas na literatura esto racionadas tambm s linhas de produo de software. Diversos autores com Demir (2006), Greenfield e Short (2003), Frankel (2005) uma linha de produtos se refere um conjunto de sistemas que usa software intensivamente, compartilhando um conjunto de caractersticas comuns e que satisfaz necessidades de mercados especficos.

51

Este captulo apresentou uma reviso bibliogrfica dos principais trabalhos envolvendo fbrica de software. No captulo seguinte sero apresentados os fundamentos do processo unificado.

CAPTULO 3 OS FUNDAMENTOS DO PROCESSO UNIFICADO

3.1 Introduo Um processo de desenvolvimento de software a definio de um conjunto de atividades, mtodos, prticas e tecnologias que as pessoas utilizam para desenvolver e manter software e produtos relacionados. A presena de um processo bem determinado e bem especificado um aspecto determinante de diferenciao entre projetos bem-sucedidos e projetos mal-sucedidos. O processo unificado captura algumas das melhores prticas atuais de desenvolvimento de software, de forma que possa ser adaptada a uma ampla variedade de projetos e empresas. Porm, o processo unificado no pode ser considerado como apenas uma unio das melhores e principais caractersticas das metodologias mais populares, ele tambm possui caractersticas especficas, como ser orientado por casos de uso, ser centrado na arquitetura e ser iterativo e incremental. Este captulo abordar os fundamentos do processo unificado (PU), definindo suas caractersticas, seus ciclos de desenvolvimento, e as fases que o compem.

3.2 Histricos do Processo Unificado (PU)

52

O processo unificado teve suas razes no trabalho realizado no final da dcada de 60 por Ivar Jacobson, na Ericsson. Pouco depois de 1995 a Rational comprou a empresa de Jacobson, A partir da temos a definio de Os trs amigos, a maneira como os autores ficaram reconhecidos no mercado. O processo unificado (antigamente conhecido como Rational Unified Process RUP) e a Linguagem de modelagem unificada (UML) avanaram e continuam avanando. Hoje a UML um padro da OMG (Object Management Group). O processo est fundamentado em trs princpios bsicos: a) Dirigido por Casos de Uso: Um caso de uso uma sequncia de aes, executadas por um ou mais atores1 (pessoas ou entidades no humanas fora do sistema) e pelo prprio sistema, que produz um ou mais resultados de valor para um ou mais atores. A expresso dirigida por casos de uso refere-se utiliz-los para dirigir todo o trabalho de desenvolvimento, desde captao inicial e negociao de requisitos2 at a aceitao do cdigo. Os casos de uso so bastante apropriados para captar requisitos e dirigir anlise, projeto e implementao. Os casos de uso iniciam o processo de desenvolvimento e o mantm coeso. Eles so desenvolvidos juntamente com a arquitetura do sistema, ou seja, a direcionam que por sua vez influencia a seleo dos casos de uso (SCOTT, 2002).

b) Centrado na arquitetura: a arquitetura fornece uma base slida para a construo do software e representa uma viso do projeto como um todo, na qual as caractersticas mais importantes so colocadas em destaque, deixando os detalhes de lado. O PU descreve como projetar uma arquitetura que seja flexvel e que acomode mudanas, alm de promover o reuso mais eficaz de software. Todo produto tem funo e forma, nenhum desses elementos sozinho suficiente e precisam ser balanceados para obter um produto de qualidade. Os casos de uso devem se encaixar na arquitetura, e esta ser disponvel para a construo de todas as funcionalidades descritas nos casos de uso. Ambos so refinados no decorrer do ciclo de vida do sistema. Concluindo, os casos de uso representam a funcionalidade1

Atores: algo que interage com o software a ser desenvolvido, pode ser um usurio, subsistema ou perifrico 2 Requisitos : Especifica o que o sistema deve fazer.

53

e a arquitetura representa a forma (SCOTT, 2002, p. 76).

c) Iterativo e Incremental: A ideia mais importante do PU, o desenvolvimento organizado em uma srie de miniprojetos de durao fixa chamada iteraes 3, o produto de cada iterao um sistema testado, integrado e executvel. Sendo assim o sistema cresce incrementalmente ao longo do tempo, iterao por iterao. A abordagem iterativa permite que as mudanas nos requerimentos e nas caractersticas do software se tornem mais fceis. O benefcio mais importante que este estilo de desenvolvimento traz a possibilidade de, logo concentrar os esforos nos riscos mais crticos do projeto. A equipe deve organizar interaes, baseando-as em anlise de riscos, de forma continua, o objetivo final de minimiz-los no maior grau possvel, a cada iterao (SCOTT, 2002).

3.2.1 Fases e Disciplina do Processo Unificado O PU organiza o desenvolvimento do software em quatro fases: Concepo, Elaborao, Construo, e Transio. Cada fase tem um conjunto de objetivos. Vejamos: a) Concepo: o foco entender o escopo do sistema, definindo os requisitos que o sistema deve ter. Aqui tambm so identificados os maiores riscos do projeto, utilizados no planejamento da prxima fase. b) Elaborao: o objetivo reduzir o risco do projeto atravs da criao de uma arquitetura slida a ser utilizada em todo o desenvolvimento do projeto. c) Construo: o objetivo construir o software com base na arquitetura estabelecida. O sistema construdo por incremento, adicionando-se conjuntos de casos de uso. d) Transio: objetivo entregar o sistema completo funcionando. Esta fase concentra em corrigir defeitos e modificar o sistema para corrigir problemas no identificados.

3

Iteraes: um miniprojeto que resulta em uma verso do sistema liberada interna ou externamente;

54

3.3 Diferenas entre PU e RUP Segundo Kruchten (2003), o RUP segue as melhores prticas de desenvolvimento de software: desenvolvimento iterativo, gerenciamento de requisitos, arquitetura baseada em componentes, modelagem visual do software, verificao constante da qualidade e controle de mudanas. De acordo com estudos, as diferenas entre o PU e o RUP esto em sua estrutura de fluxos de trabalho, sendo que o RUP possui alguns fluxos adicionais, e no fato de que o PU descrito em um livro, enquanto o RUP vendido como uma base de conhecimento em hipermdia com milhares de arquivos, o que evidencia seu maior nvel de detalhamento. O RUP descreve como fazer um desenvolvimento efetivo de software fazendo-se valer das chamadas boas praticas de desenvolvimento. As causas dos fracassos da maioria dos projetos de desenvolvimento de software so similares e requerem boas prticas para que sejam evitadas, As mais comuns so: gerenciamento informal dos requisitos, no entendimento das necessidades dos usurios, incapacidade de lidar com as mudanas de requisitos, complexidade crescente e excessiva, qualidade ruim, testes insuficientes e baixo desempenho. RUP um produto da IBM acompanha software e tem disciplinas a mais tem prticas.

3.3.1 Prticas O RUP busca resolver todos estes problemas, entre outros. Para isto, ele prov as seguintes prticas: Algumas so implcitas no PU:

a) Gerenciamento de Requisitos um processo utilizado para compreender e controlar as mudanas dos requisitos de sistema. necessrio manter o acompanhamento dos requisitos individuais e manter as ligaes entre os requisitos dependentes, de modo que seja

55

possvel

avaliar

o

impacto

das

suas

alteraes.

(KRUCHTEN,

2003;

SOMMERVILLE, 2007). Os benefcios dos requisitos incluem: i) Melhoria no controle de projetos complexos; ii) Qualidade aperfeioamento de software; e iii) Custos de projetos reduzidos e demoras.

b) Arquitetura Baseada em Componente A arquitetura baseada em componente foca o desenvolvimento na modularizao, atravs do uso destas, de modo a criar um sistema flexvel, adaptvel, intuitivamente, entendvel e reutilizvel. O RUP entende componentes como mdulos no triviais e/ou

subsistemas com uma funo clara e especfica. Usa a arquitetura baseada em componentes oferece diferentes recursos para as causas de origem de problemas no desenvolvimento de software. (KRUCHTEN, 2003).

c) Modelagem de Software Visual A modelagem importante porque ajuda a equipe visualizar, especificar, construir e documentar a estrutura e a caracterstica da arquitetura do sistema. Utilizando uma modelagem padro como UML (Unified Modeling Language), membros da equipe de desenvolvimento podem, sem ambiguidade, comunicar suas decises uns para os outros. A modelagem visual facilita a visualizao de informaes do sistema sem a necessidade de se analisar o cdigo-fonte da aplicao.

d) Verificao Contnua da Qualidade do Software Verificar continuamente a qualidade consiste em criar testes para cada cenrio, chave de um projeto com base nos padres sem esquecer a confiabilidade, funcionalidade e do desempenho da aplicao. Quanto mais cedo um erro for

56

localizado, menor o custo para a soluo. A verificao da qualidade do sistema proporciona a certeza de que existe consistncia entre requisitos, projetos e implementao.

e) Controle de Mudanas no Software O processo de controle de mudanas tem o objetivo de controlar as verses dos artefatos criados e modificados durante o projeto. O desafio ainda maior quando a equipe grande, dispersa em muitos locais, utiliza vrias plataformas, ou h muitos sistemas e componentes.

3.3.2 Estruturas do Processo A estrutura do RUP organizada em duas dimenses. O eixo vertical a parte esttica do processo, apresentando as principais disciplinas que compem o processo; o eixo horizontal representa o tempo, o aspecto dinmico do processo, e apresenta o aspecto do ciclo de vida do processo em termos de ciclos, fases, iteraes e marcos.

Figura 10: Ciclo de vida do Processo Unificado Fonte: Kruchtem (2003)

57

O eixo vertical os processos determinam quem est executando o qu e quando. O quem est associado aos papis que as pessoas vo executar no projeto, sendo que cada pessoa pode executar mais de um papel. O papel define as responsabilidades e as tarefas que sero efetuadas como, por exemplo, analista de sistemas, designer, projetista de testes, dentre outros, sendo que cada papel requer certo conjunto de conhecimentos. O o qu est associado s atividades desempenhadas e aos artefatos trabalhados pelas pessoas executando determinados papis. Cada atividade representa um pacote de trabalho ou tarefa resumo e produz um resultado relevante para o projeto, geralmente associado criao ou atualizao de um artefato. O quando est associado ao sequenciamento das atividades, que devem ser agrupadas e sequenciadas de modo a produzir resultados de valor para o projeto. Os processos devem ser adaptados s vrias fases do projeto, em funo dos objetivos das fases. No eixo horizontal a abordagem iterativa concebida para acomodar mudanas de objetivos e estratgias, pertinentes aos projetos de desenvolvimento de software. Algumas das causas: usurio muda de ideia, o problema muda; mudanas tcnicas e mudanas de mercado.

3.4 Ciclos de Vida O desenvolvimento de software consiste da repetio de uma srie de ciclo. No PU o ciclo de vida dividido por fases, a saber:

a) Concepo: Nesta fase, o principal objetivo estabelecer a viabilidade do sistema proposto, as principais tarefas executveis nesta fase incluem: a) definir o escopo4 do sistema (isto , o que est dentro e o que est fora); b) identificar os riscos crticos e determinar quando e como o projeto os abordar; c) iniciar a anlise econmica do projeto, mostrando se o projeto vale a pena, com base em estimativas iniciais de custos, cronograma, esforo e qualidade do produto.4

Escopo: Documento elaborado para descrever o foco do projeto, incluindo somente o trabalho exigido para atender necessidade com sucesso. (KRUCHTEM, 2003)

58

b) Elaborao: o principal objetivo estabelecer a capacidade para a construo de um sistema, dadas as restries financeiras e de cronogramas. As tarefas executadas durante a elaborao so as seguintes: a) detalhamento do produto e da arquitetura a ser utilizada; b) captura a maioria dos requisitos funcionais vlidos restantes; c) estabelecer uma arquitetura de fundao slida e eliminar os elementos de projeto que oferecem maior risco. c) Construo: durante esta fase, um produto completo desenvolvido de maneira iterativa e incremental, para que esteja pronta para distribuio comunidade usuria. Ou seja, o foco construir o software (preencher o esqueleto com todos os msculos e implementar o sistema por completo).

d) Transio: O principal objetivo entregar o sistema funcionando para o cliente. Nesta fase ocorre instalao, configurao, treinamento, suporte tcnico dentre outros.

3.5 Disciplinas No RUP, o processo discorrido nas fases e, em cada fase, como visto anteriormente, passam nove disciplinas de forma iterativa e incremental. No obrigatoriamente h atividades a serem executadas em uma determinada disciplina numa fase. As iteraes so utilizadas para centralizar os objetivos das atividades de cada disciplina do processo. As seis primeiras disciplinas so ligadas ao processo, enquanto as trs ltimas so ligadas ao suporte. So definidos da seguinte forma:

I. Modelagem de Negcios Tem o objetivo de entender a estrutura e a dinmica da organizao na qual o sistema ser entregue; identificar problemas correntes na organizao e possveis aperfeioamentos; assegurar que o cliente o usurio final e desenvolvedor

59

possuam a mesma compreenso da empresa, e produzir os requisitos de sistemas necessrios para suportar os objetivos da organizao.

II. Requisitos Estabelecer e manter o consentimento entre clientes e stakeholders sobre o que o sistema deve fazer; fornecer uma melhor compreenso dos requisitos aos desenvolvedores de sistemas; definir os limites do sistema; fornecer as bases para o planejamento das iteraes, estimativa de custo e tempo de desenvolvimento e definir as interfaces do sistema baseado nas necessidades e objetivos dos usurios.

III. Anlise e Design Transformar os requisitos dentro de um design do que ser o sistema; desenvolver uma arquitetura robusta para o sistema e adaptar o design para combinar com o ambiente de implementao, projetar para performance.

IV. Implementao Na disciplina de Implementao feita a codificao de novos componentes, com base em um modelo de cdigo fonte pr-estabelecido pela organizao, construdo em camadas, e/ou a integrao de componentes j existentes.

V. Teste A disciplina de Teste tem por objetivo prezar pela qualidade do sistema e detectar possveis problemas e/ou defeitos para que no haja custos futuros para a organizao que est desenvolvendo. Essa disciplina tem uma diferena fundamental em relao s outras: ela procura e expe as fraquezas do software.

VI. Implantao

60

Descrever as atividades associadas verificao do software, o objetivo tornar o software disponvel ao usurio final.

VII. Gerncia de Configurao e Mudana Identificar itens de configurao; restringir alteraes para aqueles itens; auditar as alteraes feitas neles e definir e gerenciar as alteraes daqueles itens.

VIII. Gerenciamento de Projeto Fornecer uma estrutura para gerenciamento de projeto de software; fornecer um guia prtico para planejamento, recrutamento, execuo e monitoramento de projeto e fornecer uma estrutura para o gerenciamento de risco.

IX. Ambiente Dar suporte equipe de desenvolvimento, atravs de processos e ferramentas. Ela que prepara o ambiente no projeto e nas iteraes, e do suportes durantes as iteraes. De acordo com estudos, as diferenas entre o UP e o RUP esto em sua estrutura de fluxos de trabalho, sendo que o RUP possui alguns fluxos adicionais, e no fato de que o PU descrito em um livro, enquanto o RUP vendido como uma base de conhecimento em hipermdia com milhares de arquivos, o que evidencia seu maior nvel de detalhamento. O RUP descreve como fazer um desenvolvimento efetivo de software fazendo-se valer das chamadas boas prticas de desenvolvimento. Este captulo apresentou os fundamentos do Processo Unificado mais utilizado pela indstria de software, e os benefcios que o PU proporciona. Explicamos o que o RUP, quais os seus conceitos e como

61

pode ser utilizado. Apontamos que o RUP pode ser visto no apenas como um processo, mas como um produto ou um framework de processo de desenvolvimento. Por fim, apresentamos como o RUP estruturado e que caracterstica possui. No captulo seguinte sero apresentados os processos de desenvolvimento de software, enfatizando sua origem e sua evoluo.

CAPTULO 4 UMA PROPOSTA DE ADEQUAO AOS PROCESSOS DE UMA FBRICA DE SOFTWARE PARA CURSOS DE COMPUTAO E INFORMTICA4.1 Introduo Os cursos de Cincia da Computao e Informtica, devido a sua dimenso prtica e aplicada, necessitam de recursos computacionais variados em termos de complexidade e capacidade. Devido constante evoluo das tecnologias, imprescindvel que os estudantes disponham de equipamentos modernos, interligados em rede e com livre acesso internet. Neste captulo apresentamos uma proposta de adequao aos Processos de uma Fbrica de software para Cursos de Cincia da Computao e Informtica numa Instituio de Ensino.

4.2 Motivaes de uma Fbrica no Ambiente Acadmico O mercado brasileiro de Tecnologia da Informao e Comunicao (TIC) vive um momento peculiar. H uma intensa demanda por servios no Pas e, consequentemente, uma demanda maior para a contratao de profissionais

62

qualificados, comprovadas por pesquisas e estudos que o governo e empresas do ramo vm realizando nos ltimos anos. Neste contexto, as instituies de ensino e pesquisa tecnolgica tm o potencial de disseminar conhecimento, atuando na formao de capital humano de qualidade. A Fbrica de Software, portanto, surge no mbito de um Programa de Formao Complementar com o propsito de aprimorar as competncias em Gesto e Desenvolvimento de Projeto de Software.

4.3 O Projeto da Fbrica de Software da Faculdade Loureno Filho A Fbrica de Software da Faculdade Loureno Filho (FLF) um laboratrio de prtica onde a principal estratgia o aprendizado, a partir de vivncias prticas de desenvolvimento de software para resoluo de problemas reais, em alguns casos, executadas utilizando tecnologias de desenvolvimento de fbricas de software diferenciadas. Entre os principais diferencias que esta fbrica ter, destaca-se a aplicao de processos, tcnicas e ferramentas focadas em reuso e qualidade como:

Necessidade do projeto (Anlise) O objetivo o levantamento da

necessidade de que forma o software a ser criado dever solucionar est necessidade;

Planejamento Inicial O objetivo criar o plano de base para o projeto. O

gerente de projeto responsvel para realizar este planejamento; Requerimentos (requisitos) Objetivo identificar as funes necessrias

que devem ser feitas no projeto. Os requisitos devem ser cuidadosamente planejados, porque a falta de um requisito pode ser vital para o sucesso, como o excesso de requisitos pode tornar o projeto invivel;

Anlise e Design O objetivo define a arquitetura a ser usada e transforma

os requisitos em um projeto do sistema a ser criado; Implementao O objetivo desenvolver o cdigo necessrio ao

funcionamento do sistema em questo;

Teste Objetivo garantir que o sistema funcionara conforme o esperado

pelo cliente, para que o software entre na fase de Implantao;

63

Homologao - O objetivo avaliar o funcionamento do software, verificando

se o mesmo atende o requisito especificado para aplicao. Ao final da homologao o usurio da sua provao final para o sistema.

4.4.1 Fluxo do Processo Operacional O fluxo operacional diz respeito ao workflow de produtos e informaes no ambiente da fbrica, que geralmente automatizado. Atravs dele sero circulado produtos (solicitaes de servios, documentos de especificaes, cdigo, mdulos de software) e atravs de ferramentas e sistemas de informaes gerenciais a informao de controle operacional e de gesto. Neste contexto entendemos que a Fbrica de Software da F