Projeto de Sistema de Gestão Rural como Serviço - Saas

Tamanho: px
Começar a partir da página:

Download "Projeto de Sistema de Gestão Rural como Serviço - Saas"

Transcrição

1 1 UNIJUI - UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO RIO GRANDE DO SUL DCEEng DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS Projeto de Sistema de Gestão Rural como Serviço - Saas JOÃO CARLOS WINTER Ijuí Dezembro/2011

2 2 UNIJUI - UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO RIO GRANDE DO SUL DCEEng DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS Projeto de Sistema de Gestão Rural como Serviço - Saas JOÃO CARLOS WINTER Trabalho de Conclusão de Curso apresentado ao Curso de Informática - Sistemas de Informação do Departamento de Ciências Exatas e Engenharias (DCEEng), da Universidade Regional do Noroeste do Estado do Rio Grande do Sul (UNIJUÍ), como requisito para a obtenção do título Bacharel em Informática - Sistemas de Informação. Orientador: Prof. (MS). Marcos R. M. Cavalheiro Ijuí Dezembro/2011

3 3 Projeto de Sistema de Gestão Rural como Serviço - Saas JOÃO CARLOS WINTER Trabalho de Conclusão de Curso apresentado ao Curso de Informática - Sistemas de Informação do Departamento de Ciências Exatas e Engenharias (DCEEng), da Universidade Regional do Noroeste do Estado do Rio Grande do Sul (UNIJUÍ), como requisito para a obtenção do título Bacharel em Informática - Sistemas de Informação. Orientador: Prof. (Ms). Macos R. M. Cavalheiro BANCA EXAMINADORA Prof. (Ms). Romário L. Alcântara Ijuí Dezembro/2011

4 4 AGRADECIMENTOS A UNIJUI pelo excelente ambiente de estudos disponibilizado. Ao professor Marcos R. M. Cavalheiro pelo incentivo, e esclarecimentos transmitidos. Aos demais professores do curso de Informática Sistemas de Informação pelos ensinamentos transmitidos ao longo do curso. Aos Agricultores visitados durante o processo de coleta e análise de requisitos, pela acolhida e disponibilidade para o fornecimento das informações requeridas. A família pelo apoio e compreensão do tempo destinado ao desenvolvimento do projeto. Finalmente a todos que de certa forma contribuíram para que a realização deste trabalho fosse possível.

5 5 RESUMO A evolução da humanidade ao longo dos séculos nos trouxe à hera da informação. Esta sempre foi de suma importância permitindo às pessoas adquirirem conhecimento. Armazenando as informações em papel, através de livros, da arte, da música, as pessoas sempre buscaram meios para guardar dados e conhecimentos. Neste sentido desenvolveram-se os computadores, e com eles os softwares. E com a evolução do software, e sua crescente demanda, levou à necessidade de desenvolvimento de tecnologia adequada para o processo de criação de sistemas de informações informatizados. Surgiu então a engenharia de software, empregando técnicas, processos, e mecanismos para o desenvolvimento de softwares de qualidade. Ao longo das décadas, desde o surgimento do software, o seu processo evoluiu, mudou paradigmas, sendo atualmente empregada a orientação a objetos. Neste contexto, diferentes linguagens foram utilizadas para o desenvolvimento de projetos e documentação de sistemas, até a proposição de uma linguagem unificada. Desenvolvido por engenheiros de software, a UML Linguagem de Modelagem Unificada consolidou-se como paradigma no processo de engenharia de software. A intensificação do uso de tecnologias de informação tornou as organizações, mais competitivas, sendo um diferencial. Contudo, esta não é uma realidade no meio rural brasileiro, especialmente nas médias e pequenas propriedades. Neste meio, a resistência a mudanças ainda é muito forte. Contudo, esta realidade está mudando, à medida que se dissemina o uso de computadores, conectados à internet, cada vez mais acessível. Um novo modelo de software, oferecido como serviço, através da internet, traz uma nova visão ao uso de tecnologias de software. Possibilitando um meio acessível para o uso de software, faz crer que o desenvolvimento de um sistema informatizado aplicando-se a tecnologia de Software como Serviço SaaS, pode ser disseminada pelos agropecuaristas de médio e pequeno porte. Neste contexto, este trabalho, retrata o referencial teórico do processo de engenharia de software, e propõe a modelagem para um projeto de sistema de gestão rural como serviço.

6 6 LISTA DE TABELAS TABELA 1: PROPRIEDADES DA EVOLUÇÃO DO SOFTWARE (PETERS E PEDRYCZ, 2001)...37 TABELA 2: FASES DO PROCESSO UNIFICADO, PÁDUA PAULA FILHO, TABELA 3: FLUXOS DO PROCESSO UNIFICADO, PÁDUA PAULA FILHO, TABELA 4: NOTAÇÕES PARA ESPECIFICAÇÃO DE REQUISITOS (SOMMERVILLE, 2005)...47 TABELA 5: ESPECIFICAÇÃO REQUISITOS NÃO FUNCIONAIS (SOMMERVILLE, 2005)...48 TABELA 6: USUÁRIOS E REQUISITOS - INTER-RELAÇÕES...53

7 7 LISTA DE FIGURAS FIGURA 1. ENGENHARIA DE REQUISITOS (SOMMERVILLE, 2005)...26 FIGURA 2. PROCESSO DE PROJETO (SOMMERVILLE, 2005)...27 FIGURA 3. PROCESSO DE TESTES (SOMMERVILLE, 2005)...29 FIGURA 4. EVOLUÇÃO DE SISTEMA (SOMMERVILLE, 2005)...30 FIGURA 5. MODELO CASCATA (PRESSMAN, 1995)...31 FIGURA 6. PROTOTIPAGEM - ADAPTADO DE PAULA FILHO...34 FIGURA 7. MODELO ESPIRAL (SOMMERVILLE, 2005)...36 FIGURA 8. PROCESSO ENG. DE REQUISITOS...49 FIGURA 9. PROCESSAMENTO CENTRALIZADO...64 FIGURA 10. ARQUITETURA CLIENTE-SERVIDOR...67 FIGURA 11. ARQUITETURA TRÊS CAMADAS...67 FIGURA 12. CLIENTE-SERVIDOR TRÊS CAMADAS...69 FIGURA 13. MODELO DE CLASSE DE OBJETOS...72 FIGURA 14. EXEMPLO DE DEPENDÊNCIA...73 FIGURA 15. EXEMPLO DE GENERALIZAÇÃO...74 FIGURA 16. EXEMPLO DE ASSOCIAÇÃO...74 FIGURA 17. ARQUITETURA - VISÕES (BOOCH, 2000)...79 FIGURA 18. CASO DE USO E RELACIONAMENTOS...84 FIGURA 19. COLABORAÇÃO ESTENDIDA...85 FIGURA 20. COLABORAÇÃO INCLUSÃO...86 FIGURA 21. ASSOCIAÇÃO...86 FIGURA 22. GENERALIZAÇÃO...86 FIGURA 23. MODELO DE CLASSE...88 FIGURA 24. PROPRIEDADES DOS ATRIBUTOS (ADAPTADO DE ALCÂNTARA, 2005)...89 FIGURA 25. AGREGAÇÃO...90 FIGURA 26. CLASSE ABSTRATA...91 FIGURA 27. CLASSE CONCRETA...91 FIGURA 28. CLASSE FOLHA...91 FIGURA 29. CLASSE RAIZ...91 FIGURA 30. DIAGRAMA DE SEQUÊNCIA...92 FIGURA 31. DIAGRAMA DE ESTADO...93

8 8 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS JUSTIFICATIVA METODOLOGIA ORGANIZAÇÃO DO TRABALHO ASPECTOS RELACIONADOS À ENGENHARIA E MODELAGEM DE SOFTWARE DEFINIÇÃO DE SOFTWARE TIPOS DE APLICAÇÃO DE SOFTWARE Software como Serviço DEFINIÇÃO DE ENGENHARIA DE SOFTWARE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ATIVIDADES PARA O PROCESSO DE SOFTWARE Especificação de software Projeto e implementação de software Validação de software Evolução de software MODELOS DE PROCESSO DE SOFTWARE Modelo Cascata Modelo de Prototipação Modelo Espiral Modelo Ciclo Evolutivo Modelo RUP (Rational Unified Process) GERENCIAMENTO DE RISCOS Identificação de riscos Análise de riscos Planejamento de Riscos Monitoramento de Riscos REQUISITOS DE SOFTWARE Requisitos de Usuário Requisitos de Sistema Classificação de Requisitos ENGENHARIA DE REQUISITOS Estudo de Viabilidade dos Requisitos Obtenção e análise de requisitos Princípios de Especificação Validação de Requisitos Gerência de Requisitos PROJETO DE ARQUITETURA Estruturas do Sistema Processamento Centralizado Processamento Distribuído ORIENTAÇÃO A OBJETOS Relacionamentos de Objetos Benefícios da Orientação a Objetos MODELAGEM DE SISTEMAS UML Arquitetura Ciclo de Vida no Desenvolvimento do Software Diagramas UML Diagramas de Casos de Uso Diagramas de Classes...87

9 Diagramas de Sequência Diagrama de Estado SÍNTESE MODELAGEM DO PROJETO DE SISTEMA DE GESTÃO RURAL COMO SERVIÇO SAAS PROPOSTA DE MODELAGEM DO SISTEMA DOMÍNIO OBJETIVOS DO SISTEMA ANÁLISE DE REQUISITOS LOCAL DO SISTEMA PROCESSO DE SOFTWARE CENÁRIOS PRIMÁRIOS CENÁRIOS SECUNDÁRIOS CASOS DE USO DIAGRAMAS DE CLASSES PROJETO LÓGICO DIAGRAMAS DE SEQUÊNCIA DIAGRAMAS DE ESTADO PROJETO DE TELAS CONCLUSÃO CONTRIBUIÇÕES E LIMITAÇÕES DESTE TRABALHO SUGESTÃO PARA TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS REFERÊNCIAS DA WEB ANEXOS ANEXO I DOCUMENTOS DE CONTROLE DE ANIMAIS DOS AGRICULTORES ENTREVISTADOS...202

10 10 1 INTRODUÇÃO Para lograr uma entrada eficiente, competitiva e sustentável no mercado, o agricultor tem a necessidade de se qualificar e administrar mais eficazmente sua propriedade. Tal adaptação torna-se necessária num ambiente cada vez mais complexo e interligado, o qual exige dele a aquisição de novas habilidades nas áreas de gestão, tecnologias de produtos e processos, bem como acesso a informações sobre as melhores condições técnicas e ambientais de produção (BUAINAIN et al., 2007). Desta maneira, a gestão das propriedades rurais, através do uso de software expõe uma revolução em sua forma de administrar, na busca da melhoria de qualidade de vida daqueles que são responsáveis pela produção primária. A abordagem de software como serviço (Software as a Service), tendo em vista a atual conjuntura econômica global, na busca de redução de custos de produção por parte de todos os segmentos da economia, no objetivo de agregar valor ao produto ofertado, e agilizar os processos, oferece uma forma rápida para geração de valor aos negócios. O desenvolvimento do conceito de Saas (software as a service), oferece uma oportunidade de adesão a este paradigma. Contudo a ausência de aplicações disponíveis, para atender o segmento do agronegócio, especialmente do agricultor familiar, oferece um campo a ser explorado. Diante do fato de que a maioria dos pequenos e médios produtores rurais não utiliza qualquer tipo de software para o gerenciamento de suas propriedades há necessidade de desenvolver um sistema completo de gestão, a fim de atender esta demanda. Neste contexto, o objetivo deste trabalho, é documentar o projeto e modelagem do sistema a que se propõe o presente trabalho de conclusão do curso de sistemas de informações oferecido pelo Departamento de Ciências Exatas e Engenharias da Universidade Regional do Noroeste do Estado do Rio Grande do Sul.

11 Objetivos Na propriedade rural, inúmeras informações importantes são geradas diariamente, no entanto, não são armazenadas, perdendo-se no decorrer do tempo. Esta prática impede o gestor de conhecer o seu próprio empreendimento. Gurgel e Grossi (2004) afirmam que o campo é um espaço de produção econômica baseado em tecnologia, e a TI é um poderoso e indispensável instrumento para o crescimento do agronegócio, com aumento de sua utilização no setor que vive uma mutação acelerada. A informática é considerada uma inovação tecnológica com enorme potencial para aumentar rendimentos dos recursos produtivos na agropecuária e no suporte à criação de banco de dados para tomada de decisões gerenciais. Sob este aspecto, o software é uma ferramenta essencial para uma adequada administração da propriedade informatizada. Contudo sua disseminação está necessariamente atrelada à melhores práticas de gestão por parte de agricultores, especialmente, os agricultores familiares. Desta maneira, o projeto de trabalho de conclusão de curso será voltado ao desenvolvimento de um projeto de software de gestão de propriedades rurais. Para isso será necessário atender os seguintes objetivos: Realizar um estudo sobre as práticas de modelagem e desenvolvimento de sistemas. Realizar a coleta de requisitos primários e secundários para o desenvolvimento do sistema. Realizar a modelagem do sistema. resultados: Atendidos os objetivos de projeto do software se espera os seguintes Uma modelagem de projeto de software de qualidade. Facilitar a compreensão do domínio para o desenvolvimento do software.

12 12 Documentar o domínio do sistema para o desenvolvimento do software de gestão rural como serviço. Ressaltar a importância do uso de ferramentas de TI para gerenciamento operacional e de apoio a decisão no meio agrícola. 1.2 Justificativa O uso de novas tecnologias somente é viável se ela agregar ganhos reais e lucratividade a uma organização. Beal (2001, pág. 1) afirma que a TI pode ser decisiva para o sucesso de uma organização, contribuindo para que ela seja ágil, flexível e robusta. Entretanto, o cenário que se presenciou na administração rural brasileira foi sempre desfavorável à consolidação de novas tecnologias relacionadas à informática, destacando-se o fator cultural como principal empecilho nesse desenvolvimento. Até pouco tempo, a informática era empregada principalmente pela população urbana, entretanto esta realidade está mudando, pois o mundo virtual desperta a cada dia mais o interesse da comunidade rural. Atualmente os agricultores buscam informações na internet, seja as cotações dos produtos agrícolas na bolsa de valores, notícias em geral, e especialmente informações meteorológicas. Uma grande ferramenta de auxílio ao administrador rural na hora de gerenciar a Empresa Agropecuária é a informática e principalmente o software. Utilizando-se deste recurso podem-se organizar os dados de tal forma que a qualquer momento seja possível consultá-los, efetuar cálculos, elaborar gráficos, imprimir relatórios ou consultar informações solicitadas. A informática é uma ferramenta gerencial que propicia ganho de tempo e dinheiro, culminando muitas vezes em redução de custos através da análise detalhada de todos os fatores de produção envolvidos. Em painel com especialistas em agroinformática (EMBRAPA INFORMÁTICA AGROPECUÁRIA, 2009), realizado pela Embrapa Informática Agropecuária em parceria com a Associação para Promoção da Excelência do Software Brasileiro (Softex), afirmou-se que muitos produtores rurais, especialmente os de menor porte,

13 13 não fazem a gestão da sua propriedade, não fazem nenhum controle contábil, e sequer sabem usar um computador. Dessa forma, enxergam a aquisição de tecnologias em computação como artigo caro e desnecessário. No painel também se destacou a hipótese que trata da idade do gestor como fator influente na aquisição de softwares. Contatou-se que pessoas mais velhas são mais resistentes à adoção de novas tecnologias. Realmente, TEIXEIRA (2000) afirma que a insegurança e a ansiedade causadas pelas inovações são as causas da resistência dos mais idosos às tecnologias emergentes. Dessa forma, um fator determinante para concluir que o público consumidor de softwares no agronegócio aceitará mais tal inovação a curto e médio prazo é a renovação do público gestor do agronegócio. Nos últimos anos, o surgimento de diversos cursos de nível superior na área de gestão do agronegócio também é indicador da crescente profissionalização do campo nacional. Segundo Marion e Segatti, o fazendeiro está se transformando em empresário rural, um administrador profissional, que, além de se preocupar com a produção, busca a produtividade e a lucratividade. Seu objetivo é produzir mais com menos recursos e para isso necessita de informações para avaliar, controlar e decidir (MARION e SEGATTI, 2005, p. 3). Todos esses fatores indicam o potencial grande da demanda de tecnologias a TI, especialmente que está por vir no mercado agropecuário brasileiro. Existem alguns pontos desfavoráveis à adoção de tecnologias pela agricultura familiar. Segundo especialistas em agro informática, em painéis relatados por Acosta et al. (2008a, 2008b), e Cruz et al (2008), entre os principais entraves estão a falta de capacitação gerencial e tecnológica dos produtores e o alto custo-benefício para adquirir tais tecnologias. No que tange o primeiro ponto, observa-se a falta de percepção, por parte de alguns produtores familiares, da necessidade de melhor gerenciar seus negócios e enxergar sua atividade como um patrimônio financeiro. Sem essa consciência, esses produtores conseguem apenas manter suas propriedades.

14 14 Com relação ao segundo ponto, afirma-se que os softwares disponíveis possuem, em geral, mais funções do que o agricultor familiar precisa, tornando-se complexos e exigindo um alto dispêndio numa aquisição que pode não refletir em aumento direto da sua receita. A pouca disponibilidade de software voltado exclusivamente para esse público pode evidenciar que ele é considerado como um potencial público-alvo para as empresas desenvolvedoras, como citado anteriormente. Contudo, uma maior atuação de micro e pequenas empresas no mercado de software para agricultores familiares poderia se tornar um arranjo que beneficiaria em grande medida, tanto demandante como ofertantes. Por um lado, o potencial de demandantes da agricultura familiar é grande. Há no Brasil mais de 4 milhões de estabelecimentos rurais gerenciados por agricultores familiares (GUANZIROLI et al., 2001). Uma tendência a inserção no mercado dessa categoria, inevitavelmente, abriria uma grande possibilidade de modernização e informatização desse público. Por outro lado, a atuação de micro e pequenas empresas tenderia a fortalecê-las consideravelmente, possibilitando-as uma maior sobrevivência num momento em que o setor vem passando por um processo de centralização de capitais (EMBRAPA INFORMÁTICA AGROPECUÁRIA, 2009). A importância do agronegócio para a economia e para a sociedade brasileira pode ser compreendida analisando a participação do PIB do agronegócio no PIB total do país. Em 2007, por exemplo, ¼ de toda a riqueza produzida no Brasil derivou desse setor, segundo dados do Cepea-USP/CNA. De acordo com o Censo Agropecuário 2006, IBGE, em termos absolutos, o PIB do agronegócio, que estava por volta dos 360 bilhões de reais na década de 1990, em 2007 ultrapassou a marca dos 450 bilhões um acréscimo de 30% no período. A agricultura familiar constitui uma parcela bastante representativa deste ambiente. Em 2006, havia registrado mais de 5,2 milhões de estabelecimentos rurais em todo país, conforme IBGE, Censo Agropecuário A agricultura familiar é responsável por 77% da população ocupada no meio rural (GUANZIROLI et al., 2001). Em 2003 esse segmento era responsável por quase 33% do valor bruto da produção agropecuária e 10% do PIB nacional (GUILHOTO et. al., 2005).

15 15 É neste contexto que um projeto de software pode ser desenvolvido, a fim de atender a demanda, uma vez que as tecnologias da informação avançam sobre o setor do agronegócio brasileiro, inclusive sobre a agricultura familiar, especialmente por meio dos agricultores mais jovens. Neste contexto a implementação de software como serviço permite o rápido desenvolvimento e facilidade de integração com sistemas de gestão. Oferece excelente acesso às funções e aos negócios com baixa exigência de infra-estrutura de TI e baixo custo inicial se comparado com outros softwares. A propriedade do software continua com a empresa desenvolvedora. Em função disso reduz-se o custo de manutenção bem como o tempo. Desta forma a equipe de TI pode concentrar-se mais no desenvolvimento de inovações e novas aplicações, que são disponibilizadas aos usuários com maior freqüência, a custos viáveis. O conceito de Saas (Software as a Service) difunde-se rapidamente acompanhando o modelo de computação conhecido como cloud computing, ou computação nas nuvens. Este modelo é uma solução viável para as pequenas e médias empresas, oferecendo uma forma de acesso às tecnologias de software sem grandes investimentos em infra-estrutura e hardware. Sendo assim, é o modelo ideal de software a ser projetado e disponibilizado a todos os tamanhos de propriedades rurais, para a gestão das atividades agropecuárias. A ausência de sistemas de gestão de propriedades rurais limita o conhecimento que os proprietários tem em relação às movimentações de produção. Isto se refere a custos de produção, quantidade de insumos consumidos, quantidade produzida, faturamento com vendas, lucro líquido.

16 16 Munido das informações transacionais da propriedade o gestor, acompanhado de um técnico, seja ele agrônomo, ou veterinário, poderá realizar a análise dos dados a fim de gerar conhecimento que lhe capacitem no processo de tomada de decisão. 1.3 Metodologia Para o desenvolvimento do trabalho de conclusão do curso serão realizadas entrevistas, com profissionais da área de agronomia e veterinária, bem como com produtores rurais das áreas de agricultura e pecuária, e desta maneira realizar a coleta dos requisitos necessários para o projeto e modelagem do software. Com base nos requisitos coletados será realizada a modelagem do software através da UML (Unified Modeling Language), a fim de documentar de modo claro e conceitual o sistema, utilizando como ferramenta o UMLStúdio. 1.4 Organização do Trabalho Este trabalho está organizado em quatro capítulos, sendo o primeiro e o último, introdução e conclusão respectivamente. Nos capítulos dois e três, serão abordados respectivamente, aspectos relacionados à engenharia e modelagem de software, e a modelagem do sistema proposto. No capítulo dois serão abordados conceitos, definições, recomendações, para o processo de engenharia de software, bem como para a realização da modelagem do software, ou seja, o processo de documentação do projeto de software. No capítulo três será apresentada a modelagem, proposta para o desenvolvimento do software, conforme requisitos e necessidades levantadas junto aos agricultores, ou seja, o estudo de caso, razão deste trabalho.

17 17 2 ASPECTOS RELACIONADOS À ENGENHARIA E MODELAGEM DE SOFTWARE A evolução dos produtos baseados em computador, e recentemente, pela mais ampla gama de produtos desenvolvidos pela tecnologia moderna, tais como, televisores, celulares, Ipeds, Ipods, veículos, transformaram o software em um produto de primeira necessidade. A fim de atender esta imensa demanda de softwares dos mais variados tipos e utilidades cada vez mais se faz importante a aplicação de princípios desenvolvidos no decorrer do processo de evolução das técnicas de engenharia de software. A engenharia de software é uma disciplina que integra uma série de paradigmas propostos, cada um, exibindo potencialidades e fragilidades no processo de construção de sistemas informatizados. 2.1 Definição de software Com o advento da era da informática, há mais de 50 anos, surgiu uma necessidade cada dia mais presente em nossa vida, o software. Tornou-se o elemento chave dos sistemas e produtos para computadores, evoluindo de apenas uma ferramenta de análise de informações e resolução de problemas, para uma indústria em si. No entanto, ao longo da história da programação, o software tornouse um fator limitante na evolução dos sistemas informatizados. Pressman (1995). Software pode ser definido como um conjunto de programas, em linguagem capaz de interagir com a máquina, que quando executadas produzem a ação e o desempenho que esperamos. Apresenta estruturas de dados a fim de que os programas manipulem de forma adequada as informações. E ainda, documenta as operações e o uso dos programas. O software possui um conceito lógico, e não físico. Ao contrário do hardware, que ao ser desenvolvido, torna-se um objeto físico, podendo ser tocado, e ocupando lugar no espaço, o software é um elemento abstrato.

