SISTEMA DE ENSINO PRESENCIAL CONECTADO ANALISE E DESENVOLVIMENTO DE SISTEMAS

HELAN ALLYSSON CHAGAS BARBOSA JOS VALMIR TRAJANO JUNIOR JOAO BATISTA VICENTE FILHO RAMALHO EANES DUTRA TEIXEIRA

PORTIFLIO ENGENHARIA DE SOFTWARE

Sobral CE, 22/10/2010

HELAN ALLYSSON CHAGAS BARBOSA JOS VALMIR TRAJANO JUNIOR JOAO BATISTA VICENTE FILHO RAMALHO EANES DUTRA TEIXEIRA

Titulo

Trabalho apresentado ao Curso Analise e Desenvolvimento de Sistemas da UNOPAR Universidade Norte do Paran, para a disciplina Engenharia de Software.

Orientador: Prof. Luis Claudio Perini

Sobral 2010

Sumario:
1 - Introduo 2 Modelos de Processos geis. 3 - Modelos de Processos Evolucionrios. 4 - Anlise Comparativa entre Metodologias Evolucionaria e geis. 5 Entrevistas. 6 - Concluso Referncias Bibliogrficas Pag. 04. Pag. 05. Pag. 05. Pag. 08. Pag. 11. Pag. 19. Pag. 20.

1 Introduo
Desde a crise do software o processo de desenvolvimento de software vem evoluindo e se estruturando para que erros que caracterizaram esta crise, como a m qualidade do que foi desenvolvido, no ocorram com projetos atuais. Para isso linguagens para modelagem do sistema, como a UML, foram criadas. Alm das linguagens, principalmente, foram desenvolvidas metodologias de desenvolvimento de software, onde passos eram detalhados para que o processo de desenvolvimento seguisse um padro e assim atingisse a qualidade necessria. Com o tempo, as metodologias se tornaram mais complexas e distintas melhorando a qualidade do produto, independente do foco do sistema sempre haveria uma metodologia para manter a qualidade. Este trabalho prope uma anlise comparativa de duas frentes destas metodologias, (...), e as metodologias geis, que se opem s tradicionais evitando, sempre que possvel, a documentao e focando a codificao do projeto.

2 Modelos de Processos geis.

Os processos de desenvolvimento gil de software parecem ser mais eficientes do que as metodologias antigas. Utiliza menos tempo do programador no desenvolvimento de softwares funcionais de alta qualidade, mas tem a desvantagem de ter uma perspectiva de negocio que no prov uma capacidade de planejamento em longo prazo. Em essncia, eles provem mais funcionalidades por custo/benefcio, mas no dizem exatamente o que a funcionalidade ir fazer. Existem vrias metodologias que podem ser consideradas como abordagens geis, entre elas: Scrum, Programao extrema, FDD, Crystal Clear, DSDM; entre outras.

2.1 Extreme Programming

A Programao Extrema (Extreme Programming ou XP) o mais bem conhecido processo gil. Em XP, as fases so continuadas em passos extremamente pequenos (ou contnuos) comparados aos processos antigos. A primeira passada (iterao incompleta) atravs das etapas deve levar um dia ou uma semana, ao invs de meses ou anos para cada fase completa do modelo em cascata. Primeiramente, escreve-se um autmato de teste, que prov objetivos concretos para o desenvolvimento. Depois codificado (por um par de programadores), este passo est completo quando todos os testes se concluem, e os programadores no pensem em nada mais que possa ser testado. Projetistas e Arquitetos executam uma refatorao do cdigo. O projeto feito por pessoas que esto codificando. O sistema incompleto, mas funcional entregue e demonstrado para os usurios. Neste ponto, os envolvidos iniciam novamente uma nova fase de escrita e teste para as prximas partes mais importante do sistema.

3 - Modelos de Processos Evolucionrios.

Estudos mostraram que o software, como todos os sistemas complexos evoluem durante um perodo de tempo e os requisitos do negcio e do produto mudam freqentemente medida que o desenvolvimento prossegue dificultando um caminho direto para um produto final (PRESSMAN, 2006). Os modelos que sero citados frente so interativos e caracterizam-se pela forma como se desenvolve verses cada vez mais completas do software.

