3

SISTEMA DE ENSINO PRESENCIAL CONECTADO CURSO SUPERIOR DE TECNOLOGIA EM ANLISE E DESENVOLVIMENTO DE SISTEMAS

ATIVIDADE PORTFLIO:
Analise de sistemas 1

Belo Horizonte 2010

ATIVIDADE PORTFLIO:
Analise de sistemas 1

Trabalho apresentado a disciplina Linguagem e Tcnica de Programao I da Universidade Norte do Paran UNOPAR Prof(s). Simone Sawasaki Tanaka

Belo Horizonte 2010

Sumario

1. Introduo....................................................................4 2. Modelos de ciclo de vida no processo de

desenvolvimento de software ..........................................5 2.1. Modelo cascata .........................................................6 2.2. Modelo espiral ...........................................................7 3.3. Modelo interativo e icremental...................................8 2. Processos geis............................................................9 2.1. Extreme programming.............................................10 3. RUP............................................................................12 4. Apndice.....................................................................13 5 Referencia...................................................................14

1. Introduo .

Este

portflio

abordar

conceitos

sobre

os

ciclos

de

vida

do

desenvolvimento nos processos de desenvolvimento de software, veremos os principais modelos de ciclos de vidas,tais como modelo cascata ,modelo expiral e modelo interativo ou icremental. Veremos tambm os processos geis para construo de software,veremos tambm um tpico sobre RUP (Rational Unified Process).

2. Modelos

de

ciclo

de

vida

no

processo

de

desenvolvimento de software.
Um processo de desenvolvimento de software pode ser definido como um conjunto de atividades ou praticas que objetivam a produo ou manuteno de um sistema de software, em outras palavras passo que devem ser seguidos para o desenvolvimento de um determinado sistema e software. Mesmo existindo vrios processo de software, por padro ,todos possuem algumas atividades em comum,tais como; a especificao do software que responsvel por descrever as funcionalidades e restries que o software ira conter,o projeto de implementao garante que o software que ser

produzido ir atender todas as especificaes levantadas, a validao do software uma avaliao do software em relao s expectativas do cliente, pois indica que o software atende ou no tais expectativas, a evoluo do software o processo de manuteno e alteraes que o software sofre para que o mesmo atenda s necessidades mutveis dos clientes. Vem se tentado encontrar um processo ou metodologia previsvel e repetvel que melhore a produtividade e qualidade no processo de construo de software, tentaram sintetizar e formalizar a tarefa aparentemente

incontrolvel de escrever um software, outros j aplicaram tcnicas de gerenciamento de projeto na escrita de software. Sem o gerenciamento do projeto, projetos podem facilmente sofrer atraso ou estourar o oramento. Como um grande nmero de projetos no atendem suas expectativas em termos de funcionalidade, custo ou cronograma de entrega ainda no existe um modelo de processo perfeito para todas as aplicaes, vejamos alguns processos.

2.1

MODELO EM CASCATA.

O mais antigo e bem conhecido processo o modelo em cascata, onde os desenvolvedores ( a grosso modo) seguem estes passos em ordem. Eles estabeleam os requisitos, os analistas, projetam uma abordagem para a soluo, arquitetam um esboo do software, implementam o cdigo ,testam (inicialmente teste unitrios e ento os testes de sistemas), implantam e mantm. Depois que cada passo e terminado, o processo segue para o prximo passo, tal como construes que no reviso as fundaes de uma casa depois que as paredes foram erguidas. Se as iteraes no so includas no planejamento, o processo no tem meios para corrigir os erros nas etapas iniciais (por exemplo, nos requisitos) ento o processo inteiro da engenharia de software deve ser executado ate o fim, resultando em funcionalidades de software desnecessrias ou sem uso.para isso tem que fazer o implemento dos requisitos anteriormente analisados pelo programador . Os nomes dados a cada passo variam assim como a definio de exata de cada um deles, mas basicamente o ciclo comea com a analise de requisitos movendo se de seguida para a fase de codificao, implementao, testes e finalmente a manuteno do sistema, uma das grandes falhas deste modelo o fato de que os requisitos esto em constate mudana j que o negocio e o ambiente em que se inserem muda rapidamente. A idia de interao no foi incorporada no modelo cascata. Vantagens do modelo cascata: Minimiza o tempo do planejamento, funciona bem para equipes mais fracas. Desvantagem do modelo cascata: inflexvel ,apenas a fase final produz um deliverable que no um documento, torna-se difcil voltar atrs para corrigir erros.

2.2

MODELO ESPIRAL.