18 Tipos de Aplicação de Software Desde o surgimento do software observa-se uma grande ampliação de aplicações de software. E desta maneira novos tipos de aplicativos são criados rapidamente a fim de atender a demanda. Segundo Pressman (1995), a seguir serão exemplificadas e descritas algumas aplicações de software: - Software básico servem de apoio a outros programas. Como exemplo, podemos citar os compiladores, as ferramentas CASE, os drives que compõem os sistemas operacionais. Tem como características a interação direta com o hardware, utilização por múltiplos usuários, operações concorrentes, compartilhamento de recursos, estruturas de dados complexas e múltiplas interfaces externas. - Software de tempo real utilizado para monitoramento, análise, controle de eventos do mundo real. Este tipo de software é utilizado, por exemplo, em sistemas de monitoramento de distribuição, ou geração de energia elétrica, em UTIs nos hospitais. Tem como objetivo alertar quando algum fator envolvido desenvolve uma atividade fora do padrão estabelecido como aceitável. - Software comercial uma das maiores áreas de aplicação de software. Utilizado por exemplo nas áreas de contabilidade, folha de pagamento, estoque, pontos de vendas. Tem como objetivo facilitar as relações comerciais, e tomadas de decisões administrativas. - Software científico e de engenharia caracteriza-se pelo processamento de números. Tem como aplicação, por exemplo, a análise de fadiga mecânica de automóveis, a dinâmica orbital de naves espaciais recuperáveis, biologia molecular, manufatura automatizada, dentre outras. - Software embutido este reside na memória somente de leitura e é usado para controlar sistemas em produtos de consumo, com funções

19 19 muito limitadas e particulares, tal como, forno de microondas, geladeiras, freios ABS dos veículos, dentre outros. - Software de computador pessoal com a disseminação do uso de computadores pessoais houve a necessidade de softwares para processamentos de textos, planilhas eletrônicas, computação gráfica, jogos, dentre centenas de outras aplicações do gênero. - Software de inteligência artificial faz uso de algoritmos nãonuméricos para resolver problemas complexos não favoráveis a computação. Mais usado em sistemas especialistas, jogos, dentre outras aplicações. Os exemplos de softwares citados anteriormente referem-se àqueles discutidos por Pressman (1995). No entanto ao longo deste tempo houve uma grande evolução no desenvolvimento de softwares. Com o advento do Cloudcomputing (computação nas nuvens) uma nova forma de oferta de software observase nos dias atuais. O Software as a Service (SaaS), ou software como serviço Software como Serviço O software como serviço, ou Software as a Service (SaaS) ganha força nos dias atuais, uma vez que, com a popularização da internet muitas empresas passaram a oferecer serviços on-line em seus servidores. Um exemplo desta forma de serviço é o Google-docs. Oferecendo programas para escritório, como editor de texto, planilha eletrônica, apresentações, desenhos e formulários o Google ajuda a tornar popular e mostrar as vantagens desta nova maneira de oferta de software. Os conceitos de SaaS (Software como um Serviço) e Haas (Hardware como um serviço) estão se difundindo rapidamente com o novo modelo de computação conhecido como cloud computing. Segundo Cambiucci (2009), Cloud computing ou computação na nuvem é um ambiente de processamento e armazenamento de dados massivo, de alta escalabilidade e alta disponibilidade, acessível via interfaces web como HTTP, REST e SOAP, instalado em datacenters de última geração espalhados pelo mundo.

20 20 Ainda, segundo Cambiucci (2009), SaaS é um software distribuído como um serviço, implementado em plataforma web e acessado usando tecnologias e protocolos de internet. Do ponto de vista do usuário, é um software que não é instalado localmente na infra-estrutura do cliente, mas é utilizado através da web e pago pelo tempo de uso ou volume, por demanda. Assim, este tipo de software, SaaS, envolve mecanismos de tarifação e métricas de uso. A solução SaaS é indicada principalmente para pequenas e médias empresas pois permite que elas tenham acesso à boas soluções de tecnologia sem que façam grandes investimentos em hardware e infra-estrutura. O grande desafio para empresas comercializarem seus softwares como serviço é encontrar um serviço de Data Center que ofereça segurança e tranquilidade para o negócio do seu cliente e, consequentemente, para o seu negócio. Esta abordagem apresenta uma série de benefícios: Implementação mais rápida de aplicações, especialmente quando a integração com sistemas de gestão (Enterprise Resource Planning ERP) for otimizada; Excelente acesso às funções e aos negócios, com baixa exigência de infra-estrutura de TI e custos iniciais reduzidos em relação a outras opções de software; Mais flexibilidade para se adaptar às mudanças durante ciclos de negócio e de vendas; Menor custo total de propriedade devido à manutenção terceirizada de infra-estrutura não essencial e a orçamentos de manutenção com contratos de serviço; Mais tempo para a equipe de TI se concentrar em inovação e criar novas aplicações, dedicando-se menos a manutenção, suporte e gerenciamento de software;

21 21 Maior adoção por parte dos usuários e melhor desempenho, explorando aplicações SaaS que os usuários ajudaram a criar; O dono do software continua sendo a empresa que a produziu e seus clientes sempre terão a solução mais atualizada a custos viáveis. Fatores importantes a serem considerados: Experiência da equipe do Data Center com projetos que exijam alta disponibilidade e alta performance; Processos e procedimentos bem definidos e sistematizados; Equipe de atendimento qualificada; Suporte comercial para precificar os custos de infra-estrutura do Data Center em SaaS de acordo com o seu negócio ; Projetos customizados para o seu cliente; Problemas relacionados a Saas: A conexão Internet tem que funcionar; A banda passante baixa da Internet é limitante; Confidencialidade dos dados; Precisa de provedor ético; Pouca customização; Não resolve a questão para aplicações especiais das empresas; Dificuldade de integração com outras aplicações da empresa; Integração via Web Services;

22 Definição de Engenharia de Software A consolidação dos sistemas de informações, informatizados, e sua crescente expansão gerou uma nova demanda por métodos cada vez mais eficientes no desenvolvimento de softwares. Desta maneira desenvolveram-se ferramentas capazes de automatizar esses métodos, técnicas para garantir a qualidade do software e uma filosofia de coordenação predominante, controle e administração. Este conjunto de elementos forma a Engenharia de Software. Segundo Pressman (1995) a engenharia de software desenvolveu-se a partir das técnicas de engenharia de hardware. Compõem-na um conjunto de três elementos fundamentais métodos, ferramentas e procedimentos permitindo assim ao desenvolvedor o controle do processo de desenvolvimento para um software de alta qualidade. Os métodos ditam as diretrizes de como deve ser construído o software. Envolvem-se aí as tarefas de planejamento e estimativa do projeto, a análise dos requisitos do sistema, projeto de estruturas de dados, arquitetura do software, desenvolvimento dos programas, testes e manutenção. As ferramentas disponibilizam ao desenvolvedor uma forma automatizada ou semi-automatizada para o desenvolvimento e implementação dos métodos de desenvolvimento de sistemas informatizados. Enquanto isso, os procedimentos fazem a ligação entre métodos e ferramentas. Eles definem a sequência na qual os métodos serão aplicados. Definem critérios de controle a fim de assegurar a qualidade. Auxiliam na coordenação do desenvolvimento, permitindo avaliar o progresso. 2.4 Processo de Desenvolvimento de Software Um processo é considerado um conjunto de passos ordenados, constituído de atividades, métodos, práticas e transformações, usadas para atingir determinado resultado, uma meta.

23 23 O processo de desenvolvimento de software pode ser dividido em três fazes distintas, sendo elas: fase de definição, fase de desenvolvimento e fase de manutenção. Estas se aplicam a todos os processos de desenvolvimento independente da área de aplicação, ou da complexidade do sistema. Durante a fase de definição o desenvolvedor identifica o que deve ser feito. Neste momento se faz necessário conhecer o domínio do problema. Ou seja, é preciso conhecer o cenário onde o sistema informatizado irá atuar, e de que maneira ele irá resolver as necessidades do cliente. Segundo Pressman (1995) a fase de definição é composta de três etapas: Análise do Sistema nesta etapa é definido o papel de cada elemento num sistema informatizado. Planejamento do Projeto de Software aqui é definido o escopo do software, realizada a análise de riscos, os recursos são alocados, estimativa de custos e tarefas, e a definição da programação de trabalho. Análise de requisitos embora conhecido o domínio, neste momento se faz necessário uma definição detalhada das funções do software, antes do início do desenvolvimento. Na fase de desenvolvimento o desenvolvedor define como será realizada a implementação do sistema. Neste momento, tenta-se definir como a estrutura de dados e a arquitetura do software serão projetadas. Realiza-se a tradução do projeto para uma linguagem de programação, e por fim os testes que se julgarem necessários. Sendo assim, segundo Pressman, a fase de desenvolvimento pode ser dividida em três fases: Projeto de Software o projeto representa o conjunto de requisitos em uma linguagem gráfica, descrevendo a estrutura de dados, a arquitetura, o procedimento algorítmico e as características de interface.

24 24 Codificação nesta etapa as representações do projeto são implementadas em uma linguagem de programação. Assim são transformadas em linguagem de máquina as regras do negócio. Realização de Testes de Software assim que o projeto se transforma em um software, ou seja, que possa ser executado por uma máquina deve ser testado, a fim de que possam ser identificadas falhas de função, lógica e implementação. E por fim, na fase de manutenção concentram-se as mudanças associadas a correção de erros e adaptações exigidas pelo contexto do cliente. Conforme Pressman, são três os tipos de mudanças encontradas na fase de manutenção: Correção embora sejam adotadas as melhores práticas de desenvolvimento de software, é provável que sejam encontrados defeitos no software, e assim será necessária a manutenção corretiva a fim de corrigir defeitos do software. Adaptação com o tempo mudanças nas tecnologias disponíveis no ambiente original demandam a necessidade de mudanças, a fim de atender as necessidades do cliente. As adaptações decorrem ainda de mudanças na legislação, por exemplo. Melhoramento funcional a exigência de funções além das exigidas originalmente são demandadas, conforme o cliente for reconhecendo necessidades que oferecerão benefícios. 2.5 Atividades Para o Processo de software Um processo de software pode ser definido como um conjunto de atividades e resultados, que associados levam a produção de um software. Em um processo de desenvolvimento de software, o ponto de partida é a escolha de um modelo de arquitetura do ciclo de vida para o software.

25 25 Ao longo dos anos diferentes modelos de processos de software foram desenvolvidos por empresas, a partir de abordagens completamente distintas, tanto que, até mesmo dentro de uma determinada organização podem ser encontrados diferentes processos para o desenvolvimento de software. Apesar disso, de acordo com Sommerville (2005), algumas atividades fundamentais são comuns aos diferentes processos de software: Especificação de software - é preciso definir a funcionalidade do software e as restrições em sua operação. Projeto e implementação de software o software deve ser produzido de modo que cumpra a especificação. Validação de software o software precisa ser validado para garantir que faça o que o cliente deseja. Evolução de software o software precisa evoluir para atender às necessidades mutáveis do cliente Especificação de software Durante a atividade de especificação de software devem se estabelecidas as funções requeridas pelo sistema, bem como as restrições para o desenvolvimento do software. Segundo Sommerville (2005), a atividade de especificação pode ser definida como engenharia de requisitos. Esta atividade pode ser dividida em quatro fases: Estudo de viabilidade neste momento verifica-se se as necessidades do cliente podem ser satisfeitas pelas atuais tecnologias de software e hardware. Esta verificação tem por objetivo determinar se o projeto é viável do ponto de vista tecnológico. Da mesma maneira procura-se identificar a viabilidade econômico-financeira do projeto e assim decidir pela continuidade ou não do processo. Levantamento e análise de requisitos este processo tem como objetivo o levantamento de requisitos, através de conversas com o

26 26 cliente, ou pela observação dos sistemas já existentes. Neste momento pode-se envolver a prototipação de modelos permitindo ao analista uma melhor compreensão do sistema especificado. Especificação de requisitos nesta fase os requisitos são documentados. Os requisitos podem ser documentados do ponto de vista do usuário, ou seja, de uma forma abstrata, ou do ponto de vista do sistema, ou seja, detalhando as funcionalidades a serem fornecidas. Validação de requisitos aqui os requisitos são verificados a fim de identificar falhas no processo de coleta e especificação, permitindo assim a correção dos problemas. Figura 1. Engenharia de Requisitos (Sommerville, 2005) Projeto e implementação de software Nesta atividade o projeto é realizado, ou seja, transformado em um documento estruturado, de maneira iterativa a fim de acrescentar detalhes inicialmente ocultos, ou de corrigir falhas das versões anteriores. Na sequência realiza-se a implementação, que é o processo de conversão do projeto em um sistema executável. Segundo Sommerville (2005), algumas atividades específicas fazem parte do processo de desenvolvimento do projeto:

27 27 Projeto de arquitetura as relações entre os subsistemas que compõem o software são identificadas e documentadas. Especificação abstrata é realizada a definição das restrições e funções, dentro das quais cada subsistema deve operar. Projeto de interface as interfaces de cada subsistema e as corelações são projetadas e documentadas. Projeto de componentes são projetadas as interfaces dos componentes e alocadas funções a cada um deles. Projeto de estrutura de dados as estruturas de dados necessárias para a implementação do sistema são especificadas e projetadas em detalhe. Projeto de algoritmos os algoritmos a serem utilizados para implementação dos serviços do software devem ser especificados e projetados em detalhe. Figura 2. Processo de Projeto (Sommerville, 2005) Validação de software A atividade de validação do software constitui-se da aplicação de testes a fim de identificar falhas. O processo de testes deve ser implementado em paralelo com a implementação do sistema. Em sistemas pequenos, os testes podem ser realizados de maneira a envolver todo o software. No entanto, em grandes sistemas,

28 28 geralmente divididos em módulos compostos de procedimentos e funções, os testes devem ser realizados incrementalmente. Ainda segundo Sommerville (2005), o processo de testes pode ser dividido nos seguintes estágios: Teste de unidade os componentes são testados individualmente, a fim de garantir que operem corretamente. Teste de módulo módulos são compostos de coleções de componentes dependentes entre si e podem ser testados sem outros módulos do sistema. Teste de subsistema nesta fase os módulos integrados em subsistemas são testados. Um dos principais problemas encontrados neste tipo de teste são as discordâncias de interfaces. Sendo assim é nisso que o testador deve deter-se neste tipo de teste. Teste de sistema neste momento o sistema encontra-se pronto, ou seja, com os subsistemas integrados. Prioriza-se aqui a detecção de erros de interface entre as ligações dos subsistemas. Procura-se validar os requisitos funcionais e não-funcionais. Teste de aceitação é o estágio final da atividade de validação. O sistema pode enfim ser testado com dados fornecidos pelo cliente. Nesta fase revelam-se erros e omissões da fase de definição de requisitos, ou até mesmo problemas de recursos do sistema que não atendem a necessidade do usuário e quanto a desempenho inaceitável do software.

29 29 Figura 3. Processo de Testes (Sommerville, 2005) Evolução de software A evolução dos sistemas de software tem feito com que sistemas que eram operados individualmente estão sendo integrados em sistemas cada vez maiores e mais complexos. Contudo, esta prática tem eliminado redundâncias de dados, que eram armazenados repetidamente em bancos de dados diferentes para cada sistema. O processo de desenvolvimento de software é considerado uma atividade criativa desenvolvido de um conceito inicial até chegar ao sistema em operação. A manutenção de software é o ato de modificar o sistema inicialmente construído. Geralmente o custo para a manutenção de um software é mais alto do que para o desenvolvimento. Apesar disso a atividade de manutenção é considerada menos desafiadora do que o desenvolvimento de um software original. Contudo, este limite, tem se tornado irrelevante. Poucos são os sistemas completamente novos. Neste sentido, os processos de desenvolvimento e manutenção são considerados contínuos e integrados.

30 30 Sendo assim, a engenharia de software é um processo de evolução, onde o software é continuamente modificado, adaptando-se às necessidades do cliente. Figura 4. Evolução de Sistema (Sommerville, 2005) 2.6 Modelos de Processo de Software Um modelo de processo de software é a representação abstrata de um processo de software a partir de uma perspectiva particular. Para Sommerville (2005), em muitos sistemas de grande porte não existe apenas um processo de software que possa ser utilizado. Sendo assim, até mesmo em um único projeto, diferentes processos poderão ser utilizados. Por isso o importante não é escolher o melhor modelo, o mais atual, mas escolher àquele que melhor se adapta ao problema a ser resolvido. Para tanto existe o analista que de posse do conhecimento do potencial de cada modelo saberá conduzir a análise e o projeto da melhor forma possível (Alcântara, 2008). Para Peters e Pedrycz (2001), os modelos de processos de software representam o ciclo de vida de um software. Os principais modelos de processo de software são: Modelo Cascata. Modelo de Prototipação. Modelo Espiral.

31 31 Modelo do Ciclo Evolutivo. Modelo RUP (Rational Unified Process) Modelo Cascata O modelo cascata foi o primeiro a ser desenvolvido para o gerenciamento dos processos de software e que deu origem a formalização do mesmo, desencadeando o surgimento dos demais. Segundo Pressman (1995), o modelo cascata é chamado muitas vezes de paradigma para o ciclo de vida, requerendo uma abordagem sistemática e sequencial no desenvolvimento do software. Tem início no nível do sistema e avança ao longo da análise, projeto, codificação, teste e manutenção. Representado de diferentes formas, por Pressman, Sommerville, Peters e Pedrycs, o primeiro mostra o ciclo de vida clássico, como também é chamado, da seguinte forma: Figura 5. Modelo Cascata (Pressman, 1995) Análise e engenharia de sistemas o software sempre faz parte de um sistema. Desta maneira o trabalho tem início estabelecendo-se os requisitos para todos os elementos que integram o sistema. Os requisitos devem ser agrupados em subconjuntos de acordo com suas características. Neste momento do desenvolvimento há uma pequena quantidade de projeto e análise de alto nível.

32 32 Análise de requisitos de software concentra-se a análise de requisitos especificamente no software. A fim de especificar a natureza dos programas a serem implementados o desenvolvedor deverá ter o domínio da informação para o software, bem como a função, desempenho e interface exigidos. Os requisitos de sistema e de software devem ser documentados e revisados com o cliente. Projeto é um processo que se concentra na estruturação dos dados, arquitetura do software, detalhes procedimentais e na caracterização da interface. Envolve a descrição das abstrações fundamentais do sistema de software e suas relações. Codificação na etapa de codificação o projeto é traduzido em linguagem de máquina a fim de que possa ser executado em um computador. Testes assim que o código é gerado inicia-se a realização de testes do programa. Concentra-se na estrutura interna do programa, através dos aspectos lógicos, bem como nos aspectos funcionais externos, a fim de garantir que os resultados obtidos correspondam aos resultados esperados. Manutenção sem dúvidas, o software sofrerá alterações mesmo depois de entregue ao cliente. Pode ser necessária em função de erros encontrados, ou por necessidades de adaptação em função de mudanças no ambiente externo, tais como, mudança de tecnologia de sistema operacional, por exemplo; mudanças políticas que afetem a legislação, dentre outros motivos. Peters e Pedrycz (2001) citam vantagens e desvantagens deste modelo. Dentre as vantagens destaca: Permite a gerência do baseline, que identifica um conjunto fixo de documentos produzidos como resultado de cada fase do ciclo de vida; O projeto desencadeia em uma sequência lógica de desenvolvimento;

33 33 Dentre as desvantagens cita: O modelo cascata não deixa claro como seria possível descobrir as intenções dos projetistas de sistemas legados, ou seja, o processo de engenharia reversa. O cliente deve esperar até a fase de instalação e liberação para ver como o sistema funciona. Não permite o desenvolvimento incremental Modelo de Prototipação Segundo Pressman (1995), muitas situações de desenvolvimento em que o cliente não tem convicção de suas reais necessidades, ou que o desenvolvedor não confia na eficiência de um algoritmo, na adaptação do software ao sistema operacional ou na forma de interação homem-máquina, pode ser abordada a prototipação a fim de conseguir a representação da melhor abordagem para o sistema. A prototipação capacita o desenvolvedor a criar modelos de software que podem assumir três formas: um protótipo em papel ou um modelo baseado em computador; um protótipo de trabalho implementando um subconjunto das funções exigidas pelo software ideal; um programa capaz de executar parte ou toda a função desejada com características que serão melhoradas em novos esforços de desenvolvimento.

34 34 Figura 6. Prototipagem - Adaptado de Paula Filho (2003). Alcântara cita vantagens e desvantagens do Modelo Prototipação: Vantagens: Neste processo, os Clientes participam com os desenvolvedores, do processo, ajudando a definir as necessidades relacionadas com o software e a cada passagem os dados vão sendo inseridos no sistema de forma continua, sem preocupação com as fases do processo de software. Desvantagens: Alguns clientes não entendem que protótipo é algo que deverá ser melhorado, testado com maior rigor, querendo que o mesmo já entre em pleno funcionamento; Alguns desenvolvedores para satisfazer os clientes colocam o mesmo em funcionamento, deixando para fazer acertos posteriormente, mas esquecem, e o que era um mero protótipo torna-se um produto que certamente terá problemas posteriormente.

35 35 O maior problema deste processo é convencer o cliente que o programa que esta à sua frente não é um software pronto, mas apenas um modelo com pouca funcionalidade e que levará algum tempo e recursos (financeiros, materiais, humanos, etc) para ser concluído Modelo Espiral De acordo com Sommerville (2005), no processo espiral, cada loop na espiral representa uma fase do processo de software. Sendo assim, o loop mais interno relaciona-se à viabilidade do sistema; o loop seguinte, à identificação dos requisitos; na sequência o projeto do sistema, e assim sucessivamente. Cada loop na espiral é representado por quatro quadrantes: Definição de objetivos para cada fase do projeto são definidos e especificados os objetivos. Estabelecidas as restrições do processo e do produto, bem como preparado um plano de gerenciamento detalhado. Identificam-se os riscos do projeto, e de acordo com isso, se necessário, são estabelecidas estratégias alternativas. Avaliação e redução de riscos para cada risco identificado, realizase uma análise detalhada e são tomadas as providências. Por exemplo, no caso de riscos de requisitos inadequados, a solução adotada poderá ser o desenvolvimento de um protótipo. Desenvolvimento e validação após a avaliação de riscos, um modelo de desenvolvimento para o sistema é definido. Planejamento realiza-se a revisão do projeto e decide-se pela continuação no próximo loop da espiral. Desta maneira são traçados planos para a próxima fase do projeto.

36 36 Figura 7. Modelo espiral (Sommerville, 2005) Alcântara cita vantagens e desvantagens do Processo Espiral. Vantagens: Permite a constante implementação do sistema. Sua evolução se dá com o passar do tempo, passando sempre pelos quatro quadrantes, o que difere um pouco das metodologias anteriores que até pode-se voltar, mas o normal delas é sempre a seqüência ao nível posterior. O cliente/usuário está sempre presente no desenvolvimento do sistema interagindo com os desenvolvedores constantemente. A cada avaliação por parte do cliente/usuário, em cada volta no espiral o sistema pode ou não prosseguir, avaliando-se os riscos. Se os riscos forem significativos o sistema poderá ser cancelado imediatamente. Este aspecto é muito importante e torna-a diferente de outras metodologias.

