You are on page 1of 20

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

PORTIFÓLIO ENGENHARIA DE SOFTWARE

Sobral – CE, 22/10/2010

1

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

2

6 . 4 . 04. 05. 5 – Entrevistas. 19. Pag. 08. Pag. 11. 3 . 3 .Introdução 2 – Modelos de Processos Ágeis. Pag.Conclusão Referências Bibliográficas Pag. Pag.Análise Comparativa entre Metodologias Evolucionaria e Ágeis. Pag. 20.Modelos de Processos Evolucionários. Pag. 05.Sumario: 1 .

sempre que possível. e as metodologias ágeis. Este trabalho propõe uma análise comparativa de duas frentes destas metodologias. foram desenvolvidas metodologias de desenvolvimento de software.1 – Introdução Desde a crise do software o processo de desenvolvimento de software vem evoluindo e se estruturando para que erros que caracterizaram esta crise. onde passos eram detalhados para que o processo de desenvolvimento seguisse um padrão e assim atingisse a qualidade necessária. independente do foco do sistema sempre haveria uma metodologia para manter a qualidade. 4 . Além das linguagens. as metodologias se tornaram mais complexas e distintas melhorando a qualidade do produto. a documentação e focando a codificação do projeto.. Para isso linguagens para modelagem do sistema. como a UML. foram criadas. principalmente..). (. como a má qualidade do que foi desenvolvido. Com o tempo. que se opõem às tradicionais evitando. não ocorram com projetos atuais.

ao invés de meses ou anos para cada fase completa do modelo em cascata. O sistema incompleto. entre outras. as fases são continuadas em passos extremamente pequenos (ou contínuos) comparados aos processos antigos. entre elas: Scrum.Modelos de Processos Evolucionários. Projetistas e Arquitetos executam uma refatoração do código. Neste ponto. A primeira passada (iteração incompleta) através das etapas deve levar um dia ou uma semana. FDD.1 – Extreme Programming A Programação Extrema (Extreme Programming ou XP) é o mais bem conhecido processo ágil. 3 . eles provem mais funcionalidades por custo/benefício. Primeiramente. Em essência. Utiliza menos tempo do programador no desenvolvimento de softwares funcionais de alta qualidade. mas não dizem exatamente o que a funcionalidade irá fazer. mas funcional é entregue e demonstrado para os usuários. O projeto é feito por pessoas que estão codificando. este passo está completo quando todos os testes se concluem. os envolvidos iniciam novamente uma nova fase de escrita e teste para as próximas partes mais importante do sistema. Crystal Clear. Programação extrema. e os programadores não pensem em nada mais que possa ser testado. Depois é codificado (por um par de programadores). mas tem a desvantagem de ter uma perspectiva de negocio que não provê uma capacidade de planejamento em longo prazo. 2006). Em XP. 2. 5 .2 – Modelos de Processos Ágeis. como todos os sistemas complexos evoluem durante um período de tempo e os requisitos do negócio e do produto mudam freqüentemente à medida que o desenvolvimento prossegue dificultando um caminho direto para um produto final (PRESSMAN. DSDM. Estudos mostraram que o software. Existem várias metodologias que podem ser consideradas como abordagens ágeis. Os processos de desenvolvimento ágil de software parecem ser mais eficientes do que as metodologias antigas. que provê objetivos concretos para o desenvolvimento. Os modelos que serão citados à frente são interativos e caracterizam-se pela forma como se desenvolve versões cada vez mais completas do software. escreve-se um autômato de teste.

A prototipação é vista como um meio de redução de riscos. um novo elemento. com as versões anteriores de um sistema do modelo de prototipação. possibilita que o desenvolvedor aplique a abordagem de prototipação em qualquer etapa da evolução do produto. mas. O modelo define quatro importantes atividades representadas por quatro quadrantes: 1. O modelo caracteriza-se como um gerador de modelo de processo. Ele usa uma abordagem “evolucionária” à engenharia de software. 2006). Cada ciclo do modelo em espiral possui quatro atividades principais: 6 . alternativas e restrições. O modelo espiral exige uma consideração direta dos riscos técnicos em todas as etapas do projeto e. capacitando o desenvolvedor e o cliente a entender e reagir aos riscos em cada fase evolutiva. Planejamento: determinação dos objetivos. 2. Ele mantém a abordagem de passos sistemáticos sugerida pelo ciclo de vida clássico. 4. 3. acrescentando. a permitir que se descubram os problemas potenciais antes de se comprometer com um sistema completo. O modelo de ciclo de vida espiral apresentado por Boehm em 1988 combina as características positivas da gerência (documento associado às fases do ciclo) do modelo de cascata com as fases sobrepostas encontradas no modelo incremental e. mas incorpora-a numa estrutura iterativa que reflete mais realisticamente o mundo real. ao mesmo tempo. Engenharia: desenvolvimento do produto no “nível seguinte”. (Pressman. o que é mais importante. deve reduzir os riscos antes que eles se tornem problemáticos (Pressman. se adequadamente aplicado.3. O modelo espiral usa a prototipação como um mecanismo de redução de riscos. Atualização feita pelo cliente: avaliação dos resultados da engenharia.1 – Espiral O modelo espiral foi desenvolvido para abranger as melhores características tanto do ciclo de vida clássico como da prototipação. a análise de riscos que falta a esses paradigmas. 2006). também. Análise de riscos: análise de alternativas e identificação/resolução de riscos. O modelo em espiral parte do princípio de que a forma do desenvolvimento de software não pode ser completamente determinada de antemão.

Desenvolvimento baseado em componentes.3 . dentro do prazo estipulado.2 – Incremental O modelo incremental segundo Pressman (2006) combina elementos do modelo cascata sendo aplicado de maneira interativa. ou seja. Pressman (2006) não define o que é um componente e restringe-se a dizer que o modelo de desenvolvimento baseado em componentes utiliza paradigma de orientação a objetos baseando-se em uma classe como código reutilizável. mais diferente a prototipagem o incremental tem como objetivo apresentar um produto operacional a cada incremento realizado.• • • • Elaborar objetivos. Esse modelo é muito útil quando a empresa não possui mão de obra disponível no momento para uma implementação completa. Pressman (2006) caracteriza esse modelo como incorporador do modelo espiral com uma abordagem iterativa para a criação de software. O modelo de processo incremental é interativo igual à prototipagem. 3. Em orientação a objetos uma classe encapsula dados e algoritmos e este último também pode ser usado para manipular os dados. o componente. Abortar um projeto se ele apresentar um alto fator de risco. Elaborar a definição das entidades de software em um projeto. 1997). Avaliar alternativas com relação aos objetivos e restrições. e identificar as principais fontes de riscos. Planejar o próximo ciclo. Desenvolvimento baseado em componentes ou component-based development (CBD) também é conhecido como component-based software engineering (CBSE) ou simplesmente componente de software (BROWN. Através desta abordagem uma biblioteca de classes é construída com as classes identificadas no desenvolvimento do software e a partir de então toda iteração da espiral deverá verificar o conteúdo da biblioteca que pode ser reutilizado ou identificar se novas classes devem ser inseridas na biblioteca para posterior reuso. 3. 7 . restrições e alternativas para entidades de software.

etc. Porém através da análise dos tópicos descritos pelo presente capítulo as diferenças serão verificadas por aspectos como a forma e freqüência que os artefatos são gerados. No começo do projeto o foco é o núcleo do sistema.3 . é visto como um fator que aumenta o risco do projeto. Já em Processos Evolucionários é baseada em comunicação oral.Artefatos Um artefato é um pedaço de informação que é produzida. podendo ocorrer em paralelo. Porém como as liberações são definidas pelos clientes. A primeira fase. direta. produzindo uma nova versão de software. 4.Alocações de Tempo e Esforços O Modelo Evolucionário segue 4 fases seqüenciais (descritas no item 3. e após facilidades extras. A metodologia Evolucionaria e Ágeis têm seu funcionamento baseado em iterações. Em cada fase há um número de iterações.4 . A comunicação dentro de um processo Evolucionário é baseada em artefatos. usando artefatos de entrada e produzindo 8 . o conhecimento fica vinculado aos desenvolvedores e ao código. modificada ou usada por um processo.Atividades e Papéis PROCESSOS EVOLUCIONÁRIOS define uma atividade como sendo o trabalho realizado por um papel. 4. o que restringe o uso de Processos Evolucionários em projetos com grande distribuição geográfica.2 . as quatro fases têm seu foco em diferentes atividades. O aspecto tempo em Processos Evolucionários é diretamente relacionado com código produzido. são orientadas ao cliente e baseadas em papel. Como exemplos de artefatos têm-se modelos. A fase de elaboração foca em projetar (design). os mesmos irão delimitar o tempo do projeto a partir de seu grau de satisfação com o software recebido. Uma análise superficial nos diria que tratam a dinâmica de desenvolvimento de software da mesma forma.1) constituindo um ciclo de desenvolvimento. 4. com foco em estórias de usuário e código. quantidade de papéis. a de construção dá enfoque a implementação e aos testes e por fim a fase de transição onde a implantação e o gerenciamento de modificações são verificados. chamada de início foca o modelamento do negócio e a definição dos requisitos. A pouca evidência de artefatos do XP.Análise Comparativa entre Metodologias Evolucionaria e Ágeis. código fonte e arquivos executáveis.1 .

XP [Beck e Fowler 2000] apresenta apenas quatro atividades básicas: produção de código. Teste (2 papéis): testa e verifica se o produto funciona como o esperado. SVN) é possível garantir o mapeamento de alterações efetuadas bem como a recuperação de códigos e versões antigas. métodos e processos. Requerimentos (5 papéis): traduz as necessidades do sistema em forma de casos de uso. 6. 3. testes. documentando falhas e problemas. desenhando a interface com o usuário. e desenho. provendo treinamento e possíveis migrações (banco de dados) entre o sistema anterior e o atual. XP define sete papéis: 1. 2. Ambiente (3 papéis): provê suporte adequado à organização do projeto. Provê feedback à gerência do projeto sobre a qualidade do software. listening (escutar o cliente). Gerência de Projeto (2 papéis): tem como objetivo prover meios para a entrega do produto para o cliente que atenda as suas necessidades. Analise e Desenho (6 papéis): especifica a forma de implementação (arquitetura) dos requerimentos (casos de uso). os quais são individualmente testados. instalação e teste (quando “beta”) em campo. Esta atividade deve assegurar que o cliente. 9 . Através do definição de uma política adequada e de ferramentas específicas para versionamento (ClearCase. 4. estão agrupados em nove disciplinas: 1. 5. 8. gerenciando os riscos do projeto. Os papéis (total de 30) definem o comportamento e as responsabilidades do individuo. Cliente: é o responsável por escrever as estórias e as prioridades das mesmas. Programador: escreve o código e realiza testes individuais. em ferramentas. Deployment (4 papéis): tem como objetivo a distruibuição. Modelamento de Negócio (3 papéis): visa o entendimento da estrutura onde o software será aplicado e os problemas atuais do cliente. CVS. 9. os seus usuários e os desenvolvedores tenham um entendimento comum do produto a ser entregue.artefatos de saída. 2. Implementação (3 papéis): implementa as classes e os objetos em formas de componentes. 7. Configuração e Controle de Mudanças (2 papéis): o objetivo destas atividades (Gerência de Configuração e Controle de Mudanças) concentra-se na garantia da rastreabilidade de versões dentro de um projeto.

Analisa o progresso de cada iteração e avalia se os objetivos podem ser alcançados com os recursos providos. qualquer programador que encontre algum problema. Já o XP aplica o projeto baseado em teste. como o Rational Rose. Testador: tem como objetivo auxiliar o cliente a criar testes funcionais.4 . toma decisões e está em constante comunicação com a equipe para diagnosticar possíveis problemas ou falhas no processo.Ferramentas O XP não especifica nenhuma ferramenta em específico para o processo. Consultor: membro externo que auxilia o time com assuntos (problemas) técnicos específicos.Responsabilidades do Código Processos Evolucionários trata o código (geralmente de sistemas grandes) em subsistemas.5 . pois podem ocorrer casos onde o código aparentemente incorreto teve um motivo para ser estruturado da maneira que foi. XP possui estórias de usuário para guiar o que deve ser implementado.Diretivas de Projeto Processos Evolucionários são baseados em casos de uso. Essas estórias são descrições mais simples se comparadas aos 10 . 4. Já o processo nos Processos Evolucionários utiliza softwares. ou algum trecho que possa ser otimizado. juntamente com a documentação. integradas e testadas. sem atribuições específicas dentro das atividades. guiando os outros membros da equipe. 4. 7. e para cada subsistema existem membros responsáveis pelo mesmo. Porém isso pode ser algo prejudicial. temos que os Processos Evolucionários faz uma divisão de tarefas de forma específica. Já o XP trata o código como coletivo. 4. Isso pode agilizar o processo no caso de um programador necessitar corrigir algum módulo para interagir corretamente com o seu. comparando as estimativas com os resultados obtidos. Técnico (Coach): tem como responsabilidade o projeto como um todo. casos de teste são implementados antes da escrita do código. as descrições do uso do sistema são continuamente implementadas. Tracker: provê feedback no processo. embora haja ferramentas livres como o XPlanner e o Junit. enquanto a divisão de papéis proposta pelo XP tem um caráter de “uso-geral”. “Big Boss”: responsável pelo projeto. que devem ser adquiridos da própria IBM. Ao compararmos as definições das atividades (disciplinas) e os papéis. tem permissão para fazê-lo. 6. Os testes devem ser realizados regularmente e seus resultados divulgados. 4.6 .3. 5.

5 – Entrevistas. 5. 2.segundo entender o processo operacional da impressa seus requisitos do soft. testes e implantação. Processos Evolucionários indica modificação continua dos planos. 6.Qual a etapa do desenvolvimento onde ocorre erros com maior freqüência? R: Na fase de testes antes da implantação. Linguagem: Object Pascal. Banco de dados: Interbase/Firebird. como se divide a equipe? R: Trabalho sozinho.Quais as ferramentas e linguagens.diagrama de classe e a modelagem de banco de dados utilizando o modelo entidade de relacionamento. para o desenvolvimento. 3. 5.Qual a metodologia ágil ou evolucionária. 4. que a empresa utiliza para o desenvolvimento do software? R: Fazer diagrama de caso de uso. programação. com o cliente? R: primeiro passo é saber qual a finalidade do soft.Como se da o primeiro contato com o cliente e Como é feita a metodologia para a documentação da entrevista. utilizadas para o desenvolvimento do projeto? R: IDE: Delphi. Ferramenta de modelagem do BD: IBExpert.casos de uso dos Processos Evolucionários. Conversar com os funcionários para entender a necessidade do soft de forma a agilizar os processos da impressa. As duas metodologias indicam que o projeto completo não pode ser planejado em detalhe.1 – Primeira Entrevista Programador entrevistado: Felizardo Charles Dias Sá. 1.Quais os procedimentos adotados para resolução de problemas encontrados no cliente ou pela equipe de desenvolvimento? 11 . enquanto o XP propõe planejar em detalhes somente o futuro próximo. Faço desde a análise.Qual a estrutura da empresa.

com o cliente? Quase sempre o primeiro contato ocorre por indicação.Como a empresa acompanha a qualidade do sistema entregue? R: Em visitas freqüentes ao cliente e fazendo uma auditoria no banco de dados. 10. A primeira entrevista não é uma entrevista e sim uma reunião onde na grande maioria o cliente verifica confiabilidade e comprometimento do programador. relatórios e tempo de programação. 9. Nesse primeiro encontro o cliente resume o programa (aproximadamente 60% do que ele quer e 85% do que ele precisa) e pede uma idéia inicial de preço. 8. Depois chamo o cliente em minha casa para ele observar o funcionamento do software e dizer se está correspondendo às suas necessidades. ao cliente? Todo o processo de instalação e manutenção é feito “in loco” e. caso a correção do erro seja demorada. a quantidade de telas de cadastro. Programador entrevistado: Benjamim Mendes Junior 1. 5. 12 .Como se da o primeiro contato com o cliente e Como é feita a metodologia para a documentação da entrevista. afim de “amarrar” o valor do sistema mesmo com alterações na proposta inicial. faço a correção e os testes em casa para depois retornar ao cliente.Como se da à elaboração do orçamento e cronograma do projeto? R: Cada projeto é avaliado levando em conta o grau de exigência do software.2 – Segunda entrevista. o cliente tem uma necessidade. 7.Antes de o programador entregar o soft e aconselhável mostrar antes para o cliente ou só depois que estiver todo concluído? R: Pelo menos com a funcionalidade principal do software estando ok. entra em contador com algum conhecido que por sua vês conhece um programador ou uma software house (empresa que desenvolve aplicativos).Como se dá instalação e manutenção do sistema? Há um setor específico para a implantação e suporte.R: É feito um relatório especificando detalhadamente o erro ocorrido e sugestões do cliente de como deverá ser corrigido.

Qual a estrutura da empresa. pode-se gerar um documento resumindo tudo e enviá-lo ao cliente. que a empresa utiliza para o desenvolvimento do software? Uma das metodologias mais ágeis é a XP (extreme programming) onde o mínimo de documentação é feito no desenvolvimento. após as entrevistas e avaliações. Delphi. mas erros encontrados pelo cliente requerem uma avaliação para determinar se a causa foi mau uso. 6.Quais as ferramentas e linguagens. 4. SQL Server. 5. Postgre. 13 . geralmente só casos de uso. 3. como se divide a equipe? Normalmente um gerente de projeto responsável pela elaboração do mesmo e em alguns casos pelo banco de dados ou mesmo partes da codificação.Quais os procedimentos adotados para resolução de problemas encontrados no cliente ou pela equipe de desenvolvimento? Erros encontrados no desenvolvimento são imediatamente corrigidos sem grandes impactos. Dependendo da causa a empresa tem obrigação de corrigir o erro sem custo adicional para o clinte.Qual a etapa do desenvolvimento onde ocorrem erros com maior freqüência? Implantação.) e IDEs (C#. e uma equipe de 2 a 4 programadores. e cada parte terminada do programa é apresentada ao cliente. erros durante o desenvolvimento são esperados e ate bem vistos pois seu tratamento torna o programa mais estável.As entrevistas mais importantes quase sempre são feitas com os funcionários. falha de projeto ou hardware. Eclipse. utilizadas para o desenvolvimento do projeto? Está-se se referindo a elaboração do projeto a UML é essencial. já na codificação as ferramentas usadas se resumem em 2 grandes grupos. Se o cliente estiver de acordo. Netbeans). pode assinar o documento ou fazer alterações enviando o mesmo de volta para a empresa. Gerenciadores de banco de dados (MySQL. o ideal era prever e tratar todos os erros durante o desenvolvimento mas isso não é possível.Qual a metodologia ágil ou evolucionária. para o desenvolvimento. 2. Firebird/Interbase. etc. revesando-se na codificação e nos testes. já que eles é que iram usar o sistema.

Antes de o programador entregar o software é aconselhável mostrar antes para o cliente ou só depois que estiver todo concluído? É altamente recomendável mostrar o projeto mesmo parcialmente concluído. juntamente com alguém do suporte e da TI da própria empresa. como por exemplo. O setor de suporte na SH é fundamental pois ele é o contado direto do cliente com a empresa no pos-venda e se não existisse o suporte seria necessário para um programador para responder perguntas das mais variadas possíveis. pois o cliente vera que esta sendo feito e também poderá opinar sobre as alterações que sempre ocorrem.Como se da à elaboração do orçamento e cronograma do projeto? O orçamento é baseado no cronograma que é baseado na necessidade de treinamento da equipe de desenvolvimento. no conhecimento prévio e na avaliação do gerente de projeto de quantas horas-programador serão necessárias para concluir o mesmo. mas nada impede que o a SH por meio do suporte ou setor de vendas ofereça essas atualizações. sendo essa a parte mais difícil de mensurar.Como a empresa acompanha a qualidade do sistema entregue? Normalmente um sistema entregue só passa por correções e atualizações quando o cliente solicita. doença de um membro da equipe. 14 . 8. pois esta sujeita aos mais variados tipos de imprevistos.7. ao cliente? Dependendo do que foi combinado a software house (SH) pode ser responsável ou não pelo treinamento e instalação.Como se dá instalação e manutenção do sistema? Há um setor específico para a implantação e suporte.mas na maioria das vezes os próprios programadores participam da instalação e treinamento. 10. 9.

se na implantação do projeto.Passar por aprovação da diretoria. .Se Informar com a Contabilidade. São Feitas feita três reuniões. com os Chefes de setores para: . cada setor com seu modulo especifico.Detectar as atividades e retrabalho dos funcionários.Fazer o levantamento das dificuldades. 15 . alguma recomendação de segurança no trabalho.Orçamento previsto para o Projeto.3 – Terceira entrevista. . para: . será necessário prestar alguma informação acessórias ao Governo Federal. esta na 3 geração. -Identificar as necessidades. . ERP de desenvolvimento proprio a 12 anos. Cnpj: 07.Conhecer os procedimentos e atividades de cada setor. qualidade ISO e 5 S. no ramo de moagem e torrefação de café. utilidade e requisição catalogada. com o usuário? . Moageira Serra Grande. necessidades e requisições aprovadas.Identificar os setores e funcionários envolvidos na solicitação. para poder comparar com o faturamento e/ou produtividade após implantação do sistema. 1.640/0001-07. .Somente as utilidades.Como se da à requisição ou solicitação do usuário do ERP desenvolvido pela própria empresa e como é feita a metodologia para a documentação da entrevista. 2ª Reunião com a Diretoria.Fazer o levantamento do faturamento e/ou produtividade mensal. Governo Estadual ou Governo Municipal. (quanto a diretoria esta disposta a investir). . Empresa.Se Informar com o SESMET. . . cada necessidade. 1ª Reunião.815. é que seguem para o Setor TI. atua no mercado nacional a 49 anos e mercado internacional a 7 anos. Todos os processos informatizados.5.

16 . são documentadas em IT’s.Quais as ferramentas e linguagens. Relacionamentos. pode ficar engavetado. 3. utilizadas para o desenvolvimento do projeto ? IDE: Visual Studio 2005.Ás vezes.Fazer o levantamento dos requisitos de hardware e cronograma do projeto.As atividades de cada usuário.Net Banco de Dados: SQL 2005 Documentação do Projeto : O próprio DataSet (Tabelas temporárias. Entidades de Relacionamentos. para: . .Eh feito uma avaliação das regras de negocios que serão afetadas/envolvidas. que a empresa utiliza para o desenvolvimento do software ? O método adotado é o método ágil incremental. . 2. QueryAdapters e StoreProcedures) 4.Qual a estrutura da empresa. dos respectivos setores envolvidos. mediante a prioridade e orçamento liberado.Qual a metodologia ágil ou evolucionária. ASP.Net. Consultas. cotação do Dólar e Concorrência do Mercado o Projeto. Jobs e etc.As reuniões são escritas em ATA. como se divide a equipe? Estrutura: 1 DELL PowerEdge T300 para desenvolvimento. para o desenvolvimento.) O Hoje é apenas feita uma manutenção. até uma segunda avaliação de prioridade. devido a cotação do café na Bolsa de Mercados e Futuros. TablesAdapters. . 3ª Reunião com a Equipe TI. no intuito de aperfeiçoar as regras já existentes. . Linguagem: VB. Modelagem de Banco de Dados. .Todas as informações são anotadas em fichas.Eh feito um avaliação dos impactos nas tarefas e rotinas já existente. devido a todas as regras de negocio da empresa já foram desenvolvidas e testadas (Diagramas de Classes.

(MicroSoft Oficial Curse) caso necessite. Suporte (apenas aos Chefes de Setores ): 1 funcionário. são analisadas pela a Diretoria juntamente com o setor TI. Instalação remota e solução de problemas com hardware: 1 funcionário. Pois os usuários necessitam de certas funcionalidades e facilidades.Quais os procedimentos adotados para resolução de problemas encontrados no cliente ou pela equipe de desenvolvimento? É feito um relatório especificando o erro ocorrido e qual o procedimento que o usuário estava realizando. os usuários que irão utilizar o software. É na faze de levantamento. Divisão dos Trabalhos: Análise do Sistema . do faturamento e/ou produtividade antes e pós a implatacao do sistema.1 DELL PowerEdge T300 para Testes. Desenvolvimento e Data Mining : 1 funcionário. onde roda a versão release dos projetos. 5. 6. ao cliente? A Instalação é feita “in loco” e as atualizações são feitas via FTP. ocasionalmente mês a mês. que são negadas pela Diretoria. e Administração da rede : 1 funcionário.Como se da a elaboração do orçamento e cronograma do projeto? Como o ERP é desenvolvido pela própria empresa.A. 17 . D. 9. 8. Disponibilidade para realização de cursos M.Como se dá instalação e manutenção do sistema ? Há um setor específico para o implantação e suporte.C. 7. das necessidades e requisições do Setores. 1 DELL Power Edge 1900 para produção. que consume nossos produtos.B. As sugestões dos usuários . não são os nossos clientes finais. por checagem da versão do assembly. mas sim problemas e divergência de idéias.O.Como a empresa acompanha a qualidade do sistema entregue? Através de comparativos.Qual a etapa do desenvolvimento onde ocorre erros com maior freqüência? Não digo erros.

18 . Gerente TI – Grupo Jocely Dantas. 10. Só quando provado pelo Setor TI e Diretoria. é que o software é instalado nos Setores. Entrevistado: José Valmir Trajano Junior. cotação do Dólar e Concorrência do Mercado . Os Chefes de setores já recebem o software pronto.Os cronogramas costumam ser em curto tempo e orçamento depende fatores externo como a cotação do café na Bolsa de Mercados e Futuros.Antes do Setor TI entregar o software e aconselhável mostrar antes para o cliente ou só depois que estiver todo concluído? O Software é mostrado eventualmente para a Diretoria em tempo de desenvolvimento .

através de implementações diferentes. envolvimento do cliente. Processos Evolucionários e XP. e com distribuição geográfica. De forma geral o XP se apresenta como uma metodologia a ser utilizada em projetos onde os requisitos são voláteis ou não claros sendo assim muito flexível. pois apresentam mesmos valores como.6 . Os Processos Evolucionários estrutura o projeto fazendo uma divisão bem definida de atividades (tarefas e papéis) e define uma coleção de artefatos que são usados como produtos de entrada e de saída de processos. Essa estruturação (com auxílio de softwares) do processo permite que os Processos Evolucionários sejam utilizados em projetos grandes.Conclusão Metodologias para o desenvolvimento de software independente de seus processos específicos buscam reduzir riscos e aumentar a qualidade do produto gerado. Porém busca-se esses objetivos de forma diferente. pois não dá ênfase à documentação e sim a comunicação oral restringindo sua aplicação em projetos com equipes distribuídas geograficamente. 19 . As metodologias. porém existe uma limitação de uso em equipes pequenas. sendo uma desvantagem para a divisão de responsabilidades em projetos grandes. iterações. Esse custo adicional pode não ser justificável em pequenas equipes. com um custo (esforço) adicional de gerência do projeto. A divisão de atividades (tarefas e papéis) no XP também não é muito específica. têm esse fim. testes contínuos e flexibilidade.

Pollice.. On Components and Objects: The Fundation of Component-Based Development. Practicing Object-Oriented Analysis and Design. 1a edição. Ronkainen. Ed. (2003) "Using the IBM Rational Unified Process for Small Projects: Expanding Upon eXtreme Programming".IEEE. Editora Campus. Rio de Janeiro. AddisonWesley 2a edição. TCC. P. M. Salo.. SOMMERVILLE. Espoo 2002. Assessment of Software Tools and Tecnology. O.software. Abrahamsson.ERC2.2.pdf. and Warsta J. P. Engenharia de Software. IBM Education and Training.ibm. Lund University. K. (2005) “Obtendo Qualidade de Software com o RUP”.. 2002L. and Fowler. Ed. Beck. Smith. IBM. Abril. (2000) "Planning Extreme Programming". 5ª Edição. (2000) "The Rational Unified Process – An Introduction". Engenharia de Software: Teoria e Prática. I. Engenharia de Software. São Paulo. ftp://ftp. 2001. 20 .. 1997. São Paulo. ALAN W. McGrawHill..ibm. J. JAMES F. IBM Whitepaper. IBM whitepaper. ftp://ftp. Universidade de Uberaba.(6ª edição). P. Procedings Fifth International Symposium on Proceedings . 1995.(3ª edição). ROGER S. ROGER S. P. (2002) "Agile Software Development Methods: Review and Analysis". VTT Publications 478.com/software/rational/web/whitepapers/2003/TP167. G.Referências Bibliográficas BROWN. Software Engineering (International Computer Science Series).. PETERS. Runeson. (2003) "A Comparison of the IBM Rational Unified Process and eXtreme Programming". PRESSMAN. Abril. Makron Books. Kruchten. Reading: Addison-Wesley. Sweden. PRESSMAN. and Greberg.com/software/rational/web/whitepapers/2003/TP183.software. 1995. Addison Wesley. R. (2004) "Extreme Programming and Rational Unified Process – Contrasts or Synonyms?". 2006.pdf. J. Luiz..