SISTEMA DE ENSINO PRESENCIAL CONECTADO CURSO SUPERIOR DE TECNOLOGIA EM ANLISE E DESENVOLVIMENTO DE SISTEMA ANDERSON ROBERTO GENTILIN ADO

PRODUO TEXTUAL INTERDICIPLINARDependencia 2 Semestre

Goinia 2011

ANDERSON ROBERTO GENTILIN ADO

PRODUO TEXTUAL INTERDICIPLINARDependencia 2 Semestre

Trabalho apresentado a disciplina de dependncia do 2 semestre, do Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistema da Universidade Norte do Paran UNOPAR Prof. Polyanna Gomes, Roberto Y. Nishimura, Luis Claudio Perini, Anderson Gonalves.

Goinia 2011

SUMRIO 1 2 2.1 2.2 2.3 3 3.1 3.2 3.3 3.4 4 4.1 4.2 4.3 4.3.1 4.3.2 4.4 4.5 4.5.1 4.5.2 5 5.1 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 6 INTRODUO ..................................................................................................... 3 TIPOS DE METODOLOGIAS DE PROJETO....................................................... 4 Metodologias Iterativas ..................................................................................... 4 Metodologias geis .......................................................................................... 4 Contrastes de Metodologias Iterativas e geis ................................................. 4 METODOLOGIAS DE DESENVOLVIMENTO ..................................................... 5 Rational Unified Process .................................................................................. 5 Extreme Programming ...................................................................................... 6 Atividades e Papis .......................................................................................... 8 Anlise Crtica dos trabalhos relacionados ..................................................... 10 PROPOSTA DE DESENVOLVIMENTO DE SOFTWARE ................................. 11 Metodologia Evolucionria.............................................................................. 11 Metodologia Agil ............................................................................................. 11 Verificar os requisitos, separando em requisitos funcionais e no funcionais 12 Funcionais ................................................................................................... 12 No funcionais ............................................................................................ 12 A partir dos requisitos, elaborar o diagrama de Caso de Uso na ferramenta Efetuar a modelagem entidade relacionamento (conceitual e lgica) do banco Modelo Conceitual ...................................................................................... 14 Modelo Logico ............................................................................................. 15

Astah (Jude). ............................................................................................................. 13 de dados no BrModelo .............................................................................................. 14

ELABARAR PROTTIPOS DAS TELAS DE ACORDO COM O ESTUDO DE CLASSES ....................................................................................................... 16 Pessoas.cs .................................................................................................. 16 Professor.cs ................................................................................................ 17 Disciplina.cs ................................................................................................ 18 Curso.cs ...................................................................................................... 19 Turma.cs ..................................................................................................... 20

CASO, UTILIZANDO EM C# ..................................................................................... 16

CONCLUSO .................................................................................................... 21

REFERNCIAS ......................................................................................................... 22

3

1 INTRODUO Nos ltimos anos, vem crescendo rapidamente o interesse em metodologias geis (ou "leves"). Tambm caracterizadas como um antdoto contra a burocracia, estas metodologias despertaram o interesse em toda a extenso da indstria do software. Neste artigo, eu exploro os motivos para as metodologias geis, focando no tanto em sua leveza, mas sim em sua natureza adaptvel e na sua tendncia em colocar as pessoas em primeiro lugar. Eu tambm apresento um sumrio e referncias aos processos nesta linha de pensamento ainda considero os fatores que deveriam influenciar sua deciso sobre trilhar ou no este novo caminho. O sucesso de um projeto de desenvolvimento de software comea no devido planejamento e na escolha de uma metodologia compatvel com as caractersticas do mesmo. A etapa do planejamento deve estruturar o processo de desenvolvimento em torno dos recursos disponveis (i.e. oramento, fora de trabalho, tempo) visando entrega de um produto de qualidade que atenda s necessidades do cliente dentro do prazo previsto. A metodologia tradicional de desenvolvimento, em cascata (waterfall), consiste em etapas que so seguidas estritamente de forma seqencial: o produto de cada etapa tomado como base para o incio da prxima. Esta metodologia implica que um enorme esforo deve ser empregado nas fases de levantamento de requerimentos e de desenho da arquitetura. Se durante uma das fases finais do projeto (i.e. implementao, testes) for localizado uma falha, ou mesmo ocorrer uma alterao de requisitos, o projeto pode sofrer enormes (e dispendiosas) alteraes. Tanto o Rational Unified Process (RUP) quanto o Extreme Programming (XP) so metodologias que dividem o desenvolvimento de um projeto em ciclos, visando reduo de riscos (e custos) nos casos de alteraes de requisitos ou funcionalidades. O presente trabalho tem o propsito de analisar as similaridades e diferenas presentes nas metodologias empregadas pelos processos RUP e XP.

