Conhecimento específico dataprev resumo

Metodologias de modelagem e descrição de processos de negócios; identificação e controle de processos críticos em função da estratégia da organização; entendimento das diferenças entre uma organização funcional e uma centrada em processos; conhecimento de fundamentos de gestão de processos de negócio; fundamentos do BPM, notação BPMN. Metodologias de modelagem e descrição de processos de negócios A Metodologia de Modelagem de Processos consiste em um documento de orientação metodológico-instrumental de suporte às fases de análise, desenho e modelagem de processos nas organizações públicas. Na visão do Guia “d” Simplificação [2], processo é um conjunto de recursos e atividades inter-relacionadas ou interativas que transformam insumos (entradas) em serviços/produtos (saídas), sendo realizado para agregar valor. Segundo o Guia para o Gerenciamento de Processos de Negócio (Guia CBOK) da ABPMP [6], um processo é “um conjunto definido de atividades ou comportamentos executados por humanos ou máquinas para alcançar uma ou mais metas”, Metodologia de Modelagem de Processos sendo a categoria processo de negócio “um trabalho ponta-a ponta que entrega valor aos clientes”.

Lista de Siglas: Guia CBOK: Guia para o Gerenciamento de Processos de Negócio BPMN: Notação de Modelagem de Processos de Negócio SWOT: S (forças), W (fraquezas), O (oportunidades) e T (ameaças).

BPMN Especificação para modelagem visual de processos com o objetivo de prover uma interface simples, mas poderosa a ponto de ser utilizada por profissionais de processos e sistemas e por usuários.

Identificação e controle de processos críticos em função da estratégia da organização 2. ETAPAS DO MÉTODO DE IDENTIFICAÇÃO DE PROCESSOS CRÍTICOS PARA A QUALIDADE O método proposto, apresentado na Figura 1, possui três estágios: Desdobramento da qualidade, Desdobramento dos processos e Implementação das ações de melhoria. O desdobramento da qualidade refere-se à construção da matriz da qualidade.

Diferenças entre uma organização funcional e uma centrada em processos Organização funcional : As pessoas são alocadas em departamentos conforme a especialização , pois os problemas surgidos na operação de um setor serão afetos ao chefe especializado na tecnologia em questão.

Centrada ao processos : As organizações orientadas a processos, prioriza a gestão dos processos que cruzam as áreas funcionais, mas preserva a divisão do trabalho que envolve um visão dinâmica de como a organização produz o valor.

BPM: A visão centrada em processos Na visão por processos, as tarefas não são definidas em função do departamento e sim em função daquilo que agrega valor, sem se

preocupar inicialmente com qual departamento que executará a tarefa.

Organogramas não servem para análise de processos de negócios. Processos de negócio não respeitam os limites estabelecidos nos organogramas.

Organização centrada em processos: • Envolve BPM na estratégia; • Possui clara visão dos processos; • A estrutura reflete os processos; • Entende que pode surgir tensões entre processos e departamentos mas possui meios de sanar tais situações; • Recompensas e prêmios baseados em metas de processos.

Organização não centrada em processos: • Apoia iniciativas isoladas de BPM; • Entende que processo é importante pelos problemas que causa; • Pode possuir cadeia de valor bem definida; • Lista de processos e subprocessos; • Estrutura da organização reflete seus departamentos; • Prêmios baseados em metas de departamentos.

Em resumo, a Gestão de Processos é a habilidade de se obter total visibilidade e controle de ponta-a-ponta sobre todas as etapas de uma transação que viaje por múltiplas aplicações, interaja com diversas pessoas, em uma ou mais companhias.

A Gestão de Processos amplia o valor dos processos, sejam grandes ou pequenos, estejam inseridos totalmente na empresa ou se estendam para fora dela, não importa quem esteja envolvido.

Naturalmente, já foram criados alguns tipos de sistemas de gestão de processos. Estas primeiras soluções eram compostas de combinações de sistemas de controle do workflow, sistemas de gestão de documentos ou sistemas de automação, com uma grande quantidade de código para atender suas necessidades pontuais. De fato, nenhuma ferramenta foi capaz de prover uma solução satisfatória e isso ocasionou para as empresas uma grande quantidade de gaps funcionais. Atualmente, a tecnologia disponível permitiu o desenvolvimento de soluções de software que dão vida a poderosos sistemas de gerenciamento de processos.

Fundamentos do BPM, notação BPMN O que é BPM? Gerenciamento de Processos de Negócio ou BPM (Business Process Management) é uma abordagem disciplinada para identificar, desenhar, executar, documentar, medir, monitorar, controlar e melhorar processos de negócio (automatizados ou não) para alcançar resultados pretendidos, consistentes e alinhados com as metas estratégicas de uma organização.

O BPM é uma disciplina de gestão que combina uma abordagem centrada em processo e interfuncional para melhorar a maneira como as organizações atingem suas metas de negócios.

A Metodologia BPM:RAD do Club-BPM, pode implementar em qualquer organização um conjunto de técnicas e padrões formais de modelagem, desenho e integração, enquadrado em uma abordagem metodológica que permite : • Acelerar a primera etapa de projetos de BPM entre 50-70%.

• Entender e simplificar os processos, e assegurar a transversalidade (end-to-end) dos mesmos.

• Aplicar uma Metodologia comum, única, entre Organização, Sistemas (TI) e a Área de Negócio.

• Modelar e desenhar os processos em sua totalidade, holisticamente, com recursos, serviços, dados, regras de negócio, formulários, saídas e indicadores.

• Desenhar detalhadamente os processos orientados a Tecnologias BPM de forma independente do software implementado.

• Permitir uma gestão de mudanças mais rápida e efetiva, para capacitação e conhecimentos em gestão por processos e Tecnologias BPM na organização.

• Promover o trabalho em equipe e gerar entusiasmo.

• Gerar inteligência coletiva através de técnicas formais que permitam aproveitar ao máximo o conhecimento e o talento humano.

• A construção de uma Arquitetura Empresarial.

• Garantir a qualidade dos modelos e desenhos.

•

Atividades

5

Gateways

•

Objetos de conexão Conectam os objetos de fluxo uns com os outros ou a outras informações.

Business Process Modeling Notation O Business Process Model and Notation (BPMN, anteriormente conhecido como Business Process Modeling Notation) (em português Notação de Modelagem de Processos de Negócio) é uma notação da metodologia de gerenciamento de processos de negócio e trata-se de uma série de ícones padrões para o desenho de processos, o que facilita o entendimento do usuário.

Visão geral A Notação de Modelagem de Processos de Negócio é um padrão para modelagem de processos de negócios e fornece uma notação gráfica para a especificação de processos de negócios em um Business Process Diagram (BPD), ou Diagrama de Processos de Negócio, baseado em uma técnica de fluxograma muito semelhante ao de diagramas de atividades da Unified Modeling Language (UML). .

Elementos A modelagem em BPMN é feita através de diagramas simples, com um pequeno conjunto de elementos gráficos. Isto facilita que os usuários de negócio, bem como os desenvolvedores, entendam o fluxo e o processo. As quatro categorias básicas de elementos são as seguintes: Objetos de Fluxo: Eventos, Atividades, Gateways Objetos de Conexão: Fluxo de Sequência, Fluxo de Mensagem, Associação Swim lanes: Pool, Lane Artefatos: Objeto de Dados, Grupo, Anotação Obs: No BPMN versão 2.0 os Objetos de Conexão tem mais um elemento, "Associação de Dados". Nessa versão foi adicionada mais uma categoria básica, "Dados".

Objetos de fluxo são os principais elementos descritivos dentro da BPMN e consistem de três elementos essenciais (Eventos, Atividades e Gateways): 3 Eventos •

6

Fluxos de Sequência

7

Fluxo de Mensagem

8

Associação

Swim lanes A Piscina (Pool) é a representação gráfica da Colaboração entre Participantes. Um Participante representa uma entidade parceira específica (por exemplo, uma empresa) e/ou uma entidade genérica (por exemplo, um comprador, vendedor ou fabricante). Uma Colaboração é uma coleção de mensagens trocadas entre Participantes.

9

Piscina

10

Raia

Artefatos Artefatos são usados para fornecer informações adicionais sobre o processo.

11

Agrupamento

12

Anotação Obs: Anotação sempre vem associada a outro elemento por isso a figura de anotação tem uma associação.

Dados São elementos que armazenam ou transmitem dados durante a execução do processo. Esses elementos são semelhantes a uma variável de linguagem de programação.

13

Dados

•

1.

Engenharia de requisitos: conceitos básicos; técnicas de elicitação de requisitos; gerenciamento de requisitos; especificação de requisitos; técnicas de validação de requisitos; prototipação;

1- Conceitos Básicos 1.1- Engenharia de Requisitos A engenharia de requisitos procura sistematizar o processo de definição de requisitos. “Requisitos: Condição necessária para a obtenção de certo objetivo, ou para o preenchimento de certo objetivo.“ Pesquisas sobre a aquisição (elicitação) de requisitos são valorosas 2- Requisitos Funcionais versus Requisitos Não Funcionais Os requisitos funcionais são requisitos que expressam funções ou serviços que um software deve ou pode ser capaz de executar ou fornecer. As funções ou serviços são, em geral, processos que utilizam entradas para produzir saídas.

A validação de requisitos é um Processo da Engenharia de Requisitos . Este processo trata, tal como o seu nome indica, da validação quanto à consistência, precisão, contextualização de requisitos levantados no processo de identificação e descoberta e de análise e negociação de requisitos. Este processo envolve uma revisão de todos os requisitos levantados e negociados, assim como uma prototipagem e validação de modelos e teste de requisitos.

Os requisitos não funcionais (RNFs) são requisitos que declaram restrições, ou atributos de qualidade para um software e/ou para o processo de desenvolvimento deste sistema. Segurança, precisão, usabilidade, performance e manutenabilidade são exemplos de requisitos não funcionais.

Técnicas no Processo de Validação Consegue-se entender então que o processo de Validação Requisitos têm como "variáveis" de entrada o esboço vindo processo de Análise e Negociação de Requisitos, as normas qualidade da organização/projecto em que se insere e conhecimento empírico obtido de outros projectos.

de do de do

Revisão dos Requisitos A revisão de requisitos deverá ser feito numa reunião formal onde deverá estar presentes um utilizador final ou um representante deste, um especialista do domínio, um representante do cliente, os responsáveis pelo desenho do sistema e os engenheiros de requisitos.

Prototipagem No processo de análise e negociação de requisitos desenvolveu-se um protótipo para facilitar na recolha de requisitos pois é usalmente mais fácil para os Stakeholders conseguirem identificarem exactamente o que querem de uma forma visual e aproximada do que poderá ser o produto final. Logo também será mais fácil na fase de validação de requisitos validar estes através do mesmo processo.

Obviamente que através do prototipo visual é mais fácil detectar inconsistências e problemas nos requisitos. É também de referir a possibilidade de iniciar-se já nesta fase os manuais de utilização (pois normalmente são implementadas as interfaces). Deve-se notar duas pequenas desvantagens na utilização desta técnica. A implementação de um prototipo poderá levar a desilusões para os utilizadores finais, quando as interfaces da versão final não correspondem exactamente às do prototipo e poderá tentar os programadores a utilizar o protótipo como uma continuação do desenvolvimento do sistema. Também se deverá ter em conta o tempo gasto na implementação do prototipo e medir se este tempo no final será compensado pelas vantagens trazidas por este.

Validação de Modelos Uma especificação de requisitos de um sistema pode ser constituída por variadíssimos modelos, que obviamente necessitam de ser validados. Essa validação deverá avaliar individualmente a consistência de cada modelo assim como a consistência entre os vàrios modelos do sistema. Deverá também verificar se estes modelos realmente representam os requisitos reais dos stakeholders.

Testes de Requisitos Para cada requisito funcional deve ser possível definir um ou mais testes a serem realizados no sistema final para ser possível verificar se o sistema cumpre o requisito na integra. Se este teste não for possível ser definido isso vai significar que o requisito necessita de ser clarificado pois muito provavelmente irá criar problemas no desenvolvimento do produto. Na definição de cada teste deverá ser tomado em conta os seguintes pontos: 1. identificador do requisito 2. requisitos relacionados 3. descrição do teste 4. problemas na realização do teste 5. comentário e recomendações Conclusão Como já foi referido o processo de Validação de requisitos é uma das fases mais importantes na elaboração de um documento de requisitos.

Mesmo mantendo um valor bastante elevado neste processo é bastante possível que certos erros passem despercebidos na validação. Isto pode criar certos problemas quando esses erros forem detectados numa fase posterior pois o documento de requisitos já terá sido validado pelo cliente. Nestes casos será necessário uma negociação cuidadosa com os stakeholders, para tentar ultrapassar este problema da melhor forma.

Métrica e estimativas de software, análise de pontos por função; técnicas de modelagem de BI (Business Inteligence) e Data mining O termo métrica de software refere-se à mensuração dos indicadores quantitativos do tamanho e complexidade de um sistema. Estes indicadores são, por sua vez, utilizados para correlatar contra os desempenhos observados no passado afim de derivar previsões de desempenho futuro.

A métrica de software tem como princípios especificar as funções de coleta de dados de avaliação e desempenho, atribuir essas responsabilidades a toda a equipe envolvida no projeto, reunir dados de desempenho pertencentes à complementação do software, analisar os históricos dos projetos anteriores para determinar o efeito desses fatores e utilizar esses efeitos para pesar as previsões futuras. Estes princípios nos permite prever o resto do processo, avaliar o progresso e reduzir a complexidade, como numa prova de rally, onde a cada corrida ficamos mais esclarecidos da condições e limites da equipe.

Métricas Orientadas à Função Consiste em um método para medição de software do ponto de vista do usuário, que determina de forma consistente o tamanho e complexidade de um software, sob a perspectiva do usuário. Ele dimensiona um software, quantificando a funcionalidade proporcionada ao usuário a partir do seu desenho lógico. Ou seja, são medidas indiretas do software e do processo por meio do qual ele é desenvolvido. Em vez de contar linhas de código, a métrica orientada à função concentra-se na funcionalidade ou utilidade do programa.

Uma abordagem foi sugerida baseada nesta proposta chamada de pontos-por-função (function point). Os pontos-por-função (FP’s) são derivados usando-se uma relação empírica baseada em medidas de informações e complexidade do software.

Um dos princípios da análise de pontos-por-função focaliza-se na perspectiva de como os usuários "enxergam" os resultados que um sistema produz. A análise considera as várias formas com que os usuários interagem com o sistema, com os seguintes objetivos:

1.

2.

3.

4.

Fornecer medidas consistentes; Medir funcionalidades que o usuário solicita ou recebe; Independência da tecnologia; Método simples.

5. As métricas orientadas à função apresentam vários benefícios, dentre eles podemos citar o seguintes:

6. Uma ferramenta para dimensionar aplicações; 7. Um veículo para quantificar custo, esforço e tempo; 8. Um veículo para calcular índices de produtividade e qualidade;

9. Um fator de normalização para comparar software.

