SISTEMA DE ENSINO PRESENCIAL CONECTADO CURSO SUPERIOR DE TECNOLOGIA EM ANLISE DESENVOLVIMENTO DE SISTEMAS EMMANUEL NAZARENO DA COSTA LIMA

PRODUO TEXTUAL INTERDISCIPLINAR - INDIVIDUAL

Joo Pessoa 2011

EMMANUEL NAZARENO DA COSTA LIMA

PRODUO TEXTUAL INTERDISCIPLINAR - INDIVIDUAL

Trabalho apresentado ao Curso de Anlise e Desenvolvimento de Sistemas da UNOPAR Universidade Norte do Paran, para as disciplinas do 2 semestre Prof. Fbio Zanellato Prof. Luis Claudio Perini Prof.Roberto Nishimura Prof. Simone Tanaka

Joo Pessoa 2011

SUMRIO1 2 ELABORAO DE DOCUMENTAO DE CASO DE USO ................................ 4 CONCEITOS DA TCNICA DE MODELAGEM ENTIDADE RELACIONAMENTO .............................................................................................................................. 5 3 MODELOS GEIS E MODELOS EVOLUCIONRIOS......................................... 73.1 MODELOS GEIS ......................................................................................................................... 7 3.1.1 Scrum ................................................................................................................................. 11 3.1.2 Extreming programing (XP) ............................................................................................... 14 3.1.3 Crystal ................................................................................................................................ 18 3.1.4 Adaptive Soft Developmet - ADS ....................................................................................... 21 3.1.5 Feature Driven Development - FDD .................................................................................. 23 3.2 MODELOS EVOLUCIONRIOS ................................................................................................... 25 3.2.1 ESPIRAL .............................................................................................................................. 25 3.2.2 DESENVOLVIMENTO INCREMENTAL ................................................................................. 27 3.2.3 DESENVOLVIMENTO EVOLUCIONRIO ............................................................................. 27 3.2.4 RUP .................................................................................................................................... 28

4

REFERNCIAS BIBLIOGRFICAS ................................................................... 31

1 ELABORAO DE DOCUMENTAO DE CASO DE USOCaso de Uso: Controlar Matrcula Descrio: Este caso de uso tem a finalidade de registrar matrculas de alunos, atravs da digitao dos dados requeridos para o usurio Ator: Funcionrio Pr-condies: Funcionrio deve estar logado no sistema e ter permisso para realizar a tarefa. Fluxo de Eventos: Fluxo Bsico : Solicitar ao usurio a informao se a matrcula est sendo feita por um novato na instituio ou um veterano (aluno que j estuda na mesma); Apresentar formulrio para preenchimento dos seguintes dados: SRIE EM QUE DESEJA SER MATRICULADO, NOME, ENDEREO (completo), TELEFONE, E-MAIL, DATA DE NASCIMENTO, NOME DO RESPONSVEL, CPF DO RESPONSVEL, CONTATOS RESPONSVEL (fone(s), e-mail); O registro ser efetuado mediante a seleo de um cone localizado no final do formulrio de matrcula. Solicitar confirmao de registro da matrcula. Fluxo Alternativo : Para alunos veteranos, verificar se est apto para cursa a srie solicitada e informar caso no seja possvel e informar a srie que est apta. Caso seja aluno veterano disponibilizar procura do nome e autocompletar dados com base na matrcula do ano anterior e perguntar se deseja fazer alguma modificao; Variantes: Poder ser utilizada como pr-matrcula Ps-condies: Confirmao da realizao da matrcula

2

CONCEITOS DA TCNICA DE MODELAGEM ENTIDADE RELACIONAMENTOENTIDADE Qualquer coisa do mundo real, concretas ou abstratas que possuem

caractersticas ou propriedades em comum que formam algo relevante para o que se quer armazenar.

RELACIONAMENTOS So associaes que ocorrem entre as entidades, ligando-as entre si, que expressam uma regra de negcio

ATRIBUTOS uma caracterstica ou propriedade que possui uma entidade ou um relacionamento.

CARDINALIDADE quantidade de ocorrncias de entidades que podem estar associadas a uma entidade analisada, a regra de negcio, expressa quantas ocorrncias de uma entidade participam no mnimo e no mxima do relacionamento.

ADMINISTRADOR DE BANCO DE DADOS o controlador central dos dados e dos programas que iro acessar o banco de dados. responsvel pe definio do esquema (projetos lgicos, fsicos e pela modelagem dos sistemas), do armazenamento e mtodos de acesso, pela modificao de esquema e de organizao fsica, estabelece as regras e controles de acesso, e define as especificaes de restrio de integridade (regras de negcio).

MODELO CONCEITUAL Representa as regras de negcio sem limitaes tecnolgicas ou de implementao, uma anlise de forma conceitual dos dados que sero armazenados.

MODELO LGICO Modelo que, a partir da abordagem conceitual, descreve as estruturas contidas no banco de dados, identificando os tipos de atributos e algumas regras bsicas.

MODELO FSICO Descreve os detalhes de armazenamento (interno) dos dados e das formas de acesso a esses dados, levando em considerao limites impostos pelo SGBD (Sistema Gerenciador de Banco de dados), pelos requisitos no funcionais dos programas que acessam os dados, etc.

3

MODELOS GEIS E MODELOS EVOLUCIONRIOS