37 37 Na atualidade aplica-se ao desenvolvimento de aplicações em grande escala. Usa uma abordagem evolucionária, capacitando o desenvolvedor e o cliente/usuário a entender e a reagir aos riscos em cada etapa evolutiva. Desvantagens: É mais utilizado em sistemas grandes. Por isso há dificuldade em convencer grandes clientes, principalmente em situações de contrato, de que a abordagem evolutiva é controlável, porque o mesmo normalmente não tem interesse de começar um desenvolvimento e abandoná-lo pela metade Modelo Ciclo Evolutivo De acordo com Peters e Pedrycz o ciclo evolutivo propõe o desenvolvimento do software através de múltiplas versões. Este modelo impõe uma sobreposição contínua de atividades de desenvolvimento, produzindo assim uma sucessão de versões do software. Segundo Peters e Pedricz, et al (Lehman e Belady, 1985) foram encontradas cinco propriedades de sistemas de software que motivaram o modelo do ciclo de vida de software evolutivo, conforme resumo da tabela abaixo: Tabela 1: Propriedades da Evolução do Software (Peters e Pedrycz, 2001) Propriedade do Sistema de Software Mudança contínua, degradação Complexidade crescente Evolução do programa Taxa de trabalho invariável (projetos Base Os sistemas de software sofrem mudanças e se degradam continuamente, tornando-se cada vez menos úteis. Devido às contínuas mudanças, a complexidade do software aumenta. Os programas, os processos de programação, as medidas de projeto e os atributos de sistema são estatisticamente auto-reguladores, como tendências e invariantes determináveis. A taxa de atividade em grandes projetos de software é estatisticamente invariável (por exemplo, uma propriedade

38 38 grandes) Limite de crescimento incremental (projetos grandes) com a média de mudanças por ciclo é aproximadamente a mesma). Durante a vida de um grande sistema de software, o volume das modificações em sucessivas versões é estatisticamente invariável O trabalho de desenvolvimento no ciclo evolutivo reflete em cada versão a experiência e o conhecimento adquiridos durante o processo das versões anteriores. Sommerville cita dois tipos de desenvolvimento evolucionário: Desenvolvimento exploratório tem como objetivo o trabalho com o cliente, explorando os requisitos até a entrega de um sistema final. Tem início na compreensão das partes que integrarão o sistema, evoluindo com novas características, à medida que são propostas pelo cliente. Fazer protótipos descartáveis visa compreender os requisitos do cliente e desenvolver uma melhor definição de requisitos para o sistema. Concentrando-se em experimentos, através de protótipos, com partes dos requisitos que tenham sido mal compreendidos. Vantagens e desvantagens do Ciclo Evolutivo: Vantagens: Podem atender as necessidades imediatas do cliente. A abordagem evolucionária pode desenvolver a especificação do software gradativamente. Reflete a integração do usuário e desenvolvedor no processo de desenvolvimento do sistema de software. Desvantagens: O processo não é visível uma vez que para sistemas desenvolvidos rapidamente não é viável produzir documentos para cada versão.

39 39 A mudança constante tende a produzir sistemas mal estruturados, onde incorporar modificações torna-se difícil e oneroso. Caso sejam exigidas ferramentas e técnicas específicas podem tornar o sistema incompatível com outras reduzindo a amplitude de pessoal e ferramentas habilitadas para o processo Modelo RUP (Rational Unified Process) De acordo com Pádua Paula Filho, o processo unificado apresenta algumas características centrais: É dirigido por casos de uso; Centrado na arquitetura; Iterativo e incremental. O ciclo de vida do processo unificado tem como representação uma espiral. Nele cada projeto constitui um ciclo, que tem ao final um produto a ser liberado. No processo unificado as atividades técnicas são divididas em subprocessos através de fluxos de trabalho. O processo unificado é dividido em fases conforme a tabela abaixo: Tabela 2: Fases do processo unificado, Pádua Paula Filho, Fase Descrição Concepção Elaboração Construção Transição Fase na qual se justifica a execução de um projeto de desenvolvimento de software, do ponto de vista do negócio do cliente. Fase na qual o produto é detalhado o suficiente para permitir um planejamento acurado da fase de construção. Fase na qual é produzida uma versão completamente operacional do produto. Fase na qual o produto é colocado à disposição de uma comunidade de usuários. O processo unificado é composto de fluxos do processo:

40 40 Tabela 3: Fluxos do processo unificado, Pádua Paula Filho, Fluxo Descrição Requisitos Análise Desenho Fluxo que visa obter um conjunto de requisitos de um produto, acordado entre cliente e fornecedor. Tem como objetivo detalhar, estruturar e validar os requisitos, de forma que esses possam ser usados como base para o planejamento detalhado. O objetivo é formular um modelo estrutural do produto que sirva de base para a implementação. Implementação Fluxo cujo objetivo é realizar o desenho em termos de componentes de código. Testes Tem como objetivo verificar os resultados da implementação. Alcântara apresenta vantagens e desvantagens do Processo RUP. Vantagens: É orientado a caso de uso (requisitos), Tem como principal elemento a arquitetura do sistema, é Iterativo e incremental (versões) e é intimamente ligado a UML. Neste processo é evidenciado o desenvolvimento do software durante a construção do mesmo, embasado desde a modelagem de negócio até a transição mostrando todos os profissionais envolvidos no processo. Desvantagens: Utilizado para sistemas grandes, custo elevado. 2.7 Gerenciamento de Riscos Durante o processo de desenvolvimento de um sistema, uma tarefa indispensável é prever os riscos relacionados com o projeto. Os riscos estão relacionados com possíveis adversidades que venham afetar o desenvolvimento do projeto.

41 41 Segundo Sommerville, três categorias de riscos podem afetar o desenvolvimento do software: Riscos relacionados ao projeto afetam a programação ou os recursos do projeto. Riscos relacionado ao produto atingem a qualidade ou o desempenho do software em desenvolvimento. Riscos para os negócios afetam a organização de está desenvolvendo ou adquirindo o software. A maioria dos projetos possui incertezas inerentes ao desenvolvimento. Sendo assim, o gerenciamento dos riscos é uma tarefa fundamental para o sucesso projeto. O gerenciamento dos riscos parte da identificação dos mesmos. Os riscos decorrem, por exemplo, de requisitos mal definidos, erros na estimativa do prazo e dos recursos necessários, sejam humanos ou tecnológicos. A gerência de riscos depende da elaboração de planos de contingência. Desta maneira, caso um evento ocorra, haverá estabelecido passos que visem a recuperação. O processo de gerenciamento de riscos envolve alguns estágios, de acordo com Sommerville (2005): Identificação de riscos os riscos de produto, projeto e negócio são identificados. Análise de riscos as conseqüências e as possibilidades dos riscos são avaliadas. Planejamento de riscos é traçado o plano para evitar ou minimizar as consequências da ocorrência do risco.

42 42 Monitoramento de riscos a avaliação do risco deve ser constante, e o plano de contingência constantemente revisado à medida que novas informações sobre o mesmo forem coletadas. Segundo Pressman (1995), os passos de administração de riscos devem ser organizados em um Plano de Administração e Monitoração de Riscos. O plano tem como objetivo garantir que durante o rastreamento do projeto seja possível identificar se um risco previsto de fato ocorre; que os passos de reversão definidos para o risco estejam sendo adequadamente aplicados; e coletar informações que possam ser usadas em análises de risco futuras Identificação de riscos O gerenciamento de riscos tem início na fase de identificação. Neste momento os riscos são apenas detectados. Não se aplica aqui nenhum tipo de avaliação ou classificação. O processo de identificação de riscos pode ser realizado em equipe. Sommerville (2005) destaca uma lista de possíveis riscos que auxiliam no processo: Riscos de tecnologia refere-se a tecnologia de software, hardware, redes, envolvidos no processo de desenvolvimento. Risco de pessoal são riscos associados às pessoas, tais como, conhecimento, motivação, envolvimento do pessoal para o alcance do objetivo. Riscos organizacionais derivam do ambiente organizacional onde o software está sendo desenvolvido. Riscos de ferramentas tem origem nas ferramentas utilizadas como apoio no desenvolvimento. Riscos de requisitos decorrem da modificação dos requisitos do cliente, e do processo de gerenciamento da modificação dos requisitos. Riscos de estimativa associam-se as estimativas sobre as características do sistema e dos recursos necessários para construí-lo.

43 Análise de riscos De acordo com Sommerville (2005), no processo de análise de risco, cada risco é identificado e considerado individualmente. É necessário julgar a probabilidade e a seriedade no caso do risco ocorrer. A probabilidade de um risco ocorrer pode ser classificada como segue: - Muito baixa (menor que 10%); - Baixa (de 10% a 25%); - Moderada (de 25% a 50%); - Alta (de 50% a 75%); - Muito alta (acima de 75%). Os efeitos do risco podem ser determinados como: - Catastróficos; - Sérios; - Toleráveis; - Insignificantes. Uma vez que os riscos são identificados e analisados deve ser determinado quais são prioritários, em função da probabilidade de ocorrência e dos efeitos que ele pode causar Planejamento de Riscos O processo de planejamento de riscos deve demonstrar as principais estratégias identificadas para a administração dos riscos prioritários. Conforme Sommerville (2005) as estratégias podem ser classificadas em três categorias:

44 44 Estratégias preventivas tem como objetivo reduzir a probabilidade do risco ocorrer. Estratégias de minimização tem como objetivo minimizar o impacto caso um risco venha a se concretizar. Planos de contingência neste caso, se um dos riscos vier a ocorrer, a empresa desenvolvedora estará preparada, e terá uma estratégia pronta para lidar com o caso Monitoramento de Riscos Esta estratégia de gerenciamento de riscos visa avaliar regularmente cada risco individualmente. Tem como objetivo estimar a probabilidade de um risco ocorrer. O monitoramento deve ser contínuo. Realizado pela gerência, os riscos principais devem ser considerados individualmente em reuniões. 2.8 Requisitos de Software Ao iniciar o desenvolvimento de um software, a atividade de análise de requisitos para um sistema de informações para computador, é fundamental para o sucesso do projeto. Pressman (1995) diz que a tarefa de análise de requisitos é um processo de descobertas, refinamento, modelagem e especificação. Esta tarefa efetua a ligação entre o projeto de software e o sistema que está sendo estudado em nível de software. Proporciona ao engenheiro de software a representação da informação e funções a serem traduzidas em um projeto procedimental, arquitetônico e de dados. Permite assim, que desenvolvedor e cliente possuam critérios de avaliação de qualidade assim que o software estiver concluído. Peters e Pedrycz definem requisitos de software: Um requisito de software é uma descrição dos principais recursos de um produto de software, seu fluxo de informações, comportamento e atributos. Em suma, um requisito de software fornece uma estrutura básica para o

45 45 desenvolvimento de um produto de software. O grau de compreensibilidade, precisão e rigor da descrição fornecida por um documento de requisitos de software tende a ser diretamente proporcional ao grau de qualidade do produto resultante. (Peters e Pedrycz, 2001, pg. 102). Para Martins (2005), requisito é: Uma característica ou capacidade que o sistema precisa apresentar. O projeto precisa ser planejado e conduzido de modo a incorporar facilmente as mudanças, identificando os requisitos mais importantes, que tem maior influência no custo e nos aspectos técnicos. O desafio do gerenciamento de requisitos está no fato de que os requisitos são dinâmicos e mudam durante a vida do projeto (Martins 2005, pg. 174). O termo requisito pode representar um requisito que é visto como uma declaração abstrata de alto nível, uma função implementada pelo sistema ou uma restrição. Opondo-se a isso, pode representar uma definição detalhada, formal, de uma função do sistema. Sommerville (2005) et al Davis (1993) explica por que essas diferenças existem: Se uma empresa deseja estabelecer um contrato para o desenvolvimento de um grande projeto de software, ela tem de decidir suas necessidades de maneira suficientemente abstrata para que uma solução não seja predefinida. Os requisitos devem ser redigidos de modo que os diversos fornecedores possam apresentar propostas, oferecendo talvez, diferentes maneiras de atender às necessidades organizacionais do cliente. Uma vez estabelecido um contrato, o fornecedor precisa preparar uma definição de sistema para o cliente, com mais detalhes, de modo que o cliente compreenda e possa validar o que o software fará. Esses dois documentos podem ser chamados de requisitos do sistema (Sommerville 2005, pg. 82). Os requisitos podem ser avaliados e descritos do ponto de vista do usuário, de uma forma abstrata, ou então do ponto de vista do sistema, de forma detalhada. No entanto o maior nível de detalhe consegue-se com a especificação do projeto de software.

46 46 Requisitos do usuário podem ser representados através de diagramas ou da linguagem natural, descrevendo as funções oferecidas pelo sistema e quais as restrições a ele imputadas. Requisitos de sistema detalham as funções e restrições do sistema de maneira precisa. Serve como contrato entre desenvolvedor e comprador, a partir do qual será possível avaliar se as partes cumpriram com o que se propuseram. Especificação de projeto de software descreve de maneira abstrata o projeto, acrescentando detalhes à especificação de requisitos Requisitos de Usuário Os requisitos de usuário são compostos de requisitos funcionais e não funcionais (a classificação de requisitos será explicada no item 2.8.3), especificando o comportamento externo do sistema, descritos através de uma linguagem natural, utilizando-se de formulários e diagramas simples. Sommerville (2005) lista problemas decorrentes do uso de uma linguagem natural para a descrição dos requisitos: Falta de clareza a ambigüidade da linguagem pode dificultar o entendimento do documento. Confusão de requisitos os requisitos podem não estar claramente definidos. Fusão de requisitos vários requisitos são representados em um único requisito. Tendo como objetivo a clareza na expressão dos requisitos de usuário é importante que um padrão seja determinado e seguido do início ao fim do projeto. É importante utilizar uma linguagem consistente, distinguindo requisitos obrigatórios dos desejáveis. Pontos importantes devem ganhar destaque em negrito ou itálico,

47 47 por exemplo. Deve-se evitar o uso de expressões comuns à informática, ou seja, termos técnicos Requisitos de Sistema Os requisitos do sistema devem descrever de maneira detalhada os requisitos do usuário. Servem de base, e apoio ao processo de implementação do sistema. Sendo assim, devem especificar de maneira completa e detalhada todo o sistema. Representam para os engenheiros de software o ponto inicial do projeto de sistema. Para descrever os requisitos de sistema pode ser utilizada a linguagem natural. Contudo a ambigüidade que a ela se impõe, requer que para maior clareza sejam associadas alternativas que adicionam estrutura à especificação, auxiliando na compreensão. Sommerville (2005) et al Davis (1990) retrata notações para a especificação de requisitos: Tabela 4: Notações para especificação de requisitos (Sommerville, 2005). Notação Descrição Linguagem estruturada natural Esta abordagem depende da definição de formulários-padrão ou templates para expressar a especificação de requisitos. Linguagem de descrição de projeto Notações gráficas Especificações matemáticas Utiliza uma linguagem como a de programação, no entanto, com recursos mais abstratos para especificar os requisitos pela definição de um modelo operacional do sistema. Uma linguagem gráfica, complementada por anotações textuais, é usada para definir os requisitos funcionais do sistema. Por exemplo, os diagramas de casos de uso, propostos por Jacobson et al Suas notações são baseadas em modelos matemáticos, como uma máquina de estados finitos e conjuntos. Estas notações não ambíguas reduzem as discussões entre cliente e fornecedor sobre a funcionalidade do sistema. Contudo, a maioria dos clientes não compreende as especificações formais e reluta em aceitá-las no momento de uma contratação de sistema Classificação de Requisitos Sommerville (2005) classifica os requisitos conforme segue:

48 48 Requisitos funcionais são declarações de funções do sistema. Descreve o que o sistema deve fazer, e até mesmo o que não deve fazer. Sua especificação deve ser completa e consistente, ou seja, todas as funções requeridas pelo usuário devem estar definidas, e não podem ser contraditórias. Contudo esta é uma tarefa difícil de ser plenamente atendida, especialmente em sistemas grandes e complexos. Sendo assim, a medida que são identificados, os problemas devem ser sanados, corrigindo os requisitos. Requisitos não funcionais representam as restrições dos serviços oferecidos pelo sistema, tais como, restrições de tempo, processo de desenvolvimento, padrões, dentre outros. Devem ser expressos quantitativamente, utilizando-se métricas que possam ser objetivamente testadas. Tabela 5: Especificação Requisitos não Funcionais (Sommerville, 2005). Propriedade Velocidade Tamanho Facilidade de Uso Confiabilidade Robustez Portabilidade Métrica Transações processadas/segundo Tempo de resposta ao usuário/evento Tempo de refresch da tela Kbytes Número de chips de RAM Tempo de treinamento Número de frames de ajuda Tempo médio para falhar Probabilidade de indisponibilidade Taxa de ocorrência de falhas Disponibilidade Tempo de reinício depois de uma falha Porcentagem de eventos que causam falhas Probabilidade de corrupção de dados por falhas Porcentagem de declarações dependentes do sistema-alvo Número de sistemas alvo

49 49 Requisitos de domínio tem origem no domínio da aplicação do sistema, refletindo as características do domínio, e podem ser funcionais ou não funcionais. 2.9 Engenharia de Requisitos O processo de engenharia de requisitos envolve as atividades necessárias para criar e manter os requisitos do sistema. De acordo com Sommerville (2005), existem quatro atividades no processo de engenharia de requisitos: Estudo da viabilidade dos requisitos; Obtenção e análise de requisitos; Especificação e documentação de requisitos; Validação de requisitos. Abaixo o modelo de processo de engenharia de requisitos apresentado por Sommerville (2005): Figura 8. Processo Eng. de Requisitos

50 Estudo de Viabilidade dos Requisitos O processo de engenharia de requisitos tem início com o estudo de viabilidade. Descrevendo-se de maneira geral todos os processos da organização que deverão estar contemplados no sistema. A partir disso pode-se desenvolver um relatório recomendando a viabilidade ou inviabilidade de desenvolvimento do sistema. Sommerville (2005) recomenda que no estudo de viabilidade estejam respondidas algumas perguntas: O sistema contribui para os objetivos gerais da organização? O sistema pode ser implementado com a utilização de tecnologia atual dentro das restrições de custo e prazo? O sistema pode ser integrado com outros sistemas já em operação? Antes de iniciar o desenvolvimento de um software é fundamental saber se ele contribui para o desenvolvimento da organização na qual será inserido. Embora esta seja uma questão imprescindível, isto nem sempre ocorre, em função de falta de objetivos claros, ou por decisões políticas e organizacionais que influenciam na aquisição e implantação do sistema. É no estudo de avaliação da organização que as questões anteriores serão respondidas. Contudo, para certificar-se de que o estudo está correto é preciso questionar as fontes envolvidas no processo. Novamente, Sommerville (2005), exemplifica as questões a serem levantadas neste momento do processo: Como a organização de comportaria se esse sistema não fosse implementado? Quais os problemas com os processos atuais e como o novo sistema ajudará a resolver? Como o sistema contribuirá para os objetivos da empresa?

51 51 As informações podem ser transferidas para outros sistemas organizacionais ou podem ser obtidas a partir deles? O sistema requer novas tecnologias, não testadas ainda pela organização? O que é necessário que seja ou não compatível com o sistema? Servirão de fontes de informações os gerentes, usuários finais do sistema, diretores, engenheiros de software, especialistas em tecnologia, durante o estudo de viabilidade, possibilitando assim a correta identificação das informações necessárias. Ao final deste estudo um relatório deve apresentar a recomendação para o desenvolvimento ou não do sistema. Bem como propor novo enfoque, alteração no orçamento e cronograma, além de apresentar novos requisitos de alto nível para o sistema Obtenção e análise de requisitos Tendo concluído os estudos de viabilidade a próxima etapa do processo de engenharia de requisitos é o levantamento e análise de requisitos. Com o objetivo de levantar informações mais detalhadas e precisas sobre o domínio da aplicação, sobre os serviços que o sistema deve disponibilizar, restrições de hardware, desempenho exigido para o sistema, a equipe de desenvolvimento deverá trabalhar juntamente com o cliente e usuários a fim de garantir a obtenção do resultado esperado. Segundo Sommerville (2005), o levantamento e análise de requisitos são um processo difícil em função das seguintes razões: Cliente e usuários não sabem exatamente o que necessitam para o sistema informatizado. Geralmente encontram dificuldade em transmitir o que querem que o sistema execute. Podem realizar solicitações inviáveis pela complexidade ou custo, para o desenvolvimento de seus pedidos.

52 52 Os desenvolvedores podem ter dificuldade de compreender os requisitos do cliente, uma vez que eles são transmitidos em uma linguagem nos termos do conhecimento da sua área de atuação. Os usuários ou clientes tem em mente inúmeros requisitos e que podem ser expressos de maneira distinta. Sendo assim cabe ao engenheiro de requisitos encontrar os conflitos e pontos em comum. Fatores políticos podem afetar o levantamento dos requisitos, uma vez que gerentes da organização podem definir requisitos específicos com objetivo de aumentar sua influência na organização. O ambiente externo, político e econômico, em que se dá o levantamento de requisitos, são dinâmicos e inevitavelmente modificase durante o processo. Desta maneira requisitos específicos podem não ser mais importantes, enquanto que outros surgem no decorrer do processo. O processo de levantamento e análise de requisitos, segundo Sommerville (2005), pode ser realizado através do desenvolvimento das atividades descritas abaixo: Compreensão do domínio ao iniciar o processo de desenvolvimento de um sistema informatizado a primeira atividade do analista é conhecer e compreender o domínio da aplicação. Ou seja, conhecer o ambiente e ter domínio do sistema que envolve o processo da organização onde o sistema informatizado deverá atuar. Coleta de requisitos é nesta atividade que a compreensão do domínio da aplicação se dá de maneira mais detalhada. Atividade esta, na qual a interação com o cliente e usuários resulta na descoberta dos requisitos. Classificação nesta atividade os requisitos são organizados e estruturados de forma coerente.

53 53 Resolução de conflitos quando diferentes pessoas estão envolvidas no processo, inevitavelmente levantarão requisitos conflitantes. É nesta atividade que o analista devera identificar e solucionar os conflitos. Definição das prioridades dentro de qualquer conjunto de requisitos serão identificados aqueles que são mais importantes e relação aos demais. Esta atividade envolve a interação com os usuários e clientes a fim de identificar os requisitos mais importantes. Verificação de requisitos nesta atividade os requisitos são verificados, a fim de descobrir se eles são completos e consistentes e se estão em concordância com o que o cliente realmente deseja Princípios de Especificação A especificação de requisitos de software pode ser representada através da linguagem natural e gráfica, a fim de subsidiar uma implementação bem sucedida do software. Os requisitos de software devem ser representados de forma que possam ser compreendidos pelo diversificado conjunto de usuários que compõem o processo de desenvolvimento de um software. Sommerville (2005) et al Katonya e Sommerville, 1998, citam os possíveis usuários e como eles utilizam o sistema: Tabela 6: Usuários e Requisitos - inter-relações. Usuários Como os usuários utilizam o documento de requisitos Clientes do sistema Gerentes Engenheiros de sistema Engenheiros de teste de sistema Engenheiros de Especificam os requisitos e os lêem para verificar se eles atendem a suas necessidades. Especificam as mudanças nos requisitos. Utilizam o documento de requisitos para planejar um pedido de proposta para o sistema e para planejar o processo de desenvolvimento do sistema. Utilizam os requisitos para compreender que sistema deve ser desenvolvido. Utilizam os requisitos para desenvolver testes de validação do sistema. Utilizam os requisitos para ajudar a compreender o sistema e as