4

2 TIPOS DE METODOLOGIAS DE PROJETO

2.1 METODOLOGIAS ITERATIVAS Metodologias iterativas tm como objetivo o desenvolvimento de projetos de forma incremental. A cada iterao uma parte do sistema desenvolvida, sendo o produto de cada nova iterao superior da iterao anterior. Desenvolver um sistema de forma incremental traz vantagens ao projeto. Ao se construir gradualmente o sistema, os prprios desenvolvedores aprendem sobre o mesmo, possibilitando a localizao de futuros problemas em fases iniciais. Outra vantagem de se construir um sistema gradualmente a inata acomodao para mudanas, dado que o todo no desenvolvido em apenas uma etapa. 2.2 METODOLOGIAS GEIS Metodologias geis tambm dividem o desenvolvimento do software em iteraes, buscando reduo de riscos ao projeto. Ao final de cada iterao, uma verso (release) funcional do produto, embora restrita em funcionalidades, liberada ao cliente. As metodologias geis destacam aspectos humanos no desenvolvimento do projeto, promovendo interao na equipe de desenvolvimento e o relacionamento de cooperao com o cliente. Comunicao face-a-face preferida documentao compreensiva. 2.3 CONTRASTES DE METODOLOGIAS ITERATIVAS E GEIS As metodologias geis compartilham as idias de construo incremental de sistemas provenientes das metodologias iterativas, porm os perodos das iteraes so geralmente menores, medidos em semanas, enquanto iteraes de processos iterativos so geralmente medidos em meses.

5

3 METODOLOGIAS DE DESENVOLVIMENTO

3.1 RATIONAL UNIFIED PROCESS RUP uma metodologia iterativa de desenvolvimento. RUP adaptvel, podendo ser customizada para diversos tipos e tamanhos de produtos e projetos de software. A Rational Software (atual diviso da IBM) desenvolveu e mantm o RUP. A metodologia RUP identifica cada ciclo de desenvolvimento do projeto em quatro fases, cada uma com respectivos marcos de finalizao definidos (chamados milestones). Os milestones so os indicadores de progresso do projeto, e so usados como base para decises para continuar, abortar, ou mudar o rumo do projeto. As fases do RUP so: a) Incio (Inception): determinao do escopo do desenvolvimento, sendo levantado uma viso do produto final a partir de um caso de uso (bsico) definido. b) Elaborao (Elaboration): planejamento de atividades e recursos necessrios, onde so definidas funcionalidades e a arquitetura a ser desenvolvida. c) Construo (Construction): implementao do software, contruo do cdigo. Em projetos grandes esta fase pode ser segmentada em vrias iteraes, visando diviso em partes menores e mais facilmente gerenciadas. d) Transio (Transition): o produto passado aos usurios. Nesta fase ocorre treinamento dos usurios (e possveis mantenedores) e a avaliao do produto (beta-testing).

6

Figura 1. Fases do RUP - Adaptado de [Luiz 2005] A Figura 1 apresenta a arquitetura de projetos que seguem a metodologia RUP. O eixo horizontal define aspectos dinmicos, como ciclos, fases, iteraes e marcos (milestones), j a vertical define os aspectos estticos, como atividades, disciplinas, artefatos e papis.

3.2 EXTREME PROGRAMMING XP uma metodologia gil, para o desenvolvimento de projetos de IT cujas especificaes so passveis a alteraes. As iteraes do XP costumam ser curtas, provendo constantes verses do produto (releases) para o cliente, que por sua vez prov comentrios e opinies que realimentam a prxima iterao. O objetivo do XP tornar o projeto flexvel, diminuindo o custo a possveis mudanas. O cdigo produzido tomado como indicador de progresso do projeto. O ciclo XP dividido em seis fases: a) Explorao: nessa fase o cliente escreve cartes de estrias, cada um contendo uma funcionalidade desejada para o primeiro release. b) Planejamento: ocorre definio de prioridades entre as estrias junto com o cliente. Nesta etapa os programadores estimam o

7

esforo e o cronograma para cada uma das estrias. c) Iteraes para Release: nessa fase ocorrem diversas iteraes at o primeiro release ser completado. Na primeira iterao criado o sistema com toda a arquitetura, nas iteraes seguintes sero adicionadas s funcionalidades de acordo com as prioridades estabelecidas. d) Validao para Produo (Productionizing): nessa fase so feitos testes extensivos e verificaes para validao do software para ser utilizado em ambientes de produo. e) Manuteno: aps o primeiro release para produo, h novas edies do sistema com novas funcionalidades. f) Morte: quando no h mais estrias a serem implementadas, quando o cliente est satisfeito com o cdigo.