Tal métrica parece ser útil e funcional para o desenvolvimento tradicional, mas apresenta algumas falhas com o modelo de desenvolvimento em orientação a objeto (OO), pois alguns atributos do design em OO invalidam o cálculo de alguns pontos-por-função.

As características fundamentais de OO têm efeito de reduzir a validade da contagem de funções para a avaliação de esforço e recursos necessários para a execução de um projeto.

A métrica de pontos por função foi originalmente projetada para sistemas de informação comerciais. Para acomodar estas aplicações, a dimensão dos dados foi enfatizada para a exclusão de dimensões funcionais e de controle. Por esta razão, a medida de pontos por função era adequada para muitos sistemas de engenharia. Um número de extensões para a medida básica de pontos por função tem sido propostas para remediar esta situação.

Nota-se que pontos por função, "feature points" e pontos por função 3D representam a mesma coisa – "funcionalidade" ou "utilidade" fornecida pelo software. De fato, cada uma destas medidas resulta no mesmo valor se somente a dimensão de dados de uma aplicação é considerada.

Quais são os tipos de contagem utilizados na APF? Para realizar uma contagem de pontos de função (PF) é necessário definir determinados contextos, dentre eles qual o tipo de contagem a ser realizada. O tipo de contagem não altera a aplicação das regras de contagem mas pode influenciar no Calculo do tamanho no final na contagem. Antes de iniciar uma contagem de pontos de função devese identificar qual o tipo de contagem que se vai efetuar dentro dos três (3) definidos pelo CPM (Manual de Práticas de Contagem) do IFPUG. Existem os seguintes tipos de contagem: • Contagem de pontos de função de projeto de desenvolvimento • Contagem de pontos de função de projeto de melhoria • Contagem de pontos de função de aplicação Projeto. O que é projeto? É uma coleção de tarefas de trabalho para a realização de um produto a ser entregue num determinado prazo (tempo) de execução.

Projeto de desenvolvimento é aquele que tem como objetivo desenvolver e fornecer a primeira versão de uma aplicação (criação de uma aplicação). O tamanho funcional de um projeto de desenvolvimento é uma medida de funcionalidade que é oferecida aos usuários com a criação da aplicação. A contagem de pontos de função de um projeto de desenvolvimento mede as funções fornecidas ao usuário na primeira instalação da aplicação (quando o projeto é concluído). Após a finalização do projeto de desenvolvimento deve ser iniciada a contagem de pontos de função da aplicação.

Se imaginarmos que o sistema de ‘RH’, conforme figura, é a representação das funcionalidades de um projeto de desenvolvimento

onde vai ser construída a aplicação, temos que as funcionalidades do projeto são: ‘Incluir Funcionário’ e ‘Consultar Funcionário’.

Projeto de melhoria é aquele que tem como objetivo efetuar e entregar uma manutenção adaptativa de uma aplicação já existente. A contagem de um projeto de melhoria mede as modificações nas funções da aplicação existente, através da inclusão, alteração ou exclusão de funções fornecidas ao usuário na conclusão do projeto.

Quando um projeto de melhoria é concluído e instalado, a contagem de pontos de função da aplicação deve ser atualizada, utilizando uma fórmula específica para refletir as alterações das respectivas funcionalidades. O tamanho funcional de um projeto de melhoria é uma medida das funcionalidades que são oferecidas aos usuários com a implantação do respectivo projeto.

Se imaginarmos que o sistema de ‘RH’, da figura abaixo, é a representação das funcionalidades da aplicação existente mais as funcionalidades de um projeto de melhoria para acrescentar as seguintes funcionalidades: ‘Listar Funcionários Ativos’ e ‘Listar Funcionários Afastados’.

Contagem da aplicação está associada à aplicação instalada, conhecida também como uma contagem de pontos de função da baseline. Esta contag em fornece uma medida das funções que a aplicação oferece atualmente ao usuário. O tamanho da aplicação deve iniciar quando da finalização do projeto de desenvolvimento e, deve ser atualizada toda a vez que um projeto de melhoria alterar as funções da aplicação.

Se imaginarmos que o sistema de ‘RH’, da figura abaixo, é a representação das funcionalidades da aplicação existente após o projeto de melhoria, temos que toas as funcionalidades apresentadas compõem a aplicação atual.

3. Definição da Métrica 3.1Componentes da Contagem SOA Este capítulo tem o objetivo de descrever os componentes utilizados na PFS. 3.2Escopo O escopo faz referência à abrangência das funcionalidades que serão contadas. Com isso, todas as funcionalidades que fazem parte do projeto fazem parte do seu escopo.

3.3 Funções de Dados As estruturas de dados utilizados nos serviços de entidades são contadas como Funções de Dados.

A identificação de uma função de dado como ALI ou AIE é definida abaixo:  Arquivo Lógico Interno (ALI): Um serviço de entidade é identificado como Arquivo Lógico Interno (ALI), se ele pertence ao escopo do projeto e é persistido por outras funções.  Arquivo de Interface Externa (AIE): Um serviço de entidade é identificado como Arquivo de Interface Externa (AIE), se ele não fizer parte do escopo do projeto, mas for utilizado por alguma função interna. Em projetos SOA os AIEs são geralmente utilizados em serviços de negócio ou serviços Orquestrados.

3.4 Funções Transacionais Serviços de Negócio, Orquestrados e Utilitários, são identificados como funções transacionais.

As operações dos serviços definem os tipos de funções:  Entrada Externa – Operações que alterem o estado de algum arquivo lógico interno (Entidade): inclusão, alteração, exclusão etc..  Saída Externa – Operações que retornem algum resultado calculado ou processado;  Consulta Externa – Operações que retornem dados sem nenhum calculo ou processamento.

Embora as estruturas de dados (XSD) dos serviços de entidades sejam contadas como funções de dados, as operações desses serviços são contadas como funções transacionais.

Assim, todas as operações de todos os serviços envolvidos na contagem, serão consideradas funções transacionais.

3.5 Tipos de contagem Para a criação da PFS foram adaptadas as seguintes métricas do NESMA: estimativa (Early) e detalhada (Detailed).

3.5.1 Estimativa (Inicial e Intermediária) Na PFS, a fase Estimativa será dividida em duas subfases Inicial e Intermediária.

3.5.1.1 Inicial A Estimativa Inicial é feita nas primeiras atividades do projeto, utilizando o Documento de Visão, e tem como objetivo obter um valor aproximado do esforço total do projeto, baseando-se na experiência do contador.

Artefato necessário: Documento de Visão do Projeto.

3.5.1.2 Intermediária A Estimativa Intermediária é feita no início do projeto, após a Estimativa Inicial e após a conclusão do levantamento inicial dos requisitos do sistema sem que haja a necessidade de definição dos campos existentes em cada funcionalidade do sistema.

3.5.2 Detalhada A Estimativa Detalhada requer que o sistema esteja na Fase de Construção.

Para realizar a contagem detalhada, além de determinar as funções de dados (ALI, AIE) e transacionais (EE, SE, CE), é necessário determinar o grau de complexidade funcional (Baixa, Média, Alta) de cada função do sistema individualmente.

2.4.2. SOA Como integrar os sistemas e o BPM? Muitas tecnologias podem ser utilizadas para tal, o SOA é uma delas. SOA (do inglês ServiceOriented Architecture, ou Arquitetura Orientada a Serviços) promove a integração entre negócios e a tecnologia da informação, em outras palavras integração entre os sistemas.

SOA é uma arquitetura proposta para interoperabilidade de sistemas por meio de conjunto de interfaces de serviços fracamente acoplados, onde os serviços não necessitam de detalhes técnicos da plataforma dos outros serviços para a troca de informações ser realizada. (e-ping v.3,2007).

O objetivo do SOA é obter como resultado agilidade e flexibilidade para acompanhar as constantes mudanças necessárias na evolução do mundo dos negócios.

Um data warehouse consiste em uma coleção de dados orientada por assuntos integrados, variante no tempo e não volátil que dá suporte à tomada de decisão pela alta gerência da empresa.

É também um conjunto de ferramentas e técnicas de projeto, que quando aplicadas às necessidades específicas dos usuários e aos bancos de dados específicos permitirá que planejem e construam um Depósito de Dados.

O Data Warehouse não é um produto e não pode ser comprado como um software de banco de dados. O sistema de Data Warehouse é similar ao desenvolvimento de um ERP, ou seja, ele exige análise do negócio, exige o entendimento do que se quer retirar das informações.

Apesar de existirem produtos que fornecem uma gama de ferramentas para efetuar o Cleansing dos dados, a modelagem do banco e da apresentação dos dados, nada disso pode ser feito sem um elevado grau de análise e desenvolvimento.

warehouse. Realizam processos de união de fontes diferentes, facilitando a busca em ambientes heterogêneos.

O sistema de Data Warehouse não pode ser aprendido ou codificado como uma linguagem. Devido ao grande número de componentes e de etapas, um sistema de Data Warehouse suporta diversas linguagens e programações desde a extração dos dados até a apresentação dos mesmos.

Mineração de Dados A Mineração de Dados pode ser definida como um conjunto de técnicas automáticas de exploração de grandes massas de dados de forma a descobrir novos padrões e relações que, devido ao volume de dados, não seriam facilmente descobertas a olho nu pelo ser humano.

De fato, muitas são as técnicas utilizadas, porém a mineração de dados ainda é mais uma arte do que uma ciência. O sentimento do especialista não pode ser dispensado, mesmo que as mais sofisticadas técnicas sejam utilizadas.

Business Intelligence é um termo abrangente, utilizado para descrever uma variedade de técnicas voltadas a identificar, extrair e analisar dados de modo a se obter informações importantes sobre o desempenho empresarial. O objetivo final é utilizar estas informações para tornar mais eficiente o processo de tomada de decisões pelos gestores das empresas.

SOLUÇÕES UTILIZADAS As técnicas de B.I se baseiam muito em cima de ferramentas de B.I. As ferramentas de uso são, na essência, os mecanismos, através dos quais os usuários manipulam os dados no data warehouse e obtém as informações requeridas. Também denominadas ferramentas de uso final “front-end”.

Para desenvolver um Data Warehouse, devemos considerar uma série de pautas que deverão estar alinhadas com os objetivos do negócio e os fatos que precisam ser analisados, incluindo o alcance do sistema, a granularidade dos dados e a navegabilidade desejada.

Devem ser identificadas as origens dos dados para selecioná-los, depurá-los, transformá-los e importá-los. Quando é implementado uma ferramenta de BI deve-se relacionar as questões e suas possíveis decisões, tal como: • Questões de alinhamento de metas: é o primeiro passo para determinar propostas de curto e médio prazos do programa.

• Questões de base: coleta de informações de competência atual e suas necessidades.

• Custos e Riscos: as consequências financeiras da nova iniciativa de BI devem ser estimadas.

• Cliente e "stakeholder": determina quem serão os beneficiados da iniciativa e quem pagará por ela.

• Métricas relacionadas: estes requerimentos de informações devem ser operacionalizadas com clareza e definidas por parâmetros métricos.

• Mensuração Metodológica: deve ser estabelecido um método ou procedimento para determinar a melhor ou aceitável maneira de medir os requerimentos métricos.

• Resultados relacionados: alguém deve ser o monitor do programa de BI para assegurar que os objetivos estão ocorrendo.

Ajustes no programa podem ser necessários. O programa deve ser testado pela eficácia, rentabilidade e validade.

• Ferramentas de Business Intelligence Segundo Carlos Barbieri (2001), de uma maneira geral, as ferramentas para um ambiente de Business Intelligence podem ser classificadas como construção, gerência, uso e armazenamento. Abaixo pode-se obter mais detalhes sobre cada uma.

• Ferramentas de construção As ferramentas de construção têm o objetivo de auxiliar no processo de extração de dados das fontes diversas, seu tratamento de preparação, transformação e sua carga nas estruturas finais do data

• Ferramentas de gerência As ferramentas de gerência objetivam auxiliar o processo de armazenamento e de utilização do data warehouse e do repositório, onde residem as informações de metadados, responsáveis pela definição das estruturas e dos processos de transformação desejados.

Os sistemas OLTP (On-Line Transaction Processing) são os sistemas que capturam as transações de um negócio e as mantêm em estruturas relacionais chamadas Banco de Dados.

Técnicas Existem 5 (cinco) técnicas gerais de mineração de dados que englobam todas as outras formas de apresentação e permitem uma visão mais global e apropriada ao assunto. São elas a classificação, a estimativa, a previsão, a análise de afinidades e a análise de agrupamentos [Carvalho, 2005].

2.2.1 Classificação Como no mundo físico nada é exatamente igual, por mais semelhante que pareça, para se criar classes é preciso permitir que detalhes sejam desprezados e somente as características principais sejam observadas.

A tarefa de classificar geralmente exige a comparação de um objeto ou dado com outros dados ou objetos que supostamente pertençam a classes anteriormente definidas. Para comparar dados ou objetos utiliza-se uma métrica ou forma de medida de diferenças entre eles.

Na mineração de dados são comuns as tarefas de classificação de clientes em baixo, médio ou alto risco de empréstimo bancário; Os algoritmos mais utilizados para este fim são os de árvores de decisão, regressão e redes neurais.

2.2.2 Estimativa A estimativa, ao contrário da classificação, está associada a respostas contínuas.

Estimar algum índice é determinar seu valor mais provável diante de dados do passado ou de dados de outros índices semelhantes sobre os quais se tem conhecimento.

Suponha que se deseja determinar o gasto de famílias cariocas com lazer e que para isto se possua índices de gastos de famílias paulistanas com lazer, em função da faixa etária e padrão sóciocultural. Não se sabe exatamente quanto as famílias cariocas gastam com lazer mas se pode estimar baseando-se nos dados das famílias paulistanas. Certamente que esta estimativa pode levar a grandes erros, uma vez que Rio de Janeiro e São Paulo são cidades com geografias diferentes e que oferecem diferentes opções de lazer a seus habitantes.

A arte de estimar é exatamente esta: determinar da melhor forma possível um valor, baseando-se em outros valores de situações semelhantes.

Os algoritmos de regressão e as redes neurais são bastante utilizados nestes casos.

2.2.3 Previsão A previsão, como tarefa típica de DM, está associada à avaliação de um valor futuro de uma variável a partir dos dados históricos do seu comportamento passado.

Assim, pode-se prever, por exemplo, se o índice bovespa subirá ou descerá no dia seguinte; qual será o valor de determinada ação daqui a um determinado período de tempo; o número de clientes que serão

perdidos por uma empresa, em um dado horizonte futuro de tempo; qual será a população de uma certa cidade daqui a dez anos; entre outras coisas.

Os algoritmos que podem ser utilizados aqui são, dentre outros, as redes neurais, a regressão, e as árvores de decisão.

2.2.4 Análise de Afinidades A análise de afinidades preocupa-se em reconhecer padrões de ocorrência simultânea de determinados eventos nos dados em análise.