3.1 Espiral
O modelo espiral foi desenvolvido para abranger as melhores caractersticas tanto do ciclo de vida clssico como da prototipao, acrescentando, ao mesmo tempo, um novo elemento, a anlise de riscos que falta a esses paradigmas. O modelo define quatro importantes atividades representadas por quatro quadrantes:

1. Planejamento: determinao dos objetivos, alternativas e restries. 2. Anlise de riscos: anlise de alternativas e identificao/resoluo de riscos. 3. Engenharia: desenvolvimento do produto no nvel seguinte. 4. Atualizao feita pelo cliente: avaliao dos resultados da engenharia.

Ele usa uma abordagem evolucionria engenharia de software, capacitando o desenvolvedor e o cliente a entender e reagir aos riscos em cada fase evolutiva. O modelo espiral usa a prototipao como um mecanismo de reduo de riscos, mas, o que mais importante, possibilita que o desenvolvedor aplique a abordagem de prototipao em qualquer etapa da evoluo do produto. Ele mantm a abordagem de passos sistemticos sugerida pelo ciclo de vida clssico, mas incorpora-a numa estrutura iterativa que reflete mais realisticamente o mundo real. O modelo espiral exige uma considerao direta dos riscos tcnicos em todas as etapas do projeto e, se adequadamente aplicado, deve reduzir os riscos antes que eles se tornem problemticos (Pressman, 2006). O modelo de ciclo de vida espiral apresentado por Boehm em 1988 combina as caractersticas positivas da gerncia (documento associado s fases do ciclo) do modelo de cascata com as fases sobrepostas encontradas no modelo incremental e, tambm, com as verses anteriores de um sistema do modelo de prototipao. O modelo em espiral parte do princpio de que a forma do desenvolvimento de software no pode ser completamente determinada de antemo. (Pressman, 2006). A prototipao vista como um meio de reduo de riscos, a permitir que se descubram os problemas potenciais antes de se comprometer com um sistema completo. O modelo caracteriza-se como um gerador de modelo de processo. Cada ciclo do modelo em espiral possui quatro atividades principais:

Elaborar objetivos, restries e alternativas para entidades de software. Avaliar alternativas com relao aos objetivos e restries, e identificar as principais fontes de riscos. Elaborar a definio das entidades de software em um projeto. Planejar o prximo ciclo. Abortar um projeto se ele apresentar um alto fator de risco.

3.2 Incremental
O modelo incremental segundo Pressman (2006) combina elementos do modelo cascata sendo aplicado de maneira interativa. O modelo de processo incremental interativo igual prototipagem, mais diferente a prototipagem o incremental tem como objetivo apresentar um produto operacional a cada incremento realizado. Esse modelo muito til quando a empresa no possui mo de obra disponvel no momento para uma implementao completa, dentro do prazo estipulado.

3.3 - Desenvolvimento baseado em componentes.

Desenvolvimento baseado em componentes ou component-based development (CBD) tambm conhecido como component-based software engineering (CBSE) ou simplesmente componente de software (BROWN, 1997). Pressman (2006) no define o que um componente e restringe-se a dizer que o modelo de desenvolvimento baseado em componentes utiliza paradigma de orientao a objetos baseando-se em uma classe como cdigo reutilizvel, ou seja, o componente. Em orientao a objetos uma classe encapsula dados e algoritmos e este ltimo tambm pode ser usado para manipular os dados. Pressman (2006) caracteriza esse modelo como incorporador do modelo espiral com uma abordagem iterativa para a criao de software. Atravs desta abordagem uma biblioteca de classes construda com as classes identificadas no desenvolvimento do software e a partir de ento toda iterao da espiral dever verificar o contedo da biblioteca que pode ser reutilizado ou identificar se novas classes devem ser inseridas na biblioteca para posterior reuso.

4 - Anlise Comparativa entre Metodologias Evolucionaria e geis.