3.1 MODELOS GEISExistem inmeros mtodos de desenvolvimento de software rpido, cada uma destas expostas pela The Agile Alliance. A maioria dos mtodos geis tenta minimizar o risco pelo desenvolvimento do software em curtos perodos, chamados de iterao, os quais gastam tipicamente menos de uma semana a at quatro. Cada iterao como um projeto de software em miniatura dele mesmo, e inclui todas as tarefas necessrias para implantar o mini-incremento da nova funcionalidade: planejamento, anlise de requisitos, projeto, codificao, teste e documentao. Enquanto em um processo convencional, cada iterao no est necessariamente focada em adicionar um novo conjunto significativo de funcionalidades, um projeto de software gil busca a capacidade de implantar uma nova verso do software ao fim de cada iterao, etapa a qual a equipe responsvel reavalia as prioridades do projeto. Mtodos geis enfatizam comunicao em tempo real, preferencialmente face a face, a documentos escritos. A maioria dos componentes de um grupo gil deve estar agrupada em uma sala. Isto inclui todas as pessoas necessrias para terminar o software. No mnimo, isto inclui os programadores e seus clientes (clientes so as pessoas que definem o produto, eles podem ser os gerentes, analistas de negocio, ou realmente os clientes). Nesta sala devem tambm se encontrar os testadores, projetistas de iterao, redatores tcnicos e gerentes. Mtodos geis tambm enfatizam trabalho no software como uma medida primria de progresso. Combinado com a comunicao face-a-face, mtodos geis produzem pouca documentao em relao a outros mtodos, sendo este um de seus pontos negativos. 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 progresso do projeto;

At mesmo mudanas tardias de escopo no projeto so bem-vindas. Cooperao constante entre pessoas que entendem do negcio e

desenvolvedores;

Projetos surgem atravs de indivduos motivados, e que deve existir uma relao de confiana.

Design do software deve prezar pela excelncia tcnica; Simplicidade; Rpida adaptao s mudanas; Indivduos e interaes mais do que processos e ferramentas; Software funcional mais do que documentao extensa; Colaborao com clientes mais do que negociao de contratos; Responder a mudanas mais do que seguir um plano. Mtodos geis so algumas vezes caracterizados como o oposto de

metodologias guiadas pelo planejamento ou disciplinadas. Uma distino mais acurada dizer que os mtodos existem em um continuo do adaptativo at o preditivo. Mtodos geis existem do lado adaptativo deste continuo. Mtodos adaptativos buscam a adaptao rpida a mudanas da realidade. Quando uma necessidade de um projeto muda, uma equipe adaptativa mudar tambm. Um time adaptativo ter dificuldade em descrever o que ir acontecer no futuro. O que acontecer em uma data futura um item de difcil predio para um mtodo adaptativo. Uma equipe adaptativa pode relatar quais tarefas se iniciaro na prxima semana. Quando perguntado acerca de uma implantao que ocorrer daqui a seis meses, uma equipe adaptativa deve ser capaz somente de relatar a instruo de misso para a implantao, ou uma expectativa de valor versus custo. Mtodos preditivos, em contraste, colocam o planejamento do futuro em detalhe. Uma equipe preditiva pode reportar exatamente quais aspectos e tarefas esto planejados para toda a linha do processo de desenvolvimento. Elas, porm tem dificuldades de mudar de direo. O plano tipicamente otimizado para o objetivo original e mudanas de direo podem causar a perda de todo o trabalho e determinar que seja feito tudo novamente. Equipes preditivas freqentemente instituem uma comisso de controle de mudana para assegurar que somente as mudanas mais importantes sejam consideradas.

Mtodos geis tm muito em comum com tcnicas de Desenvolvimento rpido de aplicao de 1980 como exposto por James Martin e outros. Embora os mtodos geis apresentem diferenas entre suas prticas, eles compartilham inmeras caractersticas em comum, incluindo o desenvolvimento iterativo, e um foco na comunicao interativa e na reduo do esforo empregado em artefatos intermedirios. (Cohen et al., 2004). A aplicabilidade dos mtodos geis em geral pode ser examinada de mltiplas perspectivas. Da perspectiva do produto, mtodos geis so mais adequados quando os requisitos esto emergindo e mudando rapidamente, embora no exista um consenso completo neste ponto (Cohen et al., 2004). De uma perspectiva organizacional, a aplicabilidade pode ser expressa examinando trs dimenses chaves da organizao: cultura, pessoal e comunicao. Em relao a estas reas inmeros fatores chave do sucesso podem ser identificados (Cohen et al., 2004):

A cultura da organizao deve apoiar a negociao. As pessoas devem ser confiantes. Poucas pessoas, mas competentes. A organizao deve promover as decises que os desenvolvedores tomam. A organizao necessita ter um ambiente que facilite a rpida comunicao entre os membros. O fator mais importante provavelmente o tamanho do projeto (Cohen et al.,

2004). Com o aumento do tamanho, a comunicao face a face se torna mais difcil. Portanto, mtodos geis so mais adequados para projetos com pequenos times, com no mximo de 20 a 40 pessoas. De forma a determinar a aplicabilidade de mtodos geis especficos, uma analise mais sofisticada necessria. O mtodo dinmico para o desenvolvimento de sistemas, por exemplo, provm o denominado 'filtro de aplicabilidade' para este propsito. Tambm, a famlia de mtodos Crystal provm uma caracterizao de quando selecionar o mtodo para um projeto. A seleo baseada no tamanho do projeto, criticidade e prioridade. Contudo, outros mtodos geis no fornecem um instrumento explcito para definir sua aplicabilidade a um projeto. Alguns mtodos geis, como DSDM e Feature Driven Development, afirmam se aplicar a qualquer projeto de desenvolvimento gil, sem importar suas caractersticas (Abrahamsonn et al., 2003).

