UNIVERSIDADE DE PASSO FUNDO

INSTITUTO DE CINCIAS EXATAS E GEOCINCIAS CURSO SUPERIOR DE ANLISE E DESENVOLVIMENTO DE SISTEMAS

MODELOS PROCESSOS DE SOFTWARE

Disciplina: Engenharia de Software Professor: Roberto dos Santos Rabello Acadmico: Ademir Cofcewicz

Casca, agosto de 2011.

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. 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). Alguns tipos de modelos de processos: O modelo em cascata; Prototipao; Desenvolvimento iterativo: Modelo de desenvolvimento espiral; Modelo de desenvolvimento incremental; O Modelo de Montagem de Componentes.

Modelo RAD; Modelo de Mtodos Formais; Processo Unificado.

Modelo em cascata:

Neste modelo cascata descreve um mtodo de desenvolvimento que linear e seqencial. Em primeira etapa em que uma fase de desenvolvimento completada, o desenvolvimento prossegue para a prxima fase e no h retorno. A grande vantagem do desenvolvimento cascata que ele permite controle departamental e gerencial. O desenvolvimento move do conceito, atravs do projeto (design),

implementao, teste, instalao, descoberta de defeitos e termina com a operao e manuteno. A desvantagem do desenvolvimento em cascata que ele no permite muita flexibilidade ou reviso. O modelo cascata inicia de uma abordagem orientada a projetos para a engenharia de software. O projeto considerado uma tarefa claramente delineada para a

qual os resultados desejados podem ser determinados completamente e sem ambigidade. Existem alguns tipos de problemas? Os projetos reais raramente seguem o fluxo seqencial que o modelo prope. Alguma iterao sempre ocorre e traz problemas na aplicao do paradigma. Muitas vezes difcil para o cliente declarar todas as exigncias explicitamente. O ciclo de vida clssico exige isso e tem dificuldade de acomodar a incerteza natural que existe no comeo de muitos projetos. O cliente deve ter pacincia. Uma verso de trabalho dos programas no estar disponvel at um ponto tardio do cronograma do projeto. Um erro crasso, se no for detectado at que o programa de trabalho seja revisto, pode ser desastroso.

Vantagens e desvantagens:

Vantagens: Permitir a gerncia do baseline, que identifica um conjunto fixo de documentos produzidos como resultado de cada fase do ciclo de vida. Desvantagens: no capaz de estabelecer como efetuar engenharia reversa de um sistema existente e faltam noes de prototipao rpida e desenvolvimento incremental.

Prototipao

Prototipao, a montagem de prottipos, ela pode ser classificada de acordo com uma variedade de dimenses. A abordagem de prototipao tem um nmero de vantagens importante a oferecer. Primeira todo o requisitos de sistema no tem que ser completamente determinado antecipadamente e pode mesmo ser trocada durante o curso do projeto. Segundo, a entrega de prototipao clara, definies de sistema entendvel e especificaes para o usurio final. Como conseqncia, o envolvimento e satisfao do usurio final so fortemente aumentados. Finalmente, prototipao faz isso possvel para rapidamente testar o ambiente de desenvolvimento voltado para a funcionalidade, performance, interface com banco de dados, etc. (IBM, 2002). Porm algumas desvantagens podem ser apontadas como, por exemplo, a modelagem iniciada antecipadamente, sem ter uma ateno devotada suficientemente para a analise de uma situao corrente e desejada, reconhecimento do problema e formulao do problema que so pelo menos to importantes como a prpria soluo. Especialmente na prototipao evolucionria o perigo da falha do projeto existe: toda iterao ajusta o prottipo de uma forma que menos da funcionalidade desejada ou funcionalidade suprflua incorporada dentro do prottipo (IBM, 2002). Um perigo final que a prototipao pode lidar com entusiasmo do usurio final. O processo de prototipao pode dar ao usurio final a impresso que praticamente qualquer sugesto pode ser implementada, no importa qual estgio do processo de desenvolvimento se est. Alm disso, para os usurios no est claro o porqu da demora para entregar a aplicao final depois que uma verso demo do sistema foi exibida.

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: Planejamento: determinao dos objetivos, alternativas e restries. Anlise de riscos: anlise de alternativas e identificao/resoluo de riscos. Engenharia: desenvolvimento do produto no nvel seguinte. Atualizao feita pelo cliente: avaliao dos resultados da engenharia. 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). 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 e 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.

Incremental