O exemplo mais clássico de análise de afinidades é o do carrinho de supermercado, do qual deseja-se conhecer quais os produtos que são comumente comprados em conjunto pelos consumidores. Isto possibilita a otimização do layout interno dos supermercados e a realização de vendas dirigidas nas quais os itens são oferecidos já em conjuntos com preços menores.

Em termos de algoritmos, a utilização das regras de associação constitui-se no procedimento mais utilizado nestes casos [Pelegrin et al., 2005].

2.2.5 Análise de agrupamentos A análise de agrupamentos visa formar grupos de objetos ou elementos mais homogêneos entre si.

Por exemplo, dadas as classes animal, vegetal e mineral, é relativamente simples classificar a qual dessas classes um certo objeto pertence, porém de posse de uma massa de dados sobre o consumo no Brasil, determinar quantas classes ou padrões de comportamento consumista existem é algo bem diferente.

Em geral, a técnica de agrupamento é executada por algoritmos estatísticos específicos para esse fim, porém as redes neurais e os algoritmos genéticos [Han et al., 2001] são também utilizados neste sentido.

O Data Warehouse (DW) se trata, sem sombras de dúvidas, da mais importante tecnologia existente no desenvolvimento de soluções de Business Intelligence (BI). Ela é a base para o armazenamento das informações necessárias para a utilização por gestores e analistas na tomada de decisão.

O DW possui estrutura e características que suportam análise de grande volumes de dados. Para entender melhor essa poderosa tecnologia, precisamos compreender melhor sua arquitetura através dos seus componentes.

Abaixo segue uma arquitetura genérica de DW e as descrições dos seus elementos:

• OLAP: o OLAP, do inglês On-line Analytical Processing, na arquitetura de um DW se refere as ferramentas com capacidade de análise em múltiplas perspectivas das informações armazenadas.

• Data Mining: Data Mining ou Mineração de Dados, se refere as ferramentas com capacidade de descoberta de conhecimento relevante dentro do DW. Encontram correlações e padrões dentro dos dados armazenados.

Fundamentos do ITIL® 2011, com ênfase em: Gerenciamento Financeiro (Estratégias de Serviço), Gerenciamento do Nível de Serviço (Desenho de Serviço), Gerenciamento da Configuração e de Ativo de Serviço (Transição de Serviço) e Gerenciamento de Mudança (Transição de Serviço).

Gerenciamento Financeiro para Serviços em TI Definições - Modelo de Custo: Uma estrutura usada para registrar e alocar custos.

- Tipos de Custos: Usado para categorizar os curso dentro de uma estrutura de Modelo de Custos.

- Elementos de Custos: Usado para auxiliar a divisão dos tipos de custos.

- Categoria de Custos: Capital ou Operacional (Classificação mínima dos Elementos de Custos) - Custos Direto ou Indireto - Custos Fixo ou Variável ITIL & Gerenciamento de Serviços em TI ITIL: Information Technology Infrastructure Library - Fornece um conjunto amplo, consistente e coerente de melhores práticas focadas no Gerenciamento de Serviços de TI. - Promove uma abordagem de qualidade para alcançar efetividade de negócio na utilização de sistemas de informação.

Gerenciamento de Serviços de TI - Focado na entrega e suporte de serviços em TI que sejam adequados aos requisitos de negócio da organização.

Gerenciamento de Configuração - Objetivo: Gerenciamento da Configuração provê um modelo lógico da infra-estrutura ou de um serviço, identificando, controlando, mantendo e verificando as versões dos itens de Configuração (ICs) existentes. * Controle de Mudanças * Conhecer todos os conponentes * Auditoria Gerenciamento de Mudanças Objetivo: Garantir que métodos e procedimentos padronizados sejam usados para lidar com rodas as mudanças de maneira eficiente e rápida a fim de minimizar o impacto de incidentes relacionados a mudanças e melhorar as operações do dia-a-dia.

(Gerenciamento de Mudança não faz a mudança, mas avalia).

• Fonte de dados: abrange todos os dados de origem que irão compor as informações do DW. Compreende os sistemas OLTP, arquivos em diversos formatos (XLS, TXT, etc), sistemas de CRM, ERP, entre vários outros.

• ETL: o ETL, do inglês Extract, Transform and Load, é o principal processo de condução dos dados até o armazenamento definitivo no DW. É responsável por todas as tarefas de extração, tratamento e limpeza dos dados, e inserção na base do DW. • Staging Area: a Staging Area é uma área de armazenamento intermediário situada dentro do processo de ETL. Auxilia a transição dos dados das origens para o destino final no DW. • Data Warehouse: essa é a estrutura propriamente dita de armazenamento das informações decisivas. Apenas os dados com valor para a gestão corporativa estarão reunidos no DW. • Data Mart: o Data Mart é uma estrutura similar ao do DW, porém com uma proporção menor de informações. Trata-se de um subconjunto de informações do DW que podem ser identificados por assuntos ou departamentos específicos. O conjunto de Data Marts em conformidade dentro da organização compõe o DW.

2.2.4 – Verificação e Validação de Requisitos É importante realçar a diferença entre verificação e validação. O objetivo da verificação é assegurar que o software esteja sendo construído de forma correta. Deve-se verificar se os artefatos produzidos atendem aos requisitos estabelecidos e se os padrões organizacionais (de produto e processo) foram consistentemente aplicados. Por outro lado, o objetivo da validação é assegurar que o software que está sendo desenvolvido é o software correto, ou seja, assegurar que os requisitos, e o software deles derivado, atendem ao uso proposto (ROCHA; MALDONADO; WEBER, 2001).

Um requisito deve ser: • Completo: o requisito deve descrever completamente a funcionalidade a ser entregue (no caso de requisito funcional), a regra de negócio a ser tratada (no caso de regras de negócio) ou a restrição a ser considerada (no caso de requisito não funcional). Ele deve conter as informações necessárias para que o desenvolvedor possa projetar, implementar e testar essa funcionalidade, regra ou restrição.

• Correto: cada requisito deve descrever exatamente a funcionalidade, regra ou restrição a ser construída.

• Consistente: o requisito não deve ser ambíguo ou conflitar com outro requisito.

• Realista: deve ser possível implementar o requisito com a capacidade e com as limitações do sistema e do ambiente de desenvolvimento.

• Necessário: o requisito deve descrever algo que o cliente realmente precisa ou que é requerido por algum fator externo ou padrão da organização.

• Passível de ser priorizado: os requisitos devem ter ordem de prioridade para facilitar o gerenciamento durante o desenvolvimento do sistema.

• Verificável e passível de confirmação: deve ser possível desenvolver testes para verificar se o requisito foi realmente implementado.

• Rastreável: deve ser possível identificar quais requisitos foram tratados em um determinado artefato, bem como identificar que produtos foram originados a partir de um requisito.

Neste contexto é útil (WIEGERS, 2003): Realizar revisões dos documentos de requisitos, procurando por problemas (conflitos, omissões, inconsistências, desvios dos padrões etc) e discutindo soluções.

• Definir casos de teste para os requisitos especificados.

• Definir critérios de aceitação de requisitos, i.e., os usuários devem descrever como vão determinar se o produto atende às suas necessidades e se é adequado para uso.

Metodologias e documentos usados em teste de software; conceitos básicos de gerenciamento de projeto (processos do PMBOK versão 4); metodologias, técnicas e processos de desenvolvimento de sistemas orientados a objetos; metodologias, técnicas e processos de desenvolvimento de sistemas web e web services; 1) Projeto Para o PMBOK, projeto é um esforço temporário para criar um serviço ou produto ou resultado exclusivo. Para tal necessita de objetivos claros, parâmetros de medição (o que não se pode medir, não se pode melhorar), datas de início e término que atendam os requisitos das partes interessadas (stakeholders).

De acordo com a norma ISO 10006 (Diretrizes para Qualidade de Gerenciamento de Projetos), projeto é um processo único, consistindo de um grupo de atividades coordenadas e controladas com data para início e término, que é a chave para se determinar se realmente estamos em um projeto. Se você estiver empenhando forças para realizar ou desenvolver um produto ou serviço e não possui data de início e fim, é provável que você não esteja em um projeto, sendo assim seu gerenciamento pelo PMBOK fica comprometido.

Figura 1 - Caracerísticas de um projeto.

Então podemos ter um outro conceito de projeto, em que o mesmo possui uma abrangência maior que imaginamos veja alguns exemplos de projetos abaixo.

• Construção de uma garagem • Pesquisa de um novo produto • Implantação de uma nova tecnologia • Realização de uma viagem • Publicação de um livro • Desenvolvimento de um software 2) Diferenciação entre Projetos e Processos Muitos processos nas organizações têm um pouco de procedimentos contínuos e repetitivos, e um pouco de projeto. Por isto muitos confundem os processos com projetos, processos na maioria das vezes são realizados muitas vezes, de acordo com a necessidade ou fluxo que lhe foi definido, porém é comum criarmos um projeto para realizar um processo de maneira mais eficaz, abrangente e seguro.

Entretanto como lembrado acima processo não tem início e fim em de criação e fechamento, apenas início de suas tarefas e finalização, para reiniciar novamente quando preciso. Isto se parece com alguns projetos que encontramos hoje no mercado, que com certeza irão

ultrapassar tempo e orçamento, pois são projetos sendo tratados como processos.

Por exemplo, efetuar a manutenção de um equipamento, a compra de um determinado software. Veja os exemplos de procedimentos abaixo que se parece com projetos.

• Fabricação de um carro • Pagamento de fornecedores • Compra de materiais • Venda de produtos 3) Portfólio s Portfólio é uma carteira de projetos, na verdade é o conjunto de todos os projetos de um setor ou da empresa toda. Cada projeto pode ou não fazer parte de um programa.

4) Programa Programa é um grupo de projetos gerenciados de forma coordenada, com o objetivo de obter benefícios muito difíceis de serem alcançados se gerenciados isoladamente. Um programa de qualidade total é um exemplo, a natureza ou produto final dos projetos podem ser bastante distintos.

5) Stakeholders Stakeholders refere-se ás partes interessadas do projeto, que podem ser pessoas, grupos ou mesmo outras empresas, cujos interesses podem ser afetados diretamente de forma positiva ou negativa com a execução e conclusão do projeto O guia Project Management Body of Knowledge (PMBOK) é um conjunto de práticas na gestão de projetos organizado pelo instituto PMI e é considerado a base do conhecimento sobre gestão de projetos por profissionais da área.

PMBOK (Project Management Body Knowledgment) é um guia, ou como muitos lugares definem, um conjunto de boas práticas, criado pelo PMI – Project Management Institute para auxiliar a todos que estejam envolvidos com gerenciamento de projetos. Foi publicado na forma de livro e hoje encontra-se em sua 4ª edição, sendo a principal bibliografia para todos que desejam obter certificação em Gestão de Projetos.

O conteúdo do guia é formado por um conjunto de conhecimentos, escritos em linguagem universal (sem termos técnicos), para que possa ser útil a profissionais de todas as áreas e facilite assim a troca de experiências sobre o assunto.

Na sua 4ª edição, o PMBOK é constituído por 42 processos, 5 grupos de processos e 9 áreas de conhecimento.

O fato do PMBOK ser um guia composto por boas práticas, significa que não precisamos aplicá-las todas e sim verificar quais se encaixam no nosso projeto.

Os 5 grupos de processo são: • Iniciação (em alguns lugares conta como Concepção) • Planejamento • Execução • Monitoramento e Controle • Encerramento Estes grupos são baseados no conceito, PDCA (Plan – Do – Check – Adjust). Que siginifica planejar, fazer, verificar e corrigir na ordem Planejar = plan, Execução = Do, Monitoramento e Controle = Check, e Iniciação e Encerramento partem do princípio que um projeto é finito, ou seja, tem início e fim.

As áreas de conhecimento são: • Integração • Escopo • Tempo (também descrito como prazo) • Custo • Qualidade • Recursos Humanos • Comunicações

• •

Riscos Aquisições

Basicamento o projeto é direcionado a partir de 4 áreas de conhecimento: escopo, tempo, custo e qualidade. Ou seja, entregar algo com a qualidade esperada, no tempo e custo acordado.

As áreas de Recursos Humanos e Aquisições fornecem recursos para a realização do projeto. Cuidam de toda a equipe e da área de contratações, incluindo fornecedores.

Riscos e Comunicações são abordadas durante todo o projeto mantendo a propagação da informação e todas as incertezas de sucesso ou fracasso sob controle.

Metodologias Orientadas a Objetos O desenvolvimento de sistemas orientado a objetos envolve a utilização de metodologias bem definidas e sedimentadas. A metodologia consiste na construção de um modelo de um domínio de aplicação e na posterior adição a este dos detalhes de implementação durante o projeto de um sistema. Existem atualmente várias Metodologias Orientadas a Objetos, mas apenas algumas serão descritas a seguir, não de forma exaustiva, mas sim apresentando uma breve descrição dos conceitos, processos, técnicas e ferramentas de suporte utilizadas em cada uma delas, de forma a ser possível encontrar semelhanças e diferenças.

4.1. Metodologia de Booch Booch (1996) definiu a notação de que um sistema é analisado a partir de um número de visões, onde cada visão é descrita por um número de modelos e diagramas.

4.2. Metodologia de Rumbaugh Este método denominado - OMT (Object Modelling Technique) – é um método desenvolvido pela GE, onde Rumbaugh trabalhava.

Segundo Rumbaugh et al (1994) é voltado para o teste de modelos, baseado nas especificações da análise e requisitos do sistema. Tem um caráter amplo em termos de domínio de alcance, não incluindo a modelagem estratégica. Este método encontra-se dividido em quatro fases:  Análise;  Desenho do sistema;  Desenho dos objetos;  Implementação.

4.3. Metodologia de Jacobson A metodologia de Jacobson et al (1992) – Object Oriented Software Engineering (OOSE) – é baseada na utilização de “use cases”, que definem os requisitos iniciais do sistema, vistos por um ator externo.

Este método é adequado para o desenvolvimento de software numa escala industrial.

4.4. Metodologia UML A UML (Unified Modeling Language) é uma tentativa de padronizar a modelagem orientada a objetos de uma forma que qualquer sistema, seja qual for o tipo, possa ser modelado corretamente, com consistência, fácil de se comunicar com outras aplicações, simples de ser atualizado e compreensível.

METODOLOGIA PARA O DESENVOLVIMENTO DE SISTEMAS WEB ADAPTATIVOS UTILIZANDO MINERAÇÃO DO USO DA WEB Ao desenvolver um web site, o desenvolvedor meticulosamente cria a aparência do site, a estrutura das informação e determina os tipos de interações que devem estar disponíveis. Diante disso, Acreditamos que deveria ser feita uma distinção severa entre as mudanças estratégicas (longo prazo) e as técnicas de adaptação (curto prazo) ao implementar um web site adaptativo, uma vez que devemos evitar danos à estrutura do site. Este cenário e pesquisas de outros trabalhos nesta área nos levou a formular as seguintes considerações para o desenvolvimento de um web site adaptativo: • Evitar que os usuários preencham questionários sobre interesses: Usuários da internet não interessam por trabalho extra (por exemplo, preenchimento de questionários), especialmente se não tem uma recompensa clara, e podem optar por sair e não participar.

