Engenharia de Software - 1-

Modelos de Processo de Software

A utilizao de um processo de software tm sido apontada como um fator primordial para o sucesso de empresas de desenvolvimento de software. Para poder melhor compreender o assunto necessrio definir o que um processo de software. Um processo de software pode ser entendido como um conjunto estruturado de atividades exigidas para desenvolver um sistema de software. Assim Sommerville[1] trs a seguinte definio: "[O processo ] um conjunto de atividades e resultados associados que produzem um produto de software". Jalote[7] conclui que um processo de software : " um conjunto de atividades, ligadas por padres de relacionamento entre ela, pelas quais se as atividades operarem corretamente e de acordo com os padres requeridos, o resultado desejado produzido. O resultado desejado um software de alta qualidade e baixo custo. Obviamente , um processo que no aumenta a produo (no suporta projetos de software grandes) ou no pode produzir software com boa qualidade no um processo adequado." A partir destas definies podemos considerar que de forma geral um processo de software padro pode ser visto como um conjunto de atividades, mtodos, ferramentas e prticas que so utilizadas para construir um produto de software. Na definio de um processo de software devem ser consideradas as seguintes informaes: atividades a serem realizadas, recursos necessrios, artefatos requeridos e produzidos, procedimentos adotados e o modelo de ciclo de vida utilizado [3]. Sucintamente podemos definir o processo de software (defini-lo(o processo) como um conjunto de atividades uniformizadas a serem aplicadas sistematicamente que se encontram agrupadas em fases, cada uma das quais com os seus intervenientes com responsabilidades, que possui diversas entradas e produz diversas sadas. Isto , define quem faz o qu, quando e como para atingir um certo objetivo. Humphrey[4] define as seguintes razes para a definio de um processo padro: Reduo dos problemas relacionados a treinamento, revises e suporte ferramentas; ?As experincias adquiridas nos projetos so incorporadas ao processo padro e contribuem para melhorias em todos os processos definidos; ?Economia de tempo e esforo na definio de novos processos adequados a projetos.

Fases de um processo de Software Para Schwartz[5] as principais fases de um processo de software so :

Prof. Dr. Roberto dos Santos Rabello

Engenharia de Software - 21. Especificao de Requisitos: traduo da necessidade ou requisito operacional para uma descrio da funcionalidade a ser executada. Projeto de Sistema: traduo destes requisitos em uma descrio de todos os componentes necessrios para codificar o sistema. Programao (Codificao): produo do cdigo que controla o sistema e realiza a computao e lgica envolvida. Verificao e Integrao (Verificao): requisitos iniciais pelo produto produzido. verificao da satisfao dos

2.

3.

4.

Ao contrrio do que possa parecer no existe uma sequncia obrigatria de fases, sendo que diversos autores apontam a natureza no-simultnea das fases como uma realidade na aplicao de processos de software, e tambm defendem que o processo de software muito mais iterativo e cclico do que a idia de fases simples pode sugerir.[6] Atividades do Processo de Software Em cada fase de um processo de software definido so executadas as atividades bsicas para que sejam atingidos os objetivos propostos. Segundo Pressman[2] estas atividades constituem um conjunto mnimo para se obter um produto de software. Realizando uma combinao de classificaes dadas por Schwartz[5] , Pressman[2] e Sommerville[1] podemos identificar as seguintes atividades[6]: 1. Especificao 1. Engenharia de Sistema: estabelecimento de uma soluo geral para o problema, envolvendo questes extra-software. Anlise de Requisitos: levantamento das necessidades do software a ser implementado. A Anlise tem como objetivo produzir uma especificao de requisitos, que convencionalmente um documento. Especificao de Sistema: descrio funcional do sistema. Pode incluir um plano de testes para verificar adequao.

2.

3.

2.

Projeto 1. Projeto Arquitetural: onde desenvolvido um modelo conceitual para o sistema, composto de mdulos mais ou menos independentes. Projeto de Interface: onde cada mdulo tem sua interface de comunicao estudada e definida. Projeto Detalhado: onde os mdulos em possivelmente traduzidos para pseudo-cdigo. si so definidos, e

2.

3.

3.

Implementao 1. Codificao: a implementao em si do sistema em uma linguagem de computador.

Prof. Dr. Roberto dos Santos Rabello

Engenharia de Software - 34. Validao 1. Teste de Unidade e Mdulo: a realizao de testes para verificar a presena de erros e comportamento adequado a nvel das funes e mdulos bsicos do sistema. Integrao: a reunio dos diferentes mdulos em um produto de software homogneo, e a verificao da interao entre estes quando operando em conjunto.

2.

5.

Manuteno e Evoluo 1. Nesta fase, o software em geral entra em um ciclo iterativo que abrange todas as fases anteriores.

Desta forma as atividades relacionadas a um processo de software esto diretamente vinculadas com a produo do software como produto final . Afim de especificar quais atividades devem ser executadas e em qual ordem temos diversos modelos de desenvolvimento de software. Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta s situaes a analisar, porque s na altura em que enfrentamos o problema que podemos escolher o modelo. Nos modelos de processo de software dado uma ateno especial representao abstrata dos elementos do processo e sua dinmica, no estabelecendo mtodos de desenvolvimento, pois este trabalha num nvel mais alto de abstrao do que os modelos de ciclo de vida.WWW[7] A seguir descrevemos os principais modelos : O modelo Cascata Modelo idealizado por Royce em 1970 , tambm conhecido como abordagem topdown , tem como principal caracterstica a sequncia de atividades onde cada fase transcorre completamente e seus produtos so vistos como entrada para uma nova fase. Sofreu diversas ajustes e aprimoramentos sendo muito utilizado nos dias atuais. Descrio Visual do Modelo

Prof. Dr. Roberto dos Santos Rabello

Engenharia de Software - 4-

A ideia principal do modelo que as diferentes etapas de desenvolvimento seguem uma sequncia, ou seja, a sada da primeira etapa "flu" para a segunda etapa e a sada da segunda etapa "flu" para a terceira e assim por diante. As atividades a executar so agrupadas em tarefas, executadas sequencialmente, de forma que uma tarefa s poder ter incio quando a anterior tiver terminado. Uma das vantagens do modelo que s avana para a tarefa seguinte quando o cliente valida e aceita os produtos finais da tarefa atual. O modelo pressupe que o cliente participa ativamente no projeto e que sabe muito bem o que quer. Este modelo minimiza o impacto da compreenso adquirida no decurso de um projeto, uma vez que se um processo no pode voltar atrs de modo a alterar os modelos e as concluses das tarefas anteriores, normal que as novas idias sobre o sistema no sejam aproveitadas. Numa tentativa de resolver este tipo de problema foi definido um novo tipo de processo baseado no clssico em cascata, designado por modelo em cascata revisto, cuja principal diferena consiste em prever a possibilidade de a partir de qualquer tarefa do ciclo se poder regressar a uma tarefa anterior de forma a contemplar alteraes funcionais e/ou tcnicas que entretanto tenham surgido, em virtude de um maior conhecimento que entretanto se tenha obtido. O risco desta abordagem que, na ausncia de um processo de gesto do projeto e de controlo das alteraes bem definido, podemos passar o tempo num ciclo infinito, sem nunca se atingir o objetivo final, ou seja disponibilizar o sistema a funcionar.[8] As desvantagens deste modelo so :

Prof. Dr. Roberto dos Santos Rabello

Engenharia de Software - 5 Dificuldade em acomodar mudanas depois que o processo est a ser executado; Partio inflexvel do projeto em estgios distintos; Dificuldade em responder a mudanas dos requisitos; mais apropriado quando os requisitos so bem compreendidos; Os projetos reais raramente se adaptam ao modelo linear e sequencial; difcil capturar os requisitos de uma s vez; Cliente tem de pacientemente esperar o resultado final; Os programadores so frequentemente atrasados sem necessidade; Alto custo de correo das especificaes quando nas fases de Teste e Implantao.

Modelo Espiral Neste modelo o projeto atacado como uma srie de pequenos ciclos, cada um finalizando um verso de um software executvel. O modelo em espiral foi proposto por Boehm em 1988 como forma de integrar os diversos modelos existentes poca, eliminando suas dificuldades e explorando seus pontos fortes. Este modelo 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. Entretanto a integrao no se d atravs da simples incorporao de caractersticas dos modelos anteriores. O modelo em espiral assume que o processo de desenvolvimento ocorre em ciclos, cada um contendo fases de avaliao e planejamento, onde a opo de abordagem para a prxima fase (ou ciclo) determinada. Estas opes podem acomodar caractersticas de outros modelos.

Prof. Dr. Roberto dos Santos Rabello

Engenharia de Software - 6-

O modelo original em espiral organiza o desenvolvimento como um processo iterativo em que vrios conjuntos de quatro fases se sucedem at se obter o sistema final. Um ciclo se inicia com a determinao de objetivos, alternativas e restries (primeira tarefa) onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratgia para alcanar os objetivos. Na segunda tarefa, anlise e avaliao de alternativas, identificao e soluo de riscos, executa-se uma anlise de risco.Prototipao uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitvel, pode parar o projeto. Na terceira tarefa ocorre o desenvolvimento do produto. Neste quadrante pode-se considerar o modelo cascata. Na quarta tarefa o produto avaliado e se prepara para iniciar um novo ciclo. Variaes do modelo espiral consideram entre trs e seis tarefas ou setores da espiral, que podem ser: comunicao com o cliente; planejamento; anlise de risco; engenharia; construo e liberao; avaliao do cliente.

O modelo espiral , atualmente a abordagem mais realstica para desenvolvimento de software em grande escala, e usa uma abordagem que capacita a empresa que presta o servio, e o cliente a entender e reagir aos riscos em cada etapa evolutiva. Este tipo de modelo exige considervel experincia na determinao de riscos e depende dessa experincia para ter sucesso, pode ser difcil convencer os clientes que uma abordagem evolutiva controlvel.

Prof. Dr. Roberto dos Santos Rabello

Engenharia de Software - 7Vantagens deste modelo modelo em espiral permite que ao longo de cada iterao se obtenham verses do sistema cada vez mais completas, recorrendo prototipagem para reduzir os riscos. Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em cascata, mas que incorpora um enquadramento iterativo que reflete, de uma forma bastante realstica, o processo de desenvolvimento.

Desvantagens Pode ser difcil convencer grandes clientes ( particularmente em situaes de contrato) de que a abordagem evolutiva controlvel. A abordagem deste tipo de modelo exige considervel experincia na avaliao dos riscos e baseia-se nessa experincia para o sucesso. Se um grande risco no for descoberto, podero ocorrer problemas. Este tipo de modelo relativamente novo e no tem sido amplamente usado. importante ter em conta que podem existir diferenas entre o prottipo e o sistema final. O prottipo pode no cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente alguns aspectos do sistema a ser desenvolvido. O modelo em espiral pode levar ao desenvolvimento em paralelo de mltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso necessrio o uso de tcnicas especficas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

Modelo de do processo de desenvolvimento iterativo e incremental Este modelo uma extenso do modelo espiral sendo porm mais formal e rigoroso. O desenvolvimento de um produto comercial de software uma grande tarefa que pode ser estendida por vrios meses, possivelmente um ano ou mais.Por isso, mais prtico dividir o trabalho em partes menores ou iteraes.Cada iterao resultar num incremento. Iteraes so passos em fluxo de trabalho e incrementos so crescimentos do produto. O princpio subjacente ao processo incremental e iterativo que a equipa envolvida possa refinar e alargar paulatinamente a qualidade, detalhe e mbito do sistema envolvido. Por exemplo, numa primeira iterao deve-se identificar a viso global e determinar a viabilidade econmica do sistema, efetuar a maior parte da anlise e um pouco de desenho e implementao.Numa segunda gerao, deve-se concluir a anlise, fazer uma parte significativa do desenho e um pouco mais de implementao.

Prof. Dr. Roberto dos Santos Rabello

Engenharia de Software - 8Numa terceira iterao, deve-se concluir o desenho, fazer-se parte substancial da implementao, testar e integrar um pouco, etc. Ou seja, a principal consequncia da aproximao iterativa que os produtos finais de todo o processo vo sendo amadurecidos e completados ao longo do tempo, mas cada iterao produz sempre um conjunto de produtos finais. A cada iterao so realizadas as seguintes tarefas: - Anlise (refinamento de requisitos, refinamento do modelo conceitual) - Projeto (refinamento do projeto arquitetural, projeto de baixo nvel) - Implementao (codificao e testes) -Transio para produto (documentao, instalao, ...)

Vantagens do processo incremental e iterativo - Possibilidade de avaliar mais cedo os riscos e pontos crticos do projeto, e identificar medidas para os eliminar ou controlar; - Reduo dos riscos envolvendo custos a um nico incremento.Se a equipa que desenvolve o software precisar repetir a iterao, a organizao perde somente o esforo mal direcionado de uma iterao, no o valor de um produto inteiro; - Definio de uma arquitetura que melhor possa orientar todo o desenvolvimento; - Disponibilizao natural de um conjunto de regras para melhor controlar os inevitveis pedidos de alteraes futuras; - Permite que os vrios intervenientes possam trabalhar mais efetivamente pela interao e partilha de comunicao da resultante;

Prof. Dr. Roberto dos Santos Rabello

Engenharia de Software - 9Modelo de Prototipagem O modelo de desenvolvimento baseado na prototipao procura suprir duas grandes limitaes do modelo cascata. De acordo com Jalote[6] a idia bsica deste modelo que ao invs de manter inalterado os requisitos durante o projeto e codificao, um prottipo desenvolvido para ajudar no entendimento dos requisitos. Este desenvolvimento passa por um projeto , codificao e teste, sendo que cada uma destas fases no executada formalmente. Usando assim os prottipos o cliente pode entender melhor os requisitos do sistema. A sequncia de eventos deste modelo esta exibido na figura abaixo:

O prottipo desenvolvido com uma verso inicial do documento de especificao dos requisitos. Depois do prottipo estar pronto o cliente o utiliza e baseado na sua avaliao do cliente fornecido ao as impresses do que precisa ser alterado, o que esta faltando e o que no preciso. O prottipo ento modificado incorporando as sugestes de mudana e o cliente usa o prottipo novamente repetindo o processo at que o mesmo seja vlido em termos de custo e tempo. No final os requisitos iniciais so alterados para produzir a especificao final dos requisitos. [9] Segundo Pressman e Jalote este modelo pode trazer os seguintes benefcios: O modelo interessante para alguns sistemas de grande porte nos quais representem um certo grau de dificuldade para exprimir rigorosamente os requisitos possvel obter uma vero do que ser o sistema com um pequeno investimento inicial A experincia de produzir o prottipo pode reduzir o custo das fases posteriores A construo do prottipo pode demonstrar a viabilidade do sistema.

Questes a serem consideradas quanto a utilizao do modelo: A Prototipao deve ser utilizada apenas quando os usurios podem participar ativamente no projeto

Prof. Dr. Roberto dos Santos Rabello

Engenharia de Software - 10 No descuidar de uma boa anlise que deve ser conduzida durante todo o processo de prototipao Esclarecer aos usurios que o desempenho apresentado pelo prottipo no necessariamente ser o mesmo do sistema final Evitar que o sistema final seja um prottipo em que foram implementados todos os requisitos especificados, pois corre-se o risco de ter-se um sistema mal implementado, uma vez que as tcnicas utilizadas para desenvolver um prottipo so diferentes daquelas utilizadas na implementao de um sistema (relaxamento de regras de negcio, manipulao de excees etc) Durante a etapa de prototipao, documentar todos os pontos levantados e implementados no prottipo, que no constavam dos requisitos iniciais, para inclu-los na documentao final

Concluso No existe um processo correto ou incorreto , como no existe um modelo de desenvolvimento que seja a panacia universal para o problema do desenvolvimento de software. Dependendo de sua aplicao , ambiente e objetivo , a utilizao de um processo ou modelo especfico pode ser vantajoso ou no. Cabe a cada organizao avaliar o seu problema com cuidado e usar os modelos apresentados como um guia para o desenvolvimento do seu prprio processo de desenvolvimento. Referncias: [1] SOMMERVILLE, I. Software engineering. 5th. ed. Addison-Wesley, 1995. [2] PRESSMAN, R. S. , Software engineering: A practitioner's approach. 4th. ed. McGraw-Hill, 1997. p. 22-53. [3] Falbo, Ricardo A., Integrao de Conhecimento em um Ambiente de Desenvolvimento de Software. Tese de Doutorado, COPPE/UFRJ, Rio de Janeiro, Brasil, 1998. [4] Humphrey, Watts S., Managing the Software Process. Addison-Wesley Publishing,Company, Massachussets, 1990. [5] SCHWARTZ, J. I. ,Construction of software. In: Practical Strategies for Developing Large Systems. Menlo Park: Addison-Wesley, 1st. ed., 1975. [6] Christian Reis . , Caracterizao de um Modelo de Processo para Projetos de Software Livre .teste de mestrado.Instituto de Cincias Matemtica e Computao. So Carlos, So Paulo Abril de 2001

Prof. Dr. Roberto dos Santos Rabello