A metodologia Evolucionaria e geis tm seu funcionamento baseado em iteraes, so orientadas ao cliente e baseadas em papel. Uma anlise superficial nos diria que tratam a dinmica de desenvolvimento de software da mesma forma. Porm atravs da anlise dos tpicos descritos pelo presente captulo as diferenas sero verificadas por aspectos como a forma e freqncia que os artefatos so gerados, quantidade de papis, etc.

4.1 - Alocaes de Tempo e Esforos

O Modelo Evolucionrio segue 4 fases seqenciais (descritas no item 3.1) constituindo um ciclo de desenvolvimento, produzindo uma nova verso de software. Em cada fase h um nmero de iteraes, as quatro fases tm seu foco em diferentes atividades, podendo ocorrer em paralelo. A primeira fase, chamada de incio foca o modelamento do negcio e a definio dos requisitos. A fase de elaborao foca em projetar (design), a de construo d enfoque a implementao e aos testes e por fim a fase de transio onde a implantao e o gerenciamento de modificaes so verificados. O aspecto tempo em Processos Evolucionrios diretamente relacionado com cdigo produzido. No comeo do projeto o foco o ncleo do sistema, e aps facilidades extras. Porm como as liberaes so definidas pelos clientes, os mesmos iro delimitar o tempo do projeto a partir de seu grau de satisfao com o software recebido.

4.2 - Artefatos
Um artefato um pedao de informao que produzida, modificada ou usada por um processo. Como exemplos de artefatos tm-se modelos, cdigo fonte e arquivos executveis. A comunicao dentro de um processo Evolucionrio baseada em artefatos. J em Processos Evolucionrios baseada em comunicao oral, direta, o que restringe o uso de Processos Evolucionrios em projetos com grande distribuio geogrfica. A pouca evidncia de artefatos do XP, com foco em estrias de usurio e cdigo, visto como um fator que aumenta o risco do projeto, o conhecimento fica vinculado aos desenvolvedores e ao cdigo.

4.3 - Atividades e Papis

PROCESSOS EVOLUCIONRIOS 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: 1. 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. 2. Modelamento de Negcio (3 papis): visa o entendimento da estrutura onde o software ser aplicado e os problemas atuais do cliente. Esta atividade deve assegurar que o cliente, os seus usurios e os desenvolvedores tenham um entendimento comum do produto a ser entregue. 3. Requerimentos (5 papis): traduz as necessidades do sistema em forma de casos de uso, desenhando a interface com o usurio. 4. Analise e Desenho (6 papis): especifica a forma de implementao (arquitetura) dos requerimentos (casos de uso). 5. Implementao (3 papis): implementa as classes e os objetos em formas de componentes, os quais so individualmente testados. 6. 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. 7. 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. 8. 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 versionamento (ClearCase, CVS, SVN) possvel garantir o mapeamento de alteraes efetuadas bem como a recuperao de cdigos e verses antigas. 9. 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:

1. Programador: escreve o cdigo e realiza testes individuais. 2. Cliente: o responsvel por escrever as estrias e as prioridades das mesmas.

3. Testador: tem como objetivo auxiliar o cliente a criar testes funcionais. Os testes devem ser realizados regularmente e seus resultados divulgados. 4. 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. 5. Tcnico (Coach): tem como responsabilidade o projeto como um todo, guiando os outros membros da equipe. 6. Consultor: membro externo que auxilia o time com assuntos (problemas) tcnicos especficos. 7. 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 os Processos Evolucionrios 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.

4.4 - Ferramentas
O XP no especifica nenhuma ferramenta em especfico para o processo, embora haja ferramentas livres como o XPlanner e o Junit. J o processo nos Processos Evolucionrios utiliza softwares, como o Rational Rose, que devem ser adquiridos da prpria IBM, juntamente com a documentao.

4.5 - Responsabilidades do Cdigo

Processos Evolucionrios trata o cdigo (geralmente de sistemas grandes) em subsistemas, e para cada subsistema existem membros responsveis pelo mesmo. J o XP trata o cdigo como coletivo, qualquer programador que encontre algum problema, ou algum trecho que possa ser otimizado, tem permisso para faz-lo. Isso pode agilizar o processo no caso de um programador necessitar corrigir algum mdulo para interagir corretamente com o seu. Porm isso pode ser algo prejudicial, pois podem ocorrer casos onde o cdigo aparentemente incorreto teve um motivo para ser estruturado da maneira que foi.