• Fazer com que o site seja mais fácil de se usar para todos usuários, incluindo usuários que estão o acessando pela primeira vez, usuários casuais, etc. . Proteger o design original do site de mudanças destrutivas: Limitar as transformações de modo que as mesmas não modifiquem a estrutura do site. Podemos acrescentar links, mas não removê-los, criar páginas, mas não destruí-las, adicionar novas estruturas, mas não embaralhar as já existentes.

• Manter o desenvolvedor no controle. O desenvolvedor precisa de se manter no controle do site, tanto para obter confiança nas técnicas de adaptação automática e evitar possíveis mudanças indesejáveis.

MÉTODOS DE TESTE Existem várias metodologias e classificações para testes, segundo a metodologia do modelo RUP, podemos dividir os métodos de teste em: Método da Caixa Branca (Estrutural) – tem por objetivo determinar defeitos na estrutura interna ou no código do software.

Os Testes de Unidade, geralmente realizados pelos programadores nos seus códigos, são normalmente classificados Testes da Caixa Branca.

Método da Caixa Preta (Funcional) – tem por objetivo determinar se os requisitos foram total ou parcialmente satisfeitos pelo software. Verifica apenas os resultados produzidos e não requer conhecimento interno do sistema, apenas conhecimento dos requisitos do negócio. Os testes do tipo funcional, usabilidade, configuração, instalação, estresse, desempenho, entre outros, são exemplos do método de Caixa Preta.

A figura abaixo apresenta uma visão geral da classificação dos testes:

3. executem todos os laços em suas fronteiras e dentro de seus limites operacionais;

4. e exercitem as estruturas de dados internas para garantir a sua validade.

TESTE DE CAMINHO BÁSICO É uma técnica de caixa branca que possibilita que o projetista do caso de teste derive uma medida da complexidade lógica de um projeto procedimental e use essa medida como guia para definir um conjunto básico de caminhos de execução.

TÉCNICAS DE TESTE DE SOFTWARE A atividade de teste de software é um elemento crítico da garantia de qualidade de software e representa a última revisão de especificação, projeto e codificação. Não é incomum que uma organização de software gaste 40% do esforço de projeto total em teste.Alguns casos dos quais dependam vidas humanas (por exemplo, controle de vôo), pode custar de 3 a 5 vezes mais que todos os outros passos de engenharia de software juntos.

FUNDAMENTOS DE TESTE DE SOFTWARE A fase de teste gera bastante conflito entre os engenheiros de software.

A atividade de teste tem a intenção de "demolir" o software que ele construiu.

Os desenvolvedores de software são, por sua própria natureza construtivos, e para atividade de teste eles devem descartar noções de "corretitude" do software que eles acabaram de desenvolver, e devem superar conflitos de interesse que ocorrem quando erros são descobertos.

OBJETIVOS DA ATIVIDADE DE TESTE 1. A atividade de teste é o processo de executar um programa com a intenção de descobrir um erro.

2. Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto.

3. Um teste bem-sucedido é aquele que revela um erro ainda não descoberto.

Se a atividade de teste for conduzida com sucesso ela descobrirá erros no software.

Mas é importante saber que " A atividade de teste não pode mostrar a ausencia de bugs ; ela só pode mostrar se defeitos de software estão presentes". É importante ter essa declaração em mente quando a atividade de teste estiver sendo realizada.

PROJETO DE CASOS DE TESTE Os projetos de casos de teste são construídos , para ajudar a garantir a integridade dos testes e proporcionar a mais alta probabilidade de revelar erros no software.

Qualquer produto de engenharia pode ser tratado de duas maneiras: 1. Conhecendo-se a função específica que um produto projetado deve executar, testes podem ser realizados para demonstrar que cada função é totalmente operacional; 2. Conhecendo-se o funcionamento interno de um produto, testes podem ser realizados para garantir que "todas as engrenagem se encaixam", ou seja, que a operação interna do produto tem um desempenho de acordo com as especificações e que os componentes internos foram adequadamente postos à prova.

Esses testes são chamados de teste da caixa preta e teste da caixa branca.

TESTE DE CAIXA BRANCA O teste da caixa branca usa a estrutura de controle do projeto procedimental para derivar casos de teste. O engenheiro de software pode derivar os casos de teste que: 1. garantam que todos os caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez; 2. exercitem todas as decisões lógicas para valores falsos ou verdadeiros;

TESTE DE ESTRUTURA DE CONTROLE Se divide em vários testes , dentre os quais merecem destaque: 1. Teste de condição É um método que põe a prova as condições lógicas contidas num módulo de programa. Ele concentra-se em testar cada condição do programa.

O propósito do teste de condição é detectar não somente erros nas condições de um programa, mas também outros erros no programa.

O teste de ramos e teste de domínio são exemplos de estratégias de teste de condição.

2. Teste de fluxo de dados O método de teste de fluxo de dados seleciona caminhos de teste de um programa de acordo com as localizações das definições e usos de variáveis no programa.

As estratégias de fluxo de dados são úteis para selecionar caminhos de teste de um programa que contenha instruções de laços e if aninhadas.

3. Teste de laços (LOOPS) Os laços são o fundamento para grande maioria de todos os algoritmos implementados no software. O teste de laços se concentra exclusivamente na validade das construções de laços.

Quatro diferentes classes de laços podem ser definidas: o Laços Simples o Laços Aninhados o Laços Concatenados o Laços Não-estruturados TESTE DE CAIXA PRETA Os métodos de caixa preta concentram-se nos requisitos funcionais do software. O engenheiro de software pode derivar conjunto de condições de entrada que exercitem completamente todos os requisitos funcionais para um programa.

O teste de caixa preta procura descobrir erros nas seguintes categorias: 1. funções incorretas ou ausentes; 2. erros de interfeace; 3. erros nas estruturas de dados ou no acesso a banco de dados externos; 4. erros de desempenho; 5. e erros de inicialização e término.

O teste de caixa preta tende a ser aplicado durante as últimas etapas da atividade de teste. Ele se concentra no domínio de informação. Testes são projetados para responder às seguintes perguntas: • Como a validade funcional é testada ?

• Quais classes de entrada constituirão bons casos de teste ?

• O sistema é particularmente sensível a certos valores de entrada ?

• Como as fronteiras de uma classe de dados são isoladas ?

• Quais índices de dados e volumes de dados o sistema pode tolerar ?

• Que efeito terão combinações específicas de dados sobre a operação do sistema ?

Alguns métodos de Caixa preta serão abordados agora : 1. Particionamento de equivalência Divide o domínio de entrada de um programa em classe de dados a partir das quais os casos de teste podem ser

derivados. O particionamento de equivalência procura definir um caso de teste que descubra classes de erros, assim reduzindo o número total de casos de teste que devem ser resolvidos.

O projeto de casos de teste para o particionamento de equivalência baseia-se numa avaliação de classes de equivalência para uma condição de entrada. Uma classe de equivalência representa um conjunto de estados válidos ou inválidos para condições de entrada. As classes de equivalência podem ser definidas de acordo com as seguintes diretrizes: 1. Se uma condição de entrada especificar um intervalo, uma classe de equivalência válida e duas classes de equivalência inválidas são definidas.

2. Se uma condição de entrada exigir um valor específico, uma classe de equivalência válida e duas classes de equivalência inválidas são definidas.

3. Se uma condição de entrada especificar um membro de um conjunto, uma classe de equivalência válida e uma classe de equivalência inválida são definidas.

4. Se uma condição de entrada for booleana, uma classe válida e uma inválida sào definidas.

Aplicando-se as diretrizes para derivação de classes de equivalências, os casos de testes para cada item de dados do domínio de entrada poderiam ser desenvolvidos e executados. Os casos de teste são selecionados de forma que o maior número de atributos de uma classe de equivalência seja exercitado de uma só vez.

2. Análise de valor limite Um número maior de erros tende a ocorrer nas fronteiras do domínio de entrada do que no "centro". Por isso é que a análise do valor limite foi desenvolvida como uma técnica de teste. Os testes põem a prova os valores fronteiriços. Essa técnica complementa o particionamento de equivalência, e sob muitos aspectos as diretrizes se assemelham àquelas apresentadas para o particionamento de equivalência: 1. Se uma condição de entrada especificar um intervalo, delimitado pelos valores a e b, os casos de teste devem ser projetados com valores a e b logo acima e logo abaixo de a e b, respectivamente.

2. Se uma condição de entrada especificar uma série de valores os casos de teste que ponham à prova números máximos e mínimos devem ser desenvolvidos. Valores logo acima e logo abaixo do mínimo e do máximo também são testados.

3. Aplique as diretrizes 1 e 2 às condições de saída.

Por exemplo, suponhamos que uma tabela de temperatura versus pressão seja exigida como saída de um programa de análise de engenharia. Os casos de teste devem ser projetados para criar um relatório de saída que produza um número máximo (e mínimo) permissível de entradas na tabela.

4. Se estruturas internas de dados do programa tiverem prescrito fronteiras , certifique-se de projetar um caso de teste para exercitar a estrutura de dados em sua fronteira.

3. Técnicas de grafo de causa-efeito O grafo de causa-efeito, é uma técnica de projetos de caso de teste que oferece uma uma representação concisa das condições lógicas e das ações correspondentes. A técnica segue quatro passos: 1. Causas (condições de entrada) e efeitos (ações) são relacionados para um módulo e um identificador é atribuído para cada um.

2. Um grafo de causa efeito é desenvolvido.

3. O grafo é convertido numa tabela de decisão.

4. As regras da tabela de decisão são convertidas em casos de teste.

4. Testes de comparação Usa-se quando a confiabilidade do software é absolutamente crítica. alguns pesquisadores tem sugerido que versões independentes de software sejam desenvolvidas para aplicações críticas , mesmo quando uma única versão for usada no sistema copmputadorizado entregue.Essas versões independentes formam a base de uma técnica de teste de caixa preta denominada teste de comparação ou teste backto-back.

O método de comparação não é infalível. Se a especificação a partir da qual todas as versões foram desenvolvidas estiver errada, provavelmente todas as versões refletirão o erro.

Além disso, se cada uma das versões independentes produzir resultados idênticos, mas incorretos, os testes de condições deixarão de detectar o erro.

5. Testes de sistemas de tempo real Métodos de projetos de caso de teste abrangente para sistemas de tempo real ainda precisam ser desenvolvidos.

Porém uma estratégia global de qutro passos pode ser proposta: 6. Teste de tarefas.

O primeiro passo da atividade de testes de softwares de tempo real consiste em testar cada tarefa independentemente.

Ou seja, testes de caixa preta e de caixa branca são projetados e executados para cada tarefa. Cada tarefa é executada independentemente durante esses testes. O teste de tarefas revela erros de lógica e de função, mas não revelará erros comportamentais ou de timing.

7. Teste comportamental.

Usando modelos de sistemas criados com as ferramentas CASE, é possível simular o comportamento de um sistema de tempo real e examinar seu comportamento como uma consequência de eventos externos. Essas atividades de análise podem servir como a base para o projeto de casos de teste que será realizado quando o software de de tempo real for construído.

8. Teste intertarefas.

Assim que os erros em tarefas individuais e no comportamento de sistema tiverem sido isolados , a atividade de teste desvia-se para erros relacionados ao tempo. As tarefas assíncronas, que sabidamente comunicam-se entre sí , são testadas com diferentes taxas de dados e cargas de processamento para determinar se ocorrerão erros de sincronização intertarefas. além disso, as tarefas que se comunicam por intermédio de uma fila de mensagens são testadas para descobrir erros na determinação do tamanho dessas áreas de armazenagem de dados.

9. Teste do sistema.

O software e o hardware são integrados e uma variedade completa de de testes de sistema é levada a efeito, numa tentativa de descobrir erros na interface software/hardware.

FERRAMENTAS DE TESTE AUTOMATIZADAS Uma vez que o teste de software frequentemente é responsável por até 40% de todo o esforço despendido num projeto de desenvolvimento de software, as ferramentas que podem reduzir o tempo de teste são muito valiosas.Muitas ferramentas de teste foram desenvolvidas e elas podem ser divididas em uma série de categorias: • Analisadores estáticos. Esses sistemas de análise de programa suportam a "comprovação" de afirmações estáticas - afirmações fracas sobre a estrutura e o formato de um programa.

• Auditores de código. Esses filtros de propósito especial são usados para verificar a qualidade do software, a fim de garantir que ele atenda aos padrões mínimos de codificação.

• Processadores de asserção. Esses sistemas préprocessadores/pós-processadores são empregados para dizer se as afirmações fornecidas pelo programador, denominadas asserções, sobre o comportamento de um

programa são de fato cumpridas durante as execuções reais do programa.

• Geradores de arquivos de teste. Esses processadores geram, e preenchem com valores previamente determinados, arquivos de entrada típicos para programas que estão em teste.

• Geradores de dados de teste. Esses sistemas de análise automatizados auxiliam o usuário a selecionar dados de teste que fazem um programa comportar-se de uma forma particular.

• Verificadores de teste. Essas ferramentas medem a cobertura interna dos testes, frequentemente expressa em termos que estão relacionados à estrutua de controle do objeto de teste, e relatam o valor da cobertura ao especialista em garantia da qualidade.

• Bancadas de teste (Teste Harnesses). Essa classe de ferramentas apóia o processamento de testes , tornando-se quase indolor para : 1. instalar um programa candidato num ambiente de teste; 2. alimentá-lo com dados de entrada; 3. Com uso de stubs o comportamento de módulos subsidiários (subordinados).

• Comparadores de saída. Esta ferramenta torna possível a comparação de um conjunto de saídas de um programa com outro conjunto (previamente arquivado) para determinar a diferença entre eles.

• Sistemas de execução simbólica. Essa ferramenta realiza testes de programas usando entrada algébrica, em vez de valores de dados numéricos. O software que é testado, parece desse modo testar classes de dados, em vez de ser um teste de caso específico. A saída é algébrica e pode ser comparada com os resultados esperados que são especificados algebricamente.

• Simuladores de ambiente. Essa ferramenta é um sistema computadorizado especializado que possibilita que o analista modele o ambiente externo do software de tempo real e depois simule dinamicamente as condições operacionais reais.

• Analisadores de fluxo de dados. Essa ferramenta rastreia o fluxo de dados mediante um sistema e tenta descobrir referências a dados, indexação incorreta e outros erros relacionados a dados.

O uso atual não definido de ferramentas automatizadas para teste vem crescendo, e é provavel que a aplicação se acelere durante a próxima década. Provavelmente, as descendentes das ferramentas de teste da primeira geração provocarão mudanças radicais na maneira como testamos softwares e , então, melhorarão a confiabilidade dos sistemas baseados em computador.

RESUMO O objetivo principal do projeto de casos de teste é derivar um conjunto de teste que tenham alta probabilidade de revelar defeitos no software.

Para atingir esse objetivo, duas categorias diferentes de técnicas de projeto de caso de teste são usadas: O teste de caixa preta e o teste de caixa branca.

