terça-feira, 28 de agosto de 2012

Estudante narra problemas de escola pública!


 
 
No Facebook, estudante narra problemas de escola pública
• Segunda-feira, 27 de agosto de 2012 - 18h52


 
 
          Isadora Faber reúne mais de 10.000 fãs na página "Diário de Classe". Segundo ela, posts "incomodam" docentes e colegas
São Paulo - Poucas pessoas já tinham ouvido falar da Escola Municipal Maria Tomázio Coelho, localizada na Praia do Santinho, em Florianópolis, Santa Catarina. Hoje, quase 10.000 pessoas acompanham de perto a rotina da escola, graças a uma página no Facebook chamada Diário de Classe, mantida por uma estudante do sétimo ano que publica na rede social fotos, vídeos e comentários sobre a rotina e os problemas da instituição.
Isadora Faber, de 13 anos, criou o Diário em julho e até o começo de agosto tinha pouco mais de 400 fãs. Nas últimas semanas, os conteúdos da página correram pela rede como um viral: somente nesta segunda-feira, a página foi "curtida" mais de 4.000 vezes.

"Não esperava que a página fizesse esse sucesso todo. Acho que as pessoas querem realmente saber como as escolas públicas funcionam e elas têm achado interessante o que eu mostro", diz a estudante em entrevista a VEJA.com.
Na página, Isadora registra todo tipo de reclamação. "Olha, temos um orelhão na escola, mas quem disse que funciona??", indaga ela em um dos posts. "Esses fios pra fora será que não é perigoso??" (sic), questiona em outro, acompanhado pela fotos de fios desemcapados que, segundo a autora, estariam provocando choque nos colegas de escola. "De 5 aulas de hoje, só tivemos 2 com os professores titulares, as outras 3 foram com professoras substitutas. Quando temos aulas com auxiliares elas dão um texto e uma pergunta e é sempre isso, acho que o tempo poderia ser melhor aproveitado", conclui.
Segundo ela, as reclamações virtuais têm incomodado os docentes. "Eles me pedem sempre para eu tirar a página do ar, mas não vou tirar. Acho que não estou incomodando ninguém. Só quero ter uma educação de qualidade. É isso que me motiva a fazer esse diário", conta. A reportagem tentou contato com a direção da Escola Municipal Maria Tomázia Coelho, mas a diretora não foi encontrada para comentar o assunto.
Alguma reclamações já teriam surtido efeito. Ventiladores quebrados teriam sido substituídos depois que Isadora postou fotos dos aparelhos estragados no Facebook. As maçanetas dos banheiros também teriam sido reparadas e os fios, trocados para evitar acidentes.
Também não tem sido fácil convencer os amigos, segundo Isadora. "Eles acham que eu estou publicando essas coisas para prejudicar a escola. Fora da escola, eles até me apoiam. Lá, porém, dizem que são contra." Isadora diz que mantém a página sozinha: todos os textos e fotos são postados por ela mesma. Uma irmã ajuda na gravação dos vídeos.
A mãe de Isadora, Mel Faber, tem conhecimento da iniciativa da filha e se diz feliz pela repercussão que a página vem ganhando. "Quando ela me disse que queria colocar tudo isso na internet, eu a alertei: disse que ela poderia receber represálias na escola e que deveria estar pronta para encarar críticas de frente", conta Mel. "Mas ela disse que estava ciente da sua responsabilidade."
Isadora diz que sua inspiração veio da Grã-Bretanha. Na Escócia, a pequena Martha Payne, de 9 anos, criou um blog para criticar a qualidade da merenda de sua escola. Todos os dias, ela fotografava a refeição e postava na página intitulada "Never Seconds". Depois de o blog receber mais de 1 milhão de acessos, a secretaria de educação da cidade de Argyll se pronunciou sobre a qualidade da merenda escolar e pressionou por mudanças. Até o famoso chef Jamie Oliver se manifestou nas redes sociais em apoio à estudante. "Vi que lá tinha dado certo. Pensei que aqui também poderia ter algum efeito", diz Isadora.


segunda-feira, 27 de agosto de 2012

Programa de instalação do syspaf da Vciga Homologado.

Vciga Sistemas






Programa de instalação do syspaf da Vciga Homologado.


1° - Passo pesquizar no google.com.br e baixe o arquivo pscp.exe do site de download.
       segue abaixo o link para baixar o pscp.




http://the.earth.li/~sgtatham/putty/latest/x86/pscp.exe

2° - Crie uma pasta com o nome C:\vciga e salve o pscp.exe dentro.



3° - Salve dentro o arquivo pscp.exe que  você baixou!



4° - Abra o prompt do commando e entre na pasta vciga que você criou!



5° - Execute o seguinte comando para baixar o instalador do sistema vciga.

pscp vciga@vciga.dyndns.org:/update/syspaf.exe .



