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í
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
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
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.
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.
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,2005... 39
TABELA 3:FLUXOS DO PROCESSO UNIFICADO,PÁDUA PAULA FILHO,2005... 40
TABELA 4:NOTAÇÕES PARA ESPECIFICAÇÃO DE REQUISITOS (SOMMERVILLE,2005)... 47
TABELA 5:ESPECIFICAÇÃO REQUISITOS NÃO FUNCIONAIS (SOMMERVILLE,2005)... 48
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
SUMÁRIO 1 INTRODUÇÃO ...10 1.1 OBJETIVOS... 11 1.2 JUSTIFICATIVA... 12 1.3 METODOLOGIA... 16 1.4 ORGANIZAÇÃO DO TRABALHO... 16
2 ASPECTOS RELACIONADOS À ENGENHARIA E MODELAGEM DE SOFTWARE ...17
2.1 DEFINIÇÃO DE SOFTWARE... 17
2.2 TIPOS DE APLICAÇÃO DE SOFTWARE... 18
2.2.1 Software como Serviço... 19
2.3 DEFINIÇÃO DE ENGENHARIA DE SOFTWARE... 22
2.4 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE... 22
2.5 ATIVIDADES PARA O PROCESSO DE SOFTWARE... 24
2.5.1 Especificação de software... 25
2.5.2 Projeto e implementação de software... 26
2.5.3 Validação de software... 27
2.5.4 Evolução de software... 29
2.6 MODELOS DE PROCESSO DE SOFTWARE... 30
2.6.1 Modelo Cascata... 31
2.6.2 Modelo de Prototipação... 33
2.6.3 Modelo Espiral... 35
2.6.4 Modelo Ciclo Evolutivo... 37
2.6.5 Modelo RUP (Rational Unified Process)... 39
2.7 GERENCIAMENTO DE RISCOS... 40 2.7.1 Identificação de riscos... 42 2.7.2 Análise de riscos... 43 2.7.3 Planejamento de Riscos... 43 2.7.4 Monitoramento de Riscos... 44 2.8 REQUISITOS DE SOFTWARE... 44 2.8.1 Requisitos de Usuário... 46 2.8.2 Requisitos de Sistema... 47 2.8.3 Classificação de Requisitos... 47 2.9 ENGENHARIA DE REQUISITOS... 49
2.9.1 Estudo de Viabilidade dos Requisitos... 50
2.9.2 Obtenção e análise de requisitos... 51
2.9.3 Princípios de Especificação... 53 2.9.4 Validação de Requisitos... 56 2.9.5 Gerência de Requisitos... 58 2.10 PROJETO DE ARQUITETURA... 61 2.10.1 Estruturas do Sistema... 63 2.10.1.1 Processamento Centralizado...63 2.10.1.2 Processamento Distribuído...64 2.11 ORIENTAÇÃO A OBJETOS... 70 2.11.1 Relacionamentos de Objetos... 73
2.11.2 Benefícios da Orientação a Objetos... 75
2.12 MODELAGEM DE SISTEMAS... 76
2.12.1 UML... 77
2.12.2 Arquitetura... 78
2.12.3 Ciclo de Vida no Desenvolvimento do Software... 80
2.12.4 Diagramas UML... 81
2.12.4.1 Diagramas de Casos de Uso...83
2.12.4.3 Diagramas de Sequência...92
2.12.4.4 Diagrama de Estado...93
2.13 SÍNTESE... 94
3 MODELAGEM DO PROJETO DE SISTEMA DE GESTÃO RURAL COMO SERVIÇO – SAAS ...95
3.1 PROPOSTA DE MODELAGEM DO SISTEMA... 95
3.2 DOMÍNIO... 95 3.3 OBJETIVOS DO SISTEMA... 96 3.4 ANÁLISE DE REQUISITOS... 96 3.5 LOCAL DO SISTEMA... 98 3.6 PROCESSO DE SOFTWARE... 99 3.7 CENÁRIOS PRIMÁRIOS... 99 3.8 CENÁRIOS SECUNDÁRIOS... 99 3.9 CASOS DE USO... 100 3.10 DIAGRAMAS DE CLASSES... 147 3.11 PROJETO LÓGICO... 151 3.12 DIAGRAMAS DE SEQUÊNCIA... 166 3.13 DIAGRAMAS DE ESTADO... 173 3.14 PROJETO DE TELAS... 179 4 CONCLUSÃO ...196
4.1 CONTRIBUIÇÕES E LIMITAÇÕES DESTE TRABALHO... 197
4.2 SUGESTÃO PARA TRABALHOS FUTUROS... 197
REFERÊNCIAS BIBLIOGRÁFICAS ...199
REFERÊNCIAS DA WEB ...200
ANEXOS ...201
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.
1.1 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.
Atendidos os objetivos de projeto do software se espera os seguintes resultados:
• Uma modelagem de projeto de software de qualidade.
• Facilitar a compreensão do domínio para o desenvolvimento do
• 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,
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.
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 2006. 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).
É 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.
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.
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 tornou-se 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.
2.2 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
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ão-numé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 Cloud-computing (computação nas nuvens) uma nova forma de oferta de software observa-se nos dias atuais. O Software as a Service (SaaS), ou software como observa-serviço.
2.2.1 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.
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;
• 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;
2.3 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.
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.
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.
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.
2.5.1 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
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)
2.5.2 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:
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
co-relaçõ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)
2.5.3 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,
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.
Figura 3. Processo de Testes (Sommerville, 2005)
2.5.4 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.
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 do Ciclo Evolutivo.
• Modelo RUP (Rational Unified Process).
2.6.1 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.
• 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;
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.
2.6.2 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.
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.
• 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.
2.6.3 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,
realiza-se uma análirealiza-se 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.
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.
• 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.
2.6.4 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
Base
Mudança contínua, degradação
Os sistemas de software sofrem mudanças e se degradam continuamente, tornando-se cada vez menos úteis.
Complexidade crescente Devido às contínuas mudanças, a complexidade do software aumenta.
Evolução do programa 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. Taxa de trabalho
invariável (projetos
A taxa de atividade em grandes projetos de software é estatisticamente invariável (por exemplo, uma propriedade
grandes) com a média de mudanças por ciclo é aproximadamente a mesma).
Limite de crescimento incremental (projetos grandes)
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
• 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.
2.6.5 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, 2005.
Fase Descrição
Concepçã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.
Elaboração Fase na qual o produto é detalhado o suficiente para permitir um planejamento acurado da fase de construção.
Construção Fase na qual é produzida uma versão completamente operacional do produto.
Transição Fase na qual o produto é colocado à disposição de uma comunidade de usuários.
Tabela 3: Fluxos do processo unificado, Pádua Paula Filho, 2005.
Fluxo Descrição
Requisitos Fluxo que visa obter um conjunto de requisitos de um produto, acordado entre cliente e fornecedor.
Análise Tem como objetivo detalhar, estruturar e validar os requisitos, de forma que esses possam ser usados como base para o planejamento detalhado.
Desenho 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.
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
• 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.
2.7.1 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
2.7.2 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.
2.7.3 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:
• 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.
2.7.4 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
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.