4.6 - Diretivas de Projeto

Processos Evolucionrios so baseados em casos de uso, as descries do uso do sistema so continuamente implementadas, integradas e testadas. J o XP aplica o projeto baseado em teste, casos de teste so implementados antes da escrita do cdigo. XP possui estrias de usurio para guiar o que deve ser implementado. Essas estrias so descries mais simples se comparadas aos

10

casos de uso dos Processos Evolucionrios. As duas metodologias indicam que o projeto completo no pode ser planejado em detalhe. Processos Evolucionrios indica modificao continua dos planos, enquanto o XP prope planejar em detalhes somente o futuro prximo.

5 Entrevistas.
5.1 Primeira Entrevista

Programador entrevistado: Felizardo Charles Dias S.

1- Como se da o primeiro contato com o cliente e Como feita a metodologia para a documentao da entrevista, com o cliente? R: primeiro passo saber qual a finalidade do soft,segundo entender o processo operacional da impressa seus requisitos do soft. Conversar com os funcionrios para entender a necessidade do soft de forma a agilizar os processos da impressa. 2- Qual a metodologia gil ou evolucionria, que a empresa utiliza para o desenvolvimento do software? R: Fazer diagrama de caso de uso,diagrama de classe e a modelagem de banco de dados utilizando o modelo entidade de relacionamento. 3- Quais as ferramentas e linguagens, utilizadas para o desenvolvimento do projeto? R: IDE: Delphi, Linguagem: Object Pascal, Banco de dados: Interbase/Firebird, Ferramenta de modelagem do BD: IBExpert. 4- Qual a estrutura da empresa, para o desenvolvimento, como se divide a equipe? R: Trabalho sozinho. Fao desde a anlise, programao, testes e implantao. 5- Qual a etapa do desenvolvimento onde ocorre erros com maior freqncia? R: Na fase de testes antes da implantao. 6- Quais os procedimentos adotados para resoluo de problemas encontrados no cliente ou pela equipe de desenvolvimento?
11

R: feito um relatrio especificando detalhadamente o erro ocorrido e sugestes do cliente de como dever ser corrigido. 7- Como se d instalao e manuteno do sistema? H um setor especfico para a implantao e suporte, ao cliente? Todo o processo de instalao e manuteno feito in loco e, caso a correo do erro seja demorada, fao a correo e os testes em casa para depois retornar ao cliente. 8- Como a empresa acompanha a qualidade do sistema entregue? R: Em visitas freqentes ao cliente e fazendo uma auditoria no banco de dados. 9- Como se da elaborao do oramento e cronograma do projeto? R: Cada projeto avaliado levando em conta o grau de exigncia do software, a quantidade de telas de cadastro, relatrios e tempo de programao. 10- Antes de o programador entregar o soft e aconselhvel mostrar antes para o cliente ou s depois que estiver todo concludo? R: Pelo menos com a funcionalidade principal do software estando ok. Depois chamo o cliente em minha casa para ele observar o funcionamento do software e dizer se est correspondendo s suas necessidades.

5.2 Segunda entrevista.

Programador entrevistado: Benjamim Mendes Junior

1- Como se da o primeiro contato com o cliente e Como feita a metodologia para a documentao da entrevista, com o cliente? Quase sempre o primeiro contato ocorre por indicao, o cliente tem uma necessidade, entra em contador com algum conhecido que por sua vs conhece um programador ou uma software house (empresa que desenvolve aplicativos). A primeira entrevista no uma entrevista e sim uma reunio onde na grande maioria o cliente verifica confiabilidade e comprometimento do programador. Nesse primeiro encontro o cliente resume o programa (aproximadamente 60% do que ele quer e 85% do que ele precisa) e pede uma idia inicial de preo, afim de amarrar o valor do sistema mesmo com alteraes na proposta inicial.

12