6° - Entrar na pasta que baixou o arquivo e executa-lo!


7° - Instalar o sistema!


8° - Executa o arquivo!


9° - clik em avançar!


10° - Escolha o segmento Referente a sua Empresa!


11° - Após escolhido o Segmento Clik em avançar!


 12° - Pasta onde será instalado o sistema paf!


13° - Escolha o tipo de Instalação, Servidor com Paf-ecf, Pdv Paf-ecf ou Retaguarda-terminal!


14° - Aqui vou escolher Retaguarda-terminal!


15° - Sistema instalando arquivos, mesmo modo para servidor-pdv ou pdv!


16° - Aparecerá uma tela que o Sistema foi instalado com sucesso!


17° - Aparecerá uma tela de configuração se o sistema e um servidor-paf, pdv-paf, ou retaguarda!


18° - Tela de configuração do Driver Letodb!


19° - Para configurar o servidor leto digite o endereço "IP" do servidor que esta instalado o sistema de banco de dados!


20° - Sistema instalado com sucesso!


21° - Para cadastra o sistema, tem que digitar um usuário e senha valido cadastrado no servidor vciga,
logo após digita os dados da empresa como "CNPJ, RAZÃO SOCIAL, FANTASIA E OUTROS"!










22° -  Sistema pronto para gerenciar sua empresa e controlar suas demandas de produtos!




sexta-feira, 24 de agosto de 2012

Empresas serão obrigadas a enviar arquivos da Escrituração Fiscal Digital



EFD - Escrituração Fiscal Digital



Atualmente, segundo dados da Gerência de Informações Fiscais da Receita Estadual, cerca de 30% dos 10,7 mil contribuintes do regime de apuração Normal são obrigados a enviar os arquivos na modalidade EFD.




A partir de 1º de janeiro do próximo ano, cerca de dez mil empresas paraibanas, no regime Normal do ICMS, serão obrigadas a enviar os arquivos na modalidade de Escrituração Fiscal Digital (EFD). A portaria nº 184 da Secretaria de Estado da Receita já foi publicada no Diário Oficial do Estado. A obrigatoriedade atinge todos os estabelecimentos com inscrição estadual com o mesmo radical do Cadastro Nacional de Pessoas Jurídicas (CNPJ).
Atualmente, segundo dados da Gerência de Informações Fiscais da Receita Estadual, cerca de 30% dos 10,7 mil contribuintes do regime de apuração Normal são obrigados a enviar os arquivos na modalidade EFD. A Gerência informa ainda que o envio dos arquivos digitais EFD, que trazem os registros dos livros dos contribuintes como os de entrada, de saída, de apuração, do inventário e do Controle de Crédito do ICMS do Ativo Permanente (CIAP), vão dispensar o envio da GIM (Guia de Informação Mensal), que é uma obrigatoriedade mensal atual dessas empresas.
O secretário de Estado da Receita, Marialvo Laureano, revelou que a portaria publicada com antecedência de mais de quatro meses, antes de entrar em vigor, vai ajudar no planejamento das empresas do regime Normal. "O envio dos arquivos digitais pela EFD é uma tendência nacional e irreversível que o mundo fiscal passa atualmente no país, com a evolução do Sistema Público de Escrituração Digital (Sped). A Paraíba vai também seguir esse modelo, que vai trazer mais agilidade e ampliação de informações e, ao mesmo tempo, redução de custos para as empresas”, comentou.  
Desde janeiro de 2009, a Receita Federal do Brasil e as Secretarias Estaduais de Fazenda e de Receita vêm exigindo gradativamente o uso da EFD por contribuintes de várias atividades econômicas. A Escrituração Fiscal Digital faz parte da modernização do Fisco e compõe o SPED. O modelo unifica informações fiscais de todos os contribuintes do ICMS, substituindo os livros fiscais no formato físico para os arquivos digitais.

Segundo a chefe do Núcleo de da Receita Estadual, Tatiana Menezes, os escritórios de contabilidade do Estado já estão se preparando para essa forte migração. "A Paraíba não é exceção. Outras unidades estaduais já fizeram essa mudança. Neste sentido, não podemos ficar à margem desse processo”, reforçou.

Tatiana acrescentou ainda que o envio de arquivos pela internet da EFD garante aos contribuintes a simplificação das obrigações acessórias e redução de custos pela dispensa de emissão e armazenamento de documentos em papel, enquanto para o Fisco vai melhorar o controle das operações e prestações dos contribuintes das informações fiscais.

quarta-feira, 22 de agosto de 2012

Simples Diagrama de Casos de Uso!

Casos de Uso