54 54 manutenção de sistema relações entre suas partes. Ainda em Sommerville (2005) et al Heninger (1980), define que um documento de requisitos de software deve satisfazer os seguintes critérios: Especificar somente o comportamento externo do sistema; Especificar as restrições à implementação; Ser fácil de ser modificado; Servir como uma ferramenta de referência para os responsáveis pela manutenção do sistema; Registrar a estratégia sobre o ciclo de vida do sistema; Caracterizar respostas aceitáveis para eventos indesejáveis. Pressman (1995) et al Balzer e Goldman propõem oito princípios para uma boa especificação do projeto de software. - Primeiro separar funcionalidade de implementação. Deve-se inicialmente realizar a descrição geral daquilo que pretende-se desenvolver, evitando neste momento descrever as maneiras pelas quais deve ser realizado a implementação do software. O resultado deste princípio é obter o que ao invés de como. - Segundo exige-se uma linguagem de especificação de sistemas orientada ao processo. Na descrição orientada ao processo a especificação o que é obtida a partir de um modelo de comportamento desejado para os modelos funcionais em relação ao ambiente em que se aplicam, representando o comportamento do sistema. - Terceiro a especificação deve representar o sistema do qual o software paz parte.

55 55 O comportamento de um determinado componente do software somente poderá ser definido em função do contexto do sistema que ele compõem. A modelagem do sistema pode ser representada como uma coleção de objetos passivos e ativos, denominados agentes, inter-relacionados, que ao longo do tempo sofrem modificações, mediante estímulos aos quais os agentes podem reagir. - Quarto o ambiente no qual o sistema opera deve estar especificado. Deve-se especificar o ambiente no qual o sistema opera e com o qual interage. O sistema composto de objetos passivos e ativos deve ser reconhecido. A especificação do ambiente permite que as interfaces sejam determinadas assim como o próprio sistema sem a introdução de qualquer outro formalismo. A especificação deve retratar de forma precisa o ambiente e como ele é percebido pelos usuários, em detalhes, de maneira iterativa, permitindo que esta atividade possa ser realizada durante a fase de desenvolvimento inicial como também durante a fase de manutenção. - Quinto a especificação do sistema deve ser um modelo cognitivo. O projeto deve descrever o sistema como ele é visto pelos usuários. Os objetos devem corresponder ao domínio, representando as pessoas, organizações e equipamentos que o constitui. O projeto representa ainda os estados do sistema limitando o comportamento dos agentes, ou ainda especificando como os objetos reagem ao sofrer determinada ação. - Sexto a especificação deve ser operacional. A especificação deve determinar uma implementação de modo que para qualquer teste aleatoriamente escolhido os dados possam ser validados. Determinase assim, como o sistema irá agir, comportando-se conforme a proposta, sendo desta forma operacional. - Sétimo a especificação deve ser tolerante com a parcialidade e ser expansível.

56 56 Por melhor que seja, nenhuma especificação será completa, em função da complexidade do ambiente que ela representa, e dos níveis de abstração e detalhes. Sendo assim deverá possibilitar modificações. Embora a parcialidade das especificações permita diferentes interpretações, ampliando o limite de comportamentos aceitáveis, satisfazendo as regras definidas pelo projeto, este deve espelhar os níveis de incertezas restantes. - Oitavo uma especificação deve ser localizada e fracamente acoplada. Embora os princípios anteriores determinem uma especificação como se fosse estática, ela é dinâmica, fornecendo a base para a implementação de um sistema, passível de modificações. Estas podem ocorrer durante a formulação da especificação, no desenvolvimento ou pela adição de requisitos funcionais que se julguem necessários Validação de Requisitos Durante a fase de validação de requisitos objetiva-se verificar se os requisitos definem o sistema que o cliente realmente deseja. Uma vez que se ocupa em descobrir problemas nos requisitos, esta fase está diretamente relacionada com a análise de requisitos. A validação de requisitos é de fundamental importância no processo de construção do software. Tendo em vista que, erros de análise e documentação de requisitos tem um custo elevado na construção de um software. A mudança de um requisito durante a fase de projeto pode ser facilmente realizada, já a mesma coisa não ocorre quando o sistema está pronto. Neste caso, uma alteração de requisito, requer que os códigos dos programas sejam refeitos, novas telas construídas, e como conseqüência novos testes realizados. Sommerville (2005), destaca cinco tipos de verificação a serem realizadas sobre os requisitos: Verificação de validade o sistema que envolve os processos de uma organização é composto por uma comunidade de usuários em diferentes escalões. Sendo assim as necessidades de um pode ser diferente das de outro usuário. O conjunto de requisitos necessários

57 57 para sumprimir os anseios desta comunidade que faz parte da organização pode ser identificado através da análise identificando quais funções são necessárias. Verificação de consistência uma determinada função do sistema pode ser utilizada para complementar outra. Sendo assim, um documento não deve ser conflitante, ou seja, uma função não pode ser representada ou descrita de mais de uma maneira, evitando-se contradições. Verificação de completeza devem estar documentadas todas as restrições e requisitos que definem as funções do sistema. Verificação de realismo tendo em vista as tecnologias disponíveis para a produção de software, deve-se verificar e assegurar que todos os requisitos possam realmente ser implementados, levando se em conta ainda o tempo disponível para o desenvolvimento do sistema, bem como o orçamento levantado. Facilidade de verificação ao escrever, ou representar um requisito, deve-se tomar o cuidado necessário para que ele possa ser verificado facilmente, tendo como objetivo a redução de divergências entre desenvolvedor e cliente. Garantindo assim que seja possível determinar que o sistema entregue atende os requisitos requeridos pelo cliente. Ainda, Sommerville (2005), cita algumas técnicas que se usadas individualmente ou em conjunto auxiliam na validação dos requisitos: Revisões de requisitos sistematicamente analisa-se os requisitos. Este é um processo manual que envolve a leitura do documento por pessoal do cliente e do fornecedor, a fim de detectar diferenças ou omissões. Este processo pode ser informal ou formal. No processo informal a revisão é feita através da leitura dos requisitos e pela discussão dos mesmos entre representantes do cliente e do fornecedor. No sistema formal o processo é conduzido pelo pessoal

58 58 responsável pelo desenvolvimento, e à medida que erros, omissões, contradições e conflitos de requisitos forem detectados, devem ser formalmente registrados. Prototipação neste modelo de validação, um protótipo do sistema é mostrado aos usuários finais e cliente, a fim de examinar o modelo e verificar se atende as necessidades. Geração de casos de teste os requisitos dever ser testáveis, através de processos de testes específicos para esta situação. Estes testes invariavelmente revelam problemas com os requisitos. Análise automatizada de consistência se os requisitos forem expressos de maneira estruturada ou formal, através de uma ferramenta de desenvolvimento ágil a consistência do modelo poderá ser verificada Gerência de Requisitos Os sistemas são desenvolvidos, numa variedade extraordinária de modelos, formatos e tamanhos. Sendo assim, o conhecimento e o domínio da aplicação são fundamentais ao gerenciamento do processo e à satisfação do cliente e dos usuários. Neste contexto os requisitos são obtidos, avaliados e documentados, de acordo com o que já foi exposto até aqui. Os requisitos de um sistema sofrem influencia de inúmeros fatores que podem afetá-los, tais como mudanças da política da empresa, tipo de tecnologia utilizada, dentre tantos outros. Estes fatores podem afetar sistemas pequenos e simples, como médios, grandes e complexos sistemas. Da mesma forma, durante o processo de software, a compreensão dos desenvolvedores sobre as funções do sistema vai tornando-se mais clara e consequentemente afetando os requisitos de software. A influência do cliente, e dos usuários, durante o processo também afetam os requisitos de um sistema.

59 59 Neste contexto é fundamental que haja um bom gerenciamento de requisitos. Sua função é compreender e controlar as mudanças dos requisitos dos sistemas. O gerenciamento de mudanças de requisitos tem início no mesmo momento em que se dá a partida no processo de levantamento dos mesmos. Vimos até aqui que os requisitos inevitavelmente se modificam, no entanto alguns são mais suscetíveis a mudanças do que outros. Sommerville (2005) explica: A. Requisitos permanentes e voláteis O processo de engenharia de requisitos volta a atenção nos recursos do software, que deve representar os objetivos da empresa de acordo com o sistema que a envolve. No entanto, os fatores que afetam a empresa e o seu sistema, interferem nos requisitos de software, refletindo em suas mudanças. Nesta perspectiva os requisitos podem ser divididos conforme segue: Requisitos permanentes ao longo do processo de software os requisitos permanentes tem sua relação com o sistema mantidas relativamente estável, por relacionarem-se diretamente com o domínio do próprio sistema. Derivam dos modelos de domínio e representam as entidades e relacionamentos que o caracterizam como domínio de aplicação. Requisitos voláteis estes requisitos provavelmente irão se modificar durante o desenvolvimento do sistema ou durante a sua operação. B. Planejamento do gerenciamento de requisitos O planejamento do processo de engenharia de requisitos deve estabelecer o nível de detalhe exigido para o gerenciamento dos requisitos. Nesta etapa devem ser tomadas decisões sobre os seguintes aspectos: Identificação de requisitos os requisitos devem ser identificados de modo único permitindo assim a referência cruzada com outros requisitos do sistema facilitando sua avaliação e rastreamento.

60 60 Processo de gerenciamento de mudanças tem como objetivo avaliar o impacto e o custo das mudanças. Políticas de facilidade de rastreamento definem as relações entre requisitos, e entre estes e o projeto, bem como, definem como os requisitos devem ser registrados e mantidos durante o processo de software. Suporte de ferramentas ágeis ferramentas de suporte ao desenvolvimento podem ser utilizadas, tais como sistemas especializados, planilhas de cálculo e sistemas simples de banco de dados. Em qualquer sistema, os requisitos encontram-se inter-relacionados de modo que para qualquer modificação deve-se verificar se ela afeta outros requisitos, e qual o impacto que dela decorre. Sendo assim a facilidade de rastreamento é uma propriedade fundamental do documento de especificação de requisitos. C. Gerenciamento de mudanças de requisitos O gerenciamento de mudanças deve ocorrer sempre que há proposta de mudanças de requisitos. Um processo formal de gerenciamento de mudanças de requisitos auxilia no tratamento das propostas de maneira consistente garantindo o controle das alterações. O processo de gerenciamento de mudanças possui três estágios principais: Análise do problema e especificação da mudança este estágio tem início com a identificação de um problema com os requisitos, ou então com uma proposta específica de mudança. Analisa-se o problema ou a proposta de mudança, efetuando-se a alteração caso seja constatada a sua validade. Análise do custo da mudança uma alteração de requisitos somente deve ser efetuada após a análise do efeito que ela causará no sistema e na sua implementação, avaliando-se o custo para tal modificação.

61 61 Implementação de mudanças concluídos os estágios anteriores do processo de mudança, e decidindo-se pela viabilidade, o documento de requisitos, o projeto de sistema, e a implementação são modificados. Para garantir maior facilidade de modificação, isto é, com o menor esforço possível, tanto do documento de requisitos, quanto dos programas, deve-se primar pela modularidade e minimizar as referências externas Projeto de Arquitetura Peters e Pedrycz (2001), et al B. Stroustrup (1991), afirmam: Descobrimos que compreender a arquitetura de software é a chave do desenvolvimento de muitas soluções de software importantes. Peters e Pedrycz (2001, pg. 181). Pressman (1995), afirma: A Arquitetura de software alude a duas importantes características de um programa de computador: a estrutura hierárquica de componentes (módulos) procedimentais e a estrutura de dados. A arquitetura de software deriva de um processo de divisão de partições que relaciona elementos de uma solução de software a partes de um problema do mundo real implicitamente definido durante a análise de requisitos. Pressman (1995, p. 429). Segundo Sommerville (2005), os desenvolvedores de software enfocam a arquitetura de diferentes modos, dependendo do conhecimento, da habilidade e intuição do arquiteto do sistema. Porém, algumas atividades são comuns às diferentes abordagens do processo de estruturação da arquitetura: Estruturação de sistema a estruturação ocorre pela decomposição do sistema principal em uma série de subsistemas capazes de atuarem de forma independente como unidades de software, identificando-se as comunicações entre eles. Modelagem de controle um modelo geral de relacionamentos de controle é estabelecido entre as partes do sistema.

62 62 Decomposição modular Os subsistemas identificados são decompostos em módulos, definindo-se seus tipos assim como suas interconexões. Durante o processo, estas atividades são realizadas de forma intercalada, e permitem que o mesmo seja especificado detalhadamente, permitindo avaliar se o projeto arquitetural cumpre com os requisitos de sistema. Sommerville (2005), afirma que a arquitetura do sistema é capaz de afetar seu desempenho, robustez, facilidade de distribuição e de manutenção. Sendo assim, a estrutura e o estilo específico escolhidos para uma aplicação dependem dos requisitos não funcionais do sistema: Desempenho se o desempenho for um requisito importante, a arquitetura a ser projetada deve restringir as operações mais importantes dentro de um pequeno conjunto de subsistemas com a menor comunicação possível entre eles. A redução de comunicação entre componentes pode ser alcançada estipulando-se uma maior granularidade destes componentes. Proteção no caso de ser definido que a proteção é o item mais importante, então sugere que uma arquitetura em camadas deve ser utilizada, protegendo assim os itens mais importantes nas camadas mais internas, aplicando-se níveis mais altos de validação e proteção. Segurança definindo-se que a segurança é um requisito importante, então projeta-se a arquitetura de modo que as operações relacionadas à ela fiquem localizadas em um único subsistema, reduzindo-se assim os custos e os problemas de validação e segurança, tornando possível fornecer os sistemas de proteção relacionados. Disponibilidade caso a disponibilidade seja um requisito fundamental, então a arquitetura deverá ser projetada para garantir componentes redundantes, permitindo assim, substituir e atualizar componentes sem a interrupção do sistema.

63 63 Facilidade de manutenção se a facilidade de manutenção for um requisito importante, então a arquitetura deve prever componentes encapsulados e com menor granularidade, permitindo assim a rápida modificação Estruturas do Sistema Segundo Peters e Pedrycz (2001), um estilo arquitetônico caracteriza-se pelos seguintes detalhes: Tipos de componentes são elementos de processamento utilizados para a transformação dos dados. Tipos de conectores são os caminhos de controle e de dados entre os componentes. Restrições referem-se ao processamento, são as restrições de dados e formas permitidas de unirem-se aos componentes eletronicamente. Atualmente os tipos de processamentos basicamente podem ser Centralizados ou Distribuídos, onde a arquitetura é definida em 1, 2, 3 ou N camadas. Desta maneira, empresas trabalham basicamente nestas duas formas de processamento ou em ambas. Nas metodologias orientadas a objetos os processamentos são realizados em ambientes centralizados com um servidor e uma série de estações de trabalho, ou diretamente na WEB, mesmo assim podendo realizar seus processamentos de dados centralizados ou distribuídos Processamento Centralizado O processamento centralizado ainda é utilizado nas empresas, e mantido basicamente em função do investimento realizado ao longo dos anos. Contudo, neste tipo de processamento o principal problema se refere a disponibilidade, pois quando em função de um problema, o sistema para de funcionar, todos os serviços

64 64 que dependem dele também param, tornando este o mais crucial dos seus inconvenientes. Sendo assim, independentemente do computador onde encontra-se o sistema instalado estar ou não conectado à internet o processamento, bem como o armazenamento de todas as informações é realizado localmente. Alcântara 2008, et al 2003 mostra o esquema do processamento centralizado: Figura 9. Processamento Centralizado Processamento Distribuído Com o surgimento dos processadores multi-core, ou seja, com mais de um núcleo de processamento, é cada vez mais presente o uso de sistemas de processamento distribuído. Um sistema distribuído é executado por um grupo de processadores integrados, cooperando entre si através de uma rede. Sommerville (2005) et al Coulouris et al, (1994), identifica seis características importantes dos sistemas distribuídos: Compartilhamento de recursos - Os sistemas distribuídos permitem o compartilhamento de hardware e software associados a diferentes computadores em uma rede. O compartilhamento também pode ser realizado por multiusuários, no entanto, neste caso os recursos devem ser fornecidos e gerenciados por um computador central.

65 65 Abertura os sistemas distribuídos são sistemas abertos e permitem a inclusão de hardware e software de diferentes fabricantes. Isto quer dizer que permite recursos não proprietários a ele. Concorrência nos sistemas distribuídos as tarefas são divididas em processos que são executados por diferentes computadores simultaneamente, podendo ou não comunicarem-se durante a sua execução. Escalabilidade um sistema distribuído pode ser escalonado, sendo assim permite que os seus recursos sejam ampliados. Contudo, pode encontrar limitação em função da capacidade de rede que interliga as estações de processamento, ou ainda dividir-se uma determinada atividade tantas vezes que se perde mais tempo para unir os resultados e apresentar a solução do que se fossem usados um número menor de nós. Tolerância a defeitos a oferta se serviço de má qualidade pode ocasionar defeitos. No entanto, a disponibilidade de vários computadores e o potencial de redundância de informações garante aos sistemas distribuídos tolerância a falhas de hardware e software. Transparência relativo a transparência, significa dizer que o usuário não necessita saber da natureza distribuída do sistema. Em alguns casos, no entanto, tornar a distribuição visível ao usuário pode permitirlhe o melhor aproveitamento dos recursos de que dispõe. Ainda em Sommerville (2005), são destacadas desvantagens dos sistemas distribuídos: Complexidade a realização de testes e a compreensão destes sistemas são mais complexas. Por exemplo, o desempenho do sistema passa a depender da velocidade da rede que interliga os nós, bem como do desempenho dos processadores de cada nó. Sendo assim, mover recursos do sistema pra outro ponto da rede pode significar uma diferença grande no resultado final esperado.

66 66 Proteção pode-se enfrentar dificuldade no gerenciamento da proteção ao sistema, em função do tráfego da rede, onde os pacotes podem estar sujeitos a interceptação. Facilidade de gerenciamento os diferentes computadores da rede podem ser de diferentes tipos e capacidades, e executar diferentes versões do sistema operacional. Sendo assim, os defeitos de uma máquina pode se propagar pela rede e afetar as demais, resultando conseqüências inesperadas, gerando maior esforço para gerenciar e manter o sistema em operação. Imprevisibilidade em função da carga dos sistemas que atuam na rede, e pelo uso desta, em relação ao congestionamento do tráfego em determinados momento, pode resultar tempos de execução bem diferentes para a mesma tarefa, apenas variando o momento em que a solicitação ocorre. Para o desenvolvimento de um sistema distribuído, eficiente e tolerante aos problemas anteriormente citados, é preciso conhecer e compreender as vantagens e desvantagens das diferentes arquiteturas de sistemas distribuídos. Neste contexto Sommerville (2005), apresenta dois tipos de arquiteturas de sistemas distribuídos: a. Arquitetura Cliente-Servidor Na arquitetura cliente-servidor as aplicações são modeladas como um conjunto de serviços que são fornecidos aos clientes. Nesta arquitetura o cliente precisa saber onde está o servidor, já este não necessita saber onde está o cliente, uma vez que somente responde caso o cliente faça uma requisição.

67 67 Figura 10. Arquitetura Cliente-Servidor O projeto cliente-servidor deve refletir uma estrutura lógica da aplicação a ser desenvolvida. Uma aplicação em três camadas pode ser representada como abaixo: Figura 11. Arquitetura três camadas A camada de apresentação se ocupa das interações e da apresentação do sistema ao usuário. A camada de regra do negócio é responsável por implantar a lógica do sistema. A camada de banco de dados é responsável por todas as operações a ele relacionadas, armazenamento das informações, consultas, alterações.

68 68 Em sistemas de processamento centralizado estas camadas não são separadas nitidamente. No entanto, para sistemas distribuídos devem ser claramente distintas, a fim de permitir o gerenciamento da distribuição do processamento entre os servidores. Dentre os modelos de arquitetura em camadas o mais simples é o de duas camadas, organizada com um servidor, ou um conjunto deles, e inúmeros clientes. Na arquitetura de duas camadas o processamento da aplicação e o gerenciamento dos dados são realizados em um único computador, enquanto que o cliente simplesmente executa o software de aplicação. Outra maneira de implementação desta arquitetura é a realização do armazenamento dos dados no servidor e da lógica do negócio tal como a interação com o usuário no cliente. Já em uma arquitetura cliente-servidor em três camadas não necessariamente o sistema deverá ser executado em computadores diferentes conectados à rede. Um único servidor poderá executar o processamento da aplicação, execução das regras do negócio bom como o gerenciamento e armazenamento dos dados. No entanto, caso seja necessário ampliar a capacidade do sistema, de uma maneira simples estas camadas podem ser separadas em servidores diferentes. Atualmente, com o advento dos sistemas web, este tipo de arquitetura tornouse muito usual. Em um sistema web o cliente é executado no Browser do usuário, o processamento da aplicação em um servidor web, enquanto que os dados são executados em um servidor de banco de dados.

69 69 Figura 12. Cliente-Servidor Três Camadas Há casos em que se torna apropriado a ampliação do modelo em três camadas para um modelo N (de inúmeras) camadas, adicionando-se servidores ao sistema, especialmente quando o sistema deve acessar dados de diferentes bancos de dados. Neste caso é necessário um servidor de integração, responsável pela interligação do servidor web com os servidores de dados. Assim o servidor de integração acessa os diferentes bancos de dados e apresenta-os à aplicação como de estivessem disponíveis em um único bando de dados. b. Arquitetura de Objetos Distribuídos Na abordagem de objetos distribuídos elimina-se a distinção de cliente e servidor. Nesta arquitetura os componentes do sistema são objetos que oferecem uma interface para os serviços a serem disponibilizados. Enquanto que outros objetos solicitam os serviços. Faz-se assim uma distinção lógica entre cliente e servidor. Nesta arquitetura os objetos distribuídos comunicam-se através de middleware, responsável por fornecer um conjunto de serviços a fim de possibilitar tal comunicação entre os objetos. A arquitetura de objetos distribuídos permite disponibilizar o serviço em qualquer nó da rede. Por esta razão não há necessidade de se decidir antecipadamente onde os objetos de lógica de aplicações serão disponibilizados.

70 70 Esta é uma arquitetura de sistemas muito aberta. Sendo assim, permite o acréscimo de novos recursos de acordo com a necessidade. A arquitetura de objetos distribuídos permite que os programas sejam escritos em diferentes linguagens de programação e comuniquem-se, fornecendo serviços uns aos outros. Sistemas baseados nesta arquitetura são extensíveis e flexíveis. Permite ainda re-configurar o sistema dinamicamente através de objetos que migram pela rede, de acordo com a necessidade. Para exemplificar a aplicação da arquitetura de objetos distribuídos podemos citar um sistema de mineração de dados, utilizado pelos sistemas de apoio à decisão. Neste exemplo o sistema de mineração procura as relações entre os dados armazenados nos diferentes bancos de dados Orientação a Objetos O desenvolvimento de um projeto orientado a objetos tem como princípio a análise do sistema a ser construído do ponto de vista dos objetos que ele deve representar, ao invés de pura e simplesmente operações e funções em código de uma linguagem de programação. De acordo com Sommerville (2005), a estratégia orientada a objetos é utilizada em todo o processo de desenvolvimento orientado a objetos: A análise orientada o objetos desenvolve um modelo de domínio de aplicação, onde os objetos representam as entidades e operações associadas ao problema a ser resolvido. O projeto orientado a objetos representa um modelo para um sistema de software que permita programar os requisitos identificados. Os objetos que representam o problema refletem na solução, uma vez que muitos deles relacionam-se com outros. À medida que o desenvolvedor vai realizando as ligações entre os objetos, invariavelmente eles se modificam, em função da solução requerida.