Os teste de caixa branca focalizam a estrutura de controle do programa. Os casos de teste são derivados para garantir que todas as instruções do programa tenham sido exercitadas pelo menos uma vez durante os testes e que todas as condições lógicas tenham sido exercitadas. Os testes de caminho básico , uma técnica de caixa branca, faz uso de grafos de programa para derivar o conjunto de testes linearmente independentes que garantirá cobertura. Os testes de fluxo de dados e das condições põem à prova lógica do programa, e os testes de laços complementam outras técnicas de caixa branca ao proporcionar um procedimento para exercitar laços de vários graus de complexidade.

Os teste de caixa branca são "testes em pequeno porte" (testing in the small). A implicação dessa colocação é que os teste de caixa branca são tipicamente aplicados a componentes de programas pequenos (Os módulos). Os testes de caixa preta, por outro lado, ampliam o nosso

foco e poderiam ser denominados "testes em grande porte" (testing in the large ).

Os testes de caixa preta são projetados para validar os requisitos funcionais, sem se preocupar com o funcionamento interno de um programa. As técnicas de teste de caixa preta concentram-se no domínio de informações do software, derivando os casos de teste ao dividir a entrada e a saída de uma maneira que proporcione uma satisfatória cobertura de teste. O particionamento de equivalência divide o domínio de entrada em classes de dados que provavelmente exercitarão uma função de software específica. A análise do valor de fronteira prova a capacidade que um programa tem de manipular dados nos limites da aceitabilidade. o grafo de causa-efeito é uma técnica que possibilita que o analista valide conjuntos complexos de ações e condições.

Os projetistas de softwares experientes frequentemente dizem: " a atividade de teste nunca termina; ela é apenas transferida do projetista para o seu cliente. toda vez que o seu cliente usa o programa, um teste é realizado". Ao aplicar o projeto de casos de teste, o engenheiro de software pode realizar testes mais completos e, portanto, descobrir e corrigir o maior número de erros possíveis antes que os "testes do cliente" se iniciem.

3. Gerenciamento de Risco O modelo de gerenciamento de risco em projetos de inovação, proposto por KERZNER(1994), é composto de quatro etapas: 1) Avaliação – tem o objetivo de identificar e classificar as áreas potenciais de risco (técnica, logística, financeira, impacto ambiental, etc.).

2) Análise – etapa em que se determina a probabilidade de ocorrência do risco e as consequências à ele associadas (análise de redes, delphi, etc.). Aqui se procura detectar as causas, efeitos e magnitudes dos riscos potenciais identificados e opções alternativas.

3) Tratamento – refere-se a procedimentos para reduzir a controlar o risco (assumir, transferir, …).

4) Aprendizado – a experiência é um excelente mestre na identificação e redução de riscos e o aprendizado deve incluir procedimentos para documentação do gerenciamento, calibrando as diversas técnicas e a percepção do gerente do projeto para futuros empreendimentos. O acompanhamento e eventuais ajustes durante a implementação é outro ponto importante a ser considerado.

O modelo é bastante racional e permite que, em cada etapa, se utilize desde técnicas simples até sofisticados métodos estatísticos e computacionais.

Para VERZUH (2001) “ toda gestão de projeto é um gerenciamento de risco”, e ele alega ainda que “ o gerenciamento dos riscos é o trabalho principal de uma gestão de projetos”, baseado na visão em que as técnicas de gestão são também técnicas de prevenção de riscos.

Na prática, os gerentes devem começar a identificar os riscos associados aos projetos desde a sua fase inicial.

Segundo KADE (2003), o processo de gerenciamento de riscos inclui: ¨ Identificação de riscos – identificar riscos de projeto, de produto e de negócios; ¨ Análise de riscos – avaliar as possibilidades e as consequências desses riscos; ¨ Planejamento de riscos – traçar planos para evitar ou minimizar os efeitos dos riscos; ¨ Monitoração de riscos – monitorar os riscos durante todo o projeto.

Alguns procedimentos básicos são, por vezes, esquecidos pelos gerentes, tal como, a falta de rotina bem definida para o controle das mudanças; é comum alguns gerentes adotarem uma posição utópica em relação às mudanças, preferindo acreditar que o projeto “ perfeito” é aquele que nunca muda. Na visão moderna, um dos papéis do gerente em relação às mudanças é agir proativamente sobre as mesmas, garantindo que estas sejam benéficas ao projeto.

O gerenciamento de riscos tem o objetivo de tentar identificar todos os riscos possíveis, maximizar os resultados dos eventos positivos, minimizar seus impactos e conseqüências, gerenciar as

responsabilidades de materialização dos eventos, e prover planos contingenciais para suprir os riscos que eventualmente se materializem.

Segundo SCHNEIDER (2002) há dois tipos de estratégias de gerenciamento de riscos: a reativa e a proativa.

Na estratégia reativa, as ações a serem tomadas são definidas quando ocorre uma fatalidade.

Ou seja, a equipe do projeto não faz nada com relação aos riscos até que aconteça algo errado.

Assim surgem os chamados “ apagadores de incêndio” . Essa estratégia tem grande chance de falhar e pode prejudicar totalmente o projeto.

Na estratégia proativa, existe uma análise de riscos antes do trabalho técnico começar. Os riscos em potencial são identificados, suas probabilidades e impactos são calculados e são classificados por ordem de importância.

Conhecimentos Básicos de ambientes operacionais/ambientes tecnológicos; engenharia de software; linguagens de programação orientadas a objeto; metodologias e técnicas para arquitetura e projeto de software com orientação a objetos; métricas de qualidade de software; técnicas de análise e modelagem de dados; Engenharia de software é uma área da computação voltada à especificação, desenvolvimento e manutenção de sistemas desoftware, com aplicação de tecnologias e práticas de gerência de projetos e outras disciplinas, visando organização, produtividade e qualidade.

Atualmente, essas tecnologias e práticas englobam linguagens de programação, banco de dados, ferramentas, plataformas ,bibliotecas, padrões, processos e a questão da Qualidade de software.

Programação Orientada a Objetos (POO) diz respeito a um padrão de desenvolvimento que é seguido por muitas linguagens, como C# e Java. A seguir, iremos entender as diferenças entre a POO e a Programação Estruturada, que era muito utilizada há alguns anos, principalmente com a linguagem C. Esse padrão se baseia em quatro pilares que veremos ao longo desse artigo. Além disso, a POO diversas vantagens em sua utilização, que também serão vistas e explicadas.

Programação Estruturada vs Programação Orientada a Objetos Na Figura 1 vemos uma comparação muito clara entre a programação estruturada e a programação orientada a objetos no que diz respeito aos dados. Repare que, no paradigma estruturado, temos procedimentos (ou funções) que são aplicados globalmente em nossa aplicação. No caso da orientação a objetos, temos métodos que são aplicados aos dados de cada objeto. Essencialmente, os procedimentos e métodos são iguais, sendo diferenciados apenas pelo seu escopo.

Figura 1. Estruturada x Orientação a Objetos A linguagem C é a principal representante da programação estruturada. Se trata de uma linguagem considerada de baixo nível, que atualmente não é utilizada para projetos muito grandes. A sua principal utilização, devido ao baixo nível, é em programação para sistemas embarcados ou outros em que o conhecimento do hardware se faz necessário para um bom programa.

Essa colocação nos traz a um detalhe importante: a programação estruturada, quando bem feita, possui um desempenho superior ao que vemos na programação orientada a objetos. Isso ocorre pelo fato de ser um paradigma sequencial, em que cada linha de código é executada após a outra, sem muitos desvios, como vemos na POO. Além disso, o paradigma estruturado costuma permitir mais liberdades com o hardware, o que acaba auxiliando na questão desempenho.

Entretanto, a programação orientada a objetos traz outros pontos que acabam sendo mais interessantes no contexto de aplicações modernas.

Como o desempenho das aplicações não é uma das grandes preocupações na maioria das aplicações (devido ao poder de processamento dos computadores atuais), a programação orientada a objetos se tornou muito difundida. Essa difusão se dá muito pela

questão da reutilização de código e pela capacidade de representação do sistema muito mais perto do que veríamos no mundo real.

Veremos em detalhes esses e outros pontos que dizem respeito a programação orientada a objetos. Como desenvolvedores, é nossa missão entender quais são as vantagens e desvantagens de cada um dos paradigmas de programação e escolhermos o melhor para nossa aplicação. A escolha da linguagem também deve estar presente nessa escolha.

Os 4 pilares da Programação Orientada a Objetos Para entendermos exatamente do que se trata a orientação a objetos, vamos entender quais são os requerimentos de uma linguagem para ser considerada nesse paradigma. Para isso, a linguagem precisa atender a quatro tópicos bastante importantes: Abstração A abstração consiste em um dos pontos mais importantes dentro de qualquer linguagem Orientada a Objetos. Como estamos lidando com uma representação de um objeto real (o que dá nome ao paradigma), temos que imaginar o que esse objeto irá realizar dentro de nosso sistema. São três pontos que devem ser levados em consideração nessa abstração.

O primeiro ponto é darmos uma identidade ao objeto que iremos criar.

Essa identidade deve ser única dentro do sistema para que não haja conflito. Na maior parte das linguagens, há o conceito de pacotes (ou namespaces). Nessas linguagens, a identidade do objeto não pode ser repetida dentro do pacote, e não necessariamente no sistema inteiro.

Nesses casos, a identidade real de cada objeto se dá por ..

A segunda parte diz respeito a características do objeto. Como sabemos, no mundo real qualquer objeto possui elementos que o definem. Dentro da programação orientada a objetos, essas características são nomeadas propriedades. Por exemplo, as propriedades de um objeto “Cachorro” poderiam ser “Tamanho”, “Raça” e “Idade”.

Por fim, a terceira parte é definirmos as ações que o objeto irá executar. Essas ações, ou eventos, são chamados métodos. Esses métodos podem ser extremamente variáveis, desde “Acender()” em um objeto lâmpada até “Latir()” em um objeto cachorro.

Encapsulamento O encapsulamento é uma das principais técnicas que define a programação orientada a objetos. Se trata de um dos elementos que adicionam segurança à aplicação em uma programação orientada a objetos pelo fato de esconder as propriedades, criando uma espécie de caixa preta.

A maior parte das linguagens orientadas a objetos implementam o encapsulamento baseado em propriedades privadas, ligadas a métodos especiais chamados getters e setters, que irão retornar e setar o valor da propriedade, respectivamente. Essa atitude evita o acesso direto a propriedade do objeto, adicionando uma outra camada de segurança à aplicação.

Para fazermos um paralelo com o que vemos no mundo real, temos o encapsulamento em outros elementos. Por exemplo, quando clicamos no botão ligar da televisão, não sabemos o que está acontecendo internamente. Podemos então dizer que os métodos que ligam a televisão estão encapsulados.

Herança O reuso de código é uma das grandes vantagens da programação orientada a objetos. Muito disso se dá por uma questão que é conhecida como herança. Essa característica otimiza a produção da aplicação em tempo e linhas de código.

Para entendermos essa característica, vamos imaginar uma família: a criança, por exemplo, está herdando características de seus pais. Os pais, por sua vez, herdam algo dos avós, o que faz com que a criança também o faça, e assim sucessivamente. Na orientação a objetos, a questão é exatamente assim, como mostra a Figura 2. O objeto abaixo na hierarquia irá herdar características de todos os objetos acima dele, seus “ancestrais”. A herança a partir das características do objeto mais

acima é considerada herança direta, enquanto as demais são consideradas heranças indiretas. Por exemplo, na família, a criança herda diretamente do pai e indiretamente do avô e do bisavô.

Figura 2. Herança na orientação a objetos A questão da herança varia bastante de linguagem para linguagem. Em algumas delas, como C++, há a questão da herança múltipla. Isso, essencialmente, significa que o objeto pode herdar características de vários “ancestrais” ao mesmo tempo diretamente. Em outras palavras, cada objeto pode possuir quantos pais for necessário. Devido a problemas, essa prática não foi difundida em linguagens mais modernas, que utilizam outras artimanhas para criar uma espécie de herança múltipla.

Outras linguagens orientadas a objetos, como C#, trazem um objeto base para todos os demais. A classe object fornece características para todos os objetos em C#, sejam criados pelo usuário ou não.

Polimorfismo Outro ponto essencial na programação orientada a objetos é o chamado polimorfismo. Na natureza, vemos animais que são capazes de alterar sua forma conforme a necessidade, e é dessa ideia que vem o polimorfismo na orientação a objetos. Como sabemos, os objetos filhos herdam as características e ações de seus “ancestrais”.

Entretanto, em alguns casos, é necessário que as ações para um mesmo método seja diferente.

Em outras palavras, o polimorfismo consiste na alteração do funcionamento interno de um método herdado de um objeto pai.

Como um exemplo, temos um objeto genérico “Eletrodoméstico”.

Esse objeto possui um método, ou ação, “Ligar()”. Temos dois objetos, “Televisão” e “Geladeira”, que não irão ser ligados da mesma forma. Assim, precisamos, para cada uma das classes filhas, reescrever o método “Ligar()”.

Com relação ao polimorfismo, valem algumas observações. Como se trata de um assunto que está intimamente conectado à herança, entender os dois juntamente é uma boa ideia. Outro ponto é o fato de que as linguagens de programação implementam o polimorfismo de maneiras diferentes. O C#, por exemplo, faz uso de método virtuais (com a palavra-chavevirtual) que podem ser reimplementados (com a palavra-chave override) nas classes filhas. Já em Java, apenas o atributo “@Override” é necessário.

Esses quatro pilares são essenciais no entendimento de qualquer linguagem orientada a objetos e da orientação a objetos como um todo. Cada linguagem irá implementar esses pilares de uma forma, mas essencialmente é a mesma coisa. Apenas a questão da herança, como comentado, que pode trazer variações mais bruscas, como a presença de herança múltipla. Além disso, o encapsulamento também é feito de maneiras distintas nas diversas linguagens, embora os getters e setters sejam praticamente onipresentes.

Métricas de Qualidade de Software Métrica é uma medida quantitativa do grau que um sistema, componente ou processo possui de um dado atributo. Por exemplo, nos primeiros dezoito meses de atividade foram encontrados somente dois erros identificados por utilizadores.

As métricas são um bom meio para entender, monitorar, controlar, prever e testar o desenvolvimento de software e os projetos de manutenção.

Em um processo de desenvolvimento de software temos vários processos, como: gestão de requisitos, gestão de riscos, testes, gestão da qualidade.

No processo de Gestão de Requisitos, podemos coletar métricas como: • Requisitos incluídos: indica a proporção de requisitos de um projeto que são adicionados aos requisitos estabelecidos inicialmente.

• Requisitos cancelados: indica a proporção de requisitos de um projeto que são anulados.

• Requisitos aprovados: indica a proporção de requisitos de um projeto que são aprovados pelo cliente antes de finalizar o desenho.

• •

Requisitos alterados: indica a proporção de requisitos de um projeto que se modificam Estabilidade de requisitos: mostra um valor de estabilidade dos requisitos no momento da medição, a partir do cálculo de fatores que influenciam na instabilidade.