Figure 2. Fases do XP Adaptado de [Abrahamsson et al 2002]

Os valores do XP so: simplicidade, coragem, feedback, e comunicao.

8

3.3 ATIVIDADES E PAPIS RUP define uma atividade como sendo o trabalho realizado por um papel, usando artefatos de entrada e produzindo artefatos de sada. Os papis (total de 30) definem o comportamento e as responsabilidades do individuo, esto agrupados em nove disciplinas: a) Gerncia de Projeto (2 papis): tem como objetivo prover meios para a entrega do produto para o cliente que atenda as suas necessidades, gerenciando os riscos do projeto. b) Modelamento de Negcio (3 papis): visa o entendimento da estrutura onde o software ser aplicado e os problemas atuais do cliente. Esta atividade debe assegurar que o cliente, os seus usurios e os desenvolvedores tenham um entendimento comum do produto a ser entregue. c) Requerimentos (5 papis): traduz as necessidades do sistema em forma de casos de uso, desenhando a interface com o usurio. d) Analise e Desenho (6 papis): especifica a forma de implementao (arquitetura) dos requerimentos (casos de uso). e) Implementao (3 papis): implementa as classes e os objetos em formas de componentes, os quais so individualmente testados. f) Teste (2 papis): testa e verifica se o produto funciona como o esperado, documentando falhas e problemas. Prov feedback gerncia do projeto sobre a qualidade do software. g) Deployment (4 papis): tem como objetivo a distruibuio, instalao e teste (quando beta) em campo, provendo treinamento e possveis migraes (banco de dados) entre o sistema anterior e o atual. h) Configurao e Controle de Mudanas (2 papis): o objetivo destas atividades (Gerncia de Configurao e Controle de Mudanas) concentra-se na garantia da rastreabilidade de verses dentro de um projeto. Atravs do definio de uma poltica adequada e de ferramentas especficas para

9

versionamento (ClearCase, CVS, SVN) possvel garantir o mapeamento de alteraes efetuadas bem como a recuperao de cdigos e verses antigas. i) Ambiente (3 papis): prov suporte adequado organizao do projeto, em ferramentas, mtodos e processos. XP [Beck e Fowler 2000] apresenta apenas quatro atividades bsicas: produo de cdigo, testes, listening (escutar o cliente), e desenho. XP define sete papis: a) Programador: escreve o cdigo e realiza testes individuais. b) Cliente: o responsvel por escrever as estrias e as prioridades das mesmas. c) Testador: tem como objetivo auxiliar o cliente a criar testes funcionais. Os testes devem ser realizados regularmente e seus resultados divulgados. d) Tracker: prov feedback no processo, comparando as estimativas com os resultados obtidos. Analisa o progresso de cada iterao e avalia se os objetivos podem ser alcanados com os recursos providos. e) Tcnico (Coach): tem como responsabilidade o projeto como um todo, guiando os outros membros da equipe. f) Consultor: membro externo que auxilia o time com assuntos (problemas) tcnicos especficos. g) Big Boss: responsvel pelo projeto, toma decises e est em constante comunicao com a equipe para diagnosticar possveis problemas ou falhas no processo. Ao compararmos as definies das atividades (disciplinas) e os papis, temos que o RUP faz uma diviso de tarefas de forma especfica, enquanto a diviso de papis proposta pelo XP tem um carter de uso-geral, sem atribuies especficas dentro das atividades.

10

3.4 ANLISE CRTICA DOS TRABALHOS RELACIONADOS Um estudo interessante encontrado foi o de Petersen e Wohlin (2010) em que avaliam os impactos da migrao de uma abordagem de desenvolvimento orientada ao planejamento para uma abordagem gil, com base em estudos e entrevistas na indstria, em projetos de pequeno porte. Os autores classificam o RUP, como metodologia orientada ao planejamento, da mesma forma que classificam Waterfall e Modelo-V, na qual as funcionalidades desejadas devem ser conhecidas de antemo, e um plano construdo e seguido at o final.

11

4 PROPOSTA DE DESENVOLVIMENTO DE SOFTWARE

4.1 METODOLOGIA EVOLUCIONRIA Segue proposta de desenvolvimento ser no modelo de

Prototipao. Onde vamos coletar os requisitos do sistema, construir um proptotipo do sistema, levar para avaliao do cliente, depois refinar emplementando e acomondando suas solicitao. Ciclo de vida do projeto: Inicio Fim Coleta e refinamento dos requisitos Construcao do prototipo Apresentacao para avalicao do prottipo no cliente Refinamento do prottipo Engenharia do produto Entrega do sistema para o cliente.