A comparao dos mtodos geis ir revelar que eles suportam diferentes fases de um ciclo de vida do software em diferentes nveis. Estas caractersticas individuais dos mtodos geis podem ser usadas como um critrio de seleo de sua aplicabilidade. Desenvolvimentos geis vm sendo amplamente documentados, como funcionando bem para equipes pequenas (< 10 desenvolvedores). O

desenvolvimento gil particularmente adequado para equipes que tm que lidar com mudanas rpidas ou imprevisveis nos requisitos. A aplicabilidade do desenvolvimento gil para os seguintes cenrios ainda uma questo aberta:

esforos de desenvolvimento em larga escala (> 20 desenvolvedores), embora estratgias para maiores escalas tenham sido descritas.

esforos de desenvolvimento distribudo (equipes no co-alocadas). esta estratgia tem sido descritas em Bridging the Distance e Using an Agile Software Process with Offshore Development

esforos crticos de misso e vida. companhias com uma cultura de comando e controle. Barry Boehm e Richard Turner sugeriram que analise de risco pode ser usada

para escolher entre mtodos adaptativos ("geis") e preditivos ("dirigidos pelo planejamento"). Os autores sugerem que cada lado deste continuo possui seu ambiente ideal" Ambiente ideal para o desenvolvimento gil:

Baixa criticidade Desenvolvedores seniores Mudanas freqentes de requisitos Pequeno nmero de desenvolvedores Cultura que tem sucesso no caos. Os mtodos geis diferem largamente no que diz respeito forma de serem

gerenciados. Alguns mtodos so suplementados com guias para direcionar o gerenciamento do projeto, mas nem todos so aplicveis. Uma das caractersticas comum dos processos geis a capacidade de funcionar em ambientes muito exigentes que tem um grande numero de incertezas e

flutuaes (mudanas) que podem vir de vrias fontes como: equipe em processo de formao que ainda no trabalhou junto em outros projetos, requisitos volteis, baixo conhecimento do domnio de negocio pela equipe, adoo de novas tecnologias, novas ferramentas, mudanas muito bruscas e rpidas no ambiente de negcios das empresas: novos concorrentes, novos produtos, novos modelos de negcio. Sistemas de gerenciamento de projetos lineares e prescritivos, neste tipo de ambiente, falham em oferecer as caractersticas necessrias para responder de forma gil as mudanas requeridas. Sua adoo pode incrementar

desnecessariamente os riscos, o custo, o prazo e baixar a qualidade do produto gerado, desgastando a equipe e todos os envolvidos no processo. A abordagem Scrum, para gesto de projetos geis, leva em considerao planejamento no linear, porm de maneira mais exaustiva e est focada em agregar valor para o cliente e em gerenciar os riscos, fornecendo um ambiente seguro. Pode ser utilizada na gesto do projeto aliada a uma metodologia de desenvolvimento como Programao_Extrema, FDD, OpenUP, DSDM, Crystal ou outras.

3.1.1 Scrum um processo para construir software incrementalmente em ambientes complexos, onde os requisitos no so claros ou mudam com muita freqncia, A metodologia Scrum foi desenvolvida para a gesto dos processos de desenvolvimento de sistemas. uma abordagem emprica aplicando as idias tericas de controle do processo industrial no desenvolvimento de sistemas, resultando em uma abordagem que reintroduz as idias de flexibilidade, adaptabilidade e produtividade. Ela no define qualquer software especfico do desenvolvimento de tcnicas da fase de implementao. O Scrum concentra-se na forma como os membros da equipe devem se portar a fim de produzir o sistema de uma forma flexvel em um ambiente de constante mutao. (SCHWABER; BEEDLE, 2002 apud CHAGAS, 2008, p. 130). A idia principal que o desenvolvimento de sistemas envolve diversas variveis de ambiente e tcnicas requisitos, tempo, recursos, tecnologia que so

suscetveis a alteraes durante o processo. Isto faz com que o processo de desenvolvimento seja imprevisvel e complexo, fato que exige flexibilidade do processo para que o mesmo seja capaz de responder s mudanas com qualidade e rapidez. (ABRAHAMSSON, 2002 apud CHAGAS, 2008, p. 130). O Scrum ajuda a melhorar as atuais prticas de engenharia - testes - em uma organizao, pois envolvem gerenciamento freqentes de atividades com o intuito de verificar consistncias, identificar eventuais deficincias ou impedimentos no desenvolvimento do processo, bem como gerenciar as prticas que so utilizadas. (ABRAHAMSSON, 2002 apud CHAGAS, 2008, p. 130). Os valores do Scrum esto intimamente ligados aos valores descritos no manifesto gil. Esses foram descritos em um livro de autoria do criador dessa metodologia (SLIGER, 2007 apud CHAGAS, 2008, p.132) :

Compromisso: Esteja disposto a assumir o compromisso de uma meta. O Scrum fornece a toda pessoa autoridade necessria para cumprir os seus

compromissos.

Foco: Faa o seu trabalho. Centre todos os seus esforos e competncias em fazer o trabalho a que lhe foi empenhado. No se preocupe com nada alm disso.