No processo de Gestão de Riscos, podemos coletar métricas como o Nível de Riscos, que é uma métrica que indica o nível de risco que assume o projeto. Na gestão de riscos podemos determinar o nível de risco para cada fase do projeto e também para obter uma classificação global do nível de risco do projeto.

No processo de Testes, podemos coletar métricas como: • Volume de erros por etapa: A estabilidade mostra um nível de confiança do software testado que serve como critério para a validação de um módulo, processo ou sistema. Conforme as correções dos erros, a taxa de defeitos por caso de teste vai diminuindo. Uma estabilidade elevada supõe um alto nível de qualidade do software.

• Gestão de Incidências: Mostra o grau de resolução das incidências detectadas por parte da equipe de projeto. Um valor baixo na Gestão de Incidências supõe um nível alto de incidências não resolvidas e, por tanto erros no software.

• No processo de Gestão de Configuração, podemos coletar

métricas como: • Evolução do Software: indica a evolução do software para cada fase do projeto, baseado no volume de modificações que se produzem no software. Esta métrica indica como se evolui o software gerado comparado com as fases do projeto.

• No processo de Gestão da Qualidade, podemos coletar

métricas como: • Estabilidade do Software: indica o número de erros detectados. Determina a qualidade dos sistemas em produção, baseado no número de erros detectados no período.

• Gestão de Não Conformidades: indica o número de não conformidades gerenciadas, não gerenciadas, moderadas, graves e leves.

•

Análises de dados é a atividade de transformar um conjunto de dados com o objetivo de poder verificá-los melhor dando-lhes ao mesmo tempo uma razão de ser e uma análise racional. É analisar os dados de um problema e identificá-los. A análise de dados possui diferentes facetas e abordagens, incorporando técnicas diversas. Tem grande importância em áreas como: ciências, estudos sociais e negócios, por conta da diversidade de modelos possíveis.

• Dados podem ser de tipos diversos, como: • •

Dados quantitativos, dados como números, quantidades Dados categóricos, temos estratos, dados diversas categorias • Dados qualitativos, nesse caso é uma característica.

de

Os três tipos de gráficos principais são: • Gráfico "pizza" ou circular; • Gráfico de colunas; • Gráfico de linha.

Modelagem de Dados – Modelo É a representação abstrata e simplificada de um sistema real, com a qual se pode explicar ou testar o seu comportamento, em seu todo ou em partes.

Ex.: Planta Baixa, manequim, desenho, etc Na área de banco de Dados É a descrição dos tipos de informações que estão armazenadas

em um banco de dados Ex: Um modelo de dados acadêmico informa que há informações sobre alunos (Matricula, CPF, Nome), mas não informa os dados de cada aluno. É a representação das entidades e seus relacionamentos Modelagem de Dados – Conceitos Método de abstração dos elementos do ambiente representando-os em um modelo de dados (Entidades e relacionamentos) É uma representação abstrata dos dados sobre entidades, juntamente com suas associações.

Técnica aplicada para modelar os dados da empresa, visando formar uma base estável para suportar o negócio e as necessidades de informações decorrentes.

Debate em Sala de Aula Digamos que você foi convidado para descrever um conjunto de lojas de departamentos associadas às suas áreas de atuação e fornecedores.

O que poderia resultar como produto deste trabalho?

Poderia resultar um modelo descritivo

Poderia resultar um modelo esquemático

Poderia resultar um modelo de dados

Modelagem de Dados – Processo de Modelagem Execução da Modelagem do Dados • Observação dos objetos o Entrevistas, reuniões, questionários • Entendimento dos Conceitos o Entendimento (características, relacionamentos) • Representação dos objetos o DER (Diagrama de Entidade e Relacionamento) • Verificação de fidelidade e coerência • Validação do modelo • Modela Desenvolvimento Orientada a Objetos Com a constante evolução das empresas, as regras de negocio se tornaram variáveis, a produção de software para se conservar o padrão de qualidade exige a adoção de métodos de desenvolvimento que atendam essa dinâmica do mercado. A orientação a objeto é um dos métodos mais utilizado, oferece recurso para desenvolver software com qualidade e com a utilização de seus conceitos pode-se interagir com o mundo real e transformar suas características para o mundo computacional.

Sommerville (2007, p. 208) afirma que “análise orientada a objetos concentra-se no desenvolvimento de um modelo orientado a objetos do domínio da aplicação. Os objetos nesse modelo refletem as entidades e as operações associadas ao problema a ser resolvido”.

Este modelo descreverá como o software funciona para satisfazer uma série de requisitos definido pelo cliente. (PRESSMAN, 2002, p.560) Abstração A abstração consiste na separação dos objetos de uma totalidade, a segmentação proporciona uma melhor utilização dos recursos da orientação a objetos. Correia (2006, p. 11) afirma que “pelo princípio da abstração, nós isolamos os objetos que queremos representar do ambiente complexo em que se situam, e nesses objetos representamos someta as características que são relevantes para o problema em questão”.

Encapsulamento O encapsulamento é um dos pilares da orientação a objetos sua característica é ocultar partes da implementação desta forma construir softwares que atinjam suas funcionalidades e escondam os detalhes de implementação do mundo exterior. Os objetos encapsulados funcionam como uma caixa preta, sabe-se da sua interface externa, mas não precisa se preocupar com o que acontece dentro dela.

(SINTES, 2002, p. 22 – 23) Correia (2006, p. 13) afirma que “as pessoas que usam os objetos não precisam se preocupar em saber como eles são constituídos internamente acelerando o tempo de desenvolvimento”.

Grande parte das linguagens de programação orientadas a objeto suportam três níveis de acessos.

Público – todos os objetos tem acesso; Protegido – o acesso é apenas para instância, no caso para o objeto e todas as subclasses; Privado – o acesso é apenas para o objeto da instância.

A escolha do acesso para o projeto é de grande importância, todo comportamento que queira torna visível para que o mundo exterior utilizasse o tipo de acesso público e o comportamento que deseja ocultar o acesso deve ser definido como protegido ou privado.

(SINTES, 2002, p. 25) Classe A classe representa um conjunto de objetos, estes apesar de possuírem atributos iguais têm valores diferentes em seus atributos. Segundo Correia (2006, p. 17), “classe é um modelo e todos os seus objetos têm os mesmos atributos (embora esses atributos possam ter valores diferentes) e os mesmos métodos”.

Objetos Para Ambler (1998, p. 5) “Um objeto é qualquer indivíduo, lugar, evento, coisa, tela, relatório ou conceito que seja aplicável ao sistema”. Todo objeto pertence a uma determinada classe e possui atributos próprios. Os atributos são mutáveis e podem receber diferentes valores de acordo com as características do objeto.

A criação de um objeto consiste em sua instanciação, segundo Pfleeger (2004, p. 213), “cada instância tem seus próprios valores de atributos, mas compartilha o nome e os comportamentos dos atributos com a outras instancias da classe”.

Herança A herança é uma das principais características das linguagens de programação orientadas a objetos, permite o reaproveitamento de métodos e atributos diminuindo o tempo de desenvolvimento, ainda reduz as linhas de código desta forma facilita as manutenções futuras.

(GUEDES, 2008, p. 43).

A utilização da herança é mais que uma simples economia de código, significa mais integridade. Quando um comportamento é alterado, todas as classes que descende dela terá acesso aos métodos atualizados sem necessidade de reprogramação.

Existem dois tipos de herança, a simples que herda apenas as características de uma superclasse, e a composta, que herda as características de duas ou mais superclasses. (CORREIA, 2006, p. 35 – 36). A Fig. 1 traz um exemplo de herança.

Fig. 1: Exemplo de Herança

Polimorfismo O polimorfismo está diretamente ligado à hereditariedade das classes, este trabalha com a redeclararão de métodos herdados, ou seja, os métodos têm a mesma assinatura (têm o mesmo nome), mas a forma de implementação utilizada diferem o da superclasse, segundo Sintes (2002, p. 122), “de sua própria maneira, o polimorfismo é o distúrbio das múltiplas personalidades do mundo do software, pois um único nome pode expressar muitos comportamentos diferentes”.

Fig. 2: Exemplo de Polimorfismo A Fig. 2 traz um método escrito em C Sharp herdado de uma superclasse e demonstra o funcionamento de polimorfismo, têm-se uma superclasse “Pessoa” e a subclasse “Profissional”, o método herdado “Listar” da subclasse “Profissional” têm o mesmo nome, mas a implementação do método é diferente da superclasse “Pessoa”.

Programação Orientado a Objetos A orientação a objetos vem sendo utilizado amplamente para o desenvolvimento de software, por ser um paradigma que traz uma facilidade maior ao desenvolvedor na hora de dar manutenção nos softwares desenvolvidos, o que está nesse artigo é o básico existem diversos conceitos que cercam o desenvolvimento orientado a objetos isto com o tempo será passado para todos da comunidade.

Introdução da linguagem Java, Classes, Objetos(Herança, Encapsulamento e Polimorfismo)

Interfaces,

Objetos Objetos são instâncias de classes. É através deles que (praticamente) todo o processamento ocorre em sistemas implementados com linguagens de programação orientadas a objetos. O uso racional de objetos, obedecendo aos princípios associados à sua definição conforme estabelecido no paradigma de desenvolvimento orientado a objetos, é chave para o desenvolvimento de sistemas complexos e eficientes.

Um objeto é um elemento que representa, no domínio da solução, alguma entidade (abstrata ou concreta) do domínio de interesse do problema sob análise. Objetos similares são agrupados em classes.

No paradigma de orientação a objetos, tudo pode ser potencialmente representado como um objeto. Sob o ponto de vista da programação orientada a objetos, um objeto não é muito diferente de uma variável normal.

Um programa orientado a objetos é composto por um conjunto de objetos que interagem através de “trocas de mensagens”. Na prática, essa troca de mensagem traduz-se na aplicação de métodos a objetos.

As técnicas de programação orientada a objetos recomendam que a estrutura de um objeto e a implementação de seus métodos devem ser tão privativos como possível. Normalmente, os atributos de um objeto não devem ser visíveis externamente. Da mesma forma, de um método deve ser suficiente conhecer apenas sua especificação, sem necessidade de saber detalhes de como a funcionalidade que ele executa é implementada.

Encapsulação é o princípio de projeto pelo qual cada componente de um programa deve agregar toda a informação relevante para sua manipulação como uma unidade (uma cápsula). Aliado ao conceito de ocultamento de informação, é um poderoso mecanismo da programação orientada a objetos.

Ocultamento da informação é o princípio pelo qual cada componente deve manter oculta sob sua guarda uma decisão de projeto única. Para a utilização desse componente, apenas o mínimo necessário para sua operação deve ser revelado (tornado público).

Na orientação a objetos, o uso da encapsulação e ocultamento da informação recomenda que a representação do estado de um objeto deve ser mantida oculta. Cada objeto deve ser manipulado

exclusivamente através dos métodos públicos do objeto, dos quais apenas a assinatura deve ser revelada.

O conjunto de assinaturas dos métodos públicos da classe constitui sua interface operacional.

Dessa forma, detalhes internos sobre a operação do objeto não são conhecidos, permitindo que o usuário do objeto trabalhe em um nível mais alto de abstração, sem preocupação com os detalhes internos da classe. Essa facilidade permite simplificar a construção de programas com funcionalidades complexas, tais como interfaces gráficas ou aplicações distribuídas.

Princípios da Orientação a Objetos Em Orientação a Objetos temos três conceitos básicos: Herança: A capacidade de uma Classe herdar métodos e propriedades de uma classe ancestral. Ela pode acrescentar ou modificar o comportamento de sua ancestral.

Encapsulamento: A capacidade que uma Classe tem de ocultar a sua própria implementação, apresentando ao “cliente” que a utiliza apenas uma interface simplificada.

Polimorfismo: A habilidade de métodos com mesmo nome apresentarem comportamento diferente em classes diferentes (porém derivadas de um mesmo ancestral). Para uma linguagem de programação ser considerada “Orientada a Objetos” é necessário implementar mecanismos que permitam utilizar estes três conceitos básicos.

Herança A herança é a principal característica de distinção entre um sistema de programação orientado a objeto e outros sistemas de programação. As classes são inseridas em uma hierarquia de especializações de tal forma que uma classe mais especializada herda todas as propriedades da classe mais geral a qual é subordinada na hierarquia. A classe mais geral é denominada superclasse e a classe mais especializada subclasse.

O principal benefício da herança é a reutilização de código. A herança permite ao programador criar uma nova classe programando somente as diferenças existentes na subclasse em relação à superclasse. Isto se adequa bem a forma como compreendemos o mundo real, no qual conseguimos identificar naturalmente estas relações.

A fim de exemplificarmos este conceito, vamos considerar que queiramos modelar os seres vivos pluricelulares existentes no planeta.

Podemos então começar com a classe SerVivo abaixo: Ela modela as características que todo ser vivo deve possuir, como a capacidade de reproduzir-se ou a necessidade de alimentar-se. Sendo assim, a classe SerVivo define atributos e métodos tais como: Atributos: Alimentos, Idade Métodos: Nascer, Alimentar, Respirar, Crescer, Reproduzir, Morrer Os seres vivos por sua vez classificam-se em Animais e Vegetais, os quais possuem características próprias que os distingue: Analisando o problema em questão (o de modelar os seres vivos), nós naturalmente identificamos classes que são especializações de classes mais genéricas e o conceito de herança da orientação a objeto nos permite implementar tal situação.

Os animais e vegetais antes de tudo são seres vivos e cada subclasse herda automaticamente os atributos e métodos (respeitando as regras dos modificadores de acesso) da superclasse, neste caso, a classe SerVivo. Além disso, as subclasses podem prover atributos e métodos adicionais para representar suas próprias características. Por exemplo, a classe Animal poderia definir os seguintes métodos e atributos: Encapsulamento Diferente da abordagem estruturada, onde dados e procedimentos são definidos de forma separada no código, na programação orientada a objeto os dados e procedimentos que manipulam estes dados são definidos numa unidade única, o objeto. Isso possibilita uma melhor modularidade do código, porém, a idéia principal é poder utilizar os objetos sem ter que se conhecer sua implementação interna, que deve ficar escondida do usuário do objeto que irá interagir com este apenas através de sua interface.

“À propriedade de se implementar dados e procedimentos correlacionados em uma mesma entidade e de se proteger sua estrutura interna escondendo-a de observadores externos dá-se o nome de encapsulamento.“.

O objetivo do encapsulamento é separar o usuário do objeto do programador do objeto e seus principais benefícios são: •possibilidade de alterar a implementação de um método ou a estrutura de dados escondidos de um objeto sem afetar as aplicações que dele se utilizam; • criação de programas mais modulares e organizados, o que possibilita um melhor reaproveitamento do código e melhor mantenabilidade da aplicação.

