Você está na página 1de 23

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

Classificao dos Paradigmas de Engenharia de Software

1. Ciclo de Vida Clssico

Definio: um mtodo sistemtico e seqencial, em que o resultado de uma fase se constitui na entrada da outra fase.

Foi modelado de acordo com o ciclo da engenharia convencional e abrange as seguintes fases:

- Levantamento de Requisitos - Anlise de Requisitos - Projeto - Implementao - Testes - Manuteno Levantamento de Requisitos: a fase em que o profissional de informtica deve estar diretamente ligado ao usurio. Exige um trabalho em equipe para a coleta das necessidades do usurio em relao ao desenvolvimento do sistema em termos de: funes, dados, escopo, hardware etc.

Esses requisitos podem ser classificados como:

- funcionais: devem descrever o que o software dever fazer;

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

- no funcionais: segurana, integridade, riscos e restries, problemas de negcio etc. - de desenvolvimento e manuteno: cronograma, testes,

prioridade das funes etc. Anlise de Requisitos: Constitui a modelagem lgica do sistema. Nessa fase, os requisitos levantados so transformados em modelos os quais representam o sistema em nvel conceitual.

O resultado dessa fase deve ser um documento ou vrios documentos que sejam: inteligveis, precisos, completos, consistentes, sem ambigidade e, facilmente modificveis. Esses documentos serviro de instrumento de comunicao entre desenvolvedores e usurios. Projeto: Nessa fase, os modelos conceituais so transformados em modelos fsicos, os quais devem estar mais prximos da implementao.

So caractersticas da fase de projeto:

- definio de interface; - definio de estrutura de dados; - definio de mdulos; - etc.

A fase de Projeto permite que o software possa ser avaliado antes da programao ter incio.

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

Implementao: Traduo do projeto em uma forma que seja legvel pela mquina. Testes: Os testes so realizados aps a implementao. Os testes so feitos internamente a um mdulo, linha a linha, e tambm so feitos testes de integrao dos mdulos. Manuteno: A fase de manuteno pode ser: - Corretiva: Erros podem ser encontrados durante o funcionamento do sistema. - Adaptativa: O usurio pode propor alguma mudana a fim de acomodar mudanas de procedimentos, como , por exemplo, nova verso do sistema operacional etc.

- Preventiva: Mudar o

sistema em funo de mudanas

necessrias para manter sua confiabilidade e eficincia, como, por exemplo, reorganizar o banco de dados etc.

Desvantagens do Ciclo de Vida Clssico

- Execuo Seqencial das fases - Implementao de Unidades - Testes de unidades (abordagem bottom_up) - Um erro grave pode ser detectado apenas no final da construo do sistema.

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

2. Ciclo de Vida Estruturado

O Ciclo de Vida Estruturado marca a utilizao efetiva de ferramentas estruturadas de Anlise e Projeto.

As ferramentas de Anlise Estruturada como o DFD (Diagrama de Fluxo de Dados), dividem o sistema em processos de forma que cada processo constitui uma funo a ser desempenhada pelo sistema.

3. Prototipao Definio: Desenvolvimento de um modelo vivo do sistema o qual enfatiza a interface com o usurio. construdo para experimentao, para se obter requisitos dos usurios e para se obter uma confirmao sobre os mesmos.

Tipos de Prototipao: Prototipao Transitria: utilizada como uma maneira de se obter informaes e apresentar essas informaes ao usurio. Aps o sistema estar aceito em termos de informaes, o prottipo deixado de lado.

- Prottipo de Demonstrao: Parte do sistema pode ser apresentada aos gerentes e patrocinadores do projeto para aprovao.

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

- Prottipo de Pesquisa: Parte do sistema pode ser utilizada como maneira de testar a especialidade do domnio, com o objetivo de verificar se todos os conceitos e relacionamentos esto adequados. Este domnio adquirido do usurio.

- Prottipo de Interface: Parte do sistema pode ser utilizada para testar se a interface est adequada. Por exemplo: solues dadas e suas respectivas explicaes.

Exemplo de uma Metodologia de Prototipao Transitria:

Requisitos Prottipo Projeto

R1 P1 Proj1

R2 P2

R3 ... P3 ... Proj3...

Proj2

Prototipao Evolutiva: utilizada como uma maneira de se obter informaes e apresentar essas informaes ao usurio. O prottipo vai sendo melhorado at atingir o objetivo final, ou seja, at que o mesmo atinja o sistema.