Abertura: O Scrum mantm tudo sobre um projeto visvel para todos. Respeito: Os indivduos so moldados por seus antecedentes e as suas experincias. importante respeitar os diferentes povos que compem uma equipe.

Coragem: Tenha a coragem de se comprometer, de agir, de estar aberto e aguardar o respeito. O ciclo de vida do Scrum subdividido em trs fases principais. A Figura 01

representa esse ciclo.

Figura 01 - Ciclo de vida SCRUM. Fonte: Chagas (2008).

A primeira fase - Pre-game uma fase preliminar ao projeto. Fase em que o sistema planejado e decises sobre a concepo do software so tomadas. (SCHWABER; BEEDLE, 2002 apud CHAGAS, 2008, p. 133). O desenvolvimento - Mid-game ou development phase a parte gil de um processo Scrum. Essa fase guiada pelos Sprints. Os Sprints so ciclos iterativos onde funcionalidades so desenvolvidas ou aprimoradas para produzir novos acrscimos. Cada Sprint inclui fases tradicionais de desenvolvimento de software engenharia de requisitos, anlise, concepo, evoluo e fases de entrega -. Um Sprint pode durar de uma semana at um ms, sendo que os Sprints de um projeto devem seguir um padro em relao a seu tempo de durao. Vale lembrar que pode haver, por exemplo, de trs a oito sprints em um PDS antes de o sistema estar pronto para distribuio. A Figura 24 mostra o ciclo de um Sprint. (SCHWABER; BEEDLE, 2002 apud CHAGAS, 2008, p. 134).

Figura 02 - Ciclo de um Sprint. Fonte: Chagas (2008).

A Figura 02 mostra que um Sprint alimentado por duas sub-fases anteriores Product Backlog, Sprint Backlog -. Essas provm algumas listas de requisitos, definies e outros aspectos importantes a serem implementados no projeto. O ciclo de um Sprint repetido at que o desenvolvimento do produto esteja complete. E essa completude se faz presente quando as variveis de tempo, qualidade, competio e custo esto balanceados. Na fase de entrega/encerramento - Post-game o processo chega ao seu final. Ou seja, quando todas as variveis de ambiente esto em equilbrio e os requisitos iniciais foram alcanados o projeto est apto a ser entregue. (SCHWABER; BEEDLE, 2002 apud CHAGAS, 2008, p. 134).

3.1.2 Extreming programing (XP)Segundo Chagas (2008, p. 144), o XP uma metodologia gil para pequenas a mdias equipes de desenvolvimento em face a sua rpida evoluo. Essa metodologia composta por quatro partes: valores, princpios, atividades e prticas. A Figura 03 mostra como elas so construdas, com atividades que so executados atravs ou em torno de todo o ciclo de vida.

Figura 03 - Base do XP. Fonte: Chagas (2008).

O XP prope cinco valores para orientar o desenvolvimento (BECK; ANDRES, 2004 apud CHAGAS, 2008, p. 146) -: Comunicao; Simplicidade;

Feedback; Coragem; Respeito. Entretanto eles no so os nicos valores possveis para o efetivo desenvolvimento de software. Esses so os valores de conduo do XP. A organizao e a equipe podem escolher diferentes valores. O mais importante o alinhamento do comportamento da equipe com os valores da mesma. O feedback rpido significa que programadores utilizam loops de curtas iteraes para aprender rapidamente se os prazos e funcionalidades de seu produto vai de encontro as necessidades do cliente. (TELES, 2008 apud CHAGAS, 2008, p. 147). O segundo princpio que temos o de assumir a simplicidade. Este, por sua vez, leva a equipe de desenvolvimento a tratar cada problema como se ele pudesse ser resolvido simplesmente. Assumir simplicidade significa que os integrantes da equipe devem se preocupar somente com a iterao corrente do projeto, sem que haja preocupaes com elementos futuros. (TELES, 2008 apud CHAGAS, 2008, p. 147). Outro princpio to importante quanto os demais o de mudanas incrementais, ou seja, resolver problemas com uma srie de pequenas mudanas. Isso se aplica ao planejamento, desenvolvimento e concepo. (BECK; ANDRES, 2004 apud CHAGAS, 2008, p. 147) Estreitamente ligado ao principio de mudana incremental temos o de aceitar as mudanas. Que nada mais do que adotar uma estratgia que preserve o

desenvolvimento enquanto so resolvidos alguns problemas detectados. (TELES, 2008 apud CHAGAS, 2008, p. 147). E por ltimo temos a qualidade do trabalho que nunca pode ser comprometida. O XP enaltece a importncia do cdigo e seus respectivos testes. (BECK; ANDRES, 2004 apud CHAGAS, 2008, p. 147).

Ciclo de vida XP No XP a premissa fundamental que o cliente e o desenvolvedor devem trabalhar juntos para produzir um software que tem real valor. O cliente dirige a equipe de desenvolvimento sobre a forma de entregar os negcios de valor durante todo o ciclo de vida de um projeto XP. O cliente est envolvido ativamente durante a vida do projeto. A Figura 04 demonstra como o ciclo XP um processo contnuo de definio e construo de valor. (CHAGAS, 2008, p. 148)

Figura 04 - O ciclo XP um processo contnuo de definio e construo de valor. Fonte: Chagas (2008).

Todo desenvolvimento est delimitado em clientes definindo valores e desenvolvedores entregando-os. A diferena que no XP com este ciclo acontece muito rapidamente. A equipe est construindo um pequeno pedao de