71 71 A programação orientada a objetos realizada através de um linguagem que tenho suporte a este tipo de implementação, se ocupa em realizar o projeto de software, através da programação direta de objetos ou através dos recursos de definição de classes dos objetos. No processo de desenvolvimento do projeto orientado a objetos os engenheiros de software envolvem-se em classificar os objetos em classes, e estabelecer as relações entre elas. Sommerville (2005), afirma que um objeto é um encapsulamento de informações, uma entidade que possui um estado e um conjunto definido de operações. O estado é representado por um conjunto de atributos do objeto. As operações associadas ao objeto fornecem serviços a outros objetos quando requisitadas. Pressman (1995), diz que as concepções de software de objetos do mundo real são divididas em categorias, de modo que todos os objetos são membros de uma classe mais ampla e herdam a estrutura de dados e as operações particulares que foram definidas para esta classe. Uma classe é um conjunto de objetos que possuem características em comum. Sendo assim, um objeto é uma instância de uma classe mais ampla. Objetos são criados a partir da definição de uma classe. Esta por sua vez serve como modelo, a fim de que todos os objetos criados estejam de acordo com o escopo estabelecido para a classe a que ele pertence. Os atributos e operações a que os objetos estão sujeitos estão definidos na classe que os criou. De acordo com a linguagem de modelagem unificada, classes de objetos são representadas através de um retângulo, o qual é dividido em três linhas, ou seções, constando na primeira o nome da classe, na segunda os atributos do objeto, e por fim as operações associadas ao objeto.

72 72 Figura 13. Modelo de Classe de Objetos Esta figura representa a instância da classe gerenciador, para o sistema proposto na modelagem deste trabalho de conclusão de curso. Vale ressaltar ainda que em UML o termo operação especifica uma ação implementada através de um método. Em Sommerville (2005), propõem algumas abordagens que auxiliam na identificação de objetos: Objetos e atributos são nomes, já operações e serviços são verbos. A utilização de entidades tangíveis (coisas) no domínio da aplicação, tais como: bens móveis e imóveis; funções, como gerente; eventos, como solicitações; interações, como reuniões; locais, como escritórios; unidades organizacionais, como empresas; e assim sucessivamente. Utiliza-se uma abordagem comportamental, em que o desenvolvedor compreende inicialmente o comportamento do sistema. Uma vez que um sistema pode apresentar variados comportamentos, dependendo do ponto analisado. Diferentes cenários de uso e aplicação do sistema devem ser analisados. À medida que cada cenário é analisado devem-se identificar os objetos, atributos e operações que são requeridos.

73 Relacionamentos de Objetos No processo de desenvolvimento de um projeto Orientado a Objetos as classes podem estar conectadas umas às outras através de relacionamentos, seja logicamente ou fisicamente. Segundo Booch (2000), na orientação a objetos, a representação dos relacionamentos pode ser realizada de três formas distintas: Dependências são relacionamentos de utilização. Por exemplo, em um sistema, o cliente necessita de uma licença para ter acesso ao mesmo, contudo uma instância de licença não existe se não existir um cliente. Neste caso, se uma classe for utilizada e modificada, então a operação de outra classe pode ser afetada. Usa-se a dependência quando se desejar indicar que um item depende de outro. Figura 14. Exemplo de dependência Generalizações conectam classes generalizadas a outras mais especializadas. Ou como comumente é conhecido este relacionamento tipo classe filha/mãe. Por exemplo, um imóvel pode ser próprio ou arrendado. Neste exemplo, tanto imóvel próprio como arrendado herdam as propriedades da classe mãe, mas não o contrário. As classes filhas, neste caso tem atributos específicos além daqueles herdados da classe mãe.

74 74 Figura 15. Exemplo de generalização Associações são relacionamentos estruturais entre instâncias. Por exemplo, uma cidade pertence a um estado. A partir de uma associação pode-se navegar do objeto de uma classe até o objeto de outra classe.e vice-versa. Figura 16. Exemplo de associação Multiplicidade De acordo com Alcântara (2005), em uma classe o número de instâncias de objetos nesta classe pode variar, a não ser que seja uma classe abstrata que não tenha qualquer instância direta, mesmo assim haverá qualquer quantidade de instâncias de suas classes filhas.

75 75 Em alguns casos é necessário restringir a quantidade de instâncias que uma classe terá. O número de instâncias de uma classe refere-se à multiplicidade, e esta é a cardinalidade que a entidade pode assumir Benefícios da Orientação a Objetos Martin e Odel (1995) relacionam algumas vantagens ao processo de desenvolvimento de software Orientado a Objetos: Desenvolvimento rápido é um requisito fundamental no processo de desenvolvimento atual, tendo em vista as exigências dos clientes e da forte concorrência do mundo contemporâneo, tanto para os clientes, quanto para os desenvolvedores. Desta forma reduzem-se custos e aumenta-se a satisfação do cliente. As classes que compõe o sistema são projetadas de forma que permitem o reuso em outros softwares. À medida que se usa a orientação a objetos é automaticamente criada e ampliada uma biblioteca de classes a cada aplicação construída. Uma vez que a cada aplicação de software é construída novos testes são realizados. E com o reuso, as mesmas classes passam todas as vezes por novos testes. Desta maneira os sistemas gerados passam a ser cada vez mais confiáveis, tendo em vista o número de testes pelos quais as classes passaram ao longo do processo. Métodos são desenvolvidos para acessar dados específicos de acordo com as permissões do usuário. Sendo assim, ele não terá acesso à áreas que não lhe são permitidas. Isto proporciona integridade aos dados do sistema. Os métodos para cada classe são criados individualmente, facilitando assim a programação, bem como a manutenção. Sistemas legados, não orientados a objetos podem ser migrados de forma rápida e econômica, preservando os investimentos,

76 76 especialmente nos dias atuais, com a expansão das aplicações web, aproveitando-se os dados armazenados ao longo dos anos. A orientação a objetos permite a interação com outras mídias, tais como: imagens, vídeo, voz, etc. A orientação a objetos possui independência de projeto. Ou seja, as classes construídas independem de plataforma, permitindo sua utilização em diferentes sistemas operacionais, gerenciadores de bancos de dados, hardware, etc Modelagem de Sistemas Segundo Booch, para desenvolver um software, capaz de possuir uma vida longa, e com qualidade duradoura, de forma rápida e com o mínimo de desperdício de tempo e retrabalho é preciso dispor das pessoas certas, ferramentas adequadas e com o enfoque correto. Para isso, é necessário um processo seguro, capaz de ser adaptado as novas necessidades do negócio e tecnologia. Para tanto a modelagem é um processo fundamental no desenvolvimento de um software de qualidade. É através de modelos que podemos demonstrar de uma forma simplificada a realidade, facilitando a sua compreensão. Martins (2005) afirma: Um modelo é uma simplificação da realidade que descreve completamente o sistema a partir de certo ponto de vista. (Martins 2005, pg. 175.) Desenvolver sistemas de informações é um processo complexo. Sendo assim os modelos ajudam a visualizar as necessidades, especificam sua estrutura e comportamento, além de proporcionar um guia para a sua implementação, documentam as decisões no decorrer do processo. A modelagem observa princípios básicos comuns ao longo da história da engenharia. Na modelagem devem ser escolhidos os modelos através dos quais os problemas serão enfrentados e as soluções definidas. Cada modelo pode ser descrito de diferentes formas, agregando níveis de precisão diferentes. Os modelos são melhores definidos quando expressam a realidade. O conjunto de modelos que

77 77 expressam a complexidade de um sistema pode ser expresso em diferentes níveis de abstração, tornando-os assim quase que independentes. Na atualidade o modelo de desenvolvimento de software observa o paradigma da orientação a objetos. Ou seja, todo objeto representa uma estrutura de algo no espaço do problema ou da solução. Os objetos com características em comum são unidos por classes. O objetivo principal da orientação a objetos é oferecer uma visão de mundo em termos de objetos. Neste contexto foi desenvolvida uma linguagem padrão para a elaboração de estruturas de software, a UML (Unified Modeling Language), permitindo assim a visualização, a especificação, a construção e a documentação de sistemas orientados a objetos UML A UML permite o desenvolvimento de modelos que auxiliem na compreensão de um sistema. A UML apresenta um vocabulário e regras que possibilitam aos desenvolvedores criar e ler os modelos que representam os objetos, classes, e demais componentes do sistema. Booch (2000), afirma que a UML é uma linguagem destinada a: Visualizar; Especificar; Construir; Documentar. O vocabulário e as regras definidas pela UML permitem a criação e apresentação de modelos, durante o processo de desenvolvimento do software, servindo como um guia que auxilia a decidir quais artefatos será construído, quais atividades e trabalhadores escolhidos para gerenciá-los, e como os artefatos serão empregados para medir e controlar o projeto.

78 78 O uso da UML auxilia na visualização das necessidades do sistema a ser implementado, uma vez que modelos explícitos facilitam a comunicação, fundamental na obtenção dos requisitos, especialmente àqueles junto ao cliente. Para isso, a linguagem utiliza-se de símbolos semanticamente bem definidos. Isto permite que diferentes desenvolvedores, que conheçam a linguagem, possam entender e interpretar sem ambigüidades o que o modelo representa. Através de modelos semanticamente estruturados a UML permite a especificação de modelos sem ambigüidades e completos. Desta maneira, atendendo todas as questões em termos de análise, projeto e implementação. Auxiliando assim nas decisões para o projeto e desenvolvimento do software. A UML permite também que seja gerado o código, a partir de um modelo, para determinadas linguagens de programação. O inverso também é possível, gerando um modelo a partir de sua implementação. Além disso, a UML abrange a documentação do sistema, desde a arquitetura, análise de requisitos e testes, bem como para o planejamento do projeto e planejamento de versões Arquitetura As tarefas do desenvolvimento de software pautado na linguagem de modelagem unificada requerem uma visualização do sistema a ser implementado, sob várias perspectivas. Isto se deve ao fato de existir, no processo de desenvolvimento, pessoas com diferentes níveis de conhecimento tal como de diferentes áreas do conhecimento. Booch (2000) afirma que a arquitetura do sistema é o artefato mais importante para o gerenciamento dos diferentes pontos de vista das pessoas envolvidas no processo, tornando possível o desenvolvimento do processo iterativo e incremental de um sistema durante seu ciclo de vida. Segundo Booch (2000) a arquitetura é um conjunto de decisões referente aos aspectos seguintes: Organização de um sistema de software.

79 79 Seleção de elementos estruturais e interfaces de um sistema. O comportamento do sistema conforme as especificações colaborativas entre elementos. A composição de elementos estruturais e comportamentais em subsistemas maiores. O estilo de arquitetura orienta a organização dos elementos estáticos e dinâmicos, suas interfaces, colaborações e composição. Booch (2000) apresenta cinco visões que permitem descrever adequadamente a arquitetura de um sistema, em relação ao seu comportamento, seu uso, funcionalidade, desempenho, flexibilidade, reutilização, abrangência, adequações e restrições de caráter econômico e tecnológico. Figura 17. Arquitetura - visões (booch, 2000) A visão de caso de uso envolve os casos de uso, responsável pela descrição de como o sistema é visto pelos usuários, analistas, testadores. Não especifica a organização do software. Com a UML aspectos estáticos desta visão são capturados em diagramas de casos de uso, enquanto que os aspectos dinâmicos são descritos através de diagramas de interação, de estados, e de atividades. A visão de projeto envolve as classes, interfaces, e colaborações, que formam o vocabulário para o problema e a sua solução. Esta visão permite estabelecer os requisitos funcionais do sistema, ou seja, os serviços a serem fornecidos aos usuários. O principal diagrama para a visualização do projeto é o diagrama de classes.

80 80 A visão do processo tem por objetivo estabelecer aspectos relativos ao desempenho e à escalabilidade do sistema, através de diagramas da visão de projeto, com foco voltado para as classes que representam os processos. A visão de implementação envolve os componentes e arquivos utilizados para a montagem e fornecimento do sistema físico. Envolve o gerenciamento de configuração de versões do sistema. A visão de implantação abrange os nós que formam a topologia de hardware em que o sistema será executado. Tem como objetivo direcionar a distribuição dos componentes do sistema, e o modo como será feita a instalação das partes que compõem o sistema físico Ciclo de Vida no Desenvolvimento do Software A UML é independente do processo de software, não se limitando ao ciclo de vida do desenvolvimento do software. Contudo, para se obter o melhor uso das características da UML, segundo Booch (2000), deve-se observar para que o processo tenha as seguintes características: Orientado a caso de uso nesta abordagem os casos de uso são os principais artefatos para a construção de um sistema, desde a obtenção dos requisitos, verificação e validação da arquitetura, realização de testes e comunicação entre os envolvidos no projeto. Centrado na arquitetura a arquitetura do sistema é utilizada como principal instrumento de conceituação, construção, gerenciamento, e evolução do sistema em desenvolvimento. Iterativo e Incremental envolve o gerenciamento de versões executáveis, bem como a integração contínua da arquitetura com a produção das versões, de maneira que a cada nova versão são incorporados aprimoramentos em relação às anteriores. Booch (2000) divide o processo de desenvolvimento baseado em UML em quatro fases:

81 81 Concepção é a primeira fase do processo, onde a idéia inicial é fundamentada. Onde se identifica o domínio do problema e os requisitos iniciais. Elaboração nesta fase a visão do produto e a arquitetura são definidas. Aqui são definidos os requisitos e as prioridades para a construção do sistema, formando-se inclusive a base de fundamentação para testes iniciais. Construção neste ponto do processo de desenvolvimento se obtém uva versão executável do sistema. Nesta fase os requisitos são constantemente re-examinados em relação às necessidades do cliente. Transição Nesta fase uma versão executável é disponibilizada aos usuários. O sistema é continuamente aprimorado, adicionando-se e eliminando-se características de acordo com a necessidade Diagramas UML Os diagramas UML são representações gráficas que auxiliam na visualização de um sistema sob diferentes perspectivas. Cada diagrama representa uma visão parcial dos elementos que compõem o sistema. Sendo assim, um conjunto de diferentes diagramas é apresentado para retratar as visões mais úteis de um sistema de software. Booch (2000) apresenta nove tipos diferentes de diagramas: Diagrama de classes exibe as classes que compõem o sistema, interfaces e colaborações, bem como os relacionamentos. Aparecem com maior freqüência na modelagem orientada a objetos fornecendo uma visão estática do sistema. Diagrama de objetos mostra um conjunto de objetos e seus relacionamentos. Retrata estaticamente instâncias de itens referentes às classes. Abrangem a visão estática da estrutura ou do processo de um sistema.

82 82 Diagrama de caso de uso abrangem a visão estática dos casos de usos e sua relação com os atores, essencial na organização e modelagem de comportamentos do sistema. Diagrama de colaboração exibe as interações de um conjunto de objetos e seus relacionamentos, expondo a visão dinâmica de um sistema. Diagrama de sequência responsável por exibir as interações com ênfase na ordenação temporal das mensagens. Os diagramas de sequência e colaboração são isomórficos. Sendo assim, podem ser transformados de um tipo em outro tipo e vice-versa. Diagrama de estado exibem estados, transições, eventos e atividades, abrangendo assim a visão dinâmica do sistema. Fundamental para a modelagem de comportamentos da interface, classe ou colaboração, bem como para dar ênfase a comportamentos de objetos ordenados por eventos. Diagrama de atividade tipo especial de diagrama de gráfico de estado. Exibe fluxos de atividade mostrando a visão dinâmica do sistema quanto ao fluxo de controle entre objetos. Diagrama de componente mostra as dependências existentes entre um conjunto de componentes, abrangendo a visão estática da implementação de um sistema, relacionado às classes, mapeando classes, interfaces e colaborações. Diagrama de Implantação mostra a configuração dos nós de processamento, exibindo a visão estática da arquitetura de implantação, relacionando-se aos diagramas de componentes, uma vez que cada nó inclui um ou mais componentes. Na sequência serão detalhados os tipos de diagramas que serão usados na modelagem do projeto de sistema proposto neste trabalho. Na ordem: diagramas de

83 83 caso de uso, diagramas de classes, diagramas de sequência e diagramas de estado Diagramas de Casos de Uso Booch (2000) diz que um caso de uso é um conjunto de ações que um sistema executa para produzir determinado resultado. Representado através de um diagrama, que mostra um conjunto de casos de usos e os atores, bem como seus relacionamentos. Os casos de uso são utilizados para especificar o comportamento desejado para o sistema, mas não determinam como esse comportamento será executado. Isto facilita a comunicação entre usuários e desenvolvedores, uma vez que não se preocupa com os detalhes. Durante a captação e análise de requisitos os desenvolvedores utilizam-se dos casos de uso para visualizar, especificar, construir e documentar o comportamento pretendido para o sistema, representando desta maneira as interações dos itens externos ao sistema (atores) com o próprio sistema. Fowler e Scott (2000) afirmam que um caso de uso é um conjunto de cenários amarrados por um objetivo comum de um usuário. Um cenário descreve uma sequência de passos gerada pela interação do usuário com o sistema para alcançar um objetivo pré-determinado. Para exemplificar, o cenário representado pelo caso de uso abaixo poderia ser descrito da seguinte forma: - Os contatos são pessoas do tipo pessoa física ou jurídica e podem ser cadastrados pelo usuário ou pelo gerenciador do sistema. Contatos podem ser clientes do sistema, mas dependem do cadastro de licença para ter acesso ao sistema. Somente o gerenciador tem privilégios para conceder a licença ao cliente. Do ponto de vista do cenário que o caso de uso representa, os cenários podem se divididos em primários e secundários. De acordo com o cenário anteriormente descrito podemos apresentar os cenários primários e secundários.

84 84 Cenário primário cadastro de licença para o cliente. Cenários secundários o contato não está cadastrado. O cliente não está cadastrado. Para estes cenários é preciso oferecer uma sugestão de solução. Para este exemplo é necessário realizar o cadastro do contato e após o cadastro do cliente. Figura 18. Caso de uso e relacionamentos Este caso de uso é parte da modelagem deste projeto de TCC, onde será detalhado no contexto que representa. Neste momento é mostrado apenas para representar os componentes de um caso de uso. Segundo Booch (2000) são elementos dos casos de uso: Nome o nome de cada caso de uso deve diferenciá-lo dos outros. É representado por um conjunto de caracteres textual. Ator o ator representa o papel desempenhado pelo usuário em relação ao caso de uso. Embora esteja representado, o ator não faz parte do software, ele representa o usuário que irá manipular o sistema. Os atores são conectados aos casos de usos através de associações.

85 85 Relacionamentos são três os tipos de relacionamentos mais utilizados pela UML: Dependência ; Associação ; Generalização. Geralmente um caso de uso não será representado sozinho, ou seja, única e exclusivamente só. Na maioria dos casos estará relacionado a outros casos de usos através de colaborações. Sendo assim o caso de uso principal obtém a colaboração de outros a fim de que seu comportamento possa ser implementado. No exemplo abaixo o caso de uso Cadastro de licença para o cliente possui a colaboração dos outros casos de usos: Figura 19. Colaboração estendida Aqui o comportamento do caso de uso principal obtém a colaboração dos demais através de extensões (<<extends>>) representadas por relacionamentos de dependência. Neste exemplo o caso de uso principal incorpora de forma implícita o comportamento dos casos de uso secundários. Segundo Booch (2000) em um relacionamento estendido entre casos de usos o caso de uso base incorpora implicitamente o comportamento de outro caso de uso em um local especificado indiretamente pelo caso de uso estendido. Um relacionamento estendido pode ser representado como uma dependência estereotipada como <<extends>>. O relacionamento entre casos de usos pode ser de inclusão. Neste caso, o caso de uso principal recebe de forma explicita e obrigatória a ação do caso de uso secundário. Assim o caso de uso principal tem seu comportamento dependente do caso de uso a ele relacionado, através de uma relação de dependência estereotipada como (<<include>>). Abaixo um exemplo deste relacionamento:

86 86 Figura 20. Colaboração inclusão Segundo Booch (2000) em um relacionamento de inclusão o caso de uso base incorpora explicitamente o comportamento de outro caso de uso em uma localização especificada na base. Um relacionamento de inclusão pode ser representada como uma dependência estereotipada como <<include>>. Os relacionamentos de associações ligam os atores aos casos de uso. Figura 21. Associação E por fim os relacionamentos generalizados ligam casos de usos que tem comportamentos semelhantes, mas onde o caso de uso especializado pode sobreescrever qualquer parte do caso de uso base, satisfazendo o mesmo objetivo inicial do usuário. Figura 22. Generalização Fowler e Scott (2000) apresentam regras para a utilização dos relacionamentos: Usa-se inclusão quando necessitar repetir dois ou mais casos de usos separados, evitando assim a repetição. Usa-se generalização para descrever as variações de comportamento normal sem muito rigor. Usa-se extensão na descrição de uma variação de comportamento normal, de forma controlada, explicando os pontos de extensão no caso de uso base.

87 87 Booch (2000) apresenta dicas para a construção de diagramas de casos de uso na UML de forma bem estruturada: O diagrama comunica um aspecto da visão estática do caso de uso do sistema. O diagrama contém somente casos de uso e atores essenciais para a compreensão do aspecto a ser representado. Fornece detalhes consistentes ao seu nível de abstração. Nomeie o caso de uso de modo a comunicar seu propósito. Organize os elementos espacialmente de modo que os comportamentos e papéis semanticamente relacionados fiquem próximos fisicamente. Mostre somente os relacionamentos necessários. Caso haja uma teia de relacionamentos muito complicados separe os elementos em outro diagrama Diagramas de Classes Booch (2000) afirma que um diagrama de classes mostra um conjunto de classes, interfaces, colaborações e seus relacionamentos. Usados para fazer a modelagem da visão estática do sistema, representando basicamente os serviços que o sistema irá fornecer aos usuários finais. Os diagramas de classes podem ser usados para representar o super conjunto de diagramas de entidade-relacionamento (E-R) para o projeto lógico de banco de dados. Com já visto anteriormente em orientação a objetos, uma classe é um conjunto de objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica. Uma classe é representada graficamente como um retângulo, dividido da seguinte forma:

88 88 Figura 23. Modelo de classe Neste exemplo o primeiro bloco do retângulo contém o nome da classe. O nome pode ser um texto composto de qualquer número de caracteres. Geralmente são substantivos ou expressões breves. O segundo bloco do retângulo contém os atributos, que descrevem o intervalo de valores que as instâncias da classe podem apresentar. Um atributo é uma propriedade do item que está sendo modelado. Pode ser uma informação, uma característica, ou seja, uma abstração do tipo de dados ou estados que os objetos da classe podem abranger. Um atributo é um substantivo ou expressão, que representa uma propriedade da classe correspondente. No terceiro bloco especifica-se as operações, que são serviços a serem implementados a fim de manipular ou modificar o comportamento requerido pela classe. Ou seja, uma operação é uma abstração de uma ação que pode ser desencadeada sobre os atributos da classe. As operações são verbos, ou locuções verbais, que representam o comportamento da classe correspondente. A fim de compreender o que segue abaixo, é fundamental que se entenda o termo usado na UML e definido como Classificador. Segundo Booch (2000), um classificador é um mecanismo que descreve características estruturais e comportamentais, e incluem classes, interfaces, tipos de dados, sinais, componentes, nós, casos de usos e subsistemas. Os atributos e as operações podem conter identificadores de visibilidade, que na UML podem assumir três níveis diferentes:

