INTRODUO 1.

1 Engenharia de Software O software de computadores hoje uma tecnologia importante no mbito mundial, tendo um crescimento rpido desde a dcada de 1950, com esse rspido crescimento comeou a ocorrer problemas relacionados a correes, adaptaes, aperfeioamento e ainda o processo de manuteno que consome mais recurso e mais pessoas que na criao de novos softwares. Com todos esses problemas novos conceitos comearam a ser criados com o uso da Engenharia de Software. A Engenharia de software, segundo Fritz Bauer, a criao e a utilizao de slidos princpios de engenharia a fim de obter softwares econmicos que sejam confiveis e que trabalhem eficientemente em maquinas reais. J IEEE desenvolveu uma definio mais abrangente que aplicao de uma abordagem sistemtica, disciplinada e quantificvel, para desenvolvimento, operao e manuteno do software, isto a aplicao da engenharia ao software. Os estudos de abordagens como as de. (PRESSMAN, 2006) Todas essas definies esto inseridas no livro de Pressman que ressalva que a engenharia de software uma tecnologia em camadas (Ferramentas, Mtodos, Processo, Foco na qualidade) e a organizao devem se apoiar num compromisso de qualidade. 1.2 Modelo de Processo de Software Um modelo de processo de software uma representao abstrata de um processo de software. Cada modelo de processo representa um processo a partir de uma perspectiva particular, de uma maneira que proporciona apenas informaes parciais sobre o processo (SOMMERVILLE 1995). Nesse trabalho, falaremos de dois modelos de desenvolvimento iterativos, o Modelo Espiral e o Modelo Incremental. MODELO INCREMENTAL O modelo em cascata de desenvolvimento requer que os clientes de um sistema se comprometam com um conjunto de requisitos antes do incio do projeto e o projetista se comprometa com estratgias especficas de projeto antes da implementao. Mudanas nos requisitos requerem retrabalho dos requisitos, do projeto e da implementao. Contudo, a separao e implementao do projeto deve levar a sistemas bem documentados sujeitos a mudanas. Por outro lado, uma abordagem evolucionaria para o desenvolvimento permite que as decises de requisitos e projeto sejam postergadas, mas tambm podem levar a um software mal estruturado e difcil de compreender e manter. A entrega incremental (figura 1) uma abordagem intermediria que combina as vantagens desses modelos em um processo de desenvolvimento incremental, o cliente identifica, em linhas gerais, o servios a serem fornecidos pelo sistema. O processo de desenvolvimento incremental tem uma srie de vantagens: 1. Os clientes no precisam esperar at a entrega do sistema inteiro para se beneficiarem dele. O primeiro incremento satisfaz os requisitos mais crticos e, dessa forma, possvel usar o software imediatamente. 2. Os clientes podem usar os incrementos iniciais como prottipos e ganhar experincia, obtendo informaes sobre os requisitos dos incrementos posteriores do sistema. 3. Existe um risco menor de falha geral do processo. Embora possam ser encontrados problemas em alguns incrementos, provvel que alguns sejam entregues com sucesso ao cliente.

Figura 1 Desenvolvimento incremental

Eles identificam quais os servios so mais importantes e quais so menos importantes. Assim, um nmero de incrementos de entrega definido, com cada incremento fornecendo um subconjunto das funcionalidades do sistema. A alocao de servios aos incrementos depende da prioridade de servio, com os servios de prioridade mais altas sendo entregues primeiro. Aps a identificao dos incrementos do sistema, os requisitos dos servios a serem fornecidos no primeiro incremento so definidos detalhadamente e ele desenvolvido. Durante o desenvolvimento, pode ser realizada a anlise dos prximos requisitos para os incrementos posteriores, mas no so aceitas mudanas de requisitos para o incremento atual. Uma vez que o incremento concludo e entregue, os clientes podero coloc-lo em operao. Isso significa que eles tm, com antecedncia, a entrega de uma parte da funcionalidade do sistema. Eles podem experimentar o sistema e isso ajuda a conhecer os requisitos dos incrementos posteriores e das verses posteriores do atual. medida que novos incrementos so concludos, eles so integrados aos j existentes, de tal forma que a funcionalidade do sistema aprimorada a cada incremento entregue. Os servios comuns podem ser implementados no incio do processo, ou podem ser implementado de forma incremental, conforme funcionalidade for exigida por um incremento.