Exemplo de uma Metodologia de Prototipao Evolutiva:

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

Coleta de requisitos

Atualizao do prottipo

Projeto rpido

Avaliao do prottipo

Construo do Prottipo

Desvantagens da Prototipao:

- Pode proporcionar uma soluo que frequentemente obtida sem anlise suficiente do problema e encoraja a explorao superficial do problema;

- um desenvolvimento caro o qual pode levar a sistemas pobremente especificados e projetados os quais no suprem as necessidades da aplicao.

- O usurio v aquilo que pensa ser o software, porm, no o . - Manuteno do sistema pode ser ruim em razo da documentao precria.

Aplicaes que poderiam se beneficiar com a construo de um prottipo: - sistemas com um grande nmero de telas;

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

- sistemas para demonstraes de propaganda; - sistemas de entrada de dados; - sistemas em que os requisitos no so claros.

4. Modelo Espiral

Planejamento Planejamento baseado nos comentrios do cliente Coleta inicial dos requisitos e planejamento do projeto

Anlise de riscos Anlise de riscos baseada na reao do cliente Anlise de riscos baseada nos requisitos iniciais

Deciso de prosseguir ou no prosseguir Prottipo de software inicial

Avaliao pelo cliente

Prottipo no nvel seguinte Sistema construdo pela engenharia

- AsAvaliao pelo cliente so organizadas como uma espiral que atividades do paradigma Engenharia tem vrios ciclos; - Cada ciclo representa uma fase; - Engloba caractersticas do ciclo de vida clssico e do ciclo de vida de prototipao (sistema construdo pela Engenharia); - Conforme a espiral seguida, verses mais completas do software vo sendo criadas; - Acrescenta a anlise de risco.

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

Um pouco sobre Anlise de Risco: - Risco: possibilidade de perigo. - Anlise de Risco: consiste em avaliar o que dever ser feito hoje para que algo que ir acontecer no futuro possa acontecer de forma satisfatria. Porm, essa mudana de atitude no garante sucesso, pois, existe o risco. - Os riscos podem ocorrer em qualquer fase do ciclo de vida; (recursos, cronograma, usurios, obsolescncia tcnica, tecnologia de ponta, construo de um produto que no ser utilizado etc).
Tipos de Risco Tecnolgico Exemplos -Componentes do software que deviam ser reutilizados contm defeitos que limitam sua utilizao; - O cdigo gerado pela ferramenta CASE no poder ser utilizado. Pessoas importantes esto doentes em perodos cruciais Problemas financeiros foraram redues no oramento do projeto Os clientes no compreendem O impacto das mudanas nos requisitos.

Pessoal Oramentrio Requisitos

6. Paradigma Unificado - Exemplo: RUP (Rational Unified Process)


Unificado: -Guiado por casos de uso; - centrado na arquitetura; - iterativo; - incremental.

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

Paradigma Unificado (s vezes conhecido como Orientado a Objetos) O Processo Unificado apia-se nos melhores recursos e caractersticas dos modelos convencionais de processo de software. Mas no pode ser considerado apenas como a unio destes modelos, ele tambm possui caractersticas especficas, como ser orientado a casos de uso, centrado na arquitetura, iterativo e incremental. Caractersticas -Orientado a casos de uso: Casos de uso capturam requisitos funcionais do sistema. Um diagrama de casos de uso define as funcionalidades do sistema para cada usurio. O sistema deve ser desenvolvido sob a perspectiva de atender as necessidades dos usurios. O processo de desenvolvimento do sistema orientado por casos de uso, ou seja, significa que o processo de desenvolvimento passa por fluxos de trabalho de derivam dos casos de uso.

- Centrado na arquitetura: A arquitetura a viso do projeto do sistema como um todo, destacando suas caractersticas mais importantes. Ajuda o arquiteto a concentrar-se nas metas corretas, como a inteligibilidade, poder de recuperao para mudanas futuras e a reutilizao.

- Iterativo e incremental Iterativo: processo referente s etapas do fluxo de trabalho. Cada iterao pode ser vista como um mini-projeto, envolvendo um ciclo completo de desenvolvimento (anlise, projeto, implementao e teste), resultando em uma verso de um produto executvel.

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

10

Incremental: processo referente ao avano tecnolgico no desenvolvimento do produto. Para cada verso incorpora aperfeioamentos incrementais em relao ao anterior, pela incorporao do produto resultante da ltima iterao. RUP: Rational Unified Process Fases do processo unificado