Via de regra, as variáveis de instância declaradas em uma definição de classe, bem como os métodos que executam operações internas sobre estas variáveis, se houverem, devem ser escondidos na definição da classe. Isso é feito geralmente através de construções nas linguagens de programação conhecidas como modificadores de acesso, como por exemplo, opublic, protected e private do Java. Quando definimos uma classe, é recomendado (para alguns é uma regra sagrada) que declaremos públicos apenas os métodos da sua interface. É na interface (ou protocolo) da classe que definimos quais mensagens podemos enviar às instâncias de uma classe, ou seja, quais são as operações que podemos solicitar que os objetos realizem.

Polimorfismo O termo Polimorfismo origina-se do grego e quer dizer "o que possui várias formas".

Em programação está relacionado à possibilidade de se usar o mesmo nome para métodos diferentes e à capacidade que o programa tem em discernir, dentre os métodos homônimos, aquele que deve ser executado. De maneira geral o polimorfismo permite a criação de programas mais claros, pois elimina a necessidade de darmos nomes diferentes para métodos que conceitualmente fazem a mesma coisa, e também programas mais flexíveis, pois facilita em muito a extensão dos mesmos.

O polimorfismo pode ser de duas formas, estático ou dinâmico: •Polimorfismo Estático: Ocorre quando na definição de uma classe criamos métodos com o mesmo nome, porém com argumentos diferentes.

Dizemos neste caso que o método está sobrecarregado (overloading). A decisão de qual método chamar é tomada em tempo de compilação, baseada nos argumentos que foram passados.

•Polimorfismo Dinâmico: Está associado com o conceito de herança e ocorre quando uma subclasse redefine um método existente na superclasse.

Dizemos neste caso que o método foi sobreescrito (overriding) na subclasse. A decisão de qual método executar é tomada somente em tempo de execução, como veremos mais adiante.

O polimorfismo dinâmico ocorre quando uma subclasse redefine um método de sua superclasse a fim de prover ao método um comportamento mais adequado às suas características.

Administração financeira e orçamentária: planejamento e execução de orçamento público;

noções

de

L. PLANEJAMENTO ORÇAMENTÁRIO 1. Planejamento As empresas vivem num ambiente extremamente competitivo, se não planejarem suas atividades correm o risco de serem surpreendidos por imprevistos e passarem por grandes dificuldades ou até mesmo chegar à falência. O planejamento deve ser usado como ferramenta para decidir antecipadamente o que fazer, de que maneira fazer, quando fazer e quem deve fazer.

Nenhuma empresa está livre de mudanças, portanto o planejamento como uma das etapas da administração é extremamente necessário.

Com o uso desta metodologia a organização opta por metas baseadas em avaliações e previsões futuras, dando forma e direcionando os esforços de administradores e trabalhadores dos demais níveis organizacionais.

O propósito do planejamento pode ser definido se como desenvolvimento de processos, técnicas e atitudes administrativas, as quais proporcionam uma situação viável de avaliar as implicações futuras de decisões presentes em função dos objetivos empresariais que facilitarão a tomada de decisão no futuro, de modo mais rápido, coerente e eficaz.

O planejamento é formado através de planos, portanto, o administrador deve saber lidar com direfentes tipos desses planos, podendo incluir período de longo a curto prazo, podendo envolver a organização inteira, uma divisão ou departamento ou ainda uma tarefa.

O planejamento possibilita o administrador avaliar os recursos a serem utilizados pela empresa, para que ela possa atingir os seus objetivos traçados. Tipos de planejamento = O planejamento dentro das empresas pode ser dividido em três formas: ESTRATÉGICO = Abrange as decisões de longo prazo (conjunto de metas a longo prazo e dos meios disponíveis que possibilitam a alcance dessas metas, dando rumo aos negócios da empresa), TÁTICO = Trata das metas de médio prazo e tem como objetivo aproveitar ao máximo determinadas áreas de resultado da empresa, ou seja, faz um planejamento específico para cada unidade da empresa, sendo desenvolvido por níveis inferiores da organização.

OPERACIONAL = Compreende as decisões a curto prazo e tem o intuito de elevar ao máximo os recursos da empresa utilizados em operações realizadas nas unidades e conforme períodos prédeterminados Leis Orçamentárias: Características: São Leis Ordinárias, privativas do chefe do Executivo.

Reguladas por Lei Complementar (LC 101/2000).

São leis apenas no sentido formal, não no sentido material. (na forma de elaboração e aprovação, são vinculadas a atos administrativos).

Os prazos dessas leis encontram-se no ADCT, art. 35 e deverão ser definitivamente disciplinadas por lei complementar.

CF - Art. 165. Leis de iniciativa do Poder Executivo estabelecerão: I - o Plano Plurianual – PPA; II - as Diretrizes Orçamentárias – LDO; III - os Orçamentos Anuais – LOA; IV – a Lei dos Créditos Orçamentários.

I - Plano Plurianual - PPA O PPA é a lei que define as prioridades do Governo pelo período de 4 (quatro) anos. O projeto de lei do PPA deve ser enviado pelo Presidente da República ao Congresso Nacional até o dia 31 de agosto do primeiro ano de seu mandato (4 meses antes do encerramento da sessão legislativa).

De acordo com a Constituição Federal, o PPA estabelecerá de forma regionalizada as DIRETRIZES, OBJETIVOS e METAS (DOM) da administração pública FEDERAL para as despesas de capital SANTOS DUMONT Concursos 6 AFO – PROF. JÚNIOR RIBEIRO (investimentos) e outras delas decorrentes(despesas correntes – relacionadas à manutenção) e para as relativas aos programas de duração continuada (superiores a um ano).

Ex.: Ensino fundamental – Programa de duração continuada.

Construção de um hospital – Despesa de capital.

Manutenção deste hospital – Despesa corrente.

Prazos do PPA: I - o projeto do plano plurianual, para vigência até o final do primeiro exercício financeiro do mandato presidencial subseqüente, será encaminhado até quatro meses antes do encerramento do primeiro exercício financeiro e devolvido para sanção até o encerramento da sessão legislativa; Vigência do PPA: Início: No começo do 2º ano de mandato.

Término: No final do 1º ano do mandato subseqüente.

Obs.: O chefe do Executivo, no 1º ano de mandato governa com o PPA, LDO e LOA que foram aprovados no mandato anterior, embora não esteja impedido de propor, ao CN, alterações.

O PPA tem o mesmo tempo de duração do mandato do chefe do Executivo – 4 anos.

Se o mandato passar para 5 ano, o PPA passará a valer para 5 anos.

Art. 167 § 1º - Nenhum investimento cuja execução ultrapasse um exercício financeiro poderá ser iniciado sem prévia inclusão no plano plurianual, ou sem lei que autorize a inclusão, sob pena de crime de responsabilidade.

A Lei nº 10.933 também estabelece que o Poder Executivo deverá enviar ao Congresso Nacional, até o dia 15 de setembro de cada exercício, relatório de avaliação contendo as estimativas das metas físicas e dos valores financeiros, tanto nas ações constantes do PPA e suas alterações, como das novas ações previstas, para os três exercícios subseqüentes ao da proposta orçamentária enviada em 31 de agosto. Fica assim estabelecido o `PPA deslizante` ou `rolante`, que deverá sempre projetar indicadores e ações para os exercícios subseqüentes ao PPA 2004-2007, assegurando, dessa forma, a perspectiva plurianual de programações.

II - Lei de Diretrizes Orçamentárias - LDO. A LDO é a lei que define as METAS e PRIORIDADES (MP) em termos de PROGRAMAS a executar pelo Governo. Inclui despesas de capital (investimento) para o exercício seguinte e orientará a elaboração da LOA. A Lei de Diretrizes Orçamentárias é elaborada anualmente, estabelecendo as regras gerais para elaboração e execução do Orçamento do ano seguinte.

De acordo com a Constituição Federal, a LDO estabelece: a) as metas e prioridades para o exercício financeiro subseqüente; b) orienta a elaboração do Orçamento (Lei Orçamentária Anual); c) dispõe sobre alterações na legislação tributária; e d) estabelece a política de aplicação das agências financeiras de fomento. e)autorizará a concessão de qualquer vantagem ou aumento de remuneração de servidores, a criação de cargos, empregos, funções ou alteração na estrutura de carreira, bem como a admissão e contratação de pessoal a qualquer título nos órgãos e entidades da Administração Pública, com exceção das empresas públicas e as sociedades de economia mista.

A LRF acrescentou à LDO: a) Dispor sobre equilíbrio de receitas e despesas; b) Estabelecer critérios de limitação de empenhos; c) Normas relativas ao controle de custos e à avaliação dos resultados dos programas financiados com recursos dos orçamentos. d) Anexo das Metas Fiscais:  Metas de resultados primário e nominal para o exercício que entra em vigor e para os dois subseqüentes;  Avaliação do cumprimento das metas do exercício anterior;  Evolução do patrimônio líquido nos últimos 3 anos;  Avaliação financeira e atuarial dos regimes de previdência;  Demonstrativo da estimativa de renúncia de receita e critério para as despesas obrigatórias de caráter continuado (superiores a 2 anos). e) Anexo dos Riscos Fiscais:  Avaliação do passivo contingente e outros riscos capazes de afetar as contas públicas informando as providências a serem tomadas caso se concretizem.

Prazos da LDO: II - o projeto de lei de diretrizes orçamentárias será encaminhado até oito meses e meio antes do encerramento do exercício financeiro(15/4) e devolvido para sanção até o encerramento do primeiro período da sessão legislativa(17/07); Vigência da LDO: No primeiro ano de mandato a LDO é aprovada antes do PPA, causando o “vazio orçamentário”. Em um mesmo exercício financeiro temos duas LDO’s em vigência, uma em relação à execução da LOA e outra em relação à elaboração da próxima LOA. Considerando a elaboração e execução da LOA, a LDO tem a vigência superior a um exercício financeiro.

Obs.: O primeiro período da sessão legislativa somente será encerrado após a aprovação da LDO. III - Lei Orçamentária Anual - LOA Estima as receitas e autoriza as despesas do Governo de acordo com a previsão de arrecadação.

Representa a materialização dos OBJETIVOS E METAS estabelecidos pelo PPA e priorizados para o ano seguinte pela LDO.

Obs.: PPA – planeja / LDO – prioriza / LOA – executa.

A Lei Orçamentária Anual compreenderá: a) o Orçamento Fiscal referente aos Poderes da União, seus fundos, órgãos e entidades da administração direta e indireta, inclusive fundações instituídas e mantidas pelo Poder Público; b) o Orçamento de Investimento das empresas em que a União, direta ou indiretamente, detenha a maioria do capital social com direito a voto; c) o Orçamento da Seguridade Social, abrangendo todas as entidades e órgãos a ela vinculados, da administração direta ou indireta, bem como os fundos e fundações instituídos e mantidos pelo Poder Público.

Prazos da LOA: III - o projeto de lei orçamentária da União será encaminhado até quatro meses antes do encerramento do exercício financeiro(31/08) e devolvido para sanção até o encerramento da sessão legislativa(22/12).

Vigência: Para o exercício financeiro – 1 ano civil – de 1º/01 a 31/12 3) Execução da Lei Orçamentária: • Essa etapa trata das operações que são efetuadas para que se possa ser colocado em prática o plano de governo para o exercício; • É a etapa onde efetivamente serão despendidos os recursos na consecução dos objetivos que foram propostos no PPA, priorizados ou não na LDO e quantificados na LOA; • Ocorre a contabilização do orçamento aprovado, pela STN que providencia a consignação da dotação orçamentária a todos os órgãos e ministérios contemplados na lei de meios; • As unidades orçamentárias passam efetivamente a executar os seus programas de trabalho, por meio da concretização de diversos atos e fatos administrativos, inerentes à execução de receita e da despesa orçamentária tais como: dação da despesa; • O registro detalhado dos créditos e respectivas dotações é fundamental para: respectivamente; e facilitar a contabilização, o controle, a fiscalização e a avaliação da execução.

Caso ocorra algum contratempo no desenvolvimento das etapas do ciclo orçamentário, que impeça a colocação da dotação orçamentária à disposição das unidades, no início do exercício financeiro, os órgãos lançam mão do mecanismo previsto na lei de diretrizes orçamentárias denominado de duodécimo.

produto será vendido e instalado é um outro fator importante - se o software é para ser vendido para um público amplo ou se será instalado em uma única empresa, sob encomenda.

Para cada uma das atividades métodos específicos devem ser elaborados. Um conjunto de métodos relacionados entre si num esquema comum de acordo com um modelo é chamado de metodologia de desenvolvimento.

O Modelo Cascata O modelo cascata tornou-se conhecido na década de 70 e é referenciado na maioria dos livros de engenharia de software ou manuais de padrões de software. Nele as atividades do processo de desenvolvimento são estruturadas numa cascata onde a saída de uma é a entrada para a próxima. As suas principais atividades são: • estudo de viabilidade • análise e especificação de requisitos • design e especificação • codificação e testes de componentes • teste do sistema e integração • entrega e instalação • manutenção Existem muitas variantes deste modelo propostas por diferentes pesquisadores ou empresas de desenvolvimento e adaptadas a diferentes tipos de software. A característica comum é um fluxo linear e seqüencial de atividades semelhantes a descritas anteriormente. A figura a seguir, mostra uma variante do modelo em cascata.

2.3 Modelos do processo de desenvolvimento Um modelo para um processo de desenvolvimento é uma proposta teórica que junto com o planejamento deve determinar quais atividades devem ser realizadas, quando, como e por quem. Nesta seção vamos apresentar alguns dos mais conhecidos modelos do processo de desenvolvimento. Eles são o modelo Cascata, o modelo Evolutivo ou Incremental, o modelo Espiral e o modelo Transformação.

A escolha de um destes modelos envolve diversos fatores. Um deles é o tipo de software - se é um software de banco de dados, um software de tempo-real, um software embutido, um sistema especialista. Outro fator importante é se a equipe de desenvolvimento é uma empresa de desenvolvimento (software house) ou se é a equipe de engenheiros da própria organização que utilizará o produto. A maneira como o

Este modelo, quando proposto, introduziu importantes qualidades ao desenvolvimento. A primeira chama a atenção de que o processo de desenvolvimento deve ser conduzido de forma disciplinada, com atividades claramente definidas, determinada a partir de um planejamento e sujeitas a gerenciamento durante a realização. Outra qualidade define de maneira clara quais são estas atividades e quais os requisitos para desempenhá-las. Por fim, o modelo introduz a separação das atividades da definição e design da atividade de programação que era o centro das atenções no desenvolvimento de software.

O modelo Cascata também é criticado por ser linear, rígido e monolítico. Inspirados em modelos de outras atividades de engenharia, este modelo argumenta que cada atividade apenas deve ser iniciada quando a outra estiver terminada e verificada. Ele é considerado monolítico por não introduzir a participação de clientes e usuário durante as atividades do desenvolvimento, mas apenas o software ter sido implementado e entregue. Não existe como o cliente verificar antecipadamente qual o produto final para detectar eventuais problemas.