Diagrama de Casos de Uso
Objetivo
O Diagrama de Casos de Uso tem o objetivo de auxiliar a comunicação entre os analistas e o cliente.
Um diagrama de Caso de Uso descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário.
O cliente deve ver no diagrama de Casos de Uso as principais funcionalidades de seu sistema.
Notação
O diagrama de Caso de Uso é representado por:
  • atores;
  • casos de uso;
  • relacionamentos entre estes elementos.
Estes relacionamentos podem ser:
  • associações entre atores e casos de uso;
  • generalizações entre os atores;
  • generalizações, extends e includes entre os casos de uso.
casos de uso podem opcionalmente estar envolvidos por um retângulo que representa os limites do sistema.
Em maiores detalhes:
  • Atores

Um ator é representado por um boneco e um rótulo com o nome do ator. Um ator é um usuário do sistema, que pode ser um usuário humano ou um outro sistema computacional.
  • Caso de uso

Um caso de uso é representado por uma elipse e um rótulo com o nome do caso de uso. Um caso de uso define uma grande função do sistema. A implicação é que uma função pode ser estruturada em outras funções e, portanto, um caso de uso pode ser estruturado.
  • Relacionamentos
o Ajudam a descrever casos de uso
    • Entre um ator e um caso de uso
      • Associação

Define uma funcionalidade do sistema do ponto de vista do usuário.
    • Entre atores
      • Generalização

- Os casos de uso de B são também casos de uso de A
- A tem seus próprios casos de uso
    • Entre casos de uso
      • Include
Um relacionamento include de um caso de uso A para um caso de uso B indica que B é essencial para o comportamento de A. Pode ser dito também que B is_part_of A.
      • Extend
Um relacionamento extend de um caso de uso B para um caso de uso A indica que o caso de uso B pode ser acrescentado para descrever o comportamento de A (não é essencial). A extensão é inserida em um ponto de extensão do caso de uso A.
Ponto de extensão em um caso de uso é uma indicação de que outros casos de uso poderão ser adicionados a ele. Quando o caso de uso for invocado, ele verificará se suas extensões devem ou não serem invocadas.
Você entendeu?! Provavelmente, não. É que extend é unanimemente considerado um conceito obscuro.
Vamos a novas explicações.
Quando se especifica B extends A, a semântica é:
· Dois casos de uso são definidos: A e A extended by B;
· B é uma variação de A. Contém eventos adicionais, para certas condições;
· Tem que ser especificado onde B é inserido em A.
      • Generalização ou Especialização (é_um)
caso de uso B é_um caso de uso A (A é uma generalização de B, ou B é uma especialização de A).
Um relacionamento entre um caso de uso genérico para um mais específico, que herda todas as características de seu pai.
· Sistema
  • Limites do sistema: representado por um retângulo envolvendo os casos de uso que compõem o sistema.
  • Nome do sistema: Localizado dentro do retângulo.
Exemplo 1

Exemplo 2


Link acessado:

segunda-feira, 20 de agosto de 2012

Diagrama de fluxo de dados!

Diagrama de fluxo de dados


O diagrama de fluxos de dados (DFD) é uma ferramenta para a modelagem de sistemas. Ela fornece apenas uma visão do sistema, a visão estruturada das funções, ou seja, o fluxo dos dados. Se estivermos desenvolvendo um sistema no qual os relacionamentos entre os dados sejam mais importantes que as funções, podemos dar menos importância ao DFD e dedicar-nos aos diagramas de entidade-relacionamento (DER)
Um DFD é uma ferramenta de modelagem que nos permite imaginar um sistema como uma rede de processos funcionais, interligados por “dutos” e “tanques de armazenamento de dados". (Edward Yourdon)

Outros nomes para este diagrama

  • Diagrama de bolhas
  • DFD (abreviatura)
  • Modelo de processo
  • Diagrama de fluxo de trabalho
  • Modelo funcional

Componentes de um DFD

Dfd.JPG

  • DFD Entidades Externas
  • DFD Processos
  • Fluxo de dados
  • Depósito de dados
O DFD pode ter vários níveis de detalhamento de acordo com a necessidade do sistema. O diagrama de contexto é uma representação macro do sistema. Em seguida, temos os DFDs de níveis. O nível mais alto é conhecido como DFD de nível 0 e está logo abaixo do diagrama de contexto. Neste nível as principais funções do sistemas são mostradas. Caso o processo não esteja claro o suficiente o mesmo será aperfeiçoado a cada nível.Quando se diz que o DFD fornece apenas uma visão do sistema,é pelo fato de que através de sua representação gráfica não nos comprometemos com a sua implementação física.