O processo RUP desenvolvido e mantido pela Rational Software. O RUP pode ser visualizado como tendo duas dimenses (ou dois eixos condutores): o eixo horizontal representa a organizao do processo atravs do tempo. Apresenta o aspecto mais dinmico do processo medida que ele se desenvolve em termos de ciclos, fases, iteraes e grandes objetivos (milestones); o eixo vertical representa a organizao esttica do processo. Representa como ele descrito em termos de: atividades (activities), (the how) artefatos (artifacts), (the what) participantes (workers) (the who) e fluxos de trabalhos (workflows) (the when).

Esquematicamente:

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

11

O ciclo de vida dividido em ciclos; Cada ciclo produz uma nova gerao do produto; Cada ciclo de desenvolvimento dividido em quatro fases consecutivas; Estas fases so: Incepo (Concepo); Elaborao; Construo e Transio.

Fases e Iteraes

Cada fase concluda quando se alcana um marco principal de progresso (milestone). Os marcos principais de progresso (milestones) de cada fase so: Lifecycle Objective (Concepo); Lifecycle Architecture (Elaborao); Initial operational capability (Construo) e Product release (Transio).

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

12

Fase de Concepo Propsitos: Estabelecer o caso de negcio (business case) do sistema: critrios de sucesso; estimativas de recursos; verificao de riscos; datas para concluso dos principais objetivos; previses de desembolso financeiro; Delimitar o escopo (abrangncia) do projeto; Identificar todas as entidades externas (atores) com os quais o sistema vai interagir; Identificar todos os casos de uso; Descrever os casos de uso mais significativos. Resultados de sua execuo: um documento de viso do projeto: viso geral dos principais requisitos do projeto; caractersticas chave; principais restries; um modelo inicial de casos de uso (10% a 20% completo); glossrio inicial do projeto; caso de negcio inicial; estimativa inicial dos riscos; um plano de projeto apresentando as fases e iteraes; um ou mais prottipos da aplicao.

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

13

Finalizando: Ao final da fase de concepo atinge-se o primeiro marco principal de progresso: Lifecycle Objective.

Concepo

Elaborao

Construo

Transio

Lifecycle Objective

Fase de Elaborao Propsitos: estabelecer uma slida fundao arquitetural para a aplicao; desenvolver um plano de projeto; eliminar os elementos de alto risco para o projeto; obter um entendimento superficial de todo o sistema; as decises referentes a arquitetura tm de ser tomadas a partir de um entendimento do todo do sistema: sua abrangncia os principais requisitos funcionais os principais requisitos no funcionais (desempenho, disponibilidade etc);

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

14

- a fase mais crtica das quatro, pois ao final de sua execuo toda engenharia necessria deve estar completa; -Isto permite a tomada da principal deciso: continuar ou no o desenvolvimento do projeto ou executar ou no as fases subsequentes (construo e transio).

Resultados: - um modelo de caso de uso (pelo menos 80% pronto); - requisitos suplementares capturando os requisitos no funcionais e quaisquer requisitos que no estejam relacionados com os casos de uso; - descrio de arquitetura do software; - prottipo executvel; - uma lista de riscos revisada; - um plano de desenvolvimento de todo o projeto; - um manual de usurio preliminar.

Finalizando: Ao final da fase de Elaborao atinge-se o segundo marco principal de progresso: Lifecycle Architecture.

Incepo

Elaborao

Construo

Transio

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

15

Lifecycle Architecture

Fase de Construo Propsitos: - desenvolver os componentes restantes e as caractersticas da aplicao e integr-los ao produto final; - testar todas as caractersticas; - nfase colocada em atividades de gerenciamento de recursos e controle para otimizar custos e qualidade.

Resultados: - produto integrado em plataforma adequada; - manuais de usurios; - descrio da verso atual.

Finalizando: Ao final da fase de Construo atinge-se o terceiro marco principal de progresso: Initial Operational Capability.

Incepo

Elaborao

Construo

Transio

Initial Operational Capability

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

16

Fase de Transio Propsitos: - transferir o sistema para os usurios; - desenvolver novas verses do sistema (em razo de erros ou caractersticas que foram proteladas); - certificar-se de que um nvel aceitvel de qualidade foi atingido. Isto pode ser feito por meio de: - um processamento paralelo; - converso de BD; - treinamento de usurios; - certificar-se de que a documentao do usurio est disponvel.