funcionalidade a todo o momento. Isso permite que o cliente possa conduzir o projeto, com adaptaes e correes. (CHAGAS, 2008, p 148)

Figura 05 - Ciclo de vida XP. Fonte: Chagas (2008)

Existem algumas fases inerentes a um projeto XP. A primeira a de explorao (Exploration) que faz um projeto inicial, levantamento em alto nvel dos requisitos de usurios e prototipao tcnica. Nesta fase todos os requisitos so expressos como cenrios (chamados de histrias do usurio). A fase seguinte a de planejamento (Planning) que executa a priorizao do trabalho, repartio do mesmo em releases (lanamentos) e ainda prope um primeiro plano de trabalho. A terceira fase a das iteraes (Iterations), etapa tal responsvel pelo desenvolvimento e testes do sistema. Os usurios finais podem interferir refinando interfaces e assegurando a usabilidade do produto. A penltima fase a de implantao (Productionizing) que justamente implanta o software para o cliente em seu ambiente de produo. E por ltimo a fase de manuteno (Maintenance) que como o prprio nome diz responsvel por dar manuteno permanente, atualizaes e novas funcionalidades. (SIQUEIRA, 2003 apud CHAGAS, 2008, p. 150). Em linhas gerais, os projetos XP propem o planejamento como um processo evolutivo que refinado e sintonizado ao longo da vida do projeto. A figura 06 apresenta um ciclo de um release em extreme programming

Figura 06 - Ciclo de um release em XP.

3.1.3 CrystalO Crystal uma famlia de diferentes metodologias em que a mais apropriada pode ser escolhida de acordo com seu projeto. Os diferentes membros da famlia podem ser adaptados para caber em variveis circunstanciais. (RUSK, 2006 apud CHAGAS, 2008, p. 96). O ncleo da filosofia Crystal pode ser visto em alguns conceitos: Desenvolvimento de software freqentemente visto como um jogo cooperativo de inveno e de comunicao, com o objetivo primordial de entregar algo til, software funcionando, e em segundo plano fixar uma meta de criao para o prximo jogo. (COCKBURN, 2001 apud CHAGAS, 2008, p. 96). Duas conseqncias dessa filosofia so que diferentes projetos precisam ser executados de maneira diferente, e que os montantes de modelagem e de comunicao que as pessoas precisam fazer devem ser feitos sob medida, ou seja, apenas a quantidade de que necessitam para conjuntamente movam o jogo a frente. (COCKBURN, 2001 apud CHAGAS, 2008, p. 96). Os membros da famlia Crystal so indexados por diferentes cores para indicar seu "peso" heaviness -, algumas cores utilizadas so: Claro - Clear; Amarelo - Yellow; Alaranjado - Orange; Vermelho - Red; Magenta; Azul - Blue; Violeta Violeta. (CHAGAS, 2008, p. 96). Quanto mais s cores ficam escuras, mais pesada a metodologia. Isso porque um processo com mais de cem pessoas necessita de metodologias mais robustas do que um com somente alguns membros. Um exemplo que pode

demonstrar extremos, porm descreve a realidade. (BASSI FILHO, 2008 apud CHAGAS, 2008, p. 96).

A equipe pode diminuir trabalhos intermedirios produzindo, com mais freqncia, cdigos executveis, bem como otimizar os canais de comunicao entre as pessoas. (COCKBURN, 2001 apud CHAGAS, 2008, p. 97). Segundo Chagas (2008, p. 98), como cada projeto diferente e evolui ao longo do tempo, o conjunto de convenes que a equipe adota tambm deve ser moldado e evolutivo. As duas regras mais comuns para a famlia Crystal so:

O projeto deve usar um desenvolvimento incremental, com incrementos de quatro meses ou menos (com forte preferncia para incrementos de um a trs meses); (PENTEADO, 2006 apud CHAGAS, 2008, p. 98);

A equipe deve possuir oficinas para reflexo no pr e ps-incremento (com preferncia para a realizao tambm em meados do incremento). (PENTEADO, 2006 apud CHAGAS, 2008, p. 98). As duas tcnicas bsicas no Crystal so:

A metodologia de sintonizao tcnica (methodology tuning technique): utilizando entrevistas no projeto e oficinas (workshops) em equipes para converter uma metodologia base em uma metodologia de inicio para o projeto; (COCKBURN, 2001 apud CHAGAS, 2008, p. 98);

A tcnica usada para estudar reflexes de uma oficina. (COCKBURN, 2001 apud CHAGAS, 2008, p. 98); A famlia Crystal segue, com pequenas diferenas, um ciclo de vida padro

em todas as suas metodologias. A Figura 07 mostra esse ciclo em detalhes.

Figura 07- Ciclo de vida Crystal. Fonte: Chagas (2008)

As fases dos processos Crystal, seguindo o padro de seu ciclo de vida, so equivalentes e com pequenos incrementos entre metodologias mais leves e as com maior robustez. Seguindo a apresentao do ciclo de vida Crystal Figura 07 podemos analisar as seguintes fases dessa famlia de desenvolvimento Penteado (2006) e Cockburn (2001) apud Chagas ( 2008, p. 100) :

Staging (Preparao): Contempla etapas como o planejamento do prximo incremento do sistema, seleo de requisitos a serem implantados na iterao e por fim o agendamento para sua entrega.