4. Como os servios de prioridade mais alta so entregues primeiro, e os incrementos posteriores so integrados a eles, inevitvel que os servios mais importantes servios de sistema recebam mais testes. Isto significa que os clientes tm menor probabilidade de encontrar falhas de software nas partes mais importantes do sistema.

Figura 3 Desenvolvimento incremental

Figura 2 Exemplificao do desenvolvimento incremental

No entanto, existem problemas com a entrega incremental. Os incrementos devem ser relativamente pequenos (no mais do que 20.000 linhas de cdigo), e cada um deve entregar alguma funcionalidade de sistema. Pode ser difcil de mapear os requisitos do cliente em tamanho adequado. Alm disso, a maior parte dos sistemas requer um conjunto de recursos bsicos usados por diferentes partes do sistema. Como os requisitos no so definidos detalhadamente at que um incremento seja implementado, pode ser difcil identificar os recursos comuns exigidos por todos os incrementos. Uma variante dessa abordagem incremental chamado extreme programming, foi desenvolvida (Beck, 2000). Ela se baseia no desenvolvimento e na entrega de incrementos muito pequenos de funcionalidades, envolvimento do cliente no processo, aprimoramento constante de cdigo e programao em pares.

Ele usa uma abordagem evolucionria engenharia de software, capacitando o desenvolvedor e o cliente a entender e reagir aos riscos em cada fase evolutiva. O modelo espiral usa a prototipao como um mecanismo de reduo de riscos, mas, o que mais importante, possibilita que o desenvolvedor aplique a abordagem de prototipao em qualquer etapa da evoluo do produto. Ele mantm a abordagem de passos sistemticos sugerida pelo ciclo de vida clssico, mas incorpora-a numa estrutura iterativa que reflete mais realisticamente o mundo real. O modelo espiral exige uma considerao direta dos riscos tcnicos em todas as etapas do projeto e, se adequadamente aplicado, deve reduzir os riscos antes que eles se tornem problemticos (Pressman, 2006).

MODELO ESPIRAL O modelo espiral foi desenvolvido para abranger as melhores caractersticas tanto do ciclo de vida clssico como da prototipao, acrescentando, ao mesmo tempo, um novo elemento, a anlise de riscos que falta a esses paradigmas. O modelo define quatro importantes atividades representadas por quatro quadrantes: 1. Planejamento: determinao dos objetivos, alternativas e restries. 2. Anlise de riscos: anlise de alternativas e identificao/resoluo de riscos. 3. Engenharia: desenvolvimento do produto no nvel seguinte. 4. Atualizao feita pelo cliente: avaliao dos resultados da engenharia.

O modelo de ciclo de vida espiral apresentado por Boehm em 1988 combina as caractersticas positivas da gerncia (documento associado s fases do ciclo) do modelo cascata com as fases sobrepostas encontradas no modelo incremental e, tambm, com as verses anteriores de um sistema do modelo de prototipao. O modelo em espiral parte do princpio de que a forma do desenvolvimento de software no pode ser completamente determinada de antemo. (Pressman, 2006). A prototipao vista como um meio de reduo de riscos, a permitir que se descubram os problemas potenciais antes de se comprometer com um sistema completo. O modelo caracteriza-se como um gerador de modelo de processo. Cada ciclo do modelo em espiral possui quatro atividades principais: Elaborar objetivos, restries e alternativas para entidades de software. Avaliar alternativas com relao aos objetivos e restries, e identificar as principais fontes de riscos. Elaborar a definio das entidades de software em um projeto. Planejar o prximo ciclo. Abortar um projeto se ele apresentar um alto fator de risco.