O DIAGRAMA DE FLUXO DE DADOS (DFD)
Todo modelo funcional de um sistema pode ser visto como sendo formado por uma representação gráfica (uma rede de funções ou processos interligados), acompanhada da descrição de cada função e suas interfaces.
A representação gráfica do modelo funcional costuma ser expressa por meio de um diagrama denominado diagrama de fluxo de dados−DFD.
O conceito de função → Caixa Preta
X o------ Y = F(X) ------o Y
por exemplo
Elevar o X o----- No X ao -----o Y
Quadrado
Há ligações de entrada e de saída da caixa.
Conhecem-se os elementos de entrada da caixa.
Conhecem-se os elementos de saída da caixa.
Sabe-se o que a caixa faz com as entradas para obter as saídas.
Não é preciso saber como a caixa realiza suas operações, e nem a ordem.
 
 

quarta-feira, 15 de agosto de 2012

Ferramentas Case - fase de análise e projeto

Astah

Presentation Transcript

  • 1. Ferramentas CASE Análise e Projeto de Software Acadêmico: Helio H. L. C. Monte Alto, 53729 Disciplina: Ambientes de Desenvolvimento de Software
  • 2. Sumário Astah* Características gerais Distribuições Funcionalidades Integração com outras ferramentas Tratamento dos dados Avaliação individual
  • 3. Sumário Argo UML Características gerais Funcionalidades Integração com outras ferramentas Tratamento dos dados Interface gráfica Avaliação individual
  • 4. Sumário Creately Características gerais Requisitos Funcionalidades Integração com outras ferramentas Tratamento dos dados Avaliação individual
  • 5. Astah
  • 6. Características gerais Antigo JUDE; Editor de diagramas UML que incorpora outros recursos de acordo com a distribuição utilizada; Multi-plataforma: Java;Interface separada por visões:Visão de gerenciamento;Visão de projeto;Visão de propriedades;Editor.
  • 7. Características gerais
  • 8. Distribuições Astahcommunity Edição gratuita; UML 2.1;Fácil instalação: baixe, instale e use; Recomendado para uso educacional e projetos pequenos; Diagramas: de classes, de casos de uso, de estados, de atividades, de sequência, de comunicação, de componentes, de deployment, de estrutura composta, de objetos e de pacotes.
  • 9. Distribuições Astah UML Versão paga (1 ano / 1 PC -> $50,00);UML 2.x + Mapas mentais (mindmaps); Engenharia reversa e geração de código: Java, C# e C++;Conversão UML<-> Mindmaps; Equipe: exclusão mútua e mesclagem de arquivos;Exporta: arquivos de imagem, RTF, HTML, CSV.Funções de expressão e assistência adicionais.
  • 10. Distribuições Astah professional Versão paga (1 ano / 1 PC -> $120,00);UML + ERD + DFD + CRUD + Mind map Inclui funcionalidades do Astah* UML Diagramas ER, DFD, CRUD e fluxogramas; Tabela e diagrama de requisitos; Mapa de rastreabilidade; Equipe: Comparação de diagramas e modelos Gerência de modelos de referência Engenharia reversa de bancos de dados; Exporta: SQL, XMI (XML Metadata Interchange), etc.
  • 11. Distribuições AstahShareVersão paga (1 servidor -> $700,00);Cliente/servidor;Desenvolvimento cooperativo pelo browser; Recursos similares aos do Astah Professional.
  • 12. Distribuições Astah UMLPad Versão gratuita para iPad; UML;Exporta XML legível pelo Astah Professional;
  • 13. Distribuições
  • 14. Funcionalidades
  • 15. Integração com outras ferramentas Exportação e importação de XMI (OMG, 2007) (*professional edition):XMI é muito utilizado para representar modelos UML em um formato padrão; Permite integração com outras ferramentas que também lidam com XMI (ex: integração parcial com Rational Rose e Enterprise Architect);
  • 16. Tratamento dos dados Communityedition:exporta arquivos JPEG e PNGUML edition: exporta EMF, SGV, RTF, HTML e CSV;exporta esqueletos de código Java, C# e C++;Importa códigos Java, C# e C++ para fazer reversa; Professional edition:exporta relatório de definição de entidades (XLS);Exporta SQL;Exporta e importa XMI
  • 17. Avaliação individual Vantagens:Edição Community possui recursos básicos adequados à modelagem UML;Edições pagas possuem recursos adicionais bastante interessantes, além de dar suporte ao desenvolvimento em equipe;Desvantagens:Edição Community é muito restrita à UML, tornando difícil a modelagem e especificação baseadas em outros modelos.
  • 18. ArgoUML
  • 19. Sumário Argo UML Características gerais Requisitos Funcionalidades Integração com outras ferramentas Tratamento dos dados Interface gráfica Avaliação individual
  • 20. Características gerais Editor UML open source; Multiplataforma: Java;Sem suporte para UML 2.x;Suporta todos os diagramas da UML 1.4;Importa/exporta XMI;Suporte a OCL (Object Constraint Language);Visões múltiplas e sobrepostas: Permite múltiplas representações gráficas do mesmo elemento em diferentes diagramas;
  • 21. Funcionalidades Geração de código para 5 linguagens (Java, C++, C#, PHP4 e PHP5):Outras linguagens podem ser adicionadas, pois o gerador de código é um framework modular;Engenharia reversa:Para Java, mas também pode ser expandido;Integração com outras ferramentas:XMI (Enterprise Architect, MagicDraw, Poseidon, etc.)


  • Funcionalidades
    Críticos de projeto:
    Agentes que executam em background, analisando e sugerindo possíveis aprimoramentos de design;
    Fornecem, parcialmente, automações corretivas por meio de wizards.
    Lista de tarefas;
    Checklists;
  • Tratamento dos dados
    Exporta GIF, PNG, PostScript, PGML, SVG e XMI;
    Exporta esqueletos de código Java, C++, C# e PHP;
  • Interface gráfica
  • Avaliação individual
    Vantagens:
    Ferramenta gratuita mais completa que o AstahCommunity;
    Desvantagens:
    Não há opção de desfazer (undo);
    Existem incompatibilidades entre versões;
    Restrito à UML 1.4;
  • Creately
  • Sumário
    Creately
    Características gerais
    Requisitos
    Funcionalidades
    Integração com outras ferramentas
    Tratamento dos dados
    Avaliação individual
  • Características gerais
    Ferramenta de diagramação de propósito geral;
    Aplicação nas nuvens (cloudcomputing);
    Multiplataforma: online (Adobe Flex/Flash)
    Foco em equipes virtuais;
    Interface arraste-e-solte WYSIWYG;
    Suporta vários modelos além do UML;
    Possui versão para Desktop, mas é necessário adquirir licença de $75,00
  • Características gerais
    Possui licenças pagas e uma gratuita:
  • Funcionalidades
    Diagramas UML, ER, DFD, fluxogramas, MindMaps, eletrônica, protótipos de GUIs, etc.
    Suporte a trabalho em equipe, incluindo controle de versões e revisões;
  • Funcionalidades
    Sugere correções em diagramas que seguem algum modelo
    Ex:
  • Funcionalidades
    Templates pré-definidos
    Ex: para Design Patterns representados em UML, como Factory, Observer, Facade, etc.
  • Integração
    Plugin para FogBugz
    Sistema de gerenciamento de projetos integrado baseado em web, com foco em rastreamento de erros (bug/issuetracking);
    Facilita correção de bugs e geração da documentação;
    Plugin para Confluence
    Plataforma de colaboração para empresas em formato wiki;
    Plugin para JIRA
    Outra ferramenta de rastreamento de erros, comumente usada para gerência de projetos;
  • Tratamentos dos dados
    Exporta PDF, JPG e PNG;
    Nas versões pagas, exporta XML (não segue o padrão XMI, servindo apenas para backup);
  • Avaliação individual
    Vantagens
    Roda em qualquer lugar pelo browser;
    Não se restringe somente à UML;
    Trabalho colaborativo com equipes virtuais;
    Integração com algumas ferramentas de gerência de projetos
    Desvantagens
    Não há geração de código ou engenharia reversa;
    Não exporta XMI;
    Não suporta alguns diagramas da UML 2.x
  • Comparativo


  • Referências
    ArgoUML. Disponível em < http://argouml.tigris.org/>. Acesso em Agosto de 2011;
    Astah. Disponível em < http://astah.net/>. Acesso em Agosto de 2011.
    Astah Basic OperationGuide. Disponível em . Acesso em Agosto de 2011.
    Case-tools.org. Disponível em < http://case-tools.org/>. Acesso em Agosto de 2011.
    Creately. Disponível em < https://creately.com/ >. Acesso em Agosto de 2011.
    GLOKNER, P. “CreatelyCombines Chart Smarts with Collaboration”. Disponívelem < http://www.readwriteweb.com/start/2009/05/creately-combines-chart-smarts.php>. Acesso em Agosto de 2011.
    OMG XMI Specifications. 2007. Disponível em: http://www.omg.org/spec/XMI/2.1.1/. Acesso em Agosto de 2011.
    Wikipedia
  • UML (Unified Modeling Language)






    UML (Unified Modeling Language) 

        É uma família de notações gráficas (É a sintaxe gráfica da linguagem de modelagem), apoiada por
    um metamodelo (Descreve a semântica dos elementos de modelagem) único, que ajuda na descrição e no projeto de sistemas de software.


    A mesma notação pode ser usada para três perspectivas diferentes:
    • Perspectiva conceitual
    • Perspectiva de especificação
    • Perspectiva de implementação
     Conceitual.
    • Os diagramas são interpretados como descrevendo coisas em uma situação do mundo real ou domínio de interesse.
    De especificação.
     
    • Os diagramas descrevem abstrações de software ou componentes com especificações e interfaces.
    • Sem comprometimento com uma implementação particular (LP)

    De implementação.

    • Os diagramas descrevem implementações de software em uma tecnologia particular



    UML – Aplicação

    UML como rascunho.
    • Diagramas incompletos e informais criados para explorar partes difíceis do problema ou espaço de soluções.

    UML como planta de software.
    Diagramas detalhados usados para:
    • Engenharia reversa: para visualizar e melhor entender o código existente em diagramas UML
    • Geração de código: engenharia avante
     UML como linguagem de programação.
    • Especificação executável completa de um sistema de software
    • Código executável será automaticamente gerado
    • Ainda em desenvolvimento em termos de teoria, ferramentas robustas e usabilidade...




    terça-feira, 14 de agosto de 2012

    CRUD Diagram

    CRUD Diagram

    In Astah Professional you can easily create CRUD Diagrams by selecting items created in Astah. CRUD simply describes which functions (Create, Read, Update and Delete) should be done at each process. The ability of exporting CRUD tables and CRUD statistics can be very useful when you create reports.



    • Create CRUD
    • Edit CRUD
    • Drag & Drop diagrams from Structure Tree to add CRUD
    • Jump to diagrams/models in Structure Tree from CRUD
    • Open diagrams from CRUD (Select item in CRUD and open a diagram where the selected item belongs to)
    • Jump to CRUD from diagrams/models in CRUD (Select item in Diagram and jump to the selected item in CRUD)
    • Export CRUD table to Excel
    • Export All CRUD statistics to Excel
    • Copy CRUD as text and paste on Excel or other applications
    Demo Movie: CRUD Diagram

    Vida Interativa e Incremental de Desenvolvimento de Software!


    Desenvolvimento iterativo e incremental

    O Desenvolvimento Iterativo e Incremental é um processo de desenvolvimento de software criado em resposta às fraquezas do modelo em cascata, o mais tradicional. Os dois padrões mais conhecidos de sistemas iterativos de desenvolvimento são o RUP (Processo Unificado da Rational) e o Desenvolvimento ágil de software. Por isso o desenvolvimento iterativo e incremental é também uma parte essencial da Programação Extrema e outros.




    Definições Incremental e Iterativo
    Desenvolvimento Incremental é uma estratégia de planejamento estagiado em que várias partes do sistema são desenvolvidas em paralelo, e integradas quando completas. Não implica, requer ou pressupõe desenvolvimento iterativo ou em cascata – ambos são estrategias de retrabalho. A alternativa ao desenvolvimento incremental é desenvolver todo o sistema com uma integração única.
    Desenvolvimento iterativo é uma estrategia de planejamento de retrabalho em que o tempo de revisão e melhorias de partes do sistema é pré-definido. Isto não pressupõe desenvolvimento incremental, mas funciona muito bem com ele. Uma diferença típica é que a saída de um incremento não é necessariamente assunto de um refinamento futuro, e seu teste ou retorno do usuário não é utilizado como entrada para planos de revisão ou especificações para incrementos sucessivos. Ao contrario, a saída de uma iteração é examinada para modificação, e especialmente para revisão dos objetivos das iterações sucessivas.




    Ciclo de vida
    A idéia básica por trás da abordagem iterativa é desenvolver um sistema de software incremental, permitindo ao desenvolvedor tirar vantagem daquilo que foi aprendido durante a fase inicial de desenvolvimento de uma versão do sistema. O aprendizado ocorre simultaneamente tanto para o desenvolvedor, quanto para o usuário do sistema.
    Os passos fundamentais do processo estão em iniciar o desenvolvimento com um subconjunto simples de Requisitos de Software e iterativamente alcançar evoluções subseqüentes das versões até o sistema todo estar implementado. A cada iteração, as modificações de projeto são feitas e novas funcionalidades são adicionadas.
    O projeto em si consiste da etapa de inicialização, iteração e da lista de controle do projeto.
    A etapa de inicialização cria uma versão base do sistema. O objetivo desta implementação inicial é criar um produto para que o usuário possa avaliar. Ele deve oferecer um exemplo dos aspectos chave do problema e prover uma solução que seja simples o bastante para que possa ser compreendida e implementada facilmente. Para guiar o processo iterativo, uma lista de controle de projeto é criada. Ela conterá um registro de todas as tarefas que necessitam ser realizadas. Isto inclui itens tais como novas características a serem implementadas e áreas para serem projeto na solução atual. A lista de controle deve ser continuamente revisada como um resultado da fase de análise.
    A etapa iterativa envolve o re-projeto e implementação das tarefas da lista de controle do projeto e a análise da versão corrente do sistema. O objetivo para o projeto de implementação de qualquer iteração é ser simples, direto e modular, preparado para suportar re-projeto neste estágio ou como uma tarefa a ser adicionada na lista de controle do projeto. O código pode, em alguns casos, representar uma fonte maior da documentação do sistema. A análise de uma interação é baseada no feedback do usuário, e facilidades da análise do programa disponíveis. As estruturas de análise envolvidas são a modularidade, usabilidade, reusabilidade, eficiência e obtenção dos objetivos. A lista de controle do projeto é modificada à luz dos resultados da análise.
    Linhas básicas para direcionar a implementação e análise incluem:
    ·      Qualquer dificuldade no projeto, codificação e teste de uma modificação deve ser sinalizada para que possa ser re-projetada ou recodificada.
    ·      Modificações devem ser ajustadas facilmente em módulos isolados e fáceis de encontrar. Se não atendem a isso, algum re-projeto deverá ser necessário.
    ·      Modificações de tabelas devem ser especialmente fáceis de fazer. Se qualquer modificação não é rápida e fácil de ser feita, indica-se a realização de um re-projeto.
    ·      Modificações devem ser fáceis para serem feitas na forma de iterações. Se elas não são, haverá um problema básico tal como um projeto falho ou uma proliferação de correções.
    ·      Correções devem normalmente ser permitidas por somente uma ou duas iterações. Correções devem ser necessariamente para evitar re-projeto durante uma fase de implementação.
    ·      A implementação existente deve ser analisada freqüentemente para determinar quão bem estão sendo atingidos os objetivos do projeto.
    ·      As ferramentas de análise de programa devem ser usadas sempre que necessário para ajudar na análise de implementações parciais.
    ·      Reclamações do usuário devem ser solicitadas e analisadas para registrar as deficiências da implementação atual.




    Características
    O uso de análise e medições como guia do processo de aprimoramento é uma das maiores diferenças entre o desenvolvimento iterativo e o atual Desenvolvimento ágil de software. Isto provê suporte determinante para a efetividade do processo de qualidade do produto, permitindo estudar o processo para um ambiente em particular. As atividades de medição e análise podem ser adicionadas a métodos de desenvolvimento ágil existentes.
    De fato, o contexto das interações múltiplas provê vantagens no uso de medições. Medições são algumas vezes difíceis de serem compreendidas no valor absoluto, mas mudanças relativas nas medições ao longo da evolução de um sistema podem ser muito instrutivas como base para uma análise. Por exemplo, um vetor de medições, m1, m2, ... mn, pode ser definido para caracterizar vários aspectos do produto em algum ponto no tempo, por exemplo, esforço para dados, mudanças, defeitos, atributos lógicos, físicos e dinâmicos, considerações do ambiente, entre outros. Portanto, um observador pode dizer como o produto se caracteriza quanto ao tamanho, complexidade, acoplamento e coesão, se estão aumentando ou diminuindo em relação ao tempo. Tais atributos podem ser monitorados em relação a mudanças de vários aspectos do produto ou podem prover parâmetros para a medição de sinais de potenciais problemas e anomalias.



    Ciclo de Vida Iterativo e Incremental
    O modelo de ciclo de vida incremental e iterativo foi proposto como uma resposta aos problemas encontrados no modelo em cascata. Um processo de desenvolvimento segundo essa abordagem divide o desenvolvimento de um produto de software em ciclos. Em cada ciclo de desenvolvimento, podem ser identificadas as fases de análise, projeto, implementação e testes. Essa característica contrasta com a abordagem clássica, na qual as fases de análise, projeto, implementação e testes são realizadas uma única vez.
    Cada um dos ciclos considera um subconjunto de requisitos. Os requisitos são desenvolvidos uma vez que sejam alocados a um ciclo de desenvolvimento. No próximo ciclo, um outro subconjunto dos requisitos é considerado para ser desenvolvido, o que produz um novo incremento do sistema que contém extensões e refinamentos sobre o incremento anterior.
    Assim, o desenvolvimento evolui em versões, através da construção incremental e iterativa de novas funcionalidades até que o sistema completo esteja construído. Note que apenas uma parte dos requisitos é considerada em cada ciclo de desenvolvimento. Na verdade, um modelo de ciclo de vida iterativo e incremental pode ser visto como uma generalização da abordagem em cascata: o software é desenvolvimento em incrementos e cada incremento é desenvolvido em cascata (figura).
    A abordagem incremental e iterativa somente é possível se existir um mecanismo para dividir os requisitos do sistema em partes, para que cada parte seja alocada a um ciclo de desenvolvimento. Essa alocação é realizada em função do grau de importância atribuído a cada requisito.

    Tipos de Ciclos de Processos

    O PROCESSO ITERATIVO

    A noção de Processo Iterativo corresponde à ideia de “ melhorar (ou refinar) pouco - a - pouco ” o sistema ( iterações ). Em cada iteração a equipe de desenvolvimento identifica e especifica os requisitos relevantes, cria um projeto utilizando a arquitetura escolhida como guia, implementa o projeto em componentes e verifica se esses componentes satisfazem os requisitos. Se uma iteração atinge os seus objectivos, o desenvolvimento prossegue com a próxima iteração, caso contrário a equipa deve rever as suas decisões e tentar uma nova abordagem.
    Portanto, o âmbito do sistema não é alterado, mas o seu detalhe vai aumentando em iterações sucessivas. Um excelente exemplo de aplicação do processo iterativo encontra-se no trabalho artístico, em que o resultado final de uma obra sofre inúmeras iterações.

    O PROCESSO INCREMENTAL

    A noção de processo incremental corresponde à ideia de “ aumentar (alargar) pouco-a-pouco ” o âmbito do sistema. Uma boa imagem para este atributo é a de uma mansão que foi construída por sucessivos incrementos a partir de uma primeira casa com apenas duas divisões.
    Um incremento não é necessariamente a adição do código executável correspondente aos casos de uso que pertencem à iteração em andamento. Especialmente nas primeiras fases do ciclo de desenvolvimento, os desenvolvedores podem substituir um projeto superficial por um mais detalhado ou sofisticado. Em fases avançadas os incrementos são tipicamente aditivos.
    Funcionamento


     
    Fases do RUP
    Em cada ciclo de desenvolvimento, podem ser identificadas as fases de análise, projeto, implementação e testes. Essa característica contrasta com a abordagem clássica, na qual as fases de análise, projeto, implementação e testes são realizadas uma única vez.
    Cada um dos ciclos considera um subconjunto de requisitos. Os requisitos são desenvolvidos uma vez que sejam alocados a um ciclo de desenvolvimento. No próximo ciclo, um outro subconjunto dos requisitos é considerado para ser desenvolvido, o que produz um novo incremento do sistema que contém extensões e refinamentos sobre o incremento anterior.
    Assim, o desenvolvimento evolui em versões, através da construção incremental e iterativa de novas funcionalidades até que o sistema completo esteja construído. Note que apenas uma parte dos requisitos é considerada em cada ciclo de desenvolvimento. Na verdade, um modelo de ciclo de vida iterativo e incremental pode ser visto como uma generalização da abordagem em cascata: o software é desenvolvimento em incrementos e cada incremento é desenvolvido em cascata (figura).
    A abordagem incremental e iterativa somente é possível se existir um mecanismo para dividir os requisitos do sistema em partes, para que cada parte seja alocada a um ciclo de desenvolvimento. Essa alocação é realizada em função do grau de importância atribuído a cada requisito.




    Vantagens
    ·      Redução dos riscos envolvendo custos a um único incremento. Se os desenvolvedores precisarem repetir a iteração, a organização perde somente o esforço mal direcionado de uma iteração, não o valor de um produto inteiro.
    ·      Redução do risco de lançar o projeto no mercado fora da data planejada. Identificando os riscos numa fase inicial o esforço despendido para gerenciá-los ocorre cedo, quando as pessoas estão sob menos pressão do que numa fase final de projeto.
    ·      Aceleração do tempo de desenvolvimento do projeto como um todo, porque os desenvolvedores trabalham de maneira mais eficiente quando buscam resultados de escopo pequeno e claro.
    ·      Reconhecimento de uma realidade freqüentemente ignorada: as necessidades dos usuários e os requisitos correspondentes não podem ser totalmente definidos no início do processo. Eles são tipicamente refinados em sucessivas iterações. Este modelo de operação facilita a adaptação a mudanças de requisitos.



    Desvantagens
    ·      Dificuldade de gerenciamento. Isso ocorre porque as fases de do ciclo podem estar ocorrendo de forma simultânea.



    ·      O usuário pode se entusiasmar excessivamente com a primeira versão do sistema e pensar que tal versão já corresponde ao sistema como um todo.
    ·      Como todo modelo esta sujeito a riscos de projeto:
    O projeto pode não satisfazer aos requisitos do usuário.
    A verba do projeto pode acabar.
    O sistema de software pode não ser adaptável, manutenível ou extensível.
    O sistema de software pode ser entregue ao usuário tarde demais.



    Modelo de um Processo



    DESENVOLVIMENTO ITERATIVO E INCREMENTAL
    O desenvolvimento de um produto comercial de software é uma grande tarefa que pode ser estendida por vários meses, possivelmente um ano ou mais.
    É mais fácil dividir o trabalho em partes menores (iterações) tendo cada uma como resultado um incremento (processo incremental).
    Assim sendo, o princípio subjacente a este processo é que a equipe envolvida pode refinar e melhorar pouco-a-pouco a qualidade e os detalhes do sistema envolvido.

     
    Referências Bibliográficas
    ·      Eduardo BEZERRA. Princípio de Análise e Projeto de Sistemas com UML . . : Campus, 2002 . ISBN 8535210326
    ·      http://pt.wikipedia.org/wiki/Desenvolvimento_iterativo_e_incremental: Origem: Wikipédia