Policy Standards (Caractersticas aplicadas): acepo de regras e prticas para adoo de padres.

Standards (Padres): definio de padres desde simples notaes at contratos (acordos) de um produto.

Roles (Regras): regras bem definidas para execuo de um incremento. Local matters (Matria local): considera alguns artifcios a serem empregados na iterao sendo que os mesmos se alteram de acordo com a metodologia utilizada. Alguns exemplos so os casos de uso e descries de funcionalidades

no caso do Crystal Clear e a anlise da documentao de requisitos no Crystal Orange.

Tools (Ferramentas): descrio das ferramentas que a equipe far uso durante a iterao. Quanto mais robusta a metodologia maior a utilizao de ferramentas auxiliares aos desenvolvedores.

Work Products (Produtos do trabalho): essa parte do processo cuida de alguns produtos decorrentes do desenvolvimento tais como: manuais, casos de testes entre outros.

Activities

(Atividades):

cuida

de

algumas

atividades

bsicas

em

que

desenvolvedores devem se preocupar ao longo da iterao.

Parallelism and flux (Paralelismo e fluxo): verifica e prope operaes em paralelismo, monitorando estabilidade e sincronizao entre equipes caso a equipe no seja nica -.

Monitoring of progress (Monitoramento de progresso): executa medies na estabilidade da(s) equipe(s) a partir de marcos e ou estgios de estabilidade.

Construction, Demonstration, Review (Construo, demonstrao, reviso): construo, demonstrao e reviso em todos os aspectos referentes ao incremento;

User usable release (Utilizao por parte dos usurios): sugere a iterao com o usurio. Fase tal realizada frequentemente.

3.1.4 Adaptive Soft Developmet - ADSJames Highsmith, o autor do Adaptive Software Development, ao criar essa nova metodologia possua em mente no s apoiar uma mudana no processo de desenvolvimento, mas tambm no ciclo de vida do mesmo. O desenvolvimento adaptvel de software foca-se em preparar organizaes para um mundo onde requisitos mudam e a flexibilidade uma necessidade. O processo e a estrutura da organizao propriamente dita devem ser suficientemente flexveis para se adaptar mudana das direes que a evoluo de um produto de software pode acarretar. (WILLIAMS, 2004 apud CHAGAS, 2008,p. 65).

O ciclo de vida, dinmico, apresentado no ASD segue as seguintes fases: especular, colaborar, aprender. A Figura 8 descreve o diagrama bsico do ASD.

Figura 8 - Ciclo de vida ASD. Fonte: Chagas (2008).

As fases do desenvolvimento dessa metodologia sero apresentadas de acordo com conceitos de Highsmith(1997) e Highsmith (2002) apud Chagas (2008, p. 68). A primeira fase do ASD a de especular que nada mais do que a iniciao e planejamento de ciclos. H cinco etapas, em geral na "especulao", embora a palavra "etapas" algo citado de forma inadequada, j que cada uma delas pode ser revista vrias vezes durante a iniciao e a fase de planejamento. A iniciao do projeto consiste em: Fixar misso e objetivos; Compreenso de constantes; Estabelecer a organizao projeto; Identificar e definir exigncias; Prever estimativas iniciais e futuras em relao ao escopo; Identificar os riscos chave do projeto. A segunda fase a de colaborao: desenvolvimento simultneo de caractersticas. Enquanto a equipe tcnica proporciona desenvolve o software, gestores de projetos facilitam a colaborao e desenvolvimento simultneo de atividades. Para projetos envolvendo equipes distribudas, com parcerias, e conhecimentos de base ampla, a forma como as pessoas interagem e como elas gerenciam suas

interdependncias so questes vitais. Para projetos menores nos quais membros da equipa trabalham fisicamente perto, a colaborao poder consistir em conversas informais e rabiscos. Todavia em projeto maiores so exigidas prticas adicionais, ferramentas de colaborao, e iteraes do gerente de projeto A colaborao - um ato de criao compartilhada - promovida pela confiana e respeito. Essa engloba a equipe de desenvolvimento, clientes, consultores externos e at mesmo vendedores. As equipes devem se ajudar com problemas de ordem tcnica, necessidades empresariais, e tomada rpida de decises. A terceira e a ltima fase do ciclo a de aprender: reviso de qualidade. A aprendizagem se torna cada vez mais difcil em ambientes no qual o princpio "faa certo na primeira vez" domina. Se as pessoas esto continuamente obrigadas a fazer tudo corretamente, elas no vo experimentar e aprender. No desenvolvimento em cascata, cada fase concluda desestimula o retorno a fases anteriores porque no deve haver quaisquer erros. Aprender com os erros e experimentao exige que os membros da equipe compartilhem o mais cedo possvel - partes parciais do cdigo e artefatos, a fim de encontrar falhas, aprender com elas, e reduzir o retrabalho - encontrando-se pequenos problemas antes que eles se tornem grandes -. As equipes tm de entender a diferenciao entre trabalhos feitos as coxas e trabalhos inacabados.

3.1.5 Feature Driven Development - FDDO FDD - Feature Driven Development - uma metodologia gil de desenvolvimento de software desenvolvida por Jeff De Luca e Peter Code. Esta metodologia teve seu nome reconhecido em 1997. Bem como seu nome propre, o FDD uma metodologia (framework) de desenvolvimento de sistemas guiada a partir de features - caractersticas-. Os seguidores do FDD discutem acerca dessa metodologia e processos inseridos na mesma em sua comunidade47 oficial na web. (KHRAMTCHENKO, 2004 apud CHAGAS, 2008, p. 107).