A principal diferena entre o modelo em espiral e os outros modelos do processo de software o reconhecimento explcito do risco no modelo em espiral. Informalmente, risco significa simplesmente algo que pode dar errado. Por exemplo, se a inteno for usar uma nova linguagem de programao, um risco que os compiladores disponveis no sejam confiveis ou no produzam cdigo objeto suficientemente eficaz. Os riscos podem causar problemas no projeto, tal como ultrapassar o cronograma e os custos; por isso, a minimizao dos riscos uma atividade de gerenciamento de projeto muito importante. 3.1 Atividade de processo As quatro atividades bsicas do processo Especificao, desenvolvimento, validao e evoluo So organizadas de modo diferente nos diversos processos de desenvolvimento. No modelo em cascata, as atividades, so organizadas em sequencia, ao passo que no desenvolvimento evolucionrio elas so intercaladas. Como essas atividades so realizadas depende do tipo de software, pessoas e estruturas organizacionais envolvidas. No existe uma forma certa ou errada de organizar essas atividades e o objetivo no caso simplesmente apresentar como elas so organizadas. 3.2 Especificao de software A especificao de software ou engenharia de requisitos o processo para compreender e definir quais servios so necessrios e identificar as restries de operao e de desenvolvimento do sistema. A engenharia de requisitos um estgio particularmente critico de processo de software, pois os erros nesse estgio conduzem inevitavelmente a problemas posteriores no projeto e na implementao do sistema. O processo de engenharia de requisitos mostrado na figura 4. Esse processo leva a produo de um documento de requisitos, que a especificao do sistema. Os requisitos so geralmente apresentados em dois niveis de detalhes neste documento. Os usuarios finais e os clientes precisam de uma declarao de requisitos de alto nivel; Os projetistas de sistema precisam de uma especificao de sistema mais detalhada.

Existem quatro fases principais no processo de engenharia de requisitos: 1. Estudo de viabilidade. feita uma avaliao para verificar se as necessidades dos usurios identificadas podem ser satisfeitas por meio das tecnologias atuais de software e hardware. O estudo considera se o sistema proposto ter custo adequado e ponto de vista comercial e se pode ser desenvolvido dentro das restries de oramento existente. O estudo de viabilidade deve ser relativamente barato e rpido. O resultado deve fornecer informaes para a tomada de deciso quanto a prosseguir para uma analise mais detalhada. 2. Elicitao e anlise de requisitos. o processo de derivao de requisitos de sistema atravs da observao de sistemas existentes, discusses com usurios potenciais e compradores, anlise de tarefas etc. Isso pode envolver o desenvolvimento de um ou mais modelos de sistema e prottipos. Eles ajudam o analista a compreender o sistema a ser especificado. 3. Especificao de requisitos. Atividade de traduzir as informaes coletadas durante a atividade de analise em um documento que define um conjunto de requisitos. Devem ser includos dois tipos de requisitos nesse documento. Requisitos de usurio so declaraes abstratas dos requisitos de sistema para o cliente e seus usurios finais; Requisitos de sistema constituem uma descrio mais detalhada da funcionalidade a ser fornecida. 4. Validao de requisitos. Essa atividade verifica os requisitos em relao ao realismo, consistncia e abrangncia. Durante esse processo, erros em documentos de requisitos so inevitavelmente descobertos. Devem, ento, ser feitas modificaes para corrigir esses problemas. Naturalmente, as atividades do processo de requisitos no so realizadas simplesmente em uma seqncia estrita. A anlise de requisitos continua durante a definio e a especificao e novos requisitos aparecem ao longo do processo. Portanto, as atividades de analise, e definio e especificao so intercaladas. Em mtodos geis, como, por exemplo, a extreme programming, os requisitos so desenvolvidos de forma incremental, de acordo com as prioridades do usurio, e a elicitao de requisitos provem de usurios que fazem parte da equipe de desenvolvimento.

CONCLUSO A Engenharia de Software um processo importante no desenvolvimento de Software, mesmo no

Figura 4 - Processo de engenharia de requisitos

possuindo uma forma especfica para realizao de processos todos os fatores podem funcionar em cada empresa tem que optar pela melhor tcnica de desenvolvimento, a melhor opo e mesclarem as tcnicas. Pode-se salientar que a Engenharia de software um crtico fator de sucesso das empresas de desenvolvimento de software, esses conceitos so organizados e agregam viabilidade de produo de software com qualidade, prazo e custos. O modelo incremental, segundo Pressman (2006), combina elementos do modelo cascata sendo aplicado de maneira interativa. O modelo de processo incremental interativo e tem como objetivo apresentar um produto operacional a cada incremento realizado. O modelo espiral, segundo Barry Boehm (1988), objetiva fornecer uma estrutura tcnica para o processo de desenvolvimento de software. Ele considera tambm, os custos agregados durante este processo, proporcionando uma ferramenta de anlise para fatores de riscos para gerencia do projeto. Por fim, cada projeto deve ser analisado antes de se definir qual metodologia usar.

REFERNCIAS BIBLIOGRFICAS PRESSMAN, ROGER S., Engenharia de Software- (7 edio), So Paulo, Ed. Pearson, 2011. SOMMERVILLE, I. Engenharia de Software- (8 edio), So Paulo, Ed. Pearson, 2010.