89 89 Público Representado pelo sinal de adição (+), determina que o atributo ou a operação possa ser visualizado e acessado por qualquer outra classe, ou classificador. Protegido Representado pelo símbolo (#), determina que somente aqueles que descenderem do mesmo classificador poderão acessá-lo. Privado Representado pelo símbolo (-), especifica que somente o próprio classificador poderá usar a característica. Além da visibilidade e do nome do atributo, podemos definir o tipo do atributo e a sua multiplicidade. No exemplo de casse mostrado anteriormente, o atributo nome é um tipo char, ou seja, poderá assumir em sua instância uma sequência de caracteres contidos pelo alfabeto. Já o número de caracteres é definido pela multiplicidade, que pode ser limitado de acordo com a necessidade, conforme abaixo: Figura 24. Propriedades dos atributos (adaptado de Alcântara, 2005) Um relacionamento é uma conexão entre itens, neste caso, as classes. Elas podem relacionar-se basicamente através de dependências, generalizações, associações e agregações, segundo Booch (2000). Suas características serão resumidas brevemente, uma vez que já foram abordadas na orientação a objetos, com exceção das agregações. Dependência é um tipo de relacionamento que tem por objetivo especificar que uma classe depende da outra, ou seja, caso haja uma alteração em um item em determinada classe isto afetará a classe dependente.

90 90 Generalização é um relacionamento entre um item geral uma classe mãe e um tipo específico deste item uma classe filha. Associação representa uma relação estrutural, demonstrando que um objeto encontra-se conectado a outro objeto de uma classe diferente. Agregação o relacionamento de agregação representa uma associação de composição. Neste caso uma determinada classe representa objetos que podem compor outra classe. Por exemplo, uma nota fiscal de venda é composta de itens de produtos. Sendo assim a nota fiscal é o todo, e os itens são a parte. Figura 25. Agregação Os relacionamentos devem representar ainda a cardinalidade. Ou seja, o número de instâncias que um objeto pode assumir em relação ao objeto em que ele encontra-se ligado. Na figura acima, que representa uma agregação, por exemplo, uma nota fiscal pode conter inúmeros itens de insumos, enquanto que cada item de insumo faz parte de apenas uma nota fiscal. tipos: Segundo Booch (2000), as classes podem ser classificadas em diferentes A. Classe abstrata quando não apresentam instâncias diretas, ou seja, necessitam de uma filha para fornecer um implementação da operação. O nome da classe deve ser escrito em itálico.

91 91 Figura 26. Classe abstrata B. Classe concreta tem instâncias diretas. Figura 27. Classe concreta C. Classe folha é uma classe que não poderá mais ter filhas. Possui a propriedade {leaf} no nome. Figura 28. Classe folha D. Classe raiz esta classe não terá uma classe mãe. Possui a propriedade {Root} no nome. Figura 29. Classe raiz Booch (2000) oferece algumas sugestões para a construção de um diagrama de classes bem estruturado: O diagrama de classes deve ter como foco comunicar um único aspecto da visão estática do sistema.

92 92 Contém somente elementos essenciais a compreensão desse aspecto. Fornece detalhes consistentes, em nível adequado de abstração, exibindo adornos somente se forem úteis para a compreensão. Deve-se atribuir nomes que comuniquem o significado para o propósito a ser transmitido Não se devem exibir muitos relacionamentos, pois em geral um único tipo de relacionamento tenderá a predominar Diagramas de Sequência Segundo Fowler e Scott (2000) os diagramas de sequência são um tipo de diagrama de interação. Para Booch (2000), estes diagramas dão ênfase à ordenação temporal das mensagens. Nos diagramas de sequência os objetos são mostrados como uma caixa na parte superior de uma linha tracejada vertical. Figura 30. Diagrama de sequência De acordo com Fowler e Scott (2000) a linha vertical é a linha de vida do objeto, que representa o ciclo de vida do referido objeto durante a interação. Os objetos comunicam-se através de mensagens. As mensagens são representadas por uma flecha entre as linhas de vida dos objetos envolvidos na interação. A cada mensagem enviada por um objeto deve haver um retorno, que é também representado como a mensagem, apenas no sentido inverso. As mensagens devem ser rotuladas.

93 93 Fowler e Scott (2000) afirmam que em um programa orientado a objetos o fluxo global de controle é uma das coisas mais difíceis de compreender, uma vez que possui muitos pequenos métodos em classes diferentes. Por isso a dificuldade em estabelecer a sequência global do comportamento pretendido. Neste caso é fundamental o uso dos diagramas de sequência, pois auxiliam na sua compreensão Diagrama de Estado Booch (2000) afirma que os Diagramas de Estados modelam aspectos dinâmicos do sistema. Segundo Fowler e Scott (2000) os diagramas de estados são usados para descrever o comportamento do sistema. Descrevem o comportamento de cada objeto em particular, ao longo do seu ciclo de vida. Os diagramas de estados utilizados pela UML são baseados no statechart de David Harel (1987). Figura 31. Diagrama de Estado Cada caixa representa um estado e as linhas representam os eventos que provocam as mudanças de estados e as ações decorrentes. De acordo com Martins (2005) na transição de um estado para outro, junto às setas, o diagrama é documentado da seguinte forma:

94 94 Evento o evento é o responsável pela mudança de estado de um objeto. Um evento pode ser implementado através de um ou mais métodos da classe. Condição (opcional) a condição precisa ser válida para que o objeto mude de estado. Ação (opcional) uma ação é executada após o objeto mudar de estado Síntese Vimos neste capítulo, a importância da qualidade no processo de desenvolvimento de software, e como ele afeta o sistema informatizado. Bem como, as técnicas de modelagem e documentação do processo de software, realizado através da UML Linguagem de Modelagem Unificada. Ao longo dos anos se desenvolveu a engenharia de software, estabelecendo recomendações, regras, e dicas para o processo de desenvolvimento de software. A sua aplicação tem como objetivo o desenvolvimento de software de qualidade, satisfazendo as necessidades dos usuários.

95 95 3 MODELAGEM DO PROJETO DE SISTEMA DE GESTÃO RURAL COMO SERVIÇO SAAS O agronegócio brasileiro é um importante setor dentro da economia do nosso país. De acordo com o Censo Agropecuário 2006, realizado pelo IBGE, no ano de 2006, o Brasil possuía mais estabelecimentos rurais. Sendo neste setor ocupada uma população de mais de pessoas. A busca constante pela inovação, pela adesão ao uso de novas tecnologias nos diferentes setores da economia está cada dia mais presente. Inclusive naqueles setores onde ainda observa-se algum tipo de resistência. A busca pela competitividade é cada vez mais acirrada. Os produtores rurais utilizam-se cada dia mais de máquinas modernas, de última geração para a realização dos seus trabalhos, seja na lavoura ou na pecuária. Contudo, a grande maioria dos agropecuaristas não sabe realmente quanto lhe custa produzir uma saca de soja, milho, ou um quilo de carne, um litro de leite, uma vez que não armazena as informações sobre o consumo de insumos para a produção, bem como dos preços praticados no momento da venda dos seus produtos. Sendo assim, não tem conhecimento do que realmente está lucrando ou perdendo em sua atividade. Neste contexto, o uso de um software, que represente de forma simples o sistema de gestão de uma propriedade rural, que seja fácil de usar, poderá ser útil aos agricultores e pecuaristas, proporcionando a geração de conhecimento, garantido uma ferramenta de auxílio no gerenciamento do seu negócio. 3.1 Proposta de Modelagem do Sistema Sistema de Gestão Rural como Serviço SAAS (Software as a Service). 3.2 Domínio O domínio do sistema enfatiza a gestão de propriedades rurais, especialmente as de pequeno porte, no entanto, pode também ser aplicado às de grande porte. Bem como, as empresas, tais como, Prefeituras Municipais e

96 96 cooperativas, que desejarem disponibilizar o software aos agricultores familiares em forma de subsídio à administração das propriedades. 3.3 Objetivos do Sistema Este sistema tem como objetivo principal a informatização dos processos a fim de servir de suporte a gestão de propriedades rurais, enfatizando a produção por atividade, bem como as diferentes culturas, da mesma forma a pecuária existente na propriedade. A rigor destaca-se os custos de produção, a produção e a lucratividade, visando proporcionar ao administrador auxílio no processo de tomada de decisão. Sendo que para isso, a partir dos dados informados no sistema, serão disponibilizados ao gestor relatórios que atendam os requisitos anteriormente citados. 3.4 Análise de Requisitos 1. Gerenciador do sistema 2. Cadastro de contatos 3. Cadastro de cliente por tipo Pessoa Física ou Jurídica 4. Cadastro de licença para o cliente 5. Cadastro de Pessoas 6. Cadastro de unidade produtora (Propriedades) por cliente 7. Alocação de pessoas como colaboradores do cliente e por unidade produtora (administrador, técnico responsável, usuário normal) 8. Cadastro de classificação de bens móveis e imóveis 9. Cadastro de imóveis da unidade produtora por classificação (próprios e arrendados) 10. Cadastro de bens móveis (máquinas e equipamentos) da unidade produtora por classificação

97 Cadastro de atividades (Ex. agricultura, bovinocultura de leite, bovinocultura de corte) 12. Cadastro área útil (Tipo de utilização por Atividade) 13. Cadastro produtos por atividade 14. Cadastro de culturas 15. Cadastro de tipos de insumos 16. Cadastro de insumos por tipo (Medicamentos dados adicionais) 17. Cadastro de vacinas 18. Calendário de vacinas 19. Cadastro de doenças 20. Cadastrar raças 21. Cadastro de Reprodutores 22. Cadastro de animais por raça compra) 23. Movimento de entrada de animais na propriedade (por nascimento ou 24. Movimento de saída de animais da propriedade (por óbito-m, venda-v, consumo-c ou outro-o) 25. Movimento de entrada de insumos por fornecedor 26. Movimento de saída e aplicação de insumos por atividade e cultura 27. Movimento de entrada de produtos por atividade e cultura (depósito venda - consumo) venda) 28. Movimento de saída de produtos por atividade e cultura (consumo

98 Controle de registro de bovinos 30. Avaliação de bovinos (por idade, peso, valor) 31. Manejo reprodutivo fêmeas 32. Controle lactações fêmeas 33. Controle leiteiro fêmeas 34. Manejo sanitário animais 35. Emitir relações 36. Emitir relatórios 3.5 Local do Sistema O sistema será implantado em diferentes propriedades pois será desenvolvido para ser executado na Web. Ou seja, deverá ser executado em um servidor Web, em um cloud computing. Contudo, a título de experimento e testes poderá ser instalado e executado em um servidor local. Os levantamentos de requisitos através de entrevistas, ou conversas informais com pessoas interessadas em fazer uso do software foram realizados no município de Nova Ramada. Uma vez que as conversas foram informais, não houve um roteiro de perguntas pré-estabelecido. No dia 12 de maio de 2011 realizou-se a entrevista com o Sr. Elvio Correa, agricultor, residente na localidade de Pinhal. No dia 19 de maio de 2011 deu-se a entrevista com o Sr. Clóvis Bona, agricultor, residente na localidade de Bom Sucesso. No dia 09 de junho de 2011, foi entrevistado o Sr. Silvio Bandeira, agricultor, residente na localidade de Pranchada. Alguns dados obtidos através dos contatos com os agricultores supracitados podem ser visualizados nos documentos disponibilizados em anexo. Além das informações obtidas através dos contatos com outros agropecuaristas, vale ressaltar o conhecimento por mim adquirido ao longo dos anos na propriedade do meu pai, onde posso identificar as necessidades reais para a administração rural.

99 99 Será responsável pelo sistema o Sr. João Carlos Winter, que contará com o apoio do Engenheiro Agrônomo Sr. Gilberto Bortolini da Emater-RS, junto à Prefeitura Municipal de Nova Ramada, tendo como contato telefônico o nº Em caso de ausência do mesmo falar com Sílvia Möbs, que repassará as informações. 3.6 Processo de Software O processo de Software utilizado será o ciclo evolutivo, pois o objetivo é o controle de versões, que proporciona rapidez no desenvolvimento, passando pela análise de requisitos, elaboração de um esboço do modelo e da arquitetura, bem como o planejamento da fase evolutiva e sua implementação, destacando-se nesta as iterações. 3.7 Cenários Primários - O Gerencidor faz login no sistema. - O Gerencidor cadastra o cliente. - O Gerencidor cadastra o usuário do cliente. - O usuário faz login no sistema. - O usuário realiza os cadastros. - O usuário realiza movimento de entrada de insumos e produtos. - O usuário realiza movimento de saída de insumos e produtos. - O usuário emite relações. - O usuário emite relatórios sobre informações de safra. 3.8 Cenários Secundários - Falha na conexão com o servidor / Tente mais tarde. - Falha de Login / Tente novamente.

100 100 - O sistema está inoperante / Tente mais tarde. - O BD está inoperante / Acesse mais tarde. 3.9 Casos de Uso Os casos de uso mostram a relação entre os requisitos do sistema, bem como sua interação com os atores, ou seja, os usuários do sistema. Caso de Uso 01: Gerenciador do sistema Objetivo: Este caso de uso visa cadastrar o Gerenciador do sistema. Atores: - Gerenciador do Sistema. Pré-condição: - Não tem. Caso de Uso relacionado: - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - O Gerenciador do sistema é cadastrado. Cenários Secundários: - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA.

101 101 Caso de Uso 02: Cadastro de contatos Objetivo: Este caso de uso visa cadastrar os contatos. Os contatos são pessoas físicas ou jurídicas. Os contatos serão clientes e, portanto, usuários do sistema. Poderão ser ainda fornecedores ou clientes das empresas ou pessoas que usam o sistema. O cadastro de contatos poderá ser usado por todos os clientes, uma vez que um determinado contato poderá ser fornecedor, ou cliente de um ou vários clientes. Atores: - Gerenciador do Sistema. - Usuário. Pré-condição: - Gerenciador do sistema. Caso de Uso relacionado: - Gerenciar sistema. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - O Contato é cadastrado.

102 102 Cenários Secundários: - É necessário um gerenciador para o sistema / Cadastre-o. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 03: Cadastro de clientes Objetivo: Este caso de uso visa cadastrar o cliente. Cliente é todo àquele contato, pessoa física ou jurídica que contratar os serviços para uso do sistema. Atores: - Gerenciador do Sistema. - Usuário. Pré-condição: - Gerenciador do sistema. - Contato cadastrado. Caso de Uso relacionado: - Gerenciar sistema. - Cadastro de contatos por tipo Pessoa física ou Jurídica. - Consultar Bando de Dados. - Acessar Banco de Dados.

103 103 Cenários Primários: - O cliente é cadastrado. Cenários Secundários: - É necessário um gerenciador para o sistema / Cadastre-o. - Contato não cadastrado / Cadastre-o. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 04: Cadastro de licença para o cliente Objetivo: Este caso de uso visa cadastrar uma licença de uso do sistema para o cliente. Cliente é todo àquele contato, pessoa física ou jurídica que contratar os serviços para uso do sistema. Atores: - Gerenciador do Sistema. - Usuário.

104 104 Pré-condição: - Gerenciador do sistema. - Contato cadastrado. - Cliente cadastrado. Caso de Uso relacionado: - Gerenciar sistema. - Cadastro de contatos por tipo Pessoa física ou Jurídica. - Cadastro de clientes. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - O cliente é cadastrado. Cenários Secundários: - É necessário um gerenciador para o sistema / Cadastre-o. - Contato não cadastrado / Cadastre-o. - Cliente não cadastrado / Cadastre-o. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 05: Cadastro de pessoas

105 105 Objetivo: Este caso de uso visa cadastrar as pessoas. Pessoas possuem endereços, cujo histórico deverá ser armazenado ao longo de sua existência. O cadastro de pessoas é de uso comum de todos os clientes. Atores: - Gerenciador do Sistema. - Usuário. Pré-condição: - Gerenciador do sistema. - Contato cadastrado. - Cliente cadastrado. - Cliente licenciado para usar o sistema. Caso de Uso relacionado: - Gerenciar sistema. - Cadastro de contatos por tipo Pessoa física ou Jurídica. - Cadastro de clientes. - Cadastro de licença para o cliente. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - A pessoa é cadastrada. Cenários Secundários: - É necessário um gerenciador para o sistema / Cadastre-o. - Contato não cadastrado / Cadastre-o. - Cliente não cadastrado / Cadastre-o. - Cliente não licenciado / Contate o Gerenciador e licencie-se. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA.

106 106 Caso de Uso 06: cadastrar unidade produtora (propriedades) por cliente. Objetivo: Este caso de uso visa cadastrar as unidades produtoras (propriedades) do cliente. Atores: - Gerenciador do sistema. - Usuário. Pré-condição: - Cliente cadastrado e licenciado. - Usuário do cliente cadastrado. Caso de Uso relacionado: - Cadastro de cliente por tipo Pessoa física ou Jurídica. - Cadastro de pessoas.

107 107 - Alocação de pessoas como colaboradores do cliente. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Cadastro de unidade produtora (Propriedades) por cliente. Cenários Secundários: - É necessário privilégios de administrador para realizar este cadastro / Consulte o administrador do sistema. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 07: Alocação de pessoas como colaboradores do cliente e por unidade produtora (Administrador, técnico responsável, usuário normal)

108 108 Objetivo: Este caso de uso visa realizar a alocação de pessoas como colaboradores dos clientes, bem como por unidade produtora de cada cliente. Os colaboradores alocados por cliente terão acesso a todas as unidades produtoras do mesmo. Já àqueles alocados por unidade produtora terão acesso apenas à própria unidade. Atores: - Gerenciador do sistema. - Administrador. - Usuário. Pré-condição: - Cliente cadastrado e licenciado. - Pessoa cadastrada. - Administrador do cliente alocado. - Unidade produtora cadastrada. Caso de Uso relacionado: - Cadastro de contatos por tipo Pessoa física ou Jurídica. - Cadastro de clientes. - Cadastrar unidade produtora (propriedades) por cliente. - Cadastro de pessoas. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Alocação de pessoas como colaboradores do cliente e por unidade produtora (Administrador, técnico responsável, usuário normal) Cenários Secundários: - É necessário privilégios de administrador para realizar a alocação / Consulte o administrador do sistema. - Unidade produtora não cadastrada / Cadastre-a. - Pessoa não cadastrada / Cadastre-a.

109 109 - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 08: Cadastro de classificação de bens móveis e imóveis. Objetivo: Este caso de uso visa cadastrar as classificações dos bens móveis e imóveis. As classificações cadastradas por um determinado cliente poderão ser acessadas e usadas por todos os demais, de acordo com a necessidade. Atores: - Usuário. Pré-condição: - Não tem. Caso de Uso relacionado: - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Cadastro de classificação de bens móveis e imóveis. Cenários Secundários: - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA.

110 110 Caso de Uso 09: Cadastro de imóveis da unidade produtora (próprios e arrendados) Objetivo: Este caso de uso visa cadastrar os imóveis próprios ou arrendados das unidades produtoras (propriedades) do cliente. Atores: - Usuário. Pré-condição: - Unidade produtora cadastrada. - Classificação de bens móveis e imóveis cadastrado. Caso de Uso relacionado: - Cadastrar unidade produtora (propriedades) por cliente. - Cadastro de classificação de bens móveis e imóveis. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Cadastro de imóveis da unidade produtora (próprios e arrendados) Cenários Secundários:

111 111 - Unidade produtora não cadastrada / Cadastre-a. - Classificação não cadastrada / Cadastre-a. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 10: Cadastro de bens móveis (máquinas e equipamentos) da unidade produtora por classificação Objetivo: Este caso de uso visa cadastrar os bens móveis do cliente. Atores: - Usuário. Pré-condição: - Unidade produtora cadastrada. - Classificação de bens móveis e imóveis cadastrado. Caso de Uso relacionado: - Cadastrar unidade produtora (propriedades) por cliente. - Cadastro de classificação de bens móveis e imóveis. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Cadastro de bens móveis da unidade produtora.

112 112 Cenários Secundários: - Unidade produtora não cadastrada / Cadastre-a. - Classificação não cadastrada / Cadastre-a. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 11: Cadastro de atividades (ex. Agricultura, bovinocultura de leite, bovinocultura de corte). Objetivo: Este caso de uso visa cadastrar as atividades. Atividades cadastradas por um determinado cliente poderão ser acessadas e usadas por todos os demais, de acordo com a necessidade de cada um. Atores: - Usuário. Pré-condição: - Não tem. Caso de Uso relacionado: - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Cadastro de atividades.

113 113 Cenários Secundários: - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 12: Cadastro área útil, tipo de utilização por atividade Objetivo: Este caso de uso visa cadastrar as áreas úteis e utilizadas, de acordo com as atividades e culturas empregadas anualmente nos imóveis próprios ou arrendados das unidades produtoras (propriedades) do cliente. Atores: - Usuário. Pré-condição: - Unidade produtora cadastrada.

114 114 - Imóvel da unidade produtora cadastrado. - Atividade cadastrada. - Cultura cadastrada. Caso de Uso relacionado: - Cadastrar unidade produtora (propriedades) por cliente. - Cadastro de imóveis da unidade produtora por classificação (próprios e arrendados). - Cadastro de atividades (Ex.: agricultura, bovinocultura de leite, bovinocultura de corte). - Cadastro de culturas. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Cadastro área útil, tipo de utilização por atividade. Cenários Secundários: - Atividade não cadastrada / Cadastre-a. - Cultura não cadastrada / Cadastre-a. - Não há imóvel cadastrado para esta unidade produtora / Cadastre-o. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 13: Cadastro de produtos por atividade.

115 115 Objetivo: Este caso de uso visa cadastrar os produtos derivados da produção de cada atividade. Atores: - Usuário. Pré-condição: - Atividade cadastrada. Caso de Uso relacionado: - Cadastro de atividades (Ex.: agricultura, bovinocultura de leite, bovinocultura de corte). - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Cadastro de produtos por atividade. Cenários Secundários: - Atividade não cadastrada / Cadastre-a. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 14: Cadastro de culturas Objetivo: Este caso de uso visa cadastrar as culturas de acordo com suas características - perene ou anual. O cadastro de culturas poderá ser acessado por todos os clientes

116 116 do sistema. Uma vez que determinada cultura certamente será comum a diferentes clientes. Atores: - Usuário. Pré-condição: Não tem. Caso de Uso relacionado: - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Cadastro de culturas. Cenários Secundários: - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 15: Cadastro de tipos de insumos. Objetivo: Este caso de uso visa o cadastro de tipos de insumos. O cadastro de tipos de insumos poderá ser acessado por todos os clientes do sistema. Uma vez que certamente serão comuns a diferentes clientes.

117 117 Atores: - Usuário. Pré-condição: - Não tem. Caso de Uso relacionado: - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Cadastrar tipos de insumos. Cenários Secundários: - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 16: Cadastro de insumos por tipo. Objetivo: Este caso de uso visa o cadastro de insumos por tipo. No caso de cadastros de medicamentos serão exigidos dados adicionais, que não são comuns aos demais itens, tais como, laboratório fabricante, período de carência para leite e carne. O cadastro de insumos poderá ser acessado por todos os clientes do sistema. Uma vez que certamente serão comuns a diferentes clientes.

118 118 Atores: - Usuário. Pré-condição: - Tipo de insumo cadastrado. Caso de Uso relacionado: - Cadastrar tipos de insumos. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Cadastrar insumos por tipo. Cenários Secundários: - Tipo de insumo não cadastrado / Cadastre-o. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 17: Cadastro de vacinas. Objetivo: Este caso de uso visa o cadastro de vacinas. O cadastro de vacinas poderá ser acessado por todos os clientes do sistema. Uma vez que certamente serão comuns a diferentes clientes. Atores: - Usuário.

119 119 Pré-condição: - Não tem. Caso de Uso relacionado: - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Cadastrar vacinas. Cenários Secundários: - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 18: Cadastro de doenças. Objetivo: Este caso de uso visa o cadastro de vacinas. O cadastro de doenças poderá ser acessado por todos os clientes do sistema. Uma vez que certamente serão comuns a diferentes clientes. Atores: - Usuário. Pré-condição: - Não tem.

120 120 Caso de Uso relacionado: - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Cadastrar doenças. Cenários Secundários: - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 19: Calendário de vacinas. Objetivo: Este caso de uso visa o cadastro do calendário de vacinas. Atores: - Usuário. Pré-condição: - Vacinas cadastradas. Caso de Uso relacionado: - Cadastro de vacinas. - Consultar Bando de Dados. - Acessar Banco de Dados.

121 121 Cenários Primários: - Calendário de vacinas. Cenários Secundários: - Vacina não cadastrada / cadastre-a. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 20: Cadastro de raças. Objetivo: Este caso de uso visa o cadastro das raças. O cadastro de raças poderá ser acessado por todos os clientes do sistema. Uma vez que certamente serão comuns a diferentes clientes. Atores: - Usuário. Pré-condição: - Não tem. Caso de Uso relacionado: - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Cadastro de raças.

122 122 Cenários Secundários: - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 21: Cadastro de reprodutores por raça Objetivo: Este caso de uso visa o cadastro de reprodutores. O cadastro de reprodutores poderá ser acessado por todos os clientes do sistema. Uma vez que certamente serão comuns a diferentes clientes. Atores: - Usuário. Pré-condição: - Cadastro de raças. Caso de Uso relacionado: - Cadastrar Raças. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Cadastro de reprodutores. Cenários Secundários: - Raça não cadastrada / cadastre-a. - O sistema não está acessando / Tente depois.

123 123 - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 22: Cadastro de animais por raça Objetivo: Este caso de uso visa o cadastro de animais por raça e unidade produtora. O cadastro de animais é particular a cada unidade produtora. Atores: - Usuário. Pré-condição: - Cadastro de raças. - Cadastro de unidade produtora (propriedades) por cliente. Caso de Uso relacionado: - Cadastrar Raças. - Cadastro de unidade produtora (propriedades) por cliente. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários:

124 124 - Cadastro de animais por raça. Cenários Secundários: - Raça não cadastrada / Cadastre-a. - Unidade produtora não cadastrada / Cadastre-a. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 23: Movimento de entrada de animais na propriedade (por nascimento ou compra). Objetivo: Este caso de uso visa o movimento de entrada de animais na propriedade (por nascimento ou compra). Atores: - Usuário. Pré-condição:

125 125 - Unidade produtora cadastrada. - Cadastro de contatos. Caso de Uso relacionado: - Cadastrar unidade produtora (propriedades) por cliente. - Cadastro de raças. - Cadastro de animais por raça. - Cadastro de contatos. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Movimento de entrada de animais na propriedade (por nascimento ou compra). Cenários Secundários: - Unidade produtora não cadastrada / cadastre-a. - Contato não cadastrado / Cadastre-o. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA.

126 126 Caso de Uso 24: Movimento de saída de animais na propriedade (por nascimento ou compra). Objetivo: Este caso de uso visa o movimento de entrada de animais na propriedade (por nascimento ou compra). Atores: - Usuário. Pré-condição: - Unidade produtora cadastrada. - Cadastro de contatos. Caso de Uso relacionado: - Cadastrar unidade produtora (propriedades) por cliente. - Cadastro de raças. - Cadastro de animais por raça. - Cadastro de contatos.

127 127 - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Movimento de entrada de animais na propriedade (por nascimento ou compra). Cenários Secundários: - Unidade produtora não cadastrada / cadastre-a. - Contato não cadastrado / Cadastre-o. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 25: Movimento de entrada de insumos por fornecedor. Objetivo: Este caso de uso visa o movimento de entrada de insumos por fornecedor. Neste caso de uso os contatos assumem o papel de fornecedores.

128 128 Atores: - Usuário. Pré-condição: - Cadastrar unidade produtora (propriedades) por cliente. - Cadastro de contatos. - Cadastro de tipos de insumos (medicamentos dados adicionais). - Cadastro de insumos por tipo. Caso de Uso relacionado: - Cadastrar unidade produtora (propriedades) por cliente. - Cadastro de contatos. - Cadastro de tipos de insumos (medicamentos dados adicionais). - Cadastro de insumos por tipo. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Movimento de entrada de insumos por fornecedor. Cenários Secundários: - Unidade produtora não cadastrada / Cadastre-a. - Contato não cadastrado / Cadastre-o. - Tipo de insumo não cadastrado Cadastre-o. - Insumo não cadastrado Cadastre-o. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA.

129 129 Caso de Uso 26: Movimento de saída e aplicação de insumos por atividade e cultura. Objetivo: Este caso de uso visa o Movimento de saída e aplicação de insumos por atividade e cultura. Atores: - Usuário. Pré-condição: - Cadastrar unidade produtora (propriedades) por cliente. - Cadastro de contatos. - Cadastro de tipos de insumos (medicamentos dados adicionais). - Cadastro de insumos por tipo. - Cadastro de culturas por tipo (perene anual). - Cadastro de atividades. - Movimento de entrada de insumos por fornecedor. Caso de Uso relacionado:

130 130 - Cadastrar unidade produtora (propriedades) por cliente. - Cadastro de contatos. - Cadastro de tipos de insumos (medicamentos dados adicionais). - Cadastro de insumos por tipo. - Cadastro de culturas por tipo (perene anual). - Cadastro de atividades (Ex.: agricultura, bovinocultura de leite, bovinocultura de corte). - Movimento de entrada de insumos por fornecedor. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Movimento de saída e aplicação de insumos por atividade e cultura. Cenários Secundários: - Unidade produtora não cadastrada / Cadastre-a. - Atividade não cadastrada / Cadastre-a. - Cultura não cadastrada / Cadastre-a. - Não há saldo suficiente do insumo / Realize movimento de entrada. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA.

131 131 Caso de Uso 27: Movimento de entrada de produtos por atividade e cultura (depósito venda consumo). Objetivo: Este caso de uso visa o movimento de entrada de produtos por atividade e cultura (depósito venda consumo). Atores: - Usuário. Pré-condição: - Cadastro de área útil (tipo de utilização por atividade). - Cadastro de culturas por tipo (perene anual). - Cadastro de atividades (Ex.: agricultura, bovinocultura de leite, bovinocultura de corte). - Cadastro de produtos por atividade. Caso de Uso relacionado: - Cadastro de área útil (tipo de utilização por atividade). - Cadastro de culturas por tipo (perene anual).

132 132 - Cadastro de atividades (Ex.: agricultura, bovinocultura de leite, bovinocultura de corte). - Cadastro de produtos por atividade. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Movimento de entrada de produtos por atividade e cultura (depósito venda consumo). Cenários Secundários: - Área útil (tipo de utilização por atividade) não cadastrado / cadastre-o. - Atividade não cadastrada / cadastre-a. - Cultura não cadastrada / cadastre-a. - Produtos por atividade não cadastrado / cadastre-o. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA.

133 133 Caso de Uso 28: Movimento de saída e aplicação de produtos por atividade e cultura. Objetivo: Este caso de uso visa o movimento de saída de produtos das safras, ou seja, dos produtos das culturas ou atividades da propriedade, os movimentos poderão ser realizados como venda, depósito, ou para consumo. Os movimentos de consumo acarretam entradas de insumos. Atores: - Usuário. Pré-condição: - Cadastro de contatos. - Cadastro de culturas por tipo (perene anual). - Cadastro de atividades (Ex.: agricultura, bovinocultura de leite, bovinocultura de corte). - Cadastro tipos de insumos.

134 134 - Cadastro de insumos por tipo (medicamentos dados adicionais). - Cadastro de culturas por tipo (perene anual). - Cadastro de produtos por atividade. - Movimento de entrada de produtos por atividade e cultura (depósito venda consumo). Caso de Uso relacionado: - Cadastro de contatos. - Cadastro de culturas por tipo (perene anual). - Cadastro de atividades (Ex.: agricultura, bovinocultura de leite, bovinocultura de corte). - Cadastro tipos de insumos. - Cadastro de insumos por tipo (medicamentos dados adicionais). - Cadastro de culturas por tipo (perene anual). - Cadastro de produtos por atividade. - Movimento de entrada de produtos por atividade e cultura (depósito venda consumo). - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Movimento de saída e aplicação de produtos por atividade e cultura. Cenários Secundários: - Contato não cadastrado / Cadastre-o. - Não há movimento de entrada de produtos / realize o movimento. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA.

135 135 Caso de Uso 29: Controle de registro de bovinos. Objetivo: Este caso de uso visa o cadastro do registro de bovinos. Atores: - Usuário. Pré-condição: - Cadastro de animais por raça. Caso de Uso relacionado: - Cadastro de animais por raça. - Cadastrar raças. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Controle de registro de bovinos.

136 136 Cenários Secundários: - Animal não cadastrado / Cadastre-o. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 30: avaliação de bovinos (por idade, peso, valor). Objetivo: Este caso de uso visa a avaliação dos bovinos conforme a idade, o peso e valor. Atores: - Usuário. Pré-condição: - Cadastro de animais por raça. Caso de Uso relacionado: - Cadastro de animais por raça. - Cadastrar raças.

137 137 - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Avaliação de bovinos (por idade, peso, valor). Cenários Secundários: - Animal não cadastrado / Cadastre-o. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 31: Manejo reprodutivo fêmeas. Objetivo: Este caso de uso visa a realização do manejo reprodutivo das fêmeas na propriedade. Atores: - Usuário.

138 138 Pré-condição: - Cadastro de animais por raça. Caso de Uso relacionado: - Cadastro de animais por raça. - Cadastro de raças. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Manejo reprodutivo fêmeas. Cenários Secundários: - Animal não cadastrado / Cadastre-o. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 32: Controle lactações fêmeas.

139 139 Objetivo: Este caso de uso visa a realização do controle de lactações das fêmeas na propriedade. Atores: - Usuário. Pré-condição: - Cadastro de animais por raça. - Manejo reprodutivo fêmeas. Caso de Uso relacionado: - Cadastro de animais por raça. - Manejo reprodutivo fêmeas. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Controle de lactações das fêmeas Cenários Secundários: - Não há fêmeas cadastradas / Cadastre. - Não há manejo reprodutivo deste animal / Realize-o. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA.

140 140 Caso de Uso 33: Controle leiteiro fêmeas. Objetivo: Este caso de uso visa a realização do controle leiteiro das fêmeas na propriedade. Atores: - Usuário. Pré-condição: - Cadastro de animais por raça. - Manejo reprodutivo fêmeas. - Controle lactações fêmeas. Caso de Uso relacionado: - Cadastro de animais por raça. - Manejo reprodutivo fêmeas.

141 141 - Controle lactações fêmeas. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Controle leiteiro fêmeas Cenários Secundários: - Animal sem controle de lactação / Realize o controle. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 34: Manejo sanitário animais. Objetivo: Este caso de uso visa a realização do manjo sanitário dos animais na propriedade. Atores: - Usuário. Pré-condição:

142 142 - Cadastro de animais por raça. Caso de Uso relacionado: - Cadastro de animais por raça. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Manejo sanitário dos animais. Cenários Secundários: - Animal não cadastrado / Cadastre-o. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA.

143 143 Caso de Uso 35: Cadastros Sistema de Gestão Rural. Objetivo: Este caso de uso visa demonstrar a relação dos cadastros a serem realizados pelo sistema. As inter-relações dos mesmos estão demonstradas individualmente nos casos de usos específicos.

144 144 Caso de Uso 36: Movimentos e controles Sistema de Gestão Rural. Objetivo: Este caso de uso visa demonstrar a relação dos movimentos e controles a serem realizados pelo sistema. As inter-relações dos mesmos estão demonstrados individualmente nos casos de usos específicos.

145 145 Caso de Uso 37: Emitir relações. Objetivo: Este caso de uso visa a emissão de relações, relativas aos cadastros realizados. Atores: - Usuário. Pré-condição:

146 146 - Cadastros realizados. Caso de Uso relacionado: - Todos os casos de usos de cadastros. - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Emitir relações. Cenários Secundários: - Não existem dados a ser consultados / Cadastre-os. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA. Caso de Uso 38: Emitir relatórios.

147 147 Objetivo: Este caso de uso visa a emissão de relatórios, relativos às movimentações realizados. Atores: - Administrador do cliente. - Usuário Normal. - Técnico Responsável Pré-condição: - Cadastros realizados. - Movimentos realizados. Caso de Uso relacionado: - Todos os casos de usos de cadastros e movimentações - Consultar Bando de Dados. - Acessar Banco de Dados. Cenários Primários: - Emitir relatórios. Cenários Secundários: - Não existem dados a ser consultados / Movimente-os. - O sistema não está acessando / Tente depois. - O Banco de Dados está inoperante / Avisar o DBA Diagramas de Classes Os diagramas de classes tem como objetivo mostrar as classes de objetos, bem como seus relacionamentos e a cardinalidade destes. Mostrando de forma clara e detalhada como deverá ser implementado o projeto lógico do banco de dados do sistema.

148 148

149 149

150 150

151 Projeto Lógico O projeto lógico tem como objetivo mostrar como deverá ser implementado o banco de dados do sistema em desenvolvimento. Detalhando os objetos, seus atributos, os tipos para cada atributo, bem como os relacionamentos entre as classes, ou seja, as tabelas. Na sequência serão mostradas as tabelas do sistema proposto nesta modelagem. Neste caso serão utilizadas as tabelas já implementadas no banco de dados, e mostradas através de imagens. OBS.: os índices foram gerados pelo sistema a partir das chaves estrangeiras de cada tabela. Tb_animais Tb_atividades

152 152 Tb_avaliacaoanimais Tb_baixaanimais Tb_bensimoveis

153 153 Tb_bensmoveis Tb_calendariovacinas Tb_cidades

154 154 Tb_classificação Tb_cliente Tb_colaboradorcliente

155 155 Tb_contato Tb_contato_pf Tb_contato_pj Tb_controleleiteiro

156 156 Tb_cultura Tb_doencas Tb_endereco Tb_entradaproducao

157 157 Tb_filiacao Tb_gerenciador Tb_imovelarendado

158 158 Tb_imovelproprio Tb_insumo Tb_lactacao

159 159 Tb_licenca Tb_medicamentos Tb_movimentoinsumo

160 160 Tb_movimentoanimais Tb_movimentodaproducao Tb_movimentoinsumo_unitario

161 161 Tb_movimentodaproducao Tb_pessoa Tb_produto

162 162 Tb_raca Tb_registro Tb_reproducao

163 163 Tb_reprodutor Tb_saidaproducao_un Tb_saldoinsumo Tb_saldoproducao

164 164 Tb_tipoinsumo Tb_tratamento Tb_unidade

165 165 Tb_unidadeprodutora Tb_util_terras Tb_vacinas

166 Diagramas de Sequência DIAGRAMA DE SEQÜÊNCIA 01: licenciar cliente Ações: - O Gerenciador acessa o sistema / Recebe retorno. - O Gerenciador cadastra o cliente / Recebe retorno. - O Gerenciador cadastra a licença do cliente / Recebe retorno.

167 167 DIAGRAMA DE SEQÜÊNCIA 02: cadastros Ações: - O Usuário acessa o sistema / Recebe retorno. - O Usuário realiza os cadastros / Recebe retorno. DIAGRAMA DE SEQÜÊNCIA 03: movimentos de animais

168 168 Ações: - O Usuário acessa o sistema / Recebe retorno. - O Usuário realiza os cadastros / Recebe retorno. - O Usuário realiza o movimento de entrada de animais / Recebe retorno. - O Usuário realiza o movimento de saída de animais / Recebe retorno. DIAGRAMA DE SEQÜÊNCIA 04: controles animais Ações: - O Usuário acessa o sistema / Recebe retorno. - O Usuário realiza os cadastros / Recebe retorno. - O Usuário realiza o movimento de entrada de animais / Recebe retorno.

169 169 - O Usuário realiza os controles dos animais / Recebe retorno. DIAGRAMA DE SEQÜÊNCIA 05: movimentos de produtos Ações: - O Usuário acessa o sistema / Recebe retorno. - O Usuário realiza os cadastros / Recebe retorno. - O Usuário realiza o movimento de entrada de produtos / Recebe retorno. - O Usuário realiza o movimento de saída de produtos / Recebe retorno.

170 170 DIAGRAMA DE SEQÜÊNCIA 06: movimentos de insumos Ações: - O Usuário acessa o sistema / Recebe retorno. - O Usuário realiza os cadastros / Recebe retorno. - O Usuário realiza o movimento de entrada de produtos / Recebe retorno. - O Usuário realiza o movimento de saída de produtos / Recebe retorno. - O Usuário realiza o movimento de entrada de insumos / Recebe retorno.

171 171 - O Usuário realiza o movimento de saída de insumos / Recebe retorno. DIAGRAMA DE SEQÜÊNCIA 07: emitir relações Ações: - O Usuário acessa o sistema / Recebe retorno. - O Usuário realiza os cadastros / Recebe retorno. - O Usuário emite relações / Recebe retorno.

172 172 DIAGRAMA DE SEQÜÊNCIA 08: emitir relatórios Ações: - O Usuário acessa o sistema / Recebe retorno. - O Usuário realiza os cadastros / Recebe retorno. - O Usuário realiza os movimentos de entrada e saída / Recebe retorno. - O Usuário emite relatórios / Recebe retorno.

173 Diagramas de Estado DIAGRAMA DE ESTADO 01: licença cliente

174 DIAGRAMA DE ESTADO 02: cadastros 174

175 DIAGRAMA DE ESTADO 03: Movimentos de animais 175

176 DIAGRAMA DE ESTADO 04: movimentos de produtos 176

177 DIAGRAMA DE ESTADO 05: movimento de insumos 177

178 178 DIAGRAMA DE ESTADO 06: controles animais DIAGRAMA DE ESTADO 07: emitindo relações

179 179 DIAGRAMA DE ESTADO 08: emitindo relatórios 3.14 Projeto de Telas 1. Tela login

180 Cadastro contato pessoa física 3. Cadastro de contato pessoa jurídica 4. Cadastro de cliente

181 Cadastro de licença para o cliente 6. Cadastro de Pessoas 7. Cadastro de unidade produtora

182 Alocação de pessoas como colaboradores do cliente e por unidade produtora (administrador, técnico responsável, usuário normal) 9. Cadastro de classificação de bens móveis e imóveis

183 Cadastro de imóveis da unidade produtora por classificação - próprio 11. Cadastro de imóveis da unidade produtora por classificação arrendados

184 Cadastro de bens móveis (máquinas e equipamentos) da unidade produtora por classificação 13. Cadastro de atividades (Ex. agricultura, bovinocultura de leite, bovinocultura de corte) 14. Cadastro área útil (Tipo de utilização por Atividade)

185 Cadastro produtos por atividade 16. Cadastro de culturas 17. Cadastro de tipos de insumos 18. Cadastro de insumos por tipo (Medicamentos dados adicionais)

186 Cadastro de vacinas 20. Calendário de vacinas 21. Cadastro de doenças

187 Cadastrar raças 23. Cadastro de Reprodutores 24. Cadastro de animais por raça

188 Movimento de entrada de animais na propriedade 26. Movimento de saída de animais da propriedade (por óbito-m, venda-v, consumo-c ou outro-o) 27. Movimento de entrada de insumos por fornecedor

189 Movimento de saída e aplicação de insumos por atividade e cultura 29. Movimento de entrada de produtos por atividade e cultura (depósito venda - consumo)

190 Movimento de saída de produtos por atividade e cultura (consumo venda) 31. Controle de registro de bovinos 32. Avaliação de bovinos (por idade, peso, valor)

191 Manejo reprodutivo fêmeas 34. Controle lactações fêmeas 35. Controle leiteiro fêmeas

Engenharia de Software

Engenharia de Software CENTRO UNIVERSITÁRIO NOVE DE JULHO Profº. Edson T. França edson.franca@uninove.br Software Sistemas Conjunto de elementos, entre os quais haja alguma relação Disposição das partes ou dos elementos de um

Leia mais

Características do Software

Características do Software Questionamentos Por que tanta demora para entregar? Por que os prazos se atrasam? Por que os custos são altos? Por que não achar todos os erros antes de entregar? Por que dificuldade em medir o progresso

Leia mais

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software O que é software? Software e Engenharia de Software Programas de computador Entidade abstrata. Ferramentas (mecanismos) pelas quais: exploramos os recursos do hardware. executamos determinadas tarefas

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO

SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO Danilo Freitas Silvas Sistemas de informação CEATEC danilofs.ti@gmail.com Resumo:

Leia mais

DEMANDA DE SOFTWARE PELA AGRICULTURA FAMILIAR: ENTRAVES E POTENCIAIS PARA MICRO E PEQUENAS EMPRESAS DESENVOLVEDORAS DE SOFTWARE

DEMANDA DE SOFTWARE PELA AGRICULTURA FAMILIAR: ENTRAVES E POTENCIAIS PARA MICRO E PEQUENAS EMPRESAS DESENVOLVEDORAS DE SOFTWARE DEMANDA DE SOFTWARE PELA AGRICULTURA FAMILIAR: ENTRAVES E POTENCIAIS PARA MICRO E PEQUENAS EMPRESAS DESENVOLVEDORAS DE SOFTWARE MATHEUS AUGUSTO SOUZA DE MORAES 1 CÁSSIA ISABEL COSTA MENDES 2 LAURIMAR GONÇALVES

Leia mais

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi Metodologias de Desenvolvimento de Sistemas Analise de Sistemas I UNIPAC Rodrigo Videschi Histórico Uso de Metodologias Histórico Uso de Metodologias Era da Pré-Metodologia 1960-1970 Era da Metodologia

Leia mais

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Processos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Objetivos Apresentar modelos de processos de software Descrever três modelos genéricos de processo e quando

Leia mais

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com REVISÃO ENGENHARIA DO SOFTWARE Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Software Sequencia de Instruções a serem seguidas ou executadas Dados e rotinas desenvolvidos por computadores Programas

Leia mais

Engenharia de Software: Metodologias e Contextualização. Prof. José Eduardo A. de O. Teixeira vqv.com.br / j.edu@vqv.com.br

Engenharia de Software: Metodologias e Contextualização. Prof. José Eduardo A. de O. Teixeira vqv.com.br / j.edu@vqv.com.br Engenharia de Software: Metodologias e Contextualização Prof. José Eduardo A. de O. Teixeira vqv.com.br / j.edu@vqv.com.br Conceitos iniciais Informática: Ciência que tem como objetivo o tratamento da

Leia mais

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho.

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. - DSI DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. Preocupação: Problema técnicos Mudança na natureza e conteúdo do trabalho

Leia mais

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

Leia mais

Processos de Desenvolvimento de Software. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 2

Processos de Desenvolvimento de Software. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 2 Processos de Desenvolvimento de Software Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 2 A Engenharia de Software Uma Tecnologia em Camadas ferramentas métodos processo foco na qualidade

Leia mais

Introdução Engenharia de Software

Introdução Engenharia de Software Introdução Engenharia de Software Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 EMENTA Parte 1 Conceitos de Engenharia de Software. Processo de desenvolvimento

Leia mais

PLANEJAMENTO E ESTRATÉGIAS 1. O CENÁRIO DO SETOR AGROPECUÁRIO BRASILEIRO

PLANEJAMENTO E ESTRATÉGIAS 1. O CENÁRIO DO SETOR AGROPECUÁRIO BRASILEIRO PLANEJAMENTO E ESTRATÉGIAS 1. O CENÁRIO DO SETOR AGROPECUÁRIO BRASILEIRO A economia brasileira tem passado por rápidas transformações nos últimos anos. Neste contexto ganham espaço novas concepções, ações

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software O que é a engenharia de software É um conjunto integrado de métodos e ferramentas utilizadas para especificar, projetar, implementar e manter um sistema. Método É uma prescrição

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software.

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software. Processos de Software Objetivos Apresentar os modelos de processo de software Conjunto coerente de atividades para especificar, projetar, implementar e testar s de software Descrever os diferentes modelos

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Limites e potenciais da adoção de TI pela agricultura familiar: perspectivas para micro e pequenas empresas de software

Limites e potenciais da adoção de TI pela agricultura familiar: perspectivas para micro e pequenas empresas de software Limites e potenciais da adoção de TI pela agricultura familiar: perspectivas para micro e pequenas empresas de software Matheus Augusto Souza de Moraes Embrapa Informática Agropecuária (matheusm@cnptia.embrapa.br)

Leia mais

monitoramento unificado

monitoramento unificado DOCUMENTAÇÃO TÉCNICA monitoramento unificado uma perspectiva de negócios agility made possible sumário resumo executivo 3 Introdução 3 Seção 1: ambientes de computação emergentes atuais 4 Seção 2: desafios

Leia mais

SISTEMA DE GESTÃO DE PESSOAS SEBRAE/TO UNIDADE: GESTÃO ESTRATÉGICA PROCESSO: TECNOLOGIA DA INFORMAÇÃO

SISTEMA DE GESTÃO DE PESSOAS SEBRAE/TO UNIDADE: GESTÃO ESTRATÉGICA PROCESSO: TECNOLOGIA DA INFORMAÇÃO SISTEMA DE GESTÃO DE PESSOAS SEBRAE/TO UNIDADE: GESTÃO ESTRATÉGICA PROCESSO: TECNOLOGIA DA INFORMAÇÃO Competências Analista 1. Administração de recursos de infra-estrutura de tecnologia da informação 2.

Leia mais

Engenharia de Software-2003

Engenharia de Software-2003 Engenharia de Software-2003 Mestrado em Ciência da Computação Departamento de Informática - UEM Profa. Dra. Elisa H. M. Huzita eng. de software-2003 Elisa Huzita Produto de Software Conceitos Software

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

Processos de Desenvolvimento de Software

Processos de Desenvolvimento de Software Processos de Desenvolvimento de Software Gerenciamento de Projetos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e

Leia mais

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas.

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas. UTILIZAÇÃO DA UML NO DESENVOLVIMENTO DE SISTEMA DE CONTROLE DE VENDAS E ESTOQUE GILBERTO FRANCISCO PACHECO DOS SANTOS Discente da AEMS Faculdades Integradas de Três Lagoas JACKSON LUIZ ARROSTI Discente

Leia mais

ENGENHARIA DE SOFTWARE II

ENGENHARIA DE SOFTWARE II UNIVERSIDADE FEDERAL DO MATO GROSSO ENGENHARIA DE SOFTWARE II Revisão dos principais conceitos da Engenharia de Software: Motivação; Histórico; Terminologia; Principais modelos de processos e métodos;

Leia mais

Engenharia de Software: Introdução. Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes

Engenharia de Software: Introdução. Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes Engenharia de Software: Introdução Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes Programa 1. O processo de engenharia de software 2. UML 3. O Processo Unificado 1. Captura de requisitos 2.

Leia mais

Tópicos. Engenharia de Software: Uma Visão Geral

Tópicos. Engenharia de Software: Uma Visão Geral Tópicos 2 3 Engenharia de Software: Uma Visão Geral SCE 186 - Engenharia de Software Profs. José Carlos Maldonado e Elisa Yumi Nakagawa 2 o semestre de 2002 A importância do Software Software Aplicações

Leia mais

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

! Introdução.  Motivação para Processos de Software. ! Processo Unificado (USDP)  Definições  RUP x USDP  Características do Processo Unificado Agenda! Introdução " Motivação para Processos de Software! (USDP) " Definições " RUP x USDP " Características do! Descrição detalhada do! Processos Derivados! Templates simplificados! Conclusões 2 Processo

Leia mais

Análise e Projeto de. Aula 01. Profa Cristiane Koehler cristiane.koehler@canoas.ifrs.edu.br

Análise e Projeto de. Aula 01. Profa Cristiane Koehler cristiane.koehler@canoas.ifrs.edu.br Análise e Projeto de Sistemas I Aula 01 Profa Cristiane Koehler cristiane.koehler@canoas.ifrs.edu.br Análise e Projeto de Sistemas I Horário das Aulas: 2as feiras das 10h10 às 11h40 e 5as feiras das 08h25

Leia mais

Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA QUESTÃO RESPOSTA QUESTÃO RESPOSTA

Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA QUESTÃO RESPOSTA QUESTÃO RESPOSTA ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TURMA 2008 3º PERÍODO - 5º MÓDULO AVALIAÇÃO MP1 DATA 05/03/2009 ENGENHARIA DE SOFTWARE Dados de identificação do Acadêmico: Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

ENGENHARIA DE SOFTWARE II. Modelos de Ciclo de Vida e Processos de Software AULA 2

ENGENHARIA DE SOFTWARE II. Modelos de Ciclo de Vida e Processos de Software AULA 2 ENGENHARIA DE SOFTWARE II Modelos de Ciclo de Vida e Processos de Software AULA 2 Sumário Motivação Conceitos de Processo de Desenvolvimento de Software Atividades que compõem os processos de desenvolvimento

Leia mais

Introdução à Engenharia de. Software. Introdução à Engenharia de. Software. O que é a Engenharia de Software? Software

Introdução à Engenharia de. Software. Introdução à Engenharia de. Software. O que é a Engenharia de Software? Software Introdução à Engenharia de Gidevaldo Novais (gidevaldo.vic@ftc.br) Introdução à Engenharia de Objetivo Depois desta aula você terá uma noção geral do que é a engenharia de software e dos seus objetivos

Leia mais

2.3. ORGANIZAÇÕES E GESTÃO DOS SISTEMAS DE INFORMAÇÃO

2.3. ORGANIZAÇÕES E GESTÃO DOS SISTEMAS DE INFORMAÇÃO 2.3. ORGANIZAÇÕES E GESTÃO DOS SISTEMAS DE INFORMAÇÃO As Empresas e os Sistemas Problemas locais - impacto no sistema total. Empresas como subsistemas de um sistema maior. Uma empresa excede a soma de

Leia mais

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE CMP1280/CMP1250 Prof. Me. Fábio Assunção Introdução à Engenharia de Software SOFTWARE Programa de computador acompanhado dos dados de documentação e configuração

Leia mais

DESENVOLVIMENTO DE SISTEMAS

DESENVOLVIMENTO DE SISTEMAS Agência Nacional de Vigilância Sanitária METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS GGTIN GESIS Brasília, julho de 2006. Página: 1 Histórico de Revisões Data Versão Descrição Autor 12/06/2006 1.0.00 Criação

Leia mais

Metodologia de Desenvolvimento de Sistemas (Versão 2.0)

Metodologia de Desenvolvimento de Sistemas (Versão 2.0) SERVIÇO PÚBLICO FEDERAL MINISTÉRIO DA INTEGRAÇÃO NACIONAL DEPARTAMENTO NACIONAL DE OBRAS CONTRA AS SECAS Metodologia de Desenvolvimento de Sistemas (Versão 2.0) 1 Sumário 1Introdução... 5 1.1 Objetivo...

Leia mais

Automação do Processo de Instalação de Softwares

Automação do Processo de Instalação de Softwares Automação do Processo de Instalação de Softwares Aislan Nogueira Diogo Avelino João Rafael Azevedo Milene Moreira Companhia Siderúrgica Nacional - CSN RESUMO Este artigo tem como finalidade apresentar

Leia mais

Notas de Aula 02: Processos de Desenvolvimento de Software

Notas de Aula 02: Processos de Desenvolvimento de Software Notas de Aula 02: Processos de Desenvolvimento de Software Objetivos da aula: Introduzir os conceitos de um processo de desenvolvimento de software Definir os processos básicos Apresentar as vantagens

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

Leia mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

Processo Unificado (RUP)

Processo Unificado (RUP) Fases do Desenvolvimento Processo Unificado (RUP) Ulf Bergmann ulf@ime.eb.br Domínio do Problema Objetos Objetos do do Mundo Mundo real real Modelo Semântico Domínio da Solução Aplicação Interface Serviços

Leia mais

O Ciclo de Vida do Desenvolvimento de Sistemas i

O Ciclo de Vida do Desenvolvimento de Sistemas i O Ciclo de Vida do de Sistemas i O Ciclo de Vida do de Sistemas ( SDLC Systems Development Life Cycle), conhecido também com o ciclo de vida do software refere-se aos estágios de concepção, projeto, criação

Leia mais

REPROJETO DA ORGANIZAÇÃO COM SISTEMAS DE INFORMAÇÃO

REPROJETO DA ORGANIZAÇÃO COM SISTEMAS DE INFORMAÇÃO Capítulo 12 REPROJETO DA ORGANIZAÇÃO COM SISTEMAS DE INFORMAÇÃO 12.1 2003 by Prentice Hall OBJETIVOS De que forma o desenvolvimento de um novo sistema poderia mudar a maneira de uma organização trabalhar?

Leia mais

Prof.: Gilberto Onodera

Prof.: Gilberto Onodera Automação de Sistemas Prof.: Gilberto Onodera Aula 21-maio maio-2007 Revisão Conceitos de Macro-economia: Globalização Objetivo: Entender os principais drivers de mercado Economia de escala Paradigma da

Leia mais

Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL)

Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL) Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL) Versão 2.0 Escritório de Gerenciamento de Projetos - EGP Superintendência da Gestão Técnica da Informação SGI Agência Nacional de Energia Elétrica

