Professional Documents
Culture Documents
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
SUMRIO
1 2 ELABORAO DE DOCUMENTAO DE CASO DE USO ................................ 4 CONCEITOS DA TCNICA DE MODELAGEM ENTIDADE RELACIONAMENTO .............................................................................................................................. 5 3 MODELOS GEIS E MODELOS EVOLUCIONRIOS......................................... 7
3.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
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
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.
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
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).
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).
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)
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
3.1.3 Crystal
O 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
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
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
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.
O ciclo de vida, dinmico, apresentado no ASD segue as seguintes fases: especular, colaborar, aprender. A Figura 8 descreve o diagrama bsico do ASD.
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.
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
As duas ltimas etapas so consideradas a parte de construo doFDD, sendo que so representadas pelo diagrama descrito na Figura 10.
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).
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.
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
3.2.4 RUP
Rational 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:
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.
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.