Durante muitos anos o modelo cascata foi a base da maior parte do desenvolvimento de projetos de software, mas em 1988 Barry Boehm sugeriu o modelo expiral . Do modelo em espiral para desenvolvimento de software saltam a vista dois aspectos: a na analise de risco e prototipagem. O modelo espiral incorpora-os de uma forma interativa permitindo que as idias e os processos sejam verificados e avaliados constantemente. Cada interao a volta da espiral pode ser baseada num modelo diferente e pode ter diferentes atividades. No caso da espiral no foi a necessidade do envolvimento dos utilizadores que inspirou a necessidade da interao, mas sim a necessidade de identificar e controlar risco. No modelo espiral para a engenharia de requisitos mostra se que as diferentes atividades so repetidas at uma deciso ser tomada e o documento de especificao ser aceito. Se forem encontrados problemas numa verso inicial do documento, reentra- se na fase de levantamento, analise, documentao e validao .Isto se repete at que seja produzido um documento aceitvel ou at que fatores externos,tais como prazos e falta de recursos ditem o final do processo de engenharia de requisitos. Vantagens do modelo espiral : As interaes inicias do projetos so mais baratas,permitindo que as tarefas de maior risco sejam levadas com o mnimo de custos, cada interao da espiral pode ser customizada para as necessidades especificas de cada projeto. Desvantagens do modelo espiral: complexo e requer ateno e conhecimento especiais para levar a cabo.

10

2.3.

MODELO ITERATIVO E INCREMENTAL

O desenvolvimento interativo e incremental prescreve a construo de uma poro pequena , mas abrangente, do projeto de software para ajudar todos os envolvidos a descobri cedo os problemas ou suposies, falhas que possam levar ao desastre. O processo interativo preferido por desenvolvedores porque lhe fornece um potencial para atingir os objetivos de projeto de um cliente que no sabe exatamente o que quer ou quando no se conhece bem todos os aspectos da soluo. Processo de desenvolvimento gil de software so construdos com os fundamentos do processo iterativo. Os processos geis usam feedback

mais que o planejamento, como seus mecanismo de controle primrio. O feedback produzido por testes desenvolvido. O desenvolvimento iterativo e incremental uma estratgia de planejamento (que segue a linha dividir para conquistar), onde o software e construdo em partes , ou seja , em ciclos (iteraes) , a cada iterao feito um novo incremento(parte do software funcional) at completar o software. regulares e das verses do software

11

3.

PROCESSOS GEIS

Os processos em desenvolvimento gil de software parecem ser mais eficientes do que as metodologias antigas. Utiliza menos tempo do programador no desenvolvimento de software funcionais de alta qualidade , mas tema desvantagem de ter uma perspectiva de negocio que no prov uma capacidade de planejamento em longo prazo.Em essncia, eles provem mais funcionalidades por custo/ beneficio,mas no dizem exatamente o que a funcionalidade ira fazer. Existem varias metodologias que podem ser consideradas como abordagens geis,entre elas o Scrum(1986), programao extrema(1996),FDD(1995) , Cristal Clear(1996),DSDM (1995) entre outras. A maioria dos mtodos geis tentam minimizar o risco pelo desenvolvimento de software em curtos perodos, chamados de iterao os quais gastam tipicamente menos de uma semana ate quatro. Cada iterao e como um projeto de software em miniatura de seu prprio, e inclui todas as tarefas necessrias para implantar o mini-incremento da nova funcionalidade: planejamento documentao. Mtodos geis enfatizam comunicao em temo real, preferencialmente face a face,a documentos escritos.Mtodos geis tambm enfatizam trabalho direto no software como uma medida primaria de processo. Combinando com a comunicao face a face, mtodos geis produzem pouca documentao em relao a outros mtodos, sendo este um ponto negativo. recomendada a produo de documentao que realmente ser til. Os princpios do desenvolvimento gil valorizam: Garantir a satisfao do consumidor entregando rapidamente e continuamente softwares funcionais. Softwares funcionais so entregues freqentemente (semanas ao invs de meses ) Softwares funcionais so a principal medida de processo do projeto. At mesmo mudanas tardias de escopo no projeto so bem vindos. analise de requisitos, projetos, codificao, teste e

12

Cooperao constate entre pessoas que entendem do negocio e desenvolvedores. Projetos surgem atravs de indivduos motivados,entre os quais existe relao de confiana. Design do software deve dar prazer pela excelncia tcnica. Simplicidade. Rpida adaptao as mudancas. Indivduos e interaes mais do que processos e ferramentas. Software funcional mais que documentao extensa. Colaborao com clientes mais do que negociao e contrato. Responder as mudanas mais do que seguir um plano.