O FDD constitudo por duas fases principais: Descobrir uma lista de caractersticas (features) para implementar; caracterstica (CHAGAS, 2008, p. 107). O ciclo de vida dessa metodologia consiste em processos seqenciais, a Figura 09 demonstra essas fases. Desenvolver caractersticas por

Figura 09 - Ciclo de vida FDD. Fonte: Chagas (2008)

As duas ltimas etapas so consideradas a parte de construo doFDD, sendo que so representadas pelo diagrama descrito na Figura 10.

Figura 10 - Parte de construo do ciclo de vida FDD. Fonte: Chagas (2008)

A Figura 10 nos mostra diversos sub-processos envolvidos no design e construo das features de um processo. Fatores tais fazem parte de qualquer fluxo bsico de um desenvolvimento de sistemas. O FDD composto de cinco fases seqenciais em seu desenvolvimento, so elas: Desenvolver um modelo geral (Develop an overall model); Construir uma lista de funcionalidades (Build a features list); Planejar por funcionalidade (Plan By

Feature);

Projetar

por

funcionalidade

(Design

by

feature);

Construir

por

funcionalidade (Build by feature). (CHAGAS, 2008, p. 110) No desenvolvimento de um modelo geral, bem como as primeiras fases de um desenvolvimento, ocorrem as definies de domnio, alguns requisitos, e a especificao de algumas features desejadas. (HIGHSMITH, 2002 apud CHAGAS, 2008, p. 111). As demais fases consistem, respectivamente, em criar uma lista de caractersticas com suas devidas prioridades, planejar o desenvolvimento a partir do material gerado e posteriormente projet-lo e desenvolv-lo. (HIGHSMITH, 2002 apud CHAGAS, 2008, p. 111).

3.2 MODELOS EVOLUCIONRIOS 3.2.1 ESPIRALEste modelo de projeto define uma srie de pequenos ciclos, em que cada um ao ser finalizado gera uma release executvel. Proposto por Boehm em 1988, o modelo espiral foi reconhecido como uma forma de integrar diversos modelos existentes na poca, e possua a finalidade de eliminar as dificuldades desse modelos explorando cada um dos seus pontos fortes. (TANAKA, 2009, p. 114) O modelo do ciclo de vida em espiral foi desenvolvido para abranger as melhores caractersticas tanto do ciclo de vida em cascata como da prototipao, acrescentando simultaneamente um novo elemento chamado anlise de riscos, que no era encontrado nos outros dois paradigmas. (TANAKA, 2009, p. 114) O modelo espiral permite que o desenvolvimento do projeto seja realizado paralelamente de mltiplas partes do projeto, cada uma sendo abordada de maneira diferenciada, sendo que, para isso necessrio que tcnicas especficas para estimar e sincronizar cronogramas sejam utilizadas, para que sejam determinados os indicadores de custo e progresso mais adequados. (TANAKA, 2009, p. 115). O ciclo de vida espiral representado pela figura 11 abaixo:

Figura 11 - Ciclo de vida Espiral.

Um ciclo se inicia com a tarefa Determinao de objetivos, alternativas e restries, cujo objetivos so o comprometimento dos envolvidos e estabelecimento de uma estratgia para alcanar os objetivos da fase que se inicia, buscando levantar as tarefas requeridas para estabelecer uma efetiva comunicao entre desenvolvedor e cliente, bem como execuo de um planejamento das tarefas requeridas para definio de recursos, referencias de tempo e outras informaes de projeto. Na segunda tarefa, Avaliao de alternativas, identificao e soluo de riscos, executa-se uma anlise de risco, sendo os prottipos uma forma de avaliar riscos. Os objetivos principais desta etapa so a deteco de riscos, avaliao de solues que ofeream menor risco de implementao, e execuo de atividades para reduzir os ricos principais. Se o risco for considerado inaceitvel, o projeto pode ser encerrado. A terceira tarefa ocorre com o desenvolvimento do produto. Deve ser escolhido um modelo de desenvolvimento de software especfico, com objetivo de

definir e validar os requisitos, projetar o software, projetar a validao e verificao, codificar, realizar testes (integrao, unidade, aceitao) Na quarta tarefa o produto avaliado e se prepara para iniciar um novo ciclo. O projeto revisado e a prxima fase da espiral planejada. Seus objetivos so o planejamento dos requisitos, ciclo de vida, desenvolvimento, integrao e testes.

3.2.2 DESENVOLVIMENTO INCREMENTALO modelo incremental combina elementos do modelo cascata sendo aplicado de maneira interativa. O modelo de processo incremental interativo igual prototipagem, mas diferentemente da prototipagem o incremental tem como objetivo apresentar um produto operacional a cada incremento realizado. Os ciclos de cada iterao so apresentados na Figura 12 que sero repetidos at que o produto completo seja produzido.

Figura 12 - Ciclo de vida Desenvolvimento Incremental.

3.2.3 DESENVOLVIMENTO EVOLUCIONRIOO modelo evolutivo descreve um processo na qual o software deve ser desenvolvido de forma a evoluir a partir de prottipos iniciais.