4.2 METODOLOGIA AGIL Proposta de desenvolvimento ser no modelo de RUP. Vamos passar por quatro fases. Concepcao, elaborao, desenvolvimento e transio. Ciclos de vida Inicio Fim Comunicacao com o cliente Planejamento Analise de risco Engenharia, Construcao Liberacao

12

4.3

VERIFICAR

OS

REQUISITOS,

SEPARANDO

EM

REQUISITOS

FUNCIONAIS E NO FUNCIONAIS

4.3.1 Funcionais O sistema devera conter os seguintes mdulos: Gesto de Matrcula Gesto de Aluno Gesto de funcionrios Gesto Cursos Gesto Turmas Gesto Professor Gesto Semestre Gesto Disciplina

4.3.2 No funcionais Sistema deve ser controlado por senhas. Banco de dados ser oracle. Rede ser em Windows Server 2008. Sistema ser desenvolvido em C#. Sistema devera ter manual de instrues. O sistema deve prever que deficientes visuais vo usar o sistema.

13

4.4 A PARTIR DOS REQUISITOS, ELABORAR O DIAGRAMA DE CASO DE USO NA FERRAMENTA ASTAH (JUDE).

Figure 3. Diagrama de Caso de Uso Ferramenta de UseCase Astah (Jude)

14

4.5 EFETUAR A MODELAGEM ENTIDADE RELACIONAMENTO (CONCEITUAL E LGICA) DO BANCO DE DADOS NO BRMODELO

4.5.1 Modelo Conceitual

Figure 4. Modelo Conceitual Ferramenta de Modelagem BRmodelo

15

4.5.2 Modelo Logico

Figure 5. Modelo Conceitual Ferramenta de Modelagem BRmodelo

16

5 ELABORAR PROTTIPOS DAS TELAS DE ACORDO COM O ESTUDO DE CASO, UTILIZANDO EM C#.

5.1 CLASSES

5.1.1 Pessoas.cs

Figura 6 Classe - Pessoa

17

5.1.2 Professor.cs

Figura 7 Classe - Professor

18

5.1.3 Disciplina.cs

Figura 8 Classe - Disciplina

19

5.1.4 Curso.cs

Figura 9 Classe - Curso

20

5.1.5 Turma.cs

Figura 10 Classe - Turma

21

6 CONCLUSO As principais dificuldades encontradas ao longo do desenvolvimento deste trabalho a falda de conhecimento da ferramenta Rational Rose e da metodologia UML e a inexperincia na utilizao dos conceitos da Anlise Orientada a Objetos, diferentes da Anlise Estruturada. Esta modelagem vem a atender todos os requisitos solicitados pelos usurios e soluciona todos os pontos crticos levantados no sistema atual. Assim, o objetivo inicial do trabalho foi totalmente cumprido. Podemos concluir que a utilizao de uma metodologia orientada a objetos, como UML, muito colabora ao longo da anlise e modelagem de um sistema, esclarecendo os processos de trabalho, o que facilita e agiliza a implementao do sistema, facilitando o contato com o usurio.

22

REFERNCIAS Pollice, G. (2003) "Using the IBM Rational Unified Process for Small Projects: Expanding Upon eXtreme Programming", IBM whitepaper, ftp://ftp.software.ibm.com/software/rational/web/whitepapers/2003/TP183.pdf, Abril. Runeson, P. and Greberg, P. (2004) "Extreme Programming and Rational Unified Process Contrasts or Synonyms?", Lund University, Sweden. BOOCH, G. Object-oriented analysis and design with applications. 2ed. California: Addison-Wesley, 1994. 589p. COAD, P.; YOURDON, E. Object-oriented analysis. New Jersey: Prentice Hall, 1990. 233p. DEBONI, J.E.Z. O que a UML?. Disponvel Acesso em: 20 dez. 2000. em

EMBLEY, D.; WOODFIELD, S. Assessing the quality of abstract data types written in ada. New York: Computer Society Press the IEEE, 1988. 479p. FREIRE, J.C. Anlise orientada a objetos. Guaratinguet: FEG/UNESP, 2000. 186p. (Apostila do Curso de Especializao em Informtica Empresarial) FURLAN, J.D. Modelagem de objetos atravs da UML. So Paulo: Makron Books, 1998. 329p. JACOBSON, I. Object-oriented software engineering a use case driven approach. California: Addison Wesley, 1992. 524p. UNIVERSIDADE FEDERAL DO PARAN. Biblioteca Central. Normas para apresentao de trabalhos. 2. ed. Curitiba: UFPR, 1992. v. 2.