Leia mais

Administração de Sistemas de Informação Gerenciais

Administração de Sistemas de Informação Gerenciais Administração de Sistemas de Informação Gerenciais UNIDADE VI: Como desenvolver Sistemas de Informação e Gerenciar Projetos. Novos sistemas de informação são construídos como soluções para os problemas

Leia mais

Transformando seu investimento ERP em resultados para seu negócio

Transformando seu investimento ERP em resultados para seu negócio 1 SUMÁRIO 1 2 3 4 Introdução A história do ERP O que um ERP fará pelo seu negócio? 1.1 - Otimização dos processos 1.2 - Gerenciamento completo 1.3 - Informações relevantes 1.4 - Controle Tributário ERP

Leia mais

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

Palavras-Chaves: engenharia de requisitos, modelagem, UML.

Palavras-Chaves: engenharia de requisitos, modelagem, UML. APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE

Leia mais

CURSO DE SISTEMAS DE INFORMAÇÃO

CURSO DE SISTEMAS DE INFORMAÇÃO 1 CURSO DE SISTEMAS DE INFORMAÇÃO EMENTÁRIO DAS DISCIPLINAS 2011.1 BRUSQUE (SC) 2015 2 SUMÁRIO 1ª FASE... 4 01 ARQUITETURA DE COMPUTADORES... 4 02 FILOSOFIA... 4 03 FUNDAMENTOS MATEMÁTICOS PARA COMPUTAÇÃO...