Tem como idia o desenvolvimento da verso inicial que exposta aos comentrios do usurio e a partir destes desenvolvido uma verso intermediria que exposta aos comentrios do usurio e assim sucessivamente (gera vrias verses) at que um sistema adequado tenha sido desenvolvido Existem dois tipos de desenvolvimento evolucionrio: o desenvolvimento exploratrio com o objetivo trabalhar com clientes e evoluir o sistema final de um esboo de especificao inicial; e a Preparao de prottipos descartveis objetivando entender os requisitos do sistema. Deve comear com requisitos pobremente entendidos

Figura 13 - Ciclo de vida Desenvolvimento Evolucionrio.

3.2.4 RUPRational Unified Process, ou RUP, uma metodologia de projecto de software criada pela Rational Software Corporation. RUP descreve como desenvolver software usando tcnicas testadas e aprovadas comercialmente. O RUP est fundamentado em trs princpios bsicos: orientao a casos de uso, arquitetura e iterao. Ele dito dirigido a casos de uso, pois so os casos de uso que orientam todo o processo de desenvolvimento. Com base no modelo de casos de uso, so criados uma srie de modelos de anlise, projeto e implementao, que realizam estes casos de uso. centrado em arquitetura, pois defende a definio de um esqueleto para a aplicao (a arquitetura), a ganhar

corpo gradualmente ao longo do desenvolvimento. Finalmente, o RUP iterativo e incremental, oferecendo uma abordagem para particionar o trabalho em pores menores ou mini-projetos. Esses trs conceitos so igualmente importantes. A arquitetura prov a estrutura para guiar o desenvolvimento do sistema em iteraes, enquanto os casos de uso definem as metas e conduzem o trabalho de cada iterao O ciclo de vida adotado no RUP tipicamente evolutivo. Contudo, uma forma de organizao em fases adotada para comportar os ciclos de desenvolvimento, permitindo uma gerncia mais efetiva de projetos complexos. Ao contrrio do tradicionalmente definido como fases na maioria dos modelos de ciclo de vida planejamento, levantamento de requisitos, anlise, projeto, implementao e testes, so definidas fases ortogonais a estas, a saber:

Figura 14 - Ciclo de vida RUP.

Concepo ou Iniciao: nesta fase, estabelecido o escopo do projeto e suas fronteiras, determinando os principais casos de uso do sistema. Esses casos de uso devem ser elaborados com a preciso necessria para se proceder estimativas de prazos e custos. As estimativas devem ser globais para o projeto como um todo e detalhadas para a fase seguinte. Assim, a nfase nesta etapa recai

sobre o planejamento e, por conseguinte, necessrio levantar requisitos do sistema e preliminarmente analislos. Ao trmino dessa fase, so examinados os objetivos do projeto para se decidirsobre a continuidade do desenvolvimento. Elaborao: a fase de preparao do projeto, o marco dessa fase a finalizao da arquitetura do projeto, assim como o domnio do problema do sistema, decidindo quais frameworks, linguagens de programao entre outros sero utilizados. Construo: a fase de desenvolvimento do projeto (no especificamente, pois, na fase de iniciao e elaborao os prottipos do sistema devem ser elaborados, de preferncia, na linguagem de programao que o sistema ser desenvolvido), o marco dessa fase a entrega de releases estveis para teste e validao. Transio: Ocorre aps o ltimo ciclo iterativo. Nesta fase, o software disponibilizado comunidade usuria. Aps o produto ter sido colocado em uso, naturalmente surgem novas consideraes que vo demandar a construo de novas verses para permitir ajustes do sistema, corrigir problemas ou concluir algumas caractersticas que foram postergadas. importante realar que dentro de cada fase, um conjunto de iteraes, envolvendo planejamento, levantamento de requisitos, anlise, projeto e implementao e testes, realizado. Contudo, de uma iterao para outra e de uma fase para a prxima, a nfase sobre as vrias atividades muda, como mostra a figura 1, em que a cor preta indica grande nfase, enquanto a cor branca indica muito pouca nfase. Na fase de concepo, o foco principal recai sobre o entendimento dos requisitos e a determinao do escopo do projeto (planejamento e levantamento de requisitos). Na fase de elaborao, o enfoque est na captura e modelagem dos requisitos (levantamento de requisitos e anlise), ainda que algum trabalho de projeto e implementao seja realizado para prototipar a arquitetura, evitando certos riscos tcnicos. Na fase de construo, o enfoque concentra-se no projeto e na implementao, visando evoluir e rechear o prottipo inicial, at obter o primeiro produto operacional. Finalmente, a fase de transio concentra-se nos testes, visando garantir que o sistema possui o nvel adequado de qualidade. Alm disso, usurios devem ser treinados, caractersticas ajustadas e elementos esquecidos adicionados.

4

REFERNCIAS BIBLIOGRFICAS

CHAGAS, Marcos Vinicius Lemos. Processo de desenvolvimento de software: O estado da arte. Londrina: Trabalho de Concluso de Curso; Universidade Estadual de Londrina, 2008 PERINI, Luis Cludio; HISATOMI, Marco Ikuro; BERTO, Wagner Luiz. Engenharia de Software. . So Paulo: Pearson Prentice Hall, 2009. SOMMERVILLE, Ian. Engenharia de Software, Traduo: Selma Shin Shimizu Melnikoff, Regional Arakaki, Edlson de Andrade Barbosa. 8 Ed. So Paulo: Pearson Addison, 2007 TANAKA, Simone Sawasaki. Anlise de Sistemas I. So Paulo: Pearson Prentice Hall, 2009.