Inicialmente os mtodos geis eram conhecidos como mtodos leves. Em 2001, membros proeminentes da comunidade se reuniram Snowrbird e adotaram o nome para mtodos geis, tendo publicado o manifesto gil , documento que rene os princpios e praticas desta metodologia de desenvolvimento. Mais tarde algumas pessoas formaram a Agile Alliance uma organizao no lucrativa que promove o

desenvolvimento gil.

3.1

EXTREME PROGRAMMING

Programao

extrema

(do

ingls

Xtreme

programming)

ou

simplesmente XP, uma metodologia para pequenas e mdias e que iro desenvolver software com requisitos vagos e em constate mudana. Para isso, adota a estratgia de constante acompanhamento e realizao de vrios pequenos ajustes durante o desenvolvimento de software. Os quatros valores principais da metodologia XP so:

comunicao,simplicidade,

feedback e coragem. A partir desses valores,

possui como princpios bsicos: feedback rpido, presumir simplicidade,

13

mudanas incrementais,abraar mudanas e trabalho de qualidade. Dentre as variveis de controle em projetos (custo, tempo, qualidade e escopo), h um foco explicito em escopo. Para isso, recomenda-se a priorizao de funcionalidades que representam maior valor expressivo ao negocio, desta forma caso seja necessrio a diminuio do escopo, as funcionalidades de menor valor sero adiadas ou canceladas. A XP incentiva o controle da qualidade como varivel do projeto, pois o pequeno ganho de curto prazo na produtividade, ao diminuir qualidade, no compensado por perdas (ou at impedimentos) a mdio e longo prazo. A XP prope aplicao de diversas praticas para agregar valor ao desenvolvimento do software, so elas: Jogo de planejamento (interaes semanais entre todas as partes) Pequenas verses ( a entrega de valor ao cliente em pequenas partes) Metfora (compreender melhor a necessidade do cliente) Projeto simples ( a menos descomplicao do sistema) Time coeso (a equipe e formada pelo cliente e pelos

desenvolvedores) Testes de aceitao ( testes com o cliente e analista para verificao da funcionalidade) Ritmo sustentvel (manter o equilbrio fsico e mental da equipe para garantir o sucesso do projeto) Reunies em p (para no perder o foco do assunto produzir reunies rpidas) Posse coletiva (os cdigos no tm dono o foco e interagir para que toda a equipe conhea o sistema.) Programao em pares (um novato codifica e o experiente acompanha) Padres de codificao (sero criadas regras para codificao) Desenvolvimento orientado a testes ( criar primeiro o teste unitrio e depois criar o cdigo para que os testes funcionem) Refatorao (programa de melhoria na programao evitando a introduo de erros)

14

Integrao continua ( sempre que produzir uma nova funcionalidade , nunca esperar uma semana para entregara a verso atual do sistema , isso aumenta as chances de conflitos e possibilidades de erros nos cdigos fonte).

4.

RUP.

O RUP, abreviao de Rational Unified Process ( ou , processo unificado racional) e um processo proprietrio de engenharia de software criado pela Rational software, adquirida ela IBM, ganhando um novo nome IRUP que agora e uma abreviao de IBM Rational Unified Process e se tornando uma brand na rea de software, fornecendo tcnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade no processo de desenvolvimento . O RUP usa abordagem de orientao da orientao a objetos em sua concepo e projetado e documentado utilizando a notao UML (Unified modeling language) para ilustrar os processos em ao. Utiliza tcnicas e praticas aprovadas comercialmente. um processo considerado pesado e preferencialmente aplicvel a grandes equipes de desenvolvimento e a grandes projetos, porem o fato de ser amplamente customizavel torna possvel que seja adaptado para projetos de qualquer escala. Para a gerncia do projeto, o RUP prov uma soluo disciplinada de como assinalar tarefas e responsabilidades dentro de uma organizao de desenvolvimento de software. O RUP por isso um produto de software. modular e automatizado, e toda sua metodologia apoiada por diversas ferramentas de desenvolvimento integradas e vendidas pela IBM atravs de seus Rational Sutes. Mtodos concorrentes da engenharia de software incluem o Cleanroon( considerado pesado)e os mtodos geis(leves) como a programao extrema(XP), Scrum,FDD e outros.

15

APNDICE

Instrumento de Pesquisa Utilizado na Coleta de Dados Google: http://www.google.com Apostilando: http://www.apostilando.com

16

REFERNCIAS FIERLI, Agla de Lima. REIS, Mrcia Cristina dos. Consideraes Gerais Normas da ABNT. 2. ed. Disponvel em: <http://www.unopar.br/bibliotecadigital/>. Acesso em 22.agosto 2010. TANAKA, Simone Sawasaki, Analise de sistemas 1 Pearson Education editora filada.

Foram coletados dados dos matrias das tele aulas .

17