Leia mais

Sistemas de Informação e Programação II Odorico Machado Mendizabal

Sistemas de Informação e Programação II Odorico Machado Mendizabal Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011 Processo de Desenvolvimento de Software Objetivos

Leia mais

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o

Leia mais

Análise estruturada de sistemas

Análise estruturada de sistemas Análise estruturada de sistemas Prof. Marcel O que é Engenharia de software Engenharia de software é uma área do conhecimento da computação voltada para a especificação, desenvolvimento e manutenção de

Leia mais

ERP. Agenda ERP. Enterprise Resource Planning. Origem Funcionalidades Integração Projeto Caso de Sucesso Projeto ERP em Números

ERP. Agenda ERP. Enterprise Resource Planning. Origem Funcionalidades Integração Projeto Caso de Sucesso Projeto ERP em Números ERP Enterprise Resource Planning 1 Agenda Origem Funcionalidades Integração Projeto Caso de Sucesso Projeto ERP em Números ERP Com o avanço da TI as empresas passaram a utilizar sistemas computacionais

Leia mais

Engenharia de Software I. Prof. André Castro Garcia

Engenharia de Software I. Prof. André Castro Garcia Engenharia de Software I Prof. André Castro Garcia 1. Introdução 1.1 A IMPORTÂNCIA DO SOFTWARE Nas primeiras décadas da era do computador, o principal desafio era desenvolver um hardware que reduzisse

Leia mais

Agenda. Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria

Agenda. Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria Agenda Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria Introdução Processo de software é o conjunto de ferramentas, métodos

Leia mais

A evolução da tecnologia da informação nos últimos 45 anos

A evolução da tecnologia da informação nos últimos 45 anos A evolução da tecnologia da informação nos últimos 45 anos Denis Alcides Rezende Do processamento de dados a TI Na década de 1960, o tema tecnológico que rondava as organizações era o processamento de

Leia mais

ENGENHARIA DE REQUISITOS

ENGENHARIA DE REQUISITOS Universidade Federal de Santa Maria Mestrado em Computação ELC 923 Processos de Negócio e Engenharia de Requisitos Especialização em Modelagem e Desenvolvimento de Aplicações Web com JAVA ENGENHARIA DE

Leia mais

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem?

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem? UML e Diagramas de Casos de Uso e Classes Prof. Ms. Luiz Alberto Contato: lasf.bel@gmail.com A linguagem UML UML (Unified Modeling Language) Linguagem de Modelagem Unificada É uma linguagem de modelagem

Leia mais

guia prático 2a Edição Gilleanes T.A. Guedes Novatec

guia prático 2a Edição Gilleanes T.A. Guedes Novatec guia prático 2a Edição Gilleanes T.A. Guedes Novatec Copyright 2007, 2014 da Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta

Leia mais

Introdução à Computação

Introdução à Computação Aspectos Importantes - Desenvolvimento de Software Motivação A economia de todos países dependem do uso de software. Cada vez mais, o controle dos processos tem sido feito por software. Atualmente, os

Leia mais

Softwares de Sistemas e de Aplicação

Softwares de Sistemas e de Aplicação Fundamentos dos Sistemas de Informação Softwares de Sistemas e de Aplicação Profª. Esp. Milena Resende - milenaresende@fimes.edu.br Visão Geral de Software O que é um software? Qual a função do software?

Leia mais

Engenharia de Requisitos Estudo de Caso

Engenharia de Requisitos Estudo de Caso Engenharia de Requisitos Estudo de Caso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 Engenharia de Requisitos Exemplo 1 Reserva de Hotel 1. INTRODUÇÃO Este

Leia mais

COMPUTAÇÃO EM NUVEM: TENDÊNCIAS E OPORTUNIDADES DE NEGÓCIOS RELATÓRIO EXECUTIVO DE NEGÓCIOS

COMPUTAÇÃO EM NUVEM: TENDÊNCIAS E OPORTUNIDADES DE NEGÓCIOS RELATÓRIO EXECUTIVO DE NEGÓCIOS COMPUTAÇÃO EM NUVEM: TENDÊNCIAS E OPORTUNIDADES DE NEGÓCIOS TM RELATÓRIO EXECUTIVO DE NEGÓCIOS A visão da computação em nuvem por Aad van Schetsen, vicepresidente da Compuware Uniface, que mostra por que

Leia mais

CONHECENDO E CONCEITUANDO SISTEMAS DE INFORMAÇÃO

CONHECENDO E CONCEITUANDO SISTEMAS DE INFORMAÇÃO CONHECENDO E CONCEITUANDO SISTEMAS DE INFORMAÇÃO Franco Vieira Sampaio 1 Atualmente a informática está cada vez mais inserida no dia a dia das empresas, porém, no início armazenavam-se os dados em folhas,

Leia mais

agility made possible

agility made possible RESUMO DA SOLUÇÃO DO PARCEIRO Soluções de garantia do serviço da CA Technologies você está ajudando seus clientes a desenvolver soluções de gerenciamento da TI para garantir a qualidade do serviço e a

Leia mais

Introdução sobre Implantação de Sistema ERP em Pequenas Empresas. Prof Valderi R. Q. Leithardt

Introdução sobre Implantação de Sistema ERP em Pequenas Empresas. Prof Valderi R. Q. Leithardt Introdução sobre Implantação de Sistema ERP em Pequenas Empresas Prof Valderi R. Q. Leithardt Objetivo Esta apresentação tem por objetivo mostrar tanto os benefícios como as dificuldades da implantação

Leia mais

Engenharia de Software

Engenharia de Software Universidade São Judas Tadeu Profª Dra. Ana Paula Gonçalves Serra Engenharia de O Processo Uma Visão Genérica Capítulo 2 (até item 2.2. inclusive) Engenharia de - Roger Pressman 6ª edição McGrawHill Capítulo

Leia mais

ERP: Pacote Pronto versus Solução in house

ERP: Pacote Pronto versus Solução in house ERP: Pacote Pronto versus Solução in house Introdução Com a disseminação da utilidade e dos ganhos em se informatizar e integrar os diversos departamentos de uma empresa com o uso de um ERP, algumas empresas

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 11 Arquitetura do sistema Nada que é visto, é visto de uma vez e por completo. --EUCLIDES

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Requisitos de Software Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Requisito O que é um REQUISITO? Em software: É a CARACTERIZAÇÃO do que o

Leia mais

Gestão da Tecnologia da Informação

Gestão da Tecnologia da Informação TLCne-051027-P0 Gestão da Tecnologia da Informação Disciplina: Governança de TI São Paulo, Outubro de 2012 0 Sumário TLCne-051027-P1 Conteúdo desta Aula Abordar o domínio Adquirir e Implementar e todos

Leia mais

REPROJETO DA ORGANIZAÇÃO COM SISTEMAS DE INFORMAÇÃO

REPROJETO DA ORGANIZAÇÃO COM SISTEMAS DE INFORMAÇÃO REPROJETO DA ORGANIZAÇÃO COM SISTEMAS DE INFORMAÇÃO 1 OBJETIVOS 1. De que forma o desenvolvimento de um novo sistema poderia mudar a maneira de uma organização trabalhar? 2. Como uma empresa pode certificar-se

Leia mais

Ciclo de Vida Clássico ou Convencional CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS. Ciclo de Vida Clássico ou Convencional. Enfoque Incremental

Ciclo de Vida Clássico ou Convencional CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS. Ciclo de Vida Clássico ou Convencional. Enfoque Incremental CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS Elicitação Ciclo de Vida Clássico ou Convencional O Modelo Cascata Análise Ana Paula Terra Bacelo Blois Implementação Material Adaptado do Prof. Marcelo Yamaguti

Leia mais

Otimismo desenvolvedoras de softwares

Otimismo desenvolvedoras de softwares Otimismo nas nuvens Ambiente favorável alavanca negócios das empresas desenvolvedoras de softwares, que investem em soluções criativas de mobilidade e computação em nuvem para agilizar e agregar flexibilidade

Leia mais

Resumo de TCC Desenvolvimento de um sistema ERP com foco nas tecnologias de software livre / código aberto

Resumo de TCC Desenvolvimento de um sistema ERP com foco nas tecnologias de software livre / código aberto UFSC - Universidade Federal de Santa Catarina CTC Centro Tecnológico INE Departamento de Informática e Estatística INE5631 Projetos I Prof. Renato Cislaghi Resumo de TCC Desenvolvimento de um sistema ERP

Leia mais

Processo de Desenvolvimento Unificado

Processo de Desenvolvimento Unificado Processo de Desenvolvimento Unificado Processo de Desenvolvimento de Software? Conjunto de atividades bem definidas; com responsáveis; com artefatos de entrada e saída; com dependências entre as mesmas

Leia mais

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1.

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1. Modelos de Sistema Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1 Objetivos Explicar por que o contexto de um sistema deve ser modelado como parte do processo de RE Descrever

Leia mais

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado

Leia mais

Unidade II GERENCIAMENTO DE SISTEMAS. Prof. Roberto Marcello

Unidade II GERENCIAMENTO DE SISTEMAS. Prof. Roberto Marcello Unidade II GERENCIAMENTO DE SISTEMAS DE INFORMAÇÃO Prof. Roberto Marcello SI Sistemas de gestão A Gestão dos Sistemas Integrados é uma forma organizada e sistemática de buscar a melhoria de resultados.

Leia mais

Evolução dos sistemas ERP nas empresas

Evolução dos sistemas ERP nas empresas Evolução dos sistemas ERP nas empresas Aloísio André dos Santos (ITA) aloisio@mec.ita.br João Murta Alves (ITA) murta@mec.ita.br Resumo Os sistemas ERP são considerados uma evolução dos sistemas de administração

Leia mais

Sistema de Automação Comercial de Pedidos

Sistema de Automação Comercial de Pedidos Termo de Abertura Sistema de Automação Comercial de Pedidos Cabana - Versão 1.0 Iteração 1.0- Release 1.0 Versão do Documento: 1.5 Histórico de Revisão Data Versão do Documento Descrição Autor 18/03/2011

Leia mais

natureza do projeto e da aplicação métodos e ferramentas a serem usados controles e produtos que precisam ser entregues

natureza do projeto e da aplicação métodos e ferramentas a serem usados controles e produtos que precisam ser entregues Modelo De Desenvolvimento De Software É uma representação abstrata do processo de desenvolvimento que define como as etapas relativas ao desenvolvimento de software serão conduzidas e interrelacionadas

Leia mais

Modelo Cascata. Alunos: Bruno Nocera Zanette Pedro Taques

Modelo Cascata. Alunos: Bruno Nocera Zanette Pedro Taques Modelo Cascata Alunos: Bruno Nocera Zanette Pedro Taques Principais Características Gerenciamento Simples das etapas Também conhecido como "Ciclo de Vida Clássico", sugere uma abordagem sistemática e sequencial

Leia mais

Análise e Projeto de Sistemas. Engenharia de Software. Análise e Projeto de Sistemas. Contextualização. Perspectiva Histórica. A Evolução do Software

Análise e Projeto de Sistemas. Engenharia de Software. Análise e Projeto de Sistemas. Contextualização. Perspectiva Histórica. A Evolução do Software Análise e Projeto de Sistemas Análise e Projeto de Sistemas Contextualização ENGENHARIA DE SOFTWARE ANÁLISE E PROJETO DE SISTEMAS ENGENHARIA DA INFORMAÇÃO Perspectiva Histórica Engenharia de Software 1940:

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Conceitos e Metodologias para Desenvolvimento de Software Cascata, Prototipação, Espiral e RUP Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br

Leia mais

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 UML 2 Guia Prático Gilleanes T.A. Guedes Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 Novatec capítulo 1 Introdução à UML A UML (Unified Modeling Language ou Linguagem de Modelagem

Leia mais

Corporativo. Transformar dados em informações claras e objetivas que. Star Soft. www.starsoft.com.br

Corporativo. Transformar dados em informações claras e objetivas que. Star Soft. www.starsoft.com.br Corporativo Transformar dados em informações claras e objetivas que possibilitem às empresas tomarem decisões em direção ao sucesso. Com essa filosofia a Star Soft Indústria de Software e Soluções vem

Leia mais

SISTEMAS INTEGRADOS P o r f.. E d E uar a d r o Oli l v i e v i e r i a

SISTEMAS INTEGRADOS P o r f.. E d E uar a d r o Oli l v i e v i e r i a SISTEMAS INTEGRADOS Prof. Eduardo Oliveira Bibliografia adotada: COLANGELO FILHO, Lúcio. Implantação de Sistemas ERP. São Paulo: Atlas, 2001. ISBN: 8522429936 LAUDON, Kenneth C.; LAUDON, Jane Price. Sistemas

Leia mais

Objetivos. PDI - Plano Diretor de Informática. O que é? Como é feito? Quanto dura sua elaboração? Impactos da não execução do PDI

Objetivos. PDI - Plano Diretor de Informática. O que é? Como é feito? Quanto dura sua elaboração? Impactos da não execução do PDI Objetivos Assegurar que os esforços despendidos na área de informática sejam consistentes com as estratégias, políticas e objetivos da organização como um todo; Proporcionar uma estrutura de serviços na

Leia mais