Características particulares do software (ser conceitual, por exemplo) e a falta de modelos teóricos, técnicas e ferramentas adequadas mostram que é necessário haver maior flexibilidade neste fluxo seqüencial, permitindo volta atrás para eventuais modificações.

Veremos mais adiante modelos que propõem maior flexibilidade no fluxo de execução.

As métricas utilizadas nas estimativas de prazos e recursos humanos são ainda bastante imprecisas e quase sempre o planejamento de atividades precisa ser revisto. Normalmente os prazos não são cumpridos pois o planejamento, neste modelo, é feito nas etapas iniciais do desenvolvimento. A estrutura seqüencial e rígida também não permite que o planejamento seja refeito para corrigir falhas nas atividades de desenvolvimento.

O Modelo Evolutivo O modelo evolutivo descreve um processo na qual o software deve ser desenvolvido de forma a evoluir a partir de protótipos iniciais. Para entender melhor este modelo é importante entender o que éprototipação. A prototipação também aparece em outros modelo de processo.

O processo de desenvolvimento pode evoluir de diversas maneiras.

Uma destas formas consiste em ir desenvolvendo partes funcionais de

um software, isto é, que funcionam, mas não atendem a todos os requisitos por completo, e ir incrementando com novos pedaços até que todos os requisitos sejam atendidos. Para cada novo componente incorporado, as qualidades do protótipo devem ser verificadas experimentalmente.

Outra forma de evolução é iniciar o desenvolvimento com um protótipo rudimentar não funcional e torná-lo funcional ao longo do processo através do refinamento de seus componentes.

O fluxo de atividades do modelo evolutivo caracteriza-se por ser cíclico ou iterativo. Ele começa com o design e desenvolvimento de um protótipo inicial, que deve ser mostrado aos usuários e avaliado.

Durante a avaliação novos requisitos são definidos e alterações e incrementos ao protótipo inicial devem ser feitas. Este ciclo deve ser repetido em direção ao produto final.

A grande vantagem deste modelo está em permitir a verificação antecipada do produto final por engenheiros, clientes e usuários, permitindo a correção dos problemas detectados.

A extrema flexibilidade deste modelo e a falta de rigor leva a software que embora satisfaça aos requisitos dos usuários têm deficiências de desempenho, portabilidade, manutenção e outras qualidades internas.

Embora a prototipação tenha enormes vantagens e deva ser incentivada, basear o desenvolvimento no incremento de protótipos pode levar a software mal documentados e com arquiteturas mal definidas. Como os requisitos estão sempre sendo revistos a cada ciclo de desenvolvimento, torna-se praticamente impossível estimar custos e prazos e planejar as atividades de desenvolvimento.

A prototipação é mais adequada como método auxiliar à análise de requisitos e ao design do software, pois permite a validação antecipada do produto. Entretanto, não se deve deixar de lado o design da arquitetura de software e dos algoritmos para que ele possa ser construído utilizando uma linguagem de programação mais adequada.

Prototipação Prototipação é uma abordagem baseada numa visão evolutiva do desenvolvimento de software, afetando o processo como um todo.

Esta abordagem envolve a produção de versões iniciais - "protótipos" - de um sistema futuro com o qual pode-se realizar verificações e experimentações para se avaliar algumas de suas qualidades antes que o sistema venha realmente a ser construído.

Tipos de Protótipos O relacionamento entre um protótipo e as atividades do processo de desenvolvimento - início do projeto e análise de requisitos, design da interface e da aplicação, e implementação - permite a identificação de quatro tipos de protótipos: • Protótipo de Apresentação - oferece suporte ao início do projeto e é usado para convencer o cliente de que o futuro sistema é viável e que a interface do usuário se adequa aos requisitos. Na maioria dos casos é usado para mostrar visão que o usuário têm do sistema e revelar aspectos importantes da interface.

• Protótipo Autêntico - é um sistema de software provisório e funcional, geralmente projetado para ilustrar aspectos específicos da interface de usuários ou parte da funcionalidade, ajudando na compreensão dos problemas envolvidos.

• Protótipo Funcional -- é derivado do modelo do domínio do problema ou da especificação do software e serve para ajudar à equipe de desenvolvimento compreender questões relacionadas com a construção do sistema. Esse protótipo não interessa aos usuários.

• Sistema Piloto - é usado não apenas com propósitos ilustrativos, mas como um núcleo básico operacional do sistema. Esse sistema

deve ser instalado no ambiente de aplicação e experimentado com os usuários.

Objetivos da Prototipação Num projeto de software várias questões podem ser respondida com a construcão de protótipos. Nas situações típicas de desenvolvimento podemos distinguir entre diferentes objetivos na prototipação: • Exploratória - é quando o protótipo é usado para ajudar a esclarecer requisitos dos usuários com respeito ao sistema futuro. Uma prototipação também é exploratória quando se busca examinar uma variedade de opções de design de maneira a evitar a escolha de uma abordagem específica não adequada. Com esses objetivos os desenvolvedores adquirem informações sobre o domínio, os usuário e tarefas. Os usuários podem emitir informações e sugestões mais precisas, tornando-se parceiro das decisões que envolvem o desenvolvimento.

• Experimental - é quando a prototipação foca aspectos técnicos do desenvolvimento, oferecendo aos desenvolvedores resultados experimentais para tomada de decisões de design e implementação. Um aspecto essencial é a viabilização de uma base de comunicação entre os usuários e desenvolvedores para soluções de problemas técnicos de viabilidade e usabilidade, dentre outros. As principais vantagens para os desenvolvedores são a verificação e validação das decisões tomadas e soluções apresentadas.

• Evolutiva - A prototipação pode ser aplicada de maneira bastante proveitosa num processo de reengenharia em organizações, para avaliar o impacto que a introdução de novas tecnologias pode trazer. Nesse caso o protótipo não é visto apenas como uma ferramenta em projetos individuais, mas como parte de um processo contínuo de evolução dos processos organizacionais. Os desenvolvedores não são mais os protagonistas da prototipação, mas consultores que trabalham em cooperação com os usuários no processo de reengenharia.

Técnicas de prototipação Do ponto de vista técnico, a prototipação pode ser conduzida segundo duas abordagens, relacionadas com técnicas específicas de construção.

Experiências em desenvolvimento de software têm apontado inúmeras qualidades no design e implementação em diversas camadas. Essas camadas podem ir desde a interface de usuário à camadas mais básicas como uma base de dados e o sistema operacional. Dessa forma, podemos identificar duas formar de subdividir a prototipação.

• Prototipação horizontal - Apenas uma camada específica do sistema é construída. Por exemplo, a interface do usuário com suas janelas e widgets, ou camadas da aplicação como as funções para transação em bancos de dados.

• Prototipação vertical - Uma parte da funcionalidade do sistema é escolhida para ser implementada completamente.

Esta técnica é apropriada quando aspectos da funcionalidade ainda estão em aberto.

Um outro critério para se classificar protótipo é de acordo com o relacionamento entre o protótipo e o sistema final. Em certos casos, o protótipo serve apenas para propósitos de especificação do sistema final e não será usado como parte integrante do sistema final. Ele é jogado fora. Um outro caso, é quando o protótipo vai sendo incrementado e se torna parte integrante (building block) do sistema.

Por fim, o protótipo pode ser construído apenas para a compreensão de certos problemas que envolvem determinados interesses. Não existe a intenção de transformá-lo num sistema.

O Modelo Transformação Um programa é uma descrição formal, isto é, ele é descrito por uma linguagem de programação cuja sintaxe e semântica são definidos formalmente. Apenas desta forma é que temos a garantia de que o programa será sempre executado da mesma forma pelo computador.

O modelo Tranformação tem suas raízes na abordagem de métodos formais para o desenvolvimento de software. A idéia é que o desenvolvimento deve ser visto como uma seqüência de passos que gradualmente transforma uma especificação formal num programa. O passo inicial é transformar os requisitos informais numa especificação funcional formal. Esta descrição formal é então transformada numa

outra descrição formal mais detalhada, e assim, sucessivamente, até chegar no ponto em que se tenha componentes de programas que satisfaçam a especificação. Durante este processo de transformações sucessivas - chamado de otimização - as especifição formais produzidas podem ser executadas por um processador abstrato, permitindo uma verificação formal da sua validação antes mesmo que o programa venha a ser implementado. Antes de serem transformadas cada especificação formal deve ser verificada em relação às expectativas dos clientes e usuários.

As transformações devem ser realizadas pelo engenheiro de software.

A natureza formal da transformação possibilitam a aplicação de verificações matemáticas como prova, consistência e completude da especificação. As transformações podem ser realizadas de maneira automática por ferramentas que traduzem especificações formais mais abstratas em especificações mais detalhadas.

Este modelo prevê que o engenheiro de software deve ter a sua disposição uma biblioteca de componentes reutilizáveis que satisfaça especificações formais. Na otimização, à medida que as especificações de mais baixo nível vão sendo obtidas verifica-se quais componentes da biblioteca implementam parte desta especificação. Um ambiente automatizado de desenvolvimento (uma ferramenta CASE - Computer Aided Software Engineering) pode auxiliar este processo armazenando o histórico de decisões dos engenheiros de software.

O Modelo Espiral O objetivo do modelo espiral é prover um metamodelo que pode acomodar diversos processos específicos. Isto significa que podemos encaixar nele as principais características dos modelos vistos anteriormente, adaptando-os a necessidades específicas de desenvolvedores ou às particularidades do software a ser desenvolvido. Este modelo prevê prototipação, desenvolvimento evolutivo e cíclico, e as principais atividades do modelo cascata.

Sua principal inovação é guiar o processo de desenvolvimento gerado a partir deste metamodelo com base em análise de riscos e um planejamento que é realizado durante toda a evolução do desenvolvimento. Riscos são circunstâncias adversas que podem surgir durante o desenvolvimento de software impedindo o processo ou diminuindo a qualidade do produto. São exemplos de riscos: pessoas que abandonam a equipe de desenvolvimento, ferramentas que não podem ser utilizadas, falha em equipamentos usados no desenvolvimento ou que serão utilizados no produto final, etc. A identificação e o gerenciamento de riscos é hoje uma atividade importantíssima no desenvolvimento de software devido à imaturidade da área e à falta de conhecimento, técnicas e ferramentas adequadas.

O modelo espiral descreve um fluxo de atividades cíclico e evolutivo constituído de quatro estágios.

• No estágio 1 devem ser determinados objetivos, soluções alternativas e restrições.

• No estágio 2, devem ser analisados os riscos das decisões do estágio anterior. Durante este estágio podem ser construídos protótipos ou realizar-se simulações do software.

• O estágio 3 consiste nas atividades da fase de desenvolvimento, incluindo design, especificação, codificação e verificação. A principal característica é que a cada especificação que vai surgindo a cada ciclo especificação de requisitos, do produto, da arquitetura, da interface de usuário e dos algoritmos e dados - deve ser feita a verificação apropriadamente.

• O estágio 4 compreende a revisão das etapas anteriores o planejamento da próxima fase. Neste planejamento, dependendo dos resultados obtidos nos estágios anteriores decisões, análise de riscos e verificação, pode-se optar por seguir o desenvolvimento num modelo Cascata (linear), Evolutivo ou Transformação. Por exemplo, se já no primeiro ciclo, os requisitos forem completamente especificados e validados pode-se optar por seguir o modelo Cascata. Caso contrário, pode-se optar pela construção de novos protótipos, incrementando-o, avaliando novos riscos e re-planejando o processo.

6.4.7 Volatibilidade Volatibilidade é a possibilidade ou a probabilidade de que mudanças venham a ocorrer.

6.4.4 Qualidade de Abstração [Scott97] apresenta duas definições para qualidade de abstração: • para Modelo de Análise, qualidade de abstração é definida como uma medida da característica do conjunto de abstrações no Modelo de Análise, que reflete as propriedades das entidades do domínio.

• para Projeto, qualidade de abstração é definida como a medida de quanto os componentes de Projeto implementam as propriedades das respectivas abstrações do Modelo de Análise.

[Scott97] também afirma que qualidade de abstração representa 3 componentes: suficiência, completude e coesão.

Coesão [Booch94] apresenta o conceito de Coesão através do seguinte exemplo: “Uma classe Cachorro é funcionalmente coeso se sua semântica representa o comportamento relativo a cachorro, todo seu comportamento e nada mais que o comportamento de cachorro.

Uma classe Cachorro que contém outros comportamentos não relativos a cachorro não é coesa.”57 As Classes de Acesso do MA devem ser coesas, representando o comportamento básico da classe equivalente do Modelo de Análise, sem acrescentar funcionalidades relativas à interface, às regras do negócio ou à persistência. Como discutido, anteriormente, na seção 6.2.1, Definição do Módulo de Acesso, classes mais especializadas podem ser definidas localmente nas camadas, mas a Classe de Acesso deve ser funcionalmente coesa.

As UNs da Camada de Negócio também devem ser coesas, assim sendo, cada UN trata das funcionalidades relativas a sua entidade em questão, toda a sua funcionalidade, mas não apresentaria funcionalidades relativas a outras entidades (que devem estar nas suas respectivas UN).

Suficiência e Completude “Suficiência é o grau no qual um conjunto de abstrações apresenta as propriedades das entidades do domínio de tal forma que este conjunto represente tais entidades para a visão necessária ao sistema em questão.” [Scott97].

“Completude é o grau no qual um conjunto de abstrações apresenta as propriedades das entidades do domínio de tal forma que este conjunto represente tais entidades para todos os sistemas que o utilizam.”

[Scott97] Diagramas Estruturais • De Classe: Este diagrama é fundamental e o mais utilizado na UML e serve de apoio aos outros diagramas. O Diagrama de Classe mostra o conjunto de classes com seus atributos e métodos e os relacionamentos entre classes.

• De Objeto: O diagrama de objeto esta relacionado com o diagrama de classes e, é praticamente um complemento dele.

Fornece uma visão dos valores armazenados pelos objetos de um Diagrama de Classe em um determinado momento da execução do processo do software.

• De Componentes: Está associado à linguagem de programação e tem por finalidade indicar os componentes do software e seus relacionamentos.

• De implantação: Determina as necessidades de hardware e características físicas do Sistema.

• De Pacotes: Representa os subsistemas englobados de forma a determinar partes que o compõem.

•

De Estrutura: Descreve a estrutura interna de um classificador.

Diagramas Comportamentais • De Caso de Uso (Use Case): Geral e informal para fases de levantamento e análise de Requisitos do Sistema.

• De Máquina de Estados: Procura acompanhar as mudanças sofridas por um objeto dentro de um processo.

• De Atividades: Descreve os passos a serem percorridos para a conclusão de uma atividade.

• De Interação: Dividem-se em: 1. De Sequência: Descreve a ordem temporal em que as mensagens são trocadas entre os objetos.

2. Geral interação: Variação dos diagramas de atividades que fornece visão geral dentro do sistema ou processo do negócio.

3. De comunicação: Associado ao diagrama de Seqüência, complementando-o e concentrando-se em como os objetos estão vinculados.

4. De tempo: Descreve a mudança de estado ou condição de uma instância de uma classe ou seu papel durante o tempo.