Resultados: - atingir auto-apoio do usurio; - atingir as linhas bases de desenvolvimento de acordo com a viso do sistema; - atingir as linhas base do produto rapidamente e de acordo com o custo estimado.

Finalizando: Ao final da fase de Transio atinge-se o quarto marco principal de progresso: Product Release.

Incepo

Elaborao

Construo

Transio

Product Release

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

17

7. Paradigma de Desenvolvimento gil - SCRUM Uma premissa fundamental das metodologias geis o reconhecimento da dificuldade do usurio saber de antemo as funcionalidades que gostaria que o sistema tivesse. Por isso, essas metodologias criam condies favorveis para as interaes e as retro-alimentaes entre usurios e o sistema durante todo o desenvolvimento. Os 12 princpios valorizados pela metodologia gil: - Garantir a satisfao do cliente desde o incio, por meio de entrega rpida e contnua de software. - Modificaes de requisitos so bem-vindas, mesmo que tardias. - A entrega de softwares feita frequentemente (semanas, ao invs de meses) - O pessoal de negcio e os desenvolvedores devem trabalhar juntos diariamente durante todo o projeto. - Projetos surgem atravs de indivduos motivados. Fornea-lhe o ambiente e apoio, e confie que eles faro o trabalho. - Conversa face a face o mtodo mais eficiente para levar informao para uma equipe de desenvolvimento. - Software funcionando a principal medida de progresso. - Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante. - Ateno contnua a excelncia tcnica. - Simplicidade - Melhores arquiteturas, requisitos e projetos surgem de equipes autoorganizadas. - Em intervalos regulares, a equipe reflete sobre como se tornar mais efetiva, ento ajusta adequadamente seu comportamento. Caractersticas para uma equipe gil Competncia: inclui habilidades especficas relacionadas a software e conhecimento global do processo. Foco Comum: focados em uma meta, como entrega dentro de um prazo. Colaborao: criar informaes que ajudaro o cliente e outros membros a entender o trabalho da equipe.

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

18

Capacidade de tomada de deciso Habilidade de resolver problemas vagos Respeito e confiana mtua Auto-organizao: (1) organizar-se para o trabalho a ser feito; (2) organizar o processo para melhor acomodar seu ambiente local; (3) a equipe organiza o cronograma de trabalho para conseguir melhor entrega. Exemplo de Paradigma gil de Processo Scrum baseado em ciclos (normalmente de 30 dias) chamados de Sprints, onde se trabalha para alcanar objetivos bem definidos. Estes objetivos so representados na Pendncia de Produtos, uma lista de coisas para fazer que constantemente atualizada e repriorizada. Funcionamento - Pendncias: todas as funcionalidades ou mudanas no produto so definidas. Esta lista priorizada para refletir a necessidade dos clientes. - Sprints: durante o sprint, os itens em pendncia que devem ser entregues so tratados. As tarefas agora so responsabilidade da equipe, que tem autonomia para decidir como elas devem ser executadas. - Reunies Scrum: so reunies curtas dirias feitas com a equipe num mesmo horrio, para que se reporte: O que foi feito ontem? O que se pretende fazer hoje? Quais so os impedimentos que esto atrapalhando a execuo das tarefas? - Demos: Entrega do incremento de software ao cliente para avaliao.

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

19

O SCRUM um modelo de desenvolvimento gil de software que fornece mtodos para se definir o planejamento, os principais papis de pessoas e a forma de trabalho do time. O nome SCRUM derivado de uma jogada de rugbi, onde todo o mesmo time avana como apenas uma unidade, trabalhando com os mesmos jogadores e em conjunto, passando sempre a bola pra um e para outro. A idia do SCRUM definir papis bem especficos para as pessoas envolvidas no projeto e como cada pessoa vai jogar, ou seja, o que cada uma vai ter que fazer para o time seguir em frente no jogo, ou seja, no prprio desenvolvimento do software. Passos do Scrum: 1. O produto definido: quais so os seus requisitos? O que realmente o cliente quer? O responsvel por esta tarefa o que chamamos de Proprietrio do Produto (Product Owner, em ingls). 2. O Proprietrio do Produto define quais so as funcionalidades do programa que mais importam, criando assim o que chamamos de Product Backlog. 3. Com as prioridades definidas, uma pessoa definida para ser o ScrumMaster, uma espcie de coordenador do projeto. O ScrumMaster, junto com o Proprietrio do Produto e o Time de desenvolvimento definem os sprints.

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