As entrevistas mais importantes quase sempre so feitas com os funcionrios, j que eles que iram usar o sistema, aps as entrevistas e avaliaes, pode-se gerar um documento resumindo tudo e envi-lo ao cliente. Se o cliente estiver de acordo, pode assinar o documento ou fazer alteraes enviando o mesmo de volta para a empresa. 2- Qual a metodologia gil ou evolucionria, que a empresa utiliza para o desenvolvimento do software? Uma das metodologias mais geis a XP (extreme programming) onde o mnimo de documentao feito no desenvolvimento, geralmente s casos de uso, e cada parte terminada do programa apresentada ao cliente. 3- Quais as ferramentas e linguagens, utilizadas para o desenvolvimento do projeto? Est-se se referindo a elaborao do projeto a UML essencial, j na codificao as ferramentas usadas se resumem em 2 grandes grupos, Gerenciadores de banco de dados (MySQL, Postgre, Firebird/Interbase, SQL Server, etc.) e IDEs (C#, Delphi, Eclipse, Netbeans); 4- Qual a estrutura da empresa, para o desenvolvimento, como se divide a equipe? Normalmente um gerente de projeto responsvel pela elaborao do mesmo e em alguns casos pelo banco de dados ou mesmo partes da codificao, e uma equipe de 2 a 4 programadores, revesando-se na codificao e nos testes. 5- Qual a etapa do desenvolvimento onde ocorrem erros com maior freqncia? Implantao, erros durante o desenvolvimento so esperados e ate bem vistos pois seu tratamento torna o programa mais estvel, o ideal era prever e tratar todos os erros durante o desenvolvimento mas isso no possvel. 6- Quais os procedimentos adotados para resoluo de problemas encontrados no cliente ou pela equipe de desenvolvimento? Erros encontrados no desenvolvimento so imediatamente corrigidos sem grandes impactos, mas erros encontrados pelo cliente requerem uma avaliao para determinar se a causa foi mau uso, falha de projeto ou hardware. Dependendo da causa a empresa tem obrigao de corrigir o erro sem custo adicional para o clinte.

13

7- Como se d instalao e manuteno do sistema? H um setor especfico para a implantao e suporte, ao cliente? Dependendo do que foi combinado a software house (SH) pode ser responsvel ou no pelo treinamento e instalao,mas na maioria das vezes os prprios programadores participam da instalao e treinamento, juntamente com algum do suporte e da TI da prpria empresa. O setor de suporte na SH fundamental pois ele o contado direto do cliente com a empresa no pos-venda e se no existisse o suporte seria necessrio para um programador para responder perguntas das mais variadas possveis. 8- Como a empresa acompanha a qualidade do sistema entregue? Normalmente um sistema entregue s passa por correes e atualizaes quando o cliente solicita, mas nada impede que o a SH por meio do suporte ou setor de vendas oferea essas atualizaes. 9- Como se da elaborao do oramento e cronograma do projeto? O oramento baseado no cronograma que baseado na necessidade de treinamento da equipe de desenvolvimento, no conhecimento prvio e na avaliao do gerente de projeto de quantas horas-programador sero necessrias para concluir o mesmo, sendo essa a parte mais difcil de mensurar, pois esta sujeita aos mais variados tipos de imprevistos, como por exemplo, doena de um membro da equipe. 10- Antes de o programador entregar o software aconselhvel mostrar antes para o cliente ou s depois que estiver todo concludo? altamente recomendvel mostrar o projeto mesmo parcialmente concludo, pois o cliente vera que esta sendo feito e tambm poder opinar sobre as alteraes que sempre ocorrem.

14

5.3 Terceira entrevista.

Empresa, Moageira Serra Grande, Cnpj: 07.815.640/0001-07, atua no mercado nacional a 49 anos e mercado internacional a 7 anos, no ramo de moagem e torrefao de caf. ERP de desenvolvimento proprio a 12 anos, esta na 3 gerao. Todos os processos informatizados, cada setor com seu modulo especifico. 1- Como se da requisio ou solicitao do usurio do ERP desenvolvido pela prpria empresa e como feita a metodologia para a documentao da entrevista, com o usurio? - Identificar os setores e funcionrios envolvidos na solicitao. So Feitas feita trs reunies, 1 Reunio, com os Chefes de setores para: - Conhecer os procedimentos e atividades de cada setor, -Identificar as necessidades, - Fazer o levantamento das dificuldades, - Detectar as atividades e retrabalho dos funcionrios, - Fazer o levantamento do faturamento e/ou produtividade mensal, para poder comparar com o faturamento e/ou produtividade aps implantao do sistema, - Se Informar com a Contabilidade, se na implantao do projeto, ser necessrio prestar alguma informao acessrias ao Governo Federal, Governo Estadual ou Governo Municipal, - Se Informar com o SESMET, alguma recomendao de segurana no trabalho, qualidade ISO e 5 S. 2 Reunio com a Diretoria, para: - Passar por aprovao da diretoria, cada necessidade, utilidade e requisio catalogada, - Somente as utilidades, necessidades e requisies aprovadas, que seguem para o Setor TI. - Oramento previsto para o Projeto. (quanto a diretoria esta disposta a investir).

15

s vezes, devido a cotao do caf na Bolsa de Mercados e Futuros, cotao do Dlar e Concorrncia do Mercado o Projeto, pode ficar engavetado, at uma segunda avaliao de prioridade. 3 Reunio com a Equipe TI, para: - Fazer o levantamento dos requisitos de hardware e cronograma do projeto, mediante a prioridade e oramento liberado. - Todas as informaes so anotadas em fichas, dos respectivos setores envolvidos, - As atividades de cada usurio, so documentadas em ITs, - As reunies so escritas em ATA. - Eh feito uma avaliao das regras de negocios que sero afetadas/envolvidas, - Eh feito um avaliao dos impactos nas tarefas e rotinas j existente. 2- Qual a metodologia gil ou evolucionria, que a empresa utiliza para o desenvolvimento do software ? O mtodo adotado o mtodo gil incremental, devido a todas as regras de negocio da empresa j foram desenvolvidas e testadas (Diagramas de Classes, Modelagem de Banco de Dados, Entidades de Relacionamentos, Jobs e etc.) O Hoje apenas feita uma manuteno, no intuito de aperfeioar as regras j existentes. 3- Quais as ferramentas e linguagens, utilizadas para o desenvolvimento do projeto ? IDE: Visual Studio 2005, Linguagem: VB.Net, ASP.Net Banco de Dados: SQL 2005 Documentao do Projeto : O prprio DataSet (Tabelas temporrias, TablesAdapters, Relacionamentos, Consultas, QueryAdapters e StoreProcedures) 4- Qual a estrutura da empresa, para o desenvolvimento, como se divide a equipe? Estrutura: 1 DELL PowerEdge T300 para desenvolvimento,

16

1 DELL PowerEdge T300 para Testes, 1 DELL Power Edge 1900 para produo, onde roda a verso release dos projetos. Disponibilidade para realizao de cursos M.O.C. (MicroSoft Oficial Curse) caso necessite. Diviso dos Trabalhos: Anlise do Sistema , Desenvolvimento e Data Mining : 1 funcionrio, D.B.A. e Administrao da rede : 1 funcionrio, Instalao remota e soluo de problemas com hardware: 1 funcionrio, Suporte (apenas aos Chefes de Setores ): 1 funcionrio. 5- Qual a etapa do desenvolvimento onde ocorre erros com maior freqncia? No digo erros, mas sim problemas e divergncia de idias; na faze de levantamento, das necessidades e requisies do Setores. Pois os usurios necessitam de certas funcionalidades e facilidades, que so negadas pela Diretoria. 6- Quais os procedimentos adotados para resoluo de problemas encontrados no cliente ou pela equipe de desenvolvimento? feito um relatrio especificando o erro ocorrido e qual o procedimento que o usurio estava realizando. As sugestes dos usurios , so analisadas pela a Diretoria juntamente com o setor TI. 7- Como se d instalao e manuteno do sistema ? H um setor especfico para o implantao e suporte, ao cliente? A Instalao feita in loco e as atualizaes so feitas via FTP, por checagem da verso do assembly. 8- Como a empresa acompanha a qualidade do sistema entregue? Atravs de comparativos, do faturamento e/ou produtividade antes e ps a implatacao do sistema, ocasionalmente ms a ms. 9- Como se da a elaborao do oramento e cronograma do projeto? Como o ERP desenvolvido pela prpria empresa, os usurios que iro utilizar o software, no so os nossos clientes finais, que consume nossos produtos.

17

Os cronogramas costumam ser em curto tempo e oramento depende fatores externo como a cotao do caf na Bolsa de Mercados e Futuros, cotao do Dlar e Concorrncia do Mercado . 10- Antes do Setor TI entregar o software e aconselhvel mostrar antes para o cliente ou s depois que estiver todo concludo? O Software mostrado eventualmente para a Diretoria em tempo de desenvolvimento . S quando provado pelo Setor TI e Diretoria, que o software instalado nos Setores. Os Chefes de setores j recebem o software pronto. Entrevistado: Jos Valmir Trajano Junior. Gerente TI Grupo Jocely Dantas.

18

6 - Concluso
Metodologias para o desenvolvimento de software independente de seus processos especficos buscam reduzir riscos e aumentar a qualidade do produto gerado. As metodologias, Processos Evolucionrios e XP, tm esse fim, pois apresentam mesmos valores como, envolvimento do cliente, iteraes, testes contnuos e flexibilidade. Porm busca-se esses objetivos de forma diferente, atravs de implementaes diferentes. De forma geral o XP se apresenta como uma metodologia a ser utilizada em projetos onde os requisitos so volteis ou no claros sendo assim muito flexvel, porm existe uma limitao de uso em equipes pequenas, pois no d nfase documentao e sim a comunicao oral restringindo sua aplicao em projetos com equipes distribudas geograficamente. A diviso de atividades (tarefas e papis) no XP tambm no muito especfica, sendo uma desvantagem para a diviso de responsabilidades em projetos grandes. Os Processos Evolucionrios estrutura o projeto fazendo uma diviso bem definida de atividades (tarefas e papis) e define uma coleo de artefatos que so usados como produtos de entrada e de sada de processos. Essa estruturao (com auxlio de softwares) do processo permite que os Processos Evolucionrios sejam utilizados em projetos grandes, e com distribuio geogrfica, com um custo (esforo) adicional de gerncia do projeto. Esse custo adicional pode no ser justificvel em pequenas equipes.

19

Referncias Bibliogrficas
BROWN, ALAN W., On Components and Objects: The Fundation of Component-Based Development, Assessment of Software Tools and Tecnology, Procedings Fifth International Symposium on Proceedings - IEEE, 1997. IBM; Practicing Object-Oriented Analysis and Design- ERC2.2.; IBM Education and Training; 2002L. PRESSMAN, ROGER S., Engenharia de Software- (3 edio), So Paulo, Ed. Makron Books, 1995. PRESSMAN, ROGER S., Engenharia de Software- (6 edio), So Paulo, Ed. McGrawHill, 2006. PETERS, JAMES F., Engenharia de Software: Teoria e Prtica, Rio de Janeiro, Editora Campus, 2001. SOMMERVILLE, I. Software Engineering (International Computer Science Series). 5 Edio. Reading: Addison-Wesley, 1995. Abrahamsson, P., Salo, O., Ronkainen, J. and Warsta J. (2002) "Agile Software Development Methods: Review and Analysis", Espoo 2002, VTT Publications 478. Beck, K. and Fowler, M. (2000) "Planning Extreme Programming", Addison Wesley, 1a edio. Kruchten, P. (2000) "The Rational Unified Process An Introduction", AddisonWesley 2a edio. Luiz, R. (2005) Obtendo Qualidade de Software com o RUP, TCC, Universidade de Uberaba. 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. Smith, J. (2003) "A Comparison of the IBM Rational Unified Process and eXtreme Programming", IBM Whitepaper, ftp://ftp.software.ibm.com/software/rational/web/whitepapers/2003/TP167.pdf, Abril.

20