O modelo incremental segundo Pressman (2006) combina elementos do modelo cascata sendo aplicado de maneira interativa. O modelo de processo incremental interativo igual prototipagem, mais diferente a prototipagem o incremental tem como objetivo apresentar um produto operacional a cada incremento realizado. Esse modelo muito til quando a empresa no possui mo de obra disponvel no momento para uma implementao completa, dentro do prazo estipulado.

O Modelo de Montagem de Componentes

Utiliza tecnologias orientadas a objeto. Quando projetadas e implementadas apropriadamente as classes orientadas a objeto so reutilizveis em diferentes aplicaes e arquiteturas de sistema. O modelo de montagem de componentes incorpora muitas das caractersticas do modelo espiral. O modelo de montagem de componentes conduz ao reuso do software: A reusabilidade fornece uma srie de benefcios: o reduo de at 70% no tempo de desenvolvimento o reduo de at 84% no custo do projeto o ndice de produtividade de at 26.2 (normal da indstria de 16.9) esses resultados dependem da robustez da biblioteca de componentes

Modelo RAD

RAD ( Rapid Application Development) um modelo sequencial linear que enfatiza um ciclo de desenvolvimento extremamente curto. A alta velocidade conseguida atravs de uma abordagem de construo baseada em componentes. Usado quando os requisitos so bem definidos e o escopo do sistema restrito. Abordagem usada principalmente para aplicaes de SI.

Cada funo principal pode ser direcionada para uma equipe RAD separada e ento integrada para formar o todo. Desvantagens: Exige recursos humanos suficientes para todas as equipes. Exige que desenvolvedores e clientes estejam comprometidos com as atividade de fogorpido a fim de terminar o projeto num prazo curto. Nem todos os tipos de aplicao so apropriadas para o RAD: Deve ser possvel a modularizao efetiva da aplicao. Se alto desempenho uma caracterstica e o desempenho obtido sintonizando as interfaces dos componentes do sistema, a abordagem RAD pode no funcionar.

Modelo de Mtodos Formais

Regras para gerar a descrio. Regras de verificao. Descreve um modelo matemtico do sistema.

Caractersticas

Base terica para descrever com exatido um grande nmero de possibilidades de fenmenos relacionados com a transmisso e a transformao das informaes - no nosso caso, para projetar sistemas de informao automticos (uso em computadores). Uniformizao na forma de se escrever projetos de sistemas (eliminao dos aspectos subjetivos na escrita do projeto). Conciso. Semntica bem definida. Provvel.
Refinamentos Requisitos Informal (elo fraco)

Anlise da especificao

esp. Implementao formal

MF

MF

MF

Processo Unificado

2 Fluxos no Ciclo de Vida do Processo Unificado O Processo Unificado consiste da repetio de uma srie de ciclos durante a vida de um sistema. Cada ciclo concludo com uma verso do produto pronta para distribuio e subdividido em quatro fases: concepo, elaborao, construo e transio. Cada fase, por sua vez, subdivido em iteraes que passam por todos os cincos fluxos do trabalho do processo: anlise de requisitos, anlise, projeto, implementao e teste.

Interaes

Antes de sua concluso, o ciclo de vida do processo unificado passa por vrias e sucessivas iteraes. Cada uma destas iteraes resulta em uma verso de um produto executvel que constitui um subconjunto do produto final em desenvolvimento e cresce de modo incremental de uma iterao para outra at se tornar o sistema final. Durante a concepo, o foco est na captao de requisitos. Durante a elaborao, o foco passa a ser a anlise e projeto do sistema. Durante a construo, a implementao a atividade central. E a transio caracterizada pela entrega de um produto aos usurios.

Fluxos de trabalho

Uma iterao tpica realiza cinco atividades ou fluxo de trabalho: Requisitos Anlise Projeto Implementao Teste

Requisitos

Estes requisitos funcionais so expressos em casos de uso atravs do modelo de casos de uso. Um modelo de casos de uso composto por todos os atores e casos de uso de um sistema, ou seja, composto pelo conjunto de diagramas de casos de uso que compem o sistema, e especifica como esse sistema ser utilizado sob a perspectiva de clientes, usurios e desenvolvedores. Durante a fase de concepo, os casos de uso mais importantes so identificados, delimitando o domnio do sistema. Ao final da fase de elaborao, devem ter sido capturados e descritos cerca de 80% dos requisitos do sistema, porm, apenas 5% a 10% destes requisitos so implementados nesta fase. Na fase de transio quase no h requisitos a serem capturados, a menos que ocorram mudanas nos mesmos.