20

4. Cada sprint possui uma parte de todo o Product Backlog, e devem ser trabalhados de acordo com as prioridades definidas no Product Backlog. Os sprints devem ser preparados de uma forma de que durem de 2 a 4 semanas, e que no final de cada perodo tenham um produto apresentvel para o cliente. 5. Os sprints vo sendo feitos at o Product Backlog acabar e o Proprietrio do Produto definir que o projeto est pronto. Mas isso no quer dizer que novas funcionalidades no podem ser includas: basta ir adicionando ao Product Backlog e realizando outros sprints. O SCRUM tem trs partes principais: Papis (Roles), Cerimnias (Cerimonies) e Artefatos (Artifacts). Cada um destes trs pilares contm outros sub-itens. Todas estas trs partes principais so utilizadas no ciclo de desenvolvimento, ou seja, o sprint. Cada sprint possui suas fases e utiliza destes papis, cerimnias e artefatos para alcanar seu objetivo final. Papis do SCRUM (Roles) Como a metodologia define como o time deve trabalhar, o primeiro passo para o desenvolvimento por SCRUM definir quem vai fazer o qu. H trs papis: o Proprietrio do Produto (Product Owner), o ScrumMaster e o Time. 1.1. Proprietrio do Produto (Product Owner) O Proprietrio do Produto representa os interesses do cliente. Ele tem que ser a interface entre o cliente e o time de desenvolvedores, ou

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

21

seja, estar sempre em contato com o cliente e saber exatamente o que o projeto tem que ser. Ele tem as seguintes responsabilidades:

Definir as caractersticas e contedo do produto; Decidir sobre a data de trmino; Ser responsvel pela rentabilidade do produto; Prorizar as funes de acordo com o valor de mercado e com o cliente;

Ajustas recursos e priorizar tarefas a cada 30 dias, como necessrio;

Aceitar ou rejeitar o resultado do trabalho.

O trabalho mais rduo do Proprietrio do Produto definir o Product Backlog, um dos dois artefatos do SCRUM, que veremos

posteriormente. Essa definio se d durante o Planejamento, que tambm veremos adiante. 1.2. ScrumMaster O ScrumMaster o lder da equipe de desenvolvimento e durante o trabalho, fica mais em contato com o Proprietrio do Produto. Ele gerencia e repassa o trabalho que foi decidido durante o planejamento pelo Proprietrio do Produto. Ele deve:

Assegurar

que

equipe

de

desenvolvimento

funcione

plenamente e seja produtiva;

Ajudar na cooperao entre todas as funes e papis do time;

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

22

Remover barreiras; Proteger a equipe de interferncias externas; Assegurar-se de que a metodologia est sendo seguida, incluindo chamadas para reunies dirias (Daily Scrum

Meetings), revises de atividade (Sprint Reviews) e reunies de planejamento das atividades (Sprint Planning). Devido a todas estas responsabilidades, o ScrumMaster o que podemos chamar de Coordenador do Projeto. Ele facilita a comunicao entre as pessoas e faz o projeto andar de verdade. 1.3. A Equipe de Desenvolvimento A equipe de desenvolvimento quem vai colocar a mo na massa para que o software comece a ter cara e funcionamento. Pode haver uma ou mais equipes de desenvolvimentos, dependendo da complexidade do software. Algumas caractersticas das equipes de desenvolvimento:

So

pequenas

multidisciplinares,

com

em

mdia

participantes;

Definem metas de cada Sprint, junto ao ScrumMaster, e especificam seus resultados de trabalho;

Tm o direito de fazer tudo dentro dos limites das diretrizes do projeto para atingir a meta de cada Sprint;

Organizam os trabalhos para atingir os objetivos dos Sprints; Trabalham para atingir todos os resultados definidos pelo Proprietrio do Produto.

Disciplina: Fundamentos da Engenharia de Software Tpico: Ciclos de Vida

23

Fontes: Roger S. Pressman, Engenharia de Software, 6 Edio


Texto do Scrum Adaptado de: http://www.devin.com.br/modelo-scrum/

http://www.deinf.ufma.br/~acmo/MOO_PUintro.pdf Roger S. Pressman, Engenharia de Software, 6 Edio