Banco de dados Formas normais 1 forma normal (1FN): no pode ter atributos multivalorados nas tuplas; ou tuplas como

atributo de uma tupla. O melhor jeito de remover esse problema de uma entidade (evitando redundncias e valores nulls) criando outra entidade com a chave primria como sendo a mesma da primeira e colocar o atributo multivalorado (da primeira entidade) como atributo atmico da segunda entidade, participando da chave primria tambm. Outra soluo ampliar a entidade para cada tupla que tenha valores multivalorados. A nova chave primria passa a ser a combinao da chave primria anterior com os atributos multivalorados. 2 forma normal (2FN): pressupe-se que a tabela j esteja na 1FN. Alm disso, todos os atributos NO PRIMRIOS de uma tabela precisam ter dependncia funcional total da chave primria. Uma tabela, cuja chave primria contm somente um nico atributo, j est na 2FN. E uma tabela contendo somente atributos que participam da chave primria tambm j est na 2FN. ### Banco de dados Formas normais 3 forma normal (3FN): pressupe-se que a tabela j esteja na 2FN. Alm disso, na tabela, no pode haver um atributo no primrio que tenha dependncia transitiva com a chave primria. Isto , para uma dependncia no trivial X->Y, ou X uma superchave ou Y um atributo primrio. Se a dependncia for trivial, ento X no precisa ser superchave e nem Y ser atributo primrio. Forma normal de Boyce-Codd (BCNF): uma forma mais "rgida" da 3FN. Toda relao que tiver na forma BCNF, estar na 3FN, mas o contrrio no , necessariamente, verdadeiro. Uma relao R est na BCNF se todas as suas dependncias funcionais no triviais X->Y, X for uma superchave. 4 forma normal (4FN): pressupe-se que a relao esteja na 3FN e, para cada dependncia multivalorada X->->Y, X seja a superchave. ### Engenharia de Software CORBA (Common Object Request Broker Architecture) uma arquitetura padro criada pela OMG (Object Management Group) para realizar troca de dados em sistemas distribudos heterogneos. ORB (object Request Broker) um mdulo intermedirio para realizar comunicao entre cliente e servidor.

 usada a Linguagem de Definio de Interface (IDL) que faz mapeamento para outras linguagens (C++, Java, C, etc.). Existe o Modelo de Componentes CORBA (CMM) para tratar de problemas deixados em aberto pelo CORBA. Neste modelo, componentes so os elementos bsicos. Os componentes so conectados atravs de interfaces ou eventos. As implementaes de componentes so denominados executores que precisam implementar interfaces locais chamadas de "callback". Executores podem ser monolticos (tratados como um nico mdulo) ou segmentados (divididos em segmentos e tratados independentemente). ### Engenharia de Software GIOP (General Inter-ORB protocol) um protocolo geral para envio de mensagens entre objetos ORB. IIOP (Internet Inter-ORB protocol) um protocolo especfico para os objetos se comunicarem usando o TCP/IP. O GIOP serve como base para criar outros protocolos mas o IIOP obrigatrio. Com isso os objetos conseguem se comunicar, pelo menos atravs do IIOP. Criar requisies de operaes podem ser por stubs e, tambm, atravs da DII (Dynamic Invocation Interface). Pode-se implementar objetos servidores dinamicamente atravs da DSI (Dynamic Skeleton Interface). As requisies podem ser sncronas ou assncronas. ### Engenharia de Software Existem as referncias de objeto (RO) que so mecanismos para identificar e localizar um objeto servidor. Para os clientes, essas referncias s servem para localizar, e no podem consultar ou modificar o contedo de uma referncia. Toda RO tem uma indicao de qual interface seu objeto oferece. Isso faz com que o ORB verifique se existe a operao requisitada a este objeto. Uma RO pode ser linearizada em forma de uma string. Esta, por sua vez, pode ser convertida de volta a uma RO. As RO so representadas atravs do padro IOR (Interoperable Object Reference). Este padro tem informao necessria para estabelecer a conexo entre um cliente e um objeto servidor. Este padro identifica os protocolos disponveis para se conectar em um determinado servidor. ### Engenharia de Software Um ORB deve oferecer um repositrio de interfaces, onde so armazenadas as descries as interfaces dos objetos servidores disponveis. Existe, tambm, um repositrio de implementaes que deve auxiliar o cliente na obteno de uma referncia para um determinado objeto servidor.

Os componentes do CORBA podem ser stateless (temporrios e um grupo de referncias so mapeados num nico executor), conversational (temporrio e cada referncia mapeada num nico executor) e durable (persistente e cada referncia mapeada num nico executor). ### Engenharia de Software UDDI um framework independente de plataforma para descrever servios, descobrir negcios e integrar servios de negcios usando a internet. um servio de diretrio, onde negcios podem registrar e procurar pelos servios Web. UDDI utiliza WSDL para descrever interfaces para servios web. WSDL uma linguagem baseada em XML. Especifica o local do servio web e as operaes que o servio expe. ### Engenharia de Software SOAP um protocolo baseado em XML para permitir troca de informaes entre aplicativos pela Internet. utilizado em sistemas computacionais distribudos. SOAP no define mecanismos de localizao e descrio de objetos em servios WEB. Isso fica para o WSDL e o UDDI. ### Engenharia de Software Padres de projeto so mais abstratos do que framework. ### Engenharia de Software RMI (Remove Method Invocation) uma arquitetura que tem como objetivo fazer com que os programadores em Java possam desenvolver programas distribudos com a mesma sintaxe e semntica que os programas no distribudos. Um sistema RMI composto de: definies de interface para os servios remotos; arquivos de stub e skeletons; um servidor para hospedar os servios remotos; um servio RMI naming que permite o cliente achar os servios remotos; um programa cliente, entre outros. ### Banco de dados Notaes de DER: Entidade = dentro de um retngulo. Entidade fraca = dentro de um retngulo duplo. Atributo = dentro de uma elipse. Atributo multivalorado = dentro de uma elipse dupla. Atributo chave = sublinhado. Atributo derivado = elipse pontilhada. Relacionamento = losngo.

Relacionamento fraco = losngo duplo. Linha dupla = a entidade que a contm de participao total. A cardinalidade: Chen: representada por um nmero perto do retngulo da entidade (1:1, 1:N, N:M, 0:N) Bachman: representada por crculo fechado (1), crculo aberto (0) ou seta (N). Martin: representada por nmero 1 (obrigatrio), pelo astersco (opcional N), 1...* (1,n) (um ou mais, obrigatrio), 0...1 (0,1), opcional. O nmero de conjuntos-entidades (classes distintas de objetos) cujas instncias podem estar associadas umas s outras atravs de um relacionamento. (Relacionamento binrio, ternrio, etc.) O grau de um tipo relacionamento o nmero de entidades que participam deste relacionamento. ### Banco de dados lgebra relacional. Grau de uma relao o nmero de atributos que uma relao tem. Domnio um conjunto de valores atmicos. Ex.: cpf, nome, salrio, idade. Seleo: operao unria usada para selecionar um subconjunto de tuplas. (comando 1) S salario > 2000 (Empregado) (selecione, de Empregado, todo mundo que tem salrio maior do que 2000). Uma seleo pode ser uma relao de outra seleo (seleo de seleo(es)). A seleo pega linhas da tabela. O grau da relao resultado o mesmo da relao original. o comando WHERE do SQL. Projeo: operao unria usada para selecionar colunas da tabela. (Comando 2) P cpf, nome, salrio (Empregado) (projete o cpf, o nome e o salrio das tuplas da tabela empregado). O grau da projeo igual ao nmero de atributos selecionados pelo comando. Se uma lista de atributos no inclui atributos-chave, tuplas duplicadas podem aparecer, porm a projeo as elimina. o comando SELECT do SQL. ### Banco de dados lgebra relacional. Sequncia de operaes: (comando 3) P pnome, unome, salrio (S dptNo = 5 (Empregado)) = projete o primeiro e ltimo nomes e salrio de todos os empregados que trabalham no departamento de nmero 5. O comando 3 pode ser feita aos passos:

A <- S dptNo = 5 (Empregado) Resultado <- P pnome, unome, salrio (A) Renomear (rebatizar): com relao ao comando 3, ele pode ser feito tambm desse jeito: A <- S dptNo = 5 (Empregado) Resultado (primeiro_nome, ltimo_nome, salrio) <- P pnome, unome, salrio (A) Operaes de Unio, interseo e subtrao (diferena). Estas operaes so similares s da matemtica, com relao s tuplas (e no aos atributos). obs.: estas operaes devem ser compatveis de unio. Duas relaes R(A1, Ai, ..., An) e S(B1, Ai, ..., Bn) so compatveis de unio se tem o mesmo grau e domnio(A) = domnio(B), para todo i. ### Banco de dados lgebra relacional Produto cartesiano (juno cruzada ou produto cruzado) R x S, sendo R com n atributos e S, com m atributos. Combina cada tupla de R com cada tupla de S. O resultado ter n+m atributos e n*m tuplas. o comando FROM do SQL. Juno = produto cartesiano com uma condio de juno. Equijuno (equijoin) = juno usando uma condio de igualdade entre os atributos (idFunc = idGer); Juno natural (natural join) = equijuno sem que precise especificar um dos atributos. Para isso, eles devem ser iguais. Um rename ser necessrio caso eles no sejam. Diviso = a diviso de R/S ter os atributos de R que no esto em S e resulta numa tabela Q. Geralmente a diviso usada quando se tem "para todos" nas consultas. Exemplo: T1 {(a1, b1), (a2, b1), (a3, b1), (a2, b2), (a3, b2), (a3, b3)}, T2 {a1, a2, a3}. T1/T2 = {b1} pois tanto a1, a2 e a3 de T2 tem o b1 como "parceiro".

### Banco de dados SQL Ela divida em 2 partes: DDL (Data description language) e DML (Data manipulation language). DDL A DDL uma parte muito pequena da SQL. A DDL se refere aos dados sobre os dados nos banco de dados. Isto , se refere aos metadados. Os comandos mais importantes dela so CREATE TABLE, DROP TABLE e ALTER TABLE. Exemplo: CREATE TABLE Funcionrio (matrcula INTEGER, nome CHAR (40) NOT NULL, PRIMARY KEY (matrcula)); CREATE TABLE Funcionrio (matrcula INTEGER PRIMARY KEY, nome CHAR (40) NOT NULL); ALTER TABLE Funcionrio ADD sobrenome CHAR (40); ALTER TABLE Funcionrio DROP COLUMN sobrenome; DROP TABLE Funcionrio; TRUNCATE TABLE Funcionrio; DROP TABLE para deletar a tabela inteira. Deleta tambm ndices e privilgios. A operao no tem como ser desfeita. Nenhum DML trigger disparado. TRUNCATE usado para deletar as linhas da tabela. No tem como ser desfeita e nenhum DML trigger disparado. A diferena dela para o DELETE que ela mais rpida e no gasta espao para as operaes poderem ser desfeitas.

Obs.: no Oracle 10g, uma tabela pode ser desfeita com o comando FLASHBACK FLASHBACK TABLE funcionrio TO BEFORE DROP; ### Banco de dados SQL Ela divida em 2 partes: DDL (Data description language) e DML (Data manipulation language). DML DML a parte mais ampla do SQL. Compreende, basicamente, os comandos SELECT, UPDATE, DELETE, INSERT. SELECT nome, matrcula FROM Funcionrio WHERE matrcula > 1000 ORDER BY nome ASC; SELECT nome FROM Funcionrio AS F WHERE matrcula BETWEEN 500 and 1000; // F um alias. SELECT nome FROM Funcionrio WHERE matrcula NOT BETWEEN 500 and 1000; SELECT nome FROM Funcionrio WHERE matrcula IN (500, 600, 700, 800, 900); SELECT nome FROM Funcionrio WHERE matrcula NOT IN (500, 600, 700, 800, 900); SELECT * from Funcionrio WHERE nome LIKE 'Paulo%'; // procura todos os nomes que comecem com Paulo no importando o resto. Poderia ser tambm: '%de Oliveira' Uma subquery um SELECT embutido em uma consulta principal. - uma subquery precisa estar includa entre parntesis; - uma subquery sempre deve estar do lado direito do operador de comparao; - o operador IN deve ser utilizado em uma subquery que retorne mltiplas linhas; - o operador igual = no pode ser utilizado em uma consulta que contenha uma subquery que retorne mltiplas linhas. UPDATE Funcionrio SET nome='Teste' WHERE matrcula < 1000; A operao DELETE usada para deletar linhas na tabela, mantendo as definies da tabela intactas. necessria a clusula WHERE para escolher algumas linhas. Caso ela no seja especificada, todas as linhas da coluna sero deletadas. necessrio o COMMIT (ou, para desfazer a operao, o ROLLBACK) aps o DELETE para confirmar. DELETE * from Funcionrio WHERE nome IS NULL; INSERT INTO Funcionrio VALUES (1300, 'Paulo'); CREATE DOMAIN TIMES CHAR (10)

DEFAULT BOTAFOGO CONSTRAINT TIMES_RJ CHECK BOTAGOFO, FLAMENGO, FLUMINENSE, VASCO) ALL SELECT empno, sal FROM emp WHERE sal > ALL (2000, 3000, 4000); equivalente a: SELECT empno, sal FROM emp WHERE sal > 2000 AND sal > 3000 AND sal > 4000; ANY SELECT empno, sal FROM emp WHERE sal > ANY (2000, 3000, 4000); equivalente a: SELECT empno, sal FROM emp WHERE sal > 2000 OR sal > 3000 OR sal > 4000; ### Banco de dados SQL Clusula CHECK serve pra forar um atributo a ter um domnio. Exemplo:

(VALUE

IN

CREATE TABLE Persons (P_Id int NOT NULL, LastName varchar(255) NOT NULL, FirstName varchar(255), Address varchar(255), City varchar(255), CHECK (P_Id>0)); ### Banco de dados CASE Select nome, CASE nome WHEN 'bla' THEN sal*10 ELSE sal END "novo nome", id FROM Pessoa; NULLIF(a, b) = null se a = b; SELECT Store_name, NULLIF(Actual,Goal) FROM Sales_Data;

EXISTS """ sintaxe: SELECT "nome_coluna1" FROM "nome_tabela1" WHERE EXISTS (SELECT * FROM "nome_tabela2" WHERE [condio]); semntica: simplesmente verifica se h uma linha na consulta interna. Se tiver, a consulta externa continua. (A condio existente na consulta interna no influencia a forma como a consulta externa executada.) A seleo interna do EXISTS deve ser olhada tupla por tupla. Se uma tupla retornada, ento ela analisada no SELECT externo. Se ela no for retornada, a vai pra prxima tupla. Obviamente, o NOT EXISTS faz o contrrio. """ HAVING sintaxe: SELECT "nome_coluna1", SUM("nome_coluna2") FROM "nome_tabela" GROUP BY "nome_coluna1" HAVING SUM("nome_coluna2") > 132; semntica: a grosso modo, having o where aplicado a funes de agregao. DISTINCT sintaxe: SELECT DISTINCT "nome_coluna" FROM "nome_tabela"; semntica: seleciona "nome_coluna" sem repeties. GROUP BY sintaxe: "nome_coluna1", SUM("nome_coluna2") FROM "nome_tabela" GROUP BY "nome_coluna1"; semntica: agrupa os resultados em colunas especificadas na sintaxe. O comando GROUP BY utilizado ao selecionar vrias colunas a partir de uma tabela (ou tabelas) e aparece pelo menos um operador aritmtico. Funes de agregao: avg(), count(), max(), sum(), min(). No pode ter funo de agregao como parmetro de outra funo de agregao. O campo do SELECT pode ter somente funo de agregao. Por exemplo: SELECT max(bla) FROM ... ### Banco de dados Mapeamento do DER para o modelo relacional. - Cada entidade regular (forte) mapeada para uma relao (tabela). Os atributos compostos (exemplo: Endereo) so decompostos em atributos simples. Escolher, para a chave primria, um dos atributos-chave. As chaves estrangeiras no so usadas por enquanto. Sero utilizadas em outros passos. - Cada entidade fraca mapeada para uma relao onde seus atributos devem ser selecionados e, alm disso, a(s) chave(s) primria(s) da entidade forte correspondente (so) escolhida(s) como a chave estrangeira da relao criada. A chave primria da relao ser composta pelas chaves primrias da entidade forte e da chave parcial da entidade fraca, caso houver.

Chave parcial ou discriminador = conjunto de chaves que permite diferenciar as tuplas dentro de uma entidade fraca. ### Banco de dados Mapeamento do DER para o modelo relacional. - Para cada relacionamento 1:1, identificar as entidades S e T. Escolher uma das opes (a 1a. a mais usada): 1) Escolha da chave estrangeira: escolha uma relao S e insira nela a chave primria de T para ser a chave estrangeira da relao. Preferencialmente, escolha S como a entidade de participao total. Incluir todos os atributos* do relacionamento 1:1 como atributos de S. 2) Opo da relao unificada: incorporar o tipo relacionamento e os dois tipos entidades a uma nica relao. Essa opo pode ser apropriada quando ambas as participaes so totais. 3) Opo referncia cruzada ou relao de relacionamento: definir uma relao R com a finalidade de servir de referncia cruzada s chaves primrias das duas relaes S e T. Essa relao R chamada relao de relacionamento (ou tabela de busca), porque cada tupla em R representa uma instncia do relacionamento que relaciona uma tupla de S a uma tupla de T. * atributos simples ou componente simples dos atributos compostos ### Banco de dados Mapeamento do DER para o modelo relacional. - Para cada relacionamento 1:N, identificar a relao do lado N como sendo a relao S e inserir em S, como chave estrangeira, a chave primria de T que representa o outro tipo entidade participante em R. Incluir, tambm, qualquer atributo* do tipo relacionamento 1:N como atributo de S. - Para cada relacionamento N:M, criar uma nova relao S para representar R. As chaves estrangeiras de S sero as chaves primrias das relaes que representam os tipos entidade participantes do relacionamento; a combinao delas formar a chave primria de S. Tambm devem estar includos quaisquer atributos* do relacionamento N:M. * atributos simples ou componente simples dos atributos compostos ### Banco de dados

Mapeamento do DER para o modelo relacional. - Para cada atributo multivalorado A, criar uma relao R. Os atributos de R sero o atributo A e a chave primria K da relao que representa o tipo entidade ou o tipo relacionamento que tem A como atributo (que ser chave estrangeira em R). A chave primria de R ser a combinao de A e K. Se o atributo multivalorado for um atributo composto, suas componentes simples sero includas. - Para cada tipo relacionamento R n-rio, em que n > 2, criar uma nova relao S para representar R. Incluir, como chave estrangeira, as chaves primrias das relaes que representam o tipo entidade. Incluir, tambm, os atributos* do relacionamento n-rio. A chave primria de S ser a combinao de todas as chaves estrangeiras que fazem referncias s relaes representantes dos tipos entidade participantes. Entretanto, se as restries de cardinalidade em qualquer um dos tipos entidade E participantes em R forem 1, ento a chave primria de S no deve incluir a chave estrangeira que faz referncia relao E' correspondente a E. * atributos simples ou componente simples dos atributos compostos ### Engenharia de Software Testes de softwares: - testes completos so impossveis na prtica; - os testes devem ser realizados, preferencialmente, por terceiros por no estarem envolvidos no projeto; - os testes so feitos em estgios: primeiro testam-se, isoladamente, os mdulos do sistema procurando identificar erros de lgica e de implementao (teste de unidade), depois a integrao dos mdulos so testados procurando erros nas interfaces entre os mdulos (teste de integrao). Por fim, o sistema, como um todo, testado, verificando o desempenho do sistema (requisitos no funcionais) e verificando possveis erros de funes (requisitos funcionais) (teste de sistema). Um driver um programa responsvel pela ativao e coordenao de um teste de unidade. Ele responsvel por passar os dados de teste para o mdulo que ser testado, receber os resultados e pass-los para o testador. Um stub uma unidade que substitui uma outra unidade que est sendo chamada pela unidade que est sendo testada, isto , simula o comportamento de uma outra unidade com um mnimo de computao ou manipulao de dados. ### Engenharia de Software O processo de teste tem 4 fases: 1) Planejamento de testes: esta a fase onde se trata das definies dos testes, das estimativas dos recursos necessrios para realizar os testes, das estratgias e tcnicas dos testes e dos critrios para determinar quando o conjunto de testes est completo.

2) Projeto dos casos de testes: a fase mais importante, pois nela necessrio criar um conjunto de testes que englobe as vrias possibilidades de execuo do sistema. Existem tcnicas para sistematizar a criao de testes. 3) Execuo dos testes: a fase onde os testes so executados e os resultados so registrados. 4) Anlise dos resultados: se forem detectadas falhas, ento ser necessrio procurar por defeitos. Caso contrrio, deve-se julgar se h necessidade de mais casos de teste ou se os testes podem ser encerrados. ### Engenharia de Software Testes de software Diversas tcnicas so utilizadas para a realizao de testes: testes funcionais, estruturais e baseados em mquinas de estado. - Os testes funcionais ou caixa-preta utilizam especificaes (requisitos, anlise e projeto) para definir os objetivos dos testes e guiar para o projeto dos casos de teste. O conhecimento sobre a implementao do cdigo no usada. Eles so usados para mostrar que uma entrada adequadamente aceita, a sada correta e a integridade da informao externa mantida. Considerando-se o programa final como caixa preta, a validao dinmica pode ser utilizada para identificar a ocorrncia de defeitos no programa ou para confirmar se ele atende aos requisitos estabelecidos. - Os testes estruturais ou caixa-branca estabelecem os objetivos com base na implementao e na verificao de detalhes do cdigo. - Os testes baseados em mquinas de estado so projetados baseando-se num conhecimento subjacente estrutura de uma mquina de estados para determinar os objetivos do teste. ### Engenharia de Software Tipos de testes caixa-branca: * Testes de estrutura de controle: enfocam nas estruturas como comandos, condicionais e lao (loop). - Teste de condio um tipo de teste de estrutura de controle que testa as condies lgicas do mdulo. - Teste de fluxo de dados um tipo de teste de estrutura de controle que seleciona caminhos de testes baseando-se nas definies e usos de variveis nos mdulos. - Teste de lao focaliza os loops. * Testes de caminho bsico: define uma medida de complexidade lgica do mdulo e com essa medida, um conjunto bsico de caminhos de execuo definido. * O teste de cobertura de todo comando diz que todo comando de cdigo fonte deve ser executado por algum caso de teste.

Tipos de testes caixa-preta: * Particionamento de equivalncia: divide os casos de teste em classes de equivalncia. A ideia que estas classes, a princpio, tem o mesmo comportamento no sitema, sendo, portanto, necessrio um nico caso de teste para cada classe de equivalncia. * Anlise do valor limite: a prtica mostra que um grande nmero de erros tende a ocorrer no limite do domnio da entrada. Os valores limite para teste so o mnimo, o mximo, um a menos do mnimo e um a mais do mximo. ### Engenharia de Software Teste dos mdulos: - Bottom-up ou ascendente: os mdulos mais internos so testados primeiros. Com isso so testados os mdulos que chamam estes mdulos mais internos at que todos os mdulos sejam testados. Apenas drivers so necessrios nesta abordagem de teste. - Top-down ou descendente: os mdulos mais externos so testados primeiros. Com isso so testados os mdulos que so chamados por estes mdulos mais externos at que todos os mdulos sejam testados. Apenas stubs so necessrios nesta abordagem de teste. - Teste sanduche: um mdulo alvo, no meio da hierarquia de mdulos, escolhido e depois as abordagens top-down e bottom-up so utilizadas. - Teste big-bang: testar individualmente cada unidade e s depois integrar os mdulos. A prtica tem mostrado que ela leva a muitos problemas. ### Engenharia de Software Testes do sistema: Muitas vezes chamados de testes de validao. Os testes do sistema incluem tipos de teste realizados na seguinte ordem: 1) Teste funcional: verifica se o sistema integrado realiza as funes especificadas nos requisitos. 2) Teste de desempenho: verifica se o sistema integrado atende os requisitos no funcionais do sistema (eficincia, segurana, confiabilidade, etc.). 3) Teste de aceitao: nos dois primeiros, os desenvolvedores que realizam os testes. Neste, os clientes realizam os testes a fim de garantir que suas necessidades sejam satisfeitas. 4) Teste de instalao: quando o teste de aceitao no for feito no ambiente onde o sistema ser usado, este teste dever ser realizado. ### Engenharia de Software Dicionrio de dados (DD) O dicionrio de dados um repositrio de metadados do software. Ele tem a definio dos elementos que tornam o modelo de dados e o diagrama de fluxo de dados precisos.

Ele uma definio formal e estruturada dos fluxos de dados, elementos de dados, memrias, entidades e relacionamentos. Regras para criar nomes nos DD's: - os palavras devem ser separadas por sublinhas com at 32 caracteres; - devem ser eliminados preposies ou conjunes; - abreviar palavras de forma mnemnica ou incluir a abreviao no dicionrio. Exemplo de notao: *senha do sistema* Senha = 6{cv}12 cv = [0-9 | a-z | A-Z] login = 1{cv}40 usurio = login + senha A senha precisa de 6 caracteres do tipo cv, no mnimo, e 12, no mximo. Ela pode ter letras ou nmeros. Comentrio veio antes da definio da senha. O login tem, no mnimo, 1 e, no mximo, 40 caracteres do tipo cv. Usurio formado de login e senha o @ serve para marcar que um item um atributo chave de outro termo. o mnimo e o mximo em {}, se no especificados, sero 0 e infinito, respectivamente. Nome = primeiro_nome + (nome_intermediario) + ultimo_nome o nome_intermediario opcional (entre parnteses). ### Engenharia de Software Ciclo de vida do projeto Justificativas de se ter um ciclo de vida de projeto: definir as atividades a serem executadas em um projeto de desenvolvimento de sistemas; introduzir consistncia entre os projetos de desenvolvimento de sistemas da organizao; introduzir pontos de verificao para controle gerencial de decises. - Ciclo de vida do projeto clssico: implementao bottom-up e a insistncia na progresso linear e sequncial entre uma fase e outra. Na implementao bottom-up, primeiro se testam os mdulos, depois os subsistemas e depois os sistemas. Com isso, os erros mais srios s sero encontrados no final e a depurao dos erros tende a ser mais difcil. - Ciclo de vida do projeto estruturado: se caracteriza pela execuo paralela das suas atividades. - Ciclo de vida do projeto semi-estruturado: se caracteriza pela implementao topdown e o uso do projeto estruturado.

A implementao top-down se caracteriza pela codificao e pela fase de testes em mdulos de alto nvel primeiro. Depois disso que os mdulos de baixo nvel vo ser codificados e testados. ### Engenharia de software Prottipos Prototipagem uma abordagem que gera um prottipo baseado em requisitos iniciais do sistema. A idia que o retrabalho seja menor nas fases posteriores. - ele serve para identificar novos requisitos ou refinar os j existentes. - no processo de projeto do sistema, ele pode ser usado para explorar solues especficas de software e apoiar o projeto de interface com o usurio. Pode ser usado para verificar a viabilidade de um projeto proposto. - no processo de teste, ele pode ser usado para realizar testes completos com o sistema que ser entregue para o cliente. Benefcios do uso da prototipao: - usabilidade aprimorada do sistema. - adequao maior do sistema s necessidades do usurio. - qualidade do projeto aprimorada. - facilidade de manuteno aprimorada. - esforo de desenvolvimento reduzido. ### Engenharia de Software UML Pr-condies ou suposies: condies que precisam ser verdadeiras antes que o caso de uso possa ser executado, mas no so testadas pelo caso de uso. Exemplo: verificao do CPF antes de abrir uma conta no banco. Ps-condies: condies que se tornam verdadeiras aps o caso de uso ser executado. Invariantes: condies que so verdadeiras durante a execuo do caso de uso. Garantias mnimas: descrevem o que os atores podem esperar de um caso de uso, no importando o que acontea durante a execuo do caso de uso. Em UML, permitida herana mltipla. ### Engenharia de Software Requisitos Funcionais: declaraes de servios que o sistema deve oferecer, como o sistema deve reagir a entradas especficas e como deve se comportar em determinadas situaes.

Exemplos: o usurio pode pesquisar todo o banco de dados; o sistema deve oferecer visualizadores apropriados; a todo pedido, deve ser associado um identificador nico. No-funcionais: definem propriedades e restries do sistema; requisitos de processos podem especificar usos de linguagens de programao. Exemplos: velocidade do acesso ao banco de dados, tamanho do sistema, facilidade de uso, etc. De domnio: so derivados do domnio da aplicao e descrevem caractersticas do sistema e qualidades que refletem o domnio; se eles no forem satisfeitos, o sistema pode tornar-se no prtico. Um problema que os especialistas no domnio entendem to bem que no tornam explcitos todos os requisitos de domnio. Exemplo: "X deve ser calculado pela frmula: X = (N*Y + M*Z)/(L*K)." Entrevistas: determinam as necessidades de um novo sistema. Elas podem ser fechadas, em que o engenheiro de requisitos procura as respostas para um conjunto pr-definido de questes; ou abertas em que no h uma agenda pr-definida e o engenheiro de requisitos discute, de forma aberta, o que os usurios querem do sistema. Do usurio: declaraes em linguagem natural e tambm em diagramas sobre as funes que o sistema deve fornecer e as restries sob as quais deve operar. Do sistema: um documento estruturado que estabelece, detalhadamente, as funes e as restries de sistema. Escrito como um contrato entre o cliente e o desenvolvedor do software. De especificao de software: uma descrio detalhada do software que serve como base para projeto e implementao. Escrito para os desenvolvedores. ### Engenharia de software Modelos de ciclo de vida ou modelos de processo de software - Cascata ou clssico: s h um ciclo (modelagem e engenharia do sistema/informao -> anlise de requisitos -> projeto -> implementao (ou gerao de cdigos) -> testes -> manuteno); esse modelo executado de forma sequncial estrita, ento h possibilidade de ter pontos de controle bem definidos. O cliente s tem o produto final. O problema que as fases de requisitos, anlise e desenho devem ser bem dominadas, pois, teoricamente, no h retrocesso no modelo. Com isso surge um problema caso haja necessidade de revisar fases anteriores. O modelo em cascata tem a vantagem que s avana para a tarefa seguinte quando o cliente d validade e aceitao os produtos finais da tarefa atual. - Cascata com realimentao: o mesmo que cascata, porm, pra cada fase, h uma possibilidade de voltar pra fase imediatamente anterior para corrigir o problema citado no modelo de cascata puro. Porm a realimentao torna difcil gerenciar projetos baseados nesse modelo de ciclo de vida. ideal para projetos de curta durao como os projetos do PSP. conveniente, tambm, para miniprocessos, que so subprocessos bem

delimitados executados em um processo maior. um dos modelos suportados pela ferramenta de estimativas COCOMO II. ### Engenharia de software Modelos de ciclo de vida ou modelos de processo de software - Espiral (requisitos -> anlise -> desenho -> implementao -> testes -> requisitos...): modelo realizado em iteraes; cada nova iterao corresponde a um ciclo na espiral; neste modelo, o cliente tem releases do produto que so submetidos avaliao dos usurios. Liberaes podem ser escolhidas como produto final. A influncia do processo MBase foi muito importante para a difuso atual desse modelo. Este ciclo de vida permite que os requisitos sejam progressivamente definidos e apresenta alta flexibilidade. Esse modelo de vida aplicado em processos recentes que se dizem "geis", tal como o XP. Vantagens - O modelo em espiral permite que ao longo de cada iterao se obtenham verses do sistema cada vez mais completas, recorrendo prototipagem para reduzir os riscos. - Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em cascata, mas que incorpora um enquadramento iterativo que reflete de uma forma bastante realstica, o processo de desenvolvimento. Desvantagens - Pode ser difcil convencer grandes clientes (particularmente em situaes de contrato) de que a abordagem evolutiva controlvel. - A abordagem deste tipo de modelo exige considervel experincia na avaliao dos riscos e fia-se nessa experincia para o sucesso. Se um grande risco no for descoberto, podero ocorrer problemas. - Este tipo de modelo relativamente novo e no tem sido amplamente usado. - importante ter em conta que podem existir diferenas entre o prottipo e o sistema final. O prottipo pode no cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente algumas facetas do sistema a desenvolver. - O modelo em espiral pode levar ao desenvolvimento em paralelo de mltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso necessrio o uso de tcnicas especficas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados. As atividades do modelo espiral so: - planejamento: determinao de objetivos, alternativas e restries. - avaliao de alternativas e riscos: executa-se uma anlise de risco. Prototipao uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitvel, pode parar o projeto. - desenvolvimento do software: pode-se considerar o modelo cascata. - avaliao feita pelo cliente. ### Engenharia de software

Modelos de ciclo de vida ou modelos de processo de software - Prototipagem evolutiva: a espiral usada, no para desenvolver o produto completo, mas para construir uma srie de verses provisrias chamadas de prottipos. Nela, o que se obtm ao final de cada iterao no um produto completamente funcional, ao contrrio do modelo em espiral. - Entrega evolutiva (requisitos -> anlise -> desenho arquitetnico -> desenho detalhado -> implementao -> testes -> desenho detalhado...): as atividades de especificao do problema e de desenho arquitetnico so executadas em cascata e as atividades restantes so executadas em espiral. O problema a realizao do desenho arquitetnico, pois ele deve manter-se ntegro ao longo dos ciclos de liberaes. Era adotado no processo Praxis. ### Engenharia de software Modelos de ciclo de vida ou modelos de processo de software - Modelo Quase-espiral: modelo intermedirio entre o espiral e o de entrega evolutiva. Existe uma fase de iniciao, na qual feita, pelo menos, uma definio mnima dos requisitos do produto para delimitar seu escopo e uma fase de transio na qual o produto completo implantado em seu ambiente definitivo. o modelo usado de fato pelo MBase, que referncia para muitos processos adotados entre os quais, o RUP e o Praxis. ### Engenharia de software Processos de software Processo Unificado (UP): processo iterativo e adaptativo; o ciclo de vida iterativo baseado em refinamentos e incrementos sucessivos a fim de convergir para um produto final e pode ser considerado um mini projeto de durao fixa contendo suas prprias anlises de requisitos, projeto, implementao e testes; o incremento baseado em experincias obtidas nas iteraes anteriores e do feedback dos usurios; em cada iterao escolhido um conjunto pequeno de requisitos, os quais so rapidamente projetados, implementados e testados pelo usurio; os usurios podem aprovar ou criticar, sendo que essas crticas no so consideradas erros e, sim, um modo de chegar no que o usurio quer de forma rpida, melhorando a compreenso dos requisitos e se o projeto est no caminho certo. Com isso, tem-se um progresso visvel desde o incio, um sistema que atenda as necessidades reais do usurio, a complexidade administrada, sendo que no existem passos longos e o aprendizado obtido em uma iterao pode ser usado para melhorar o processo de desenvolvimento. Os papis do processo unificado: analista, desenvolvedor, testador, gerente. Analista:

Analista de Sistemas, Designer de Negcios, Revisor do Modelo de Negcios, Analista do Processo de Negcios, Revisor de Requisitos, Especificador de Requisitos, Analista de Teste, Designer de Interface de Usurio. Desenvolvedor: Designer de Cpsula, Revisor de Cdigo, Designer de Banco de Dados, Implementador, Integrador, Arquiteto de Software, Revisor de Arquitetura, Revisor de Design, Designer, Designer de Teste. Testador: Testador. Gerente: Engenheiro de Processo, Gerente de Projeto, Gerente de Controle de Mudana, Gerente de Configurao, Gerente de Implantao, Revisor do Projeto, Gerente de Testes. ### Engenharia de Software As fases so do UP. - Concepo: onde requisitos no devem ser detalhados, a ideia ter uma viso inicial do problema, estimar de forma vaga o esforo e os prazos e determinar se o projeto merece uma anlise mais profunda. - Elaborao: feita de forma iterativa sendo que todos os (ou a grande maioria dos) requisitos so detalhados, comeando pelos de maior risco e valor arquitetural. Estes so implementados e servem como base de avaliao junto ao usurio e desenvolvedores para o planejamento da prxima iterao; em cada iterao, pode haver um seminrio de requisitos, onde os antigos so esclarecidos de uma forma melhor e os novos so detalhados. - Construo: implementao iterativa dos elementos restantes de menor risco e mais fceis. - Transio. ### Engenharia de Software As caractersticas centrais do UP so: - dirigido por casos de uso (associam todos os workflows de forma conjunta); - centrado na arquitetura (desenvolvimento dos casos de uso baseado em uma arquitetura global definida nas fases iniciais) - Iterativo (realizado por repetio de etapas similares) - Incremental (cada iterao representa nova funcionalidade ao produto) O processo unificado de software centrado na arquitetura e orientado por casos de uso, o que sugere um fluxo de processo iterativo e incremental. Um Modelo de Domnio no PU, como o mostrado na Figura 9.3, uma descrio de coisas em uma situao real do domnio de interesse, no de objetos de software, tais como classes Java ou C#, ou objetos de software com responsabilidades.

### Engenharia de software Processos de software PSP (Personal Software Process): uma srie de processos pessoais, sendo que os projetos devem ser realizados seguindo rigorosamente esses processos. Tem como objetivo ajudar no controle, gerenciamento e melhoria da forma pessoal de desenvolvimento de software. O PSP auxilia os engenheiros de software a organizar e planejar seus trabalhos, acompanhar seu desempenho, gerenciar os defeitos de software e analisar/melhorar os prprios processos pessoais de desenvolvimento de software. As fases do PSP so 4, subdivididas em 7: - PSP 0 e 0.1: o principal objetivo coletar os dados do processo inicial e comear o registro de tempo e defeitos, a fim de compreender cada passo e ver como os mtodos podem auxiliar a melhorar a qualidade e a produtividade, alm de criar uma base de informaes que ser til nos projetos futuros. - PSP 1 e 1.1: enfoca o planejamento e gerenciamento do projeto, introduzindo estimativas de esforo e tamanho, alm do planejamento e acompanhamento de cronogramas. Nesta fase, o engenheiro compreende o tamanho do software e o tempo de desenvolvimento. - PSP 2 e 2.1: enfoca o gerenciamento da qualidade, introduz conceitos de preveno de defeitos, por meio da reviso de cdigo e de projeto. - PSP 3: prepara o engenheiro para utilizar o PSP em grandes projetos, introduzindo conceitos. A qualidade e a produtividade no so sacrificados, pois inserido um limite de tamanho e uma estratgia de desenvolvimento cclico. Os programas grandes so decompostos em partes menores para o desenvolvimento e posterior integrao. ### Engenharia de software Processos de software TSP (Team Software Process): usa um modelo em espiral; tipicamente so executados 3 ciclos de desenvolvimento de um produto; os participantes so organizados de tal forma que cada desenvolvedor desempenhe um ou dois papis gerenciais; os papis suportados podem ser: gerentes de desenvolvimento, de planejamento, de qualidade, de processo e de suporte, alm de lder do time; o planejamento e o controle rigoroso de tamanhos, esforos, prazos e defeitos, caractersticos do PSP, continuam sendo utilizados; o TSP enfatiza algumas reas que correspondem ao nvel 2 do CMMI: gesto de requisitos, planejamento e controle de projetos, garantia da qualidade e gesto de configuraes; ### Engenharia de software Processos de software Rational Unified Process (RUP): em relao ao UP, ele tem uma estrutura diferente apesar de usar as mesmas fases e as mesmas caractersticas bsicas. As colees de atividas tcnicas so diferentes, e so chamadas de disciplinas. Comparado com o UP, o

RUP une as disciplinas de anlise e desenho em uma nica disciplina e acrescenta disciplinas adicionais de modelagem de negcios, implantao, gesto de configuraes, gesto de projetos e ambiente. Enquanto o UP um arcabouo abstrato, o RUP uma coleo de processos concretos, oferecido como uma vasta base de conhecimentos em hipermdia. Hoje em dia o RUP no pode ser considerado um processo nico, e sim uma plataforma que permite construir uma grande famlia de processos personalizados para muitos portes de projetos e muitas aplicaes diferentes. Essa plataforma utilizada pela ferramenta RMC (Rational Method Composer), ocupando, na verso 7.2, mais de 1 GB e 40.000 arquivos de material hipertexto. Na documentao oficial do RUP existe uma verso de "RUP for small projects", que uma configurao para projetos de menor porte. A prpria IBM afirma que no existe barreira para usar mtodos geis dentro do RUP. A fora dos mtodos mais "lights" (SCRUM e programao em pares) pode ser melhor observada durante a fase de construo. ### Engenharia de software Processos de software MBase: combina o modelo de cilo de vida em espiral com os princpios de negociao ganha-ganha e com o conceito de evitar choques entre modelos. Segundo este conceito, o processo deve garantir a consistncia entre os seguintes modelos: de produto (requisitos, arquitetura, cdigo), de processo (tarefas, atividades, marcos), de propriedade (custo, prazo, desempenho, confiabilidade) e de sucesso (todas as partes interessadas ganham, viso de negcio). Enterprise Unified Process (EUP): uma extenso do RUP em que so includas duas fases: Produo e Aposentadoria e vrias disciplinas (a maioria, disciplinas de empreendimento). Est se tornando o processo de desenvolvimento padro dentro das comunidades orientadas a objeto e de software baseado em componente. ### Engenharia de software Processos de software Praxis: desenhado para suportar projetos realizados por pequenas equipes, com durao de seis meses a um ano. Com isso pretende-se que ele seja utilizvel para projetos de fim de curso de graduao ou similares, ou projetos de aplicaes de disciplinas de engenharia de software. ### Arquitetura de computadores Modos de endereamento:

I) imediato: nenhum acesso memria; rpido; o operando (campo de endereo da instruo) j vem como parte da instruo; intervalo de definio dos operandos limitado; | codop | operando | | + II) direto: o campo de endereo contm o campo do operando; um nico acesso memria; espao de endereamento limitado pelo campo; | codop | endereo | | Memria (operando) | + III) indireto: o campo de endereo aponta para uma posio de memria que contm o endereo do operando; vrios acessos memria; lento; espao de endereamento grande; | codop | endereo | | Memria (endereo do operando) | Memria (operando) | + IV) via registrador: operando se encontra em um registrador indicado no campo de endereo da instruo; no h acesso memria; execuo muito rpida; espao de endereamento muito limitado; | codop | endereo do registrador | | Registrador (operando) | + V) via registrador indireto: o operando est numa posio de memria apontada pelo registrador indicado no campo de endereamento; um acesso memria; | codop | endereo do registrador | | registrador (endereo do operando) | memria (operando) | +

VI) deslocamento: o operando se encontra na memria numa posio deslocada em relao ao endereo fornecido no campo do endereo; o campo de endereo pode ter 2 valores: A que guarda os valores de base e R que guarda o contedo do deslocamento (ou vice-versa); | codop | endereo R | endereo A | | | registrador (endereo base) | | | ----------------------------| | | memria | | -----------| + ### Engenharia de software Requisitos De acordo com a qualidade dos requisitos, um enunciado dos requisitos deve ser: correto, preciso, completo, consistente, priorizado (essencial, desejvel ou opcional), verificvel, modificvel e rastrevel (para trs - origem do requisito; para frente resultados do requisito). ### Engenharia de software Requisitos Prototipagem dos requisitos: no confundir prottipo evolucionrio que verso parcial do produto que satisfaz um subconjunto de requisitos do produto final e no pode ser considerado como releases (liberaes), pois no um produto completamente funcional. O prottipo descartvel construdo com a nica finalidade de demonstrar o que foi entendido ou resolvido em relao a algum aspecto da anlise ou do desenho do produto. So feitos para esclarecer dvidas ou responder certas perguntas cessando a a sua utilidade. Ele deve ser construdo rapidamente (poucas horas ou, no mximo, poucos dias). Pode ser construdo por diversos tipos de ferramentas. Exemplos de reas tratveis por prottipos so: - funes e interfaces de usurio: permite visualizar as interfaces (de forma abastrata) e a navegao entre elas. - relatrios textuais; - relatrios grficos; (este e o anterior = usa-se alguma ferramenta especfica) - organizao e desempenho de banco de dados; - clculos e algoritmos complexos; - partes de tempo de resposta crtica em sistemas de tempo real; - tecnologia no limite do estado-da-arte.

Um exemplo de prototipagem o desenho de alguma janela do programa com as funes que ela vai ter. ### Engenharia de software Requisitos Oficinas de requisitos: reunies estruturadas para definio conjunta de requisitos, envolvendo desenvolvedores, usurios e outros especialistas. Casos de Uso: so utilizados como representaes das funes completas especificadas, enquanto os atores representam os usurios ou outros sistemas que interagem com o produto (sistemas externos), sendo que cada ator representa uma classe de usurios de produto. Os atores modelam os papis. Servem para a compreenso do problema; para delimitar o sistema; e definir as funcionalidades oferecidas para o usurio (no h preocupao com a implementao). Eles so ponto de partida para: - determinar classes, atributos e operaes; - calcular o tamanho do software medido em PF; - desenhar o uso detalhado do produto; - escrever os procedimentos da documentao de usurio. * Para cada ator, deve-se incluir uma descrio sucinta das responsabilidades do respectivo papel. * Um caso de uso pode estar associado a mais de um ator (normalmente a associao entre eles sem direo). Os casos de uso podem ser agrupados em diagramas de pacotes em um sistema de software complexo. ### Engenharia de software Relacionamentos entre casos de uso podem ser de quatro tipos: generalizao, extenso e incluso. - Comunicao representa informaes de quais atores esto associados a que casos de uso. - Generalizao indica que um caso de uso mais especializado herda comportamentos de um caso de uso mais genrico, acrescentando e redefinindo detalhes. indicado por uma seta em direo ao genrico. Quando conveniente, o caso de uso herdeiro pode redefinir a sequncia do caso de uso herdado. Com relao ao ator, o herdeiro pode participar em casos de uso em que o ator herdado no participa. - Extenso indica que um caso de uso apresenta um comportamento adicional que, normalmente, no ocorre na execuo de outro caso de uso que estendido. denotado pelo esteritipo <<extend>>. - Incluso indica que uma atividade B, complexa, invocada a partir de um fluxo de comportamento A. Diz-se que A inclui B. representado pelo esteritipo <<include>>. Ela existe somente entre casos de uso. Casos de uso que so utilizados por outros casos de uso podem ser descritos separados e depois ser includo por outros casos de uso.

### Engenharia de software Diagramas Diagramas de contexto: o diagrama de casos de uso mais importante. Mostra as interfaces do produto com seu ambiente de aplicao, inclusive os diversos tipos de usurios e outros sistemas com os quais o produto deve interagir. Os diagramas de contexto devem indicar fontes e sorvedouros (sada) de dados. Nestes diagramas, os usurios, sistemas externos e outros componentes de um sistema maior devem ser representados por atores, enquanto os casos de uso representam as possveis formas de interao do produto com os atores. Devem ser mostrados somente os casos de uso que se comunicam diretamente com os atores, atravs de interfaces. _________________ ator1 --|---caso de uso1--|-- ator2 | | | | |-------|----| | | | ator3 --|--caso de uso2---|-- ator4 |_________________| Fluxos de eventos detalham, passo a passo, as funes representadas pelos casos de uso. Cada fluxo descreve um dos caminhos mais comuns que podem ser percorridos, seguindo-se os passos da funo representada pelo caso de uso. Existem, tambm, os fluxos alternativos que correspondem a situaes menos comuns (existem 3 tipos: especfico - inicia num ponto de extenso; regional - inicia entre 2 pontos de extenso; geral - inicia em qualquer lugar). Invocao de fluxos ou subfluxos representado por uma atividade que a UML denomina chamadas de comportamento. Fluxos documentam responsabilidades, ou seja, como as responsabilidades so divididas entre sistema e atores. Um fluxo bsico (caminho primrio) deve ter: - ator e evento que o mesmo dispara para iniciar o caso; - interao normal (sem disparo de exceo) entre o ator e o sistema; - descrio de como o caso termina. Pontos de extenso servem para inserir comportamentos adicionais. Podem ser privados ou pblicos. Se privados, so visveis somente dentro do caso de uso especificado. Se pblicos, so nos casos que estendem o caso onde foram definidos. ### Conceitos de orientao a objeto - Objeto uma unidade da qual queremos representar informaes no sistema. Eles possuem atributos. O conjunto de atributos denominado estado do objeto. Eles possuem operaes (mtodos ou servios) que manipulam o estado do objeto.

- Encapsulamento: os dados associados ao objeto no esto disponveis diretamente para os usurios do objeto, sendo que a nica maneira de manipul-los atravs de operaes. A implementao das operaes no so visveis aos usurios. - Independncia de dados: a implementao das operaes podem ser modificadas sem afetar os usurios dos objetos. A interface continua a mesma, apenas as aes internas so modificadas. - Passagem de mensagens uma chamada de operao sobre um objeto (Se A manda uma mensagem para B, ento A requisita uma tarefa de B - cuidado para no trocar). - Classes so categorias que agrupam objetos que tem caractersticas em comum. - Herana: classes com atributos e operaes iguais podem ser agrupadas em hierarquias. - Polimorfismo: aplicao da mesma operao a diferentes tipos de objetos. Pode existir, tambm, polimorfismo de classe onde uma referncia a uma classe abstrata pode representar classes concretas. Polimorfismo esttico: ocorre quando na definio da classe, criamos mtodos com o mesmo nome e argumentos diferentes. Dizemos que o mtodo est sobrecarregado (overloading). Polimorfismo dinmico: est associado ao conceito de herana e acontece quando uma subclasse redefine um mtodo existente na superclasse (overriding). ### Engenharia de Software - Diagramas de casos de uso: diagramas que descrevem os requisitos funcionais de um sistema. So comumente usados, tambm, para descrever funes completas de um sistema ou aplicao. Eles so descritos por atores que representam objetos externos, casos de uso e sistema modelado. Um ator conectado a um ou mais casos de uso por associaes. Tanto atores, quanto casos de uso podem possuir relacionamento de generalizao. A responsabilidade de cada passo de um caso de uso deve ser associada s classes que participam da colaborao. - Diagramas de classe: representam a estrutura esttica das classes de um sistema. Classes podem se relacionar uma com as outras atravs de associao (relacionamento que descreve uma sria de ligaes, onde a ligao definida como a semntica entre as duplas de objetos ligados), dependncia, especializao ou em pacotes. O diagrama de classes considerado esttico j que a estrutura descrita sempre vlida em qualquer ponto do sistema. No diagrama de classe, os atributos e operaes so mostrados tambm. - Diagrama de objetos: similar aos diagramas de classes. A diferena que o diagrama de objetos mostra os objetos que foram instanciados. como se fosse o perfil do sistema em um determinado momento da sua execuo. ### Engenharia de Software - Diagramas de estado: tipicamente um complemento para a descrio das classes. Ele mostra todos os estados possveis que os objetos de certa classe podem se encontrar e

mostra quais so os eventos do sistema que provocam tais mudanas. Os diagramas de estado no so escritos para todas as classes do sistema. Somente para aquelas que possuem um nmero definido de estados conhecidos. Possuem um ponto de incio e vrios de finalizao. Um ponto de incio mostrado como um crculo preenchido e o ponto de finalizao mostrado como um crculo em volta de um outro crculo menor preenchido. Um estado mostrado como um retngulo com os cantos arredondados. As transies so mostradas como uma linha e uma seta no final dessa linha indicando a transio. Uma transio de estado possui um evento ligado a ela. Se a transio no possuir um evento ligado a ela, a mesma ocorrer quando a ao interna do cdigo do estado for executada. ### Engenharia de Software Diagramas de interao podem ser de dois tipos: diagramas de sequncia e diagramas de colaborao. - Diagrama de sequncia: mostra a colaborao dinmica entre os vrios objetos. Com ele, sabe-se das mensagens enviadas entre os objetos. Mostra a interao dos objetos, alguma coisa que acontecer em algum ponto especfico da execuo do sistema. Diagramas de sequncia possuem dois eixos: vertical onde mostra o tempo; horizontal onde mostra os objetos envolvidos na sequncia de uma atividade. Seta slida significa que um objeto foi criado ou destrudo. D nfase na sequncia dos objetos. S necessrio referenciar os objetos que esto envolvidos na sequncia. - Diagrama de colaborao: d nfase nos objetos e seus relacionamentos. Pode conter objetos ativos que executam paralelamente com outros. As setas de mensagens mostram o fluxo entre eles. As mensagens so nomeadas. ### Engenharia de Software - Diagramas de atividade: capturam aes e seus resultados. uma variao do diagrama de estado com a diferena de capturar aes e seus resultados em termos das mudanas de estados dos objetos. Mostra como um grupo de aes relacionadas pode ser executado e como elas vo afetar os objetos em torno delas. - Diagramas de componente: mostram o lado funcional do sistema. Mostram as relaes entre seus componentes e a organizao dos seus mdulos. Representam a estrutura do cdigo gerado. O componente em UML mostrado com uma elipse e dois retngulos, do lado esquerdo, ligados por uma seta (podem ser somente dois retngulos). A dependncia entre os componentes mostrada por uma linha tracejada. ### Banco de dados Varivel de relao = a tabela em si. Varivel de relao bsica = atributo no primrio da tabela.

Varivel de relao derivada = chave estrangeira da tabela. ### Banco de dados Chave candidata so as chaves que podem ser a chave primria, isto , que contm valores nicos. So superchaves mnimas. Chave primria a chave candidata escolhida. Chave estrangeira a chave que vai referenciar a chave primria em outra tabela. Superchave o conjunto de um ou mais atributos que, tomados coletivamente, nos permitem identificar, de forma nica, uma entidade em um conjunto de entidades. Dependncia trivial X -> Y significa que Y est contido em X. Caso contrrio, notrivial. X -> Y significa que os valores de Y so determinados (ou dependem) pelos valores de X. Fecho (closure) de um conjunto de dependncias funcionais F so todas as DF's que podem ser inferidas a partir de F. ### Engenharia de Software Classes de anlise no fluxo de trabalho de anlise: representam um primeiro modelo conceitual para elementos no sistema que possuam responsabilidades e comportamento. Elas representam as classes prototpicas do sistema e elas so um primeiro passo nas principais abstraes que o sistema deve tratar. Definem responsabilidades. Raramente operaes. As classes de anlise podem ser estereotipadas como classes de fronteira, classes de controle e classes de entidade. Os esteretipos, alm de fornecer orientaes mais especficas do processo para localizar as classes, so um modelo de objetos poderoso, pois as mudanas no modelo tendem a afetar somente uma rea especfica. Ao realizar a anlise de um caso de uso, possveis falhas e omisses no mesmo se tornam mais perceptveis, tratando-se, portanto, de uma oportunidade para refinar o modelo de casos de uso. As classes de anlise so identificadas, primeiramente, na Fase de Elaborao, conforme os Casos de Uso so analisados. Algumas Classes de Anlise podem ser identificadas to tarde quanto a Fase de Construo, para Casos de Uso que no so analisados at a Fase de Construo. Um designer responsvel pela integridade da classe de anlise, garantindo que: - Ela completa e logicamente consistente. - Todas as informaes (consulte as propriedades acima) foram capturadas e esto corretas. No aconselhvel gastar muito tempo mantendo as classes de anlise em um sentido formal. Pode-se perder muito tempo refinando um modelo que altamente descartvel. As classes de anlise raramente sobrevivem no design inalterado.

### Engenharia de Software Tipos de classe de anlise. Classe de fronteira ou de limite: classes que realizam interface com o usurio; classes que realizam interface com outros sistemas; classes que realizam interface com dispositivos externos. Classe de controle: so classes coordenadoras que representam um comportamento do sistema; so encontradas analisando-se o comportamento do sistema a partir dos casos de uso. Classe de entidade: modelam informaes persistentes que iro compor o banco de dados do sistema; so manipuladas por classes de controle; oferecem e recebem informaes das classes limites; representam elementos chaves gerenciados pelo sistema. ### Engenharia de Software Processo unificado: - Cada etapa gera um produto executvel. - O modelo de casos de uso desenvolvido em vrios incrementos onde as iteraes iro adicionar novos casos de uso e/ou adicionar detalhes nos j existentes. - Na fase de concepo, os casos de uso mais importantes so identificados. A maioria dos outros ficam para a fase de elaborao. Aproximadamente 80% so identificados ao final da elaborao, mas somente 5% a 10% so implementados nesta fase. - Os requisitos que sobram so implementados na fase de construo. - Na fase de transio, quase no h requisitos a serem capturados a no ser que ocorra mudana nos mesmos. ### Engenharia de Software Processo unificado (fluxo de trabalho de anlise): - O produto do fluxo de anlise o modelo de anlise. - O modelo de anlise tem a funo de refinar os requisitos especificados no fluxo anterior atravs da construo do diagrama de classes. - O modelo de anlise fornece mais poder expressivo e formalismo, como diagramas de estado e de interao. - O fluxo de anlise tem maior importncia na fase de elaborao e isso contribui para uma arquitetura estvel e facilita o entendimento detalhado dos requisitos. - O modelo de anlise cresce medida que os casos de uso so analisados. - Para cada iterao, selecionado um conjunto de casos de uso. Na prxima, outro conjunto selecionado e adicionado ao conjunto anterior. - O sistema construdo como uma estrutura de classes de anlise e relacionamentos entre elas. ### Engenharia de Software

Processo unificado (fluxo de trabalho de anlise): - A arquitetura do sistema pode auxiliar na identificao de novas classes e a reutilizao das existentes. - Cada classe de anlise possui um ou mais papis na descrio de um caso de uso e estes papis especificam responsabilidades, atributos, ou qualquer coisa que sirva para detalhar um caso de uso. - Ao estruturar os requisitos do sistema, o modelo de anlise fornece uma estrutura com foco na manuteno dos mesmos. Esta estrutura tambm serve de entrada para os fluxos de projeto e implementao. - O modelo de anlise pode ser visto como o primeiro passo para o desenvolvimento do projeto. - A preservao da estrutura do modelo de anlise permite uma fcil manuteno, uma fcil recuperao mediante mudana de requisito. - O modelo de anlise no trata de problemas que sero solucionados no modelo de projeto ou implementao. - A estrutura do modelo de anlise nem sempre deve ser preservada, mas sim transformada durante o projeto e implementao do sistema. - A razo para isso o fato de o projeto considerar a plataforma de implementao do sistema como linguagens de programao, SO, etc. - Visando a diminuio de custo e o melhor aproveitamento de prazos, a arquitetura deve ser alcanada modificando-se o modelo de anlise durante a transio para o modelo de projeto. ### Engenharia de Software Processo unificado (fluxo de trabalho de projeto): - Neste fluxo, o sistema moldado e sua forma definida de maneira a suprir as necessidades especificadas pelos requisitos. - Define um modelo de projeto que construdo com base no modelo de anlise. - Descreve o sistema em um nvel fsico (diferente do modelo de anlise que descreve o sistema em nvel conceitual). - A principal funo deste fluxo obter uma compreenso detalhada dos requisitos, levando-se em considerao fatores como linguagens, SO, tecnologias de banco de dados, etc. - O fluxo de projeto tem seu enfoque no fim da fase de elaborao e o incio da fase de construo. - Neste fluxo, os casos de usos so realizados utilizando diagramas de classe, de interao e de estados com o intuito de capturar os requisitos de implementao. Tambm pode usar diagramas de objeto. ### Engenharia de Software Processo unificado (fluxo de trabalho de projeto): - O modelo de projeto funciona como uma abstrao da implementao do sistema. - O fluxo de anlise se interessa pelo que o sistem tem que fazer. O fluxo de projeto se interessa em como ele tem que fazer. - O projeto pode dividir o sistema em subsistemas visando a organizao dos artefatos do modelo de projeto e partes mais gerenciveis.

- Um subsistema pode ser composto de classes de projeto, realizaes de caso de uso, interfaces e outros subsistemas. - Um subsistema deve ser coesivo e tem que depender, no mnimo, de um outro subsistema. - A vantagem de se trabalhar com subsistemas no fluxo de projeto que estes podero ser projetados separadamente por diferentes equipes de desenvolvimento em diferentes nveis do projeto. ### Engenharia de Software Processo unificado (fluxo de trabalho de implementao): - baseado no fluxo de projeto. - Implementa o sistema em termos de componentes (cdigo fonte, executvel, etc). - A maior parte da arquitetura do sistema definida durante o projeto. - O modelo de implementao se limita: - planejar as integraes do sistema em cada iterao. Isso faz com que o sistema seja implementado como uma sucesso de etapas pequenas e gerenciveis. - implementar os subsistemas encontrados durante o projeto. - testar as implementaes e integr-las, antes de envi-las ao fluxo de teste. - Este fluxo tem maior importncia na fase de construo. - O cdigo gerado durante a implementao deve ser simples traduo das decises de projeto em uma linguagem especfica. ### Engenharia de Software Processo unificado (fluxo de trabalho de teste): - Os testes so desenvolvidos com base no produto do fluxo de implementao. - Os componentes executveis so testados para serem disponibilizados para os usurios. - O principal propsito realizar os testes e analisar o resultado. - Componentes que tiverem defeitos voltaro para os fluxos anteriores (projeto e implementao) para correo. - O teste de um sistema primeiramente empregado durante a fase de elaborao, quando a arquitetura do sistema definida, e durante a fase de construo quando o sistema implementado. - Um planejamento inicial pode ser feito durante a fase de concepo. ### Engenharia de Software Processo unificado (fluxo de trabalho de teste): - Na fase de transio, o fluxo de testes se limita ao conserto de defeitos encontrados durante a utilizao inicial do sistema. - O produto do fluxo de teste o modelo de teste. Primeiramente ele descreve como os testes so feitos. - O modelo de testes pode descrever aspectos especficos do sistema. Por exemplo: se a interface do usurio til e consistente.

- O papel do fluxo de teste verificar se os resultados do fluxo de implementao cumprem os requisitos estipulados pelos clientes e usurios, para que possa ser decidido se o sistema necessita de revises ou se o processo de desenvolvimento pode continuar. ### Engenharia de Sofware RUP - Disciplina de Modelagem de Negcio Ela serve para entender como funciona a organizao alvo; quais os problemas pelos quais ela passa (identificando uma possvel melhoria); assegurar que os clientes tenham o mesmo entendimento da empresa alvo; entender como o software vai se adaptar empresa e gerar o contedo para a fase de requisitos do sistema para ajudar a organizao e seus processos. Sem a disciplina de modelagem de negcio, a disciplina de requisito pode ser prejudicada. Obs.: ela no obrigatria pelo RUP, mas fortemente recomendada. Work products gerados nessa fase: business vision (viso de negcio), business architecture document (documento de arquitetura de negcio), supplementary business specification (especificao de negcio suplementar), business rules (regras de negcio) e business glossary (glosrio de negcio). Roles envolvidas na disciplina: business process analyst, business architect, business designer and technical reviewer. ### Engenharia de Sofware RUP - Disciplina de Requisitos Estabelece e mantm concordncia com os clientes e outros envolvidos sobre o que o sistema deve fazer; oferece aos desenvolvedores uma viso melhor dos requisitos do sistema; define escopo do sistema; fornece uma base para planejar o contedo tcnico das iteraes; fornece uma base para estimar o custo e o tempo de desenvolvimento do sistema; define uma interface de usurio para o sistema focado nas necessidades e metas dos usurios. Obs.: obrigatrio pelo RUP. Work products gerados nessa disciplina: vision (viso), glossary (glossrio), requirements management plan (plano de gerncia de requisitos), software requirements (requisitos de software), software requirements specification (especificao de requisitos de software), stakeholder requests (pedidos de stakeholder), storyboard, supplementary specifications (especificaes suplementares), use-case model (modelo de caso de uso) e requirements attributes (atributos de requisitos). Roles envolvidas na disciplina: system analyst, requirements specifier. ###

Engenharia de software RUP - Disciplina de Anlise e Design O modelo de anlise permite uma melhor compreenso dos requisitos e seu domnio antes da realizao do modelo de design da aplicao. aplicado em projetos maiores onde uma transio direta para o modelo de design no vivel devido complexidade identificada nos requisitos. J o modelo de design representa a soluo tecnolgica para o problema exposto pelo modelo de anlise e se aplica mesmo em projetos pequenos. Este modelo deve ser criado antes da implementao do software evitando retrabalhos neste processo. A finalidade da disciplina de anlise e design transformar os requisitos em modelos de anlise sob o qual o sistema ser construdo; desenvolver e evoluir uma arquitetura estvel e robusta para o sistema e adaptar o design com foco na implementao. Work products gerados na disciplina: analysis model (modelo de anlise), design model (modelo de design), architectural proof-of-concept (prova de conceito arquitetural), data model (model de dados), reference architecture (arquitetura de referncia), software architecture document (documento de arquitetura de software), navigation map (mapa de navegao) e service model (modelo de servio). Roles: software architect, system analyst, designer, user interface designer e database designer. ### Engenharia de software RUP - Disciplina de Implementao Definir a organizao do cdigo em termos de subsistema de implementao organizados em camadas; implementar classes e objetos em termos de componentes; testar os componentes desenvolvidos como unidades e integrar, ao sistema, os resultados produzidos. ### Engenharia de software RUP - Disciplina de testes Enfatiza a qualidade do produto realizada atravs de vrias prticas: localizar e documentar defeitos; avisar de forma geral sobre a qualidade observada no software; validar as suposies feitas nas especificaes de design e requisito; validar as funes do software conforme projetadas e verificar se os requisitos foram implementados de forma adequada. ### Engenharia de software RUP - Disciplina de Implantao

Descreve as atividades que garantem que o produto de software ser disponibilizado para os seus usurios finais. ### Engenharia de software RUP - Disciplina de Gerenciamento de configurao e mudana Serve para controlar os inmeros artefatos produzidos pelas pessoas que trabalham no projeto. O controle ajuda a evitar confuses e garante que os artefatos no entrem em conflito. Gerencia mudanas e seu impacto no desenvolvimento de software. Um artefato pode entrar em conflito por algum dos seguintes problemas: - atualizao simultnea do mesmo artefato por dois ou mais membros; - notificao limitada a no todos os desenvolvedores que estejam mexendo em algum artefato. - vrias verses: a maioria dos programas de grande porte desenvolvida em releases evolutivas. O grupo responsvel por aprovar ou rejeitar mudanas nas linhas base do projeto o CCB (Chance Control Board - Comit Central de mudana CCM). Ele formado por partes interessadas responsveis pela reviso, avaliao, aprovao, atraso ou rejeio de mudanas feitas num projeto, com registro de todas as mudanas ou recomendao. ### Engenharia de software RUP - Disciplina de Gerncia de Projeto Ela fornece um framework para gerenciar projetos intensivos de software; ela fornece diretrizes prticas para planejar, montar a equipe, executar e monitorar os projetos; fornececer um framework de gerenciamento de risco. Esta disciplina NO tenta cobrir alguns aspectos do gerenciamento do projeto: gerenciamento de pessoas (contratao, treinamento, ensino); gerenciamento de oramentos (definio, alocao); gerenciamento de contratos com fornecedores e clientes. Esta disciplina enfatiza aspectos importantes do desenvolvimento iterativo: gerenciamento de risco; planejamento de um projeto iterativo, por meio da escolha do ciclo de vida e de uma iterao particular; e monitora o progresso de um projeto iterativo, mtrica. ### Engenharia de software RUP - Disciplina de Ambiente Concentra-se nas atividades necessrias configurao do processo para um projeto.

Ela descreve as atividades para o desenvolvimento das diretrizes de suporte de um projeto; a meta das atividades desta disciplina oferecer, organizao, o ambiente de desenvolvimento de software (os processos e as ferramentas) que dar suporta equipe de desenvolvimento. ### Estruturas de Dados vore binria de pesquisa: os ns da esquerda so menores do que a raz. Os ns da direita so maiores do que a raz. Mtodos de visita: pr-ordem (visita, esquerda, direita), in-ordem (simtrica) (esquerda, visita, direita), ps-ordem (esquerda, direita, visita). ### Engenharia de software UML Diagramas estruturais enfatizam nos elementos que devem existir no sistema a ser modelado. So eles: de classes, de componentes, de objetos, de estrutura composta (UML 2.0), de implantao e de pacotes. Diagramas comportamentais enfatizam na dinmica do sistema a ser modelado. So eles: de atividades, de casos de uso e de estados. Diagramas de interao so um subtipo de diagramas de comportamento, que enfatizam o controle de fluxo de aes e dados do sistema modelado. So eles: de comunicao, de sequncia, de tempo e de viso de interao. ### Banco de dados Vises As vises so tabelas virtuais criadas pelos banco de dados. Elas podem existir fisicamente falando e sero chamadas de materializadas. Os objetivos das vises so: - disponibilidade: simplificar e centralizar a definio de consultas frequentes, evitando erros e melhorando a produtividade de usurios; - confidenciabilidade: restringir acesso a projees e/ou selees de tabelas reais; - integridade: evitar alteraes indevidas no BD. sintaxe: CREATE VIEW visao AS SELECT ...; Para eliminar uma viso: DROP VIEW visao; Existem duas formas de o SGBD implementar uma viso: - Modificaes de Consultas (QM): a viso criada a cada consulta. Diminui o desempenho, mas no h necessidade de atualizao da viso para garantir consistncia dela em relao s tabelas-base.

- Materializao de Vises (VM): a viso criada na primeira consulta. Aumenta o desempenho, porm h necessidade de que as atualizaes nas tabelas-base sejam propagadas. Nas atualizaes de vises podem ocorrer problemas de ambiguidade. Uma viso pode ter sido criada a partir da unio de duas tabelas. Neste caso, no h certeza da tabela que ser atualizada. Por isso, geralmente, no permitida atualizao. Uma viso definida em uma nica tabela atualizvel se os atributos dela contiverem a chave primria, bem como todos os seus atributos com restrio NOT NULL que no contiverem os valores padres especificados. Uma insero pode ser feita sem conter a chave primria desde que a opo AUTO_INCREMENT tenha sido usada. As vises definidas, usando-se as funes de agrupamento e agregado, no so atualizveis. Na SQL, a clusula WITH CHECK OPTION deve ser acionada se ela puder ser atualizada. Isso faz com que o sistema cheque a capacidade de atualizao da viso. - As colunas modificadas das vises no so afetadas pelas clusulas GROUP BY, HAVING ou DISTINCT. - Para haver atualizao, as colunas no podem ser derivadas de qualquer modo, como pelo seguinte: avg, count, sum, min, max, grouping, stdev, stdevp, var e varp. ### Engenharia de Software: Fluxos alternativos. Por que representar um fluxo alternativo separadamente do fluxo bsico? R.: - Fluxos alternativos so opcionais e descrevem comportamentos que esto fora do comportamento normal esperado; - Nem todos representam funcionalidades essenciais no valendo o esforo de desenvolvimento; - Fluxos alternativos permitem adicionar funcionalidade do fluxo bsico de maneira incremental ou remover funcionalidade medida que o tempo e o dinheiro se esgotam. ### Banco de dados SQL SEQUENCES: um objeto de banco de dados que gera nmeros em uma ordem sequncial. Aplicaes geralmente usam estes nmeros para campos que necessitam de valores nicos, tais como as chaves primrias. As caractersticas das SEQUENCES so: - esto disponveis para todos os usurios do banco de dados; - so criadas usando comandos de SQl; - tem um mnimo e mximo de -2^63 e 2^63 - 1 (padres de 0 e 2^63 - 1); - uma vez retornado um nmero, ele no ser mais retornado; - geralmente so usadas para gerar valores para uma s sequncia; - incrementam por x unidades (default = 1). CREATE SEQUENCE bla INCREMENT BY 1 START WITH 100;

DROP SEQUENCE bla; INSERT INTO cliente (cliente_num, nome, endereo) VALUES (bla.NEXTVAL, 'Paulo', 'Rua Tal, 444'); O valor atual CURVAL referente conexo, no em relao ao objeto criado. Se um usurio A chama o NEXTVAL e obtm 1 e um B faz o mesmo e obtm 2, o CURVAL de A 1, mesmo o objeto j tendo gerado o 2 para outro usurio. ### Engenharia de Software Requisitos Uso de PDL para especificar os requisitos. PDL = Linguagem de descrio de programa. Derivada de uma LP. Apropriada para duas situaes: - quando uma operao especificada como uma sequncia de aes e quando a ordem importante; - quando interfaces de software e hardware tiverem de ser especificadas. Os requisitos no so documentos de projeto. Especificam o que deve fazer. No como deve ser feito. ### Banco de dados Triggers So procedimentos ativados pelo SGBD em resposta a algum evento que ocorre no BD. No BD relacional, so ativados em resposta aos comandos INSERT, UPDATE e DELETE e, tambm, em operaes de ABORT, COMMIT. Podem ser utilizados para: - manter restries de integridade complexas; - efetuar auditoria, registrando as alteraes efetuadas e quem as efetuou (log seletivo); - garantir restries de acesso. Triggers podem ser disparadas antes ou depois de um evento especficos com as clusulas BEFORE e AFTER. O INSERT e o DELETE "pedem" ON aps elas. UPDATE "pede" OF. Exemplo: CREATE TRIGGER trig1 AFTER INSERT ON T4 REFERENCING NEW AS newRow FOR EACH ROW WHEN (newRow.a <= 10) BEGIN INSERT INTO T5 VALUES(:newRow.b, :newRow.a); END trig1; Clusula WHEN booleana e usada somente para triggers de linha.

old = objeto que tem informao sobre o valor antigo das colunas depois de alguma alterao. new = objeto que tem informao sobre o valor novo das colunas depois de alguma alterao. (old e new s so possveis nos triggers.) INSTEAD OF = indica que o trigger ser executado ao invs do comando que o disparou. usado para vises. Os triggers so definidos em uma tabela: tabela de triggers. No podem ser chamados diretamente (precisam de um evento para cham-lo) e no permitem parmetros. So parte de uma transao (junto com as instrues). Com o ROLLBACK, ele ser desfeito. ### Banco de dados Transaes: conjunto de operaes de acesso ao banco de dados. Englobam operaes de insero, excluso, alterao ou recuperao. Propriedades da transao: ACID (DICA): atomicidade, consistncia, isolamento e durabilidade. -Atomicidade: as transaes devem ser atmicas. A transao ser executada totalmente ou no ser executada. -Consistncia: as regras de integridade dos dados so asseguradas. As transaes no podem quebrar as regras dos Bancos de Dados. - Isolamento: as transaes no sero interferidas por outras transaes concorrentes. Estas no podem ver etapas intermedirias daquelas. - Durabilidade: o que foi salvo no ser perdido. ### Banco de dados Transaes autnomas So transaes invocadas por outra transao. Ela atua de forma independente da transao que a invocou. Ela no enxerga as operaes da transao que a invocou: Se a transao A insere uma tupla e chama a transao autnoma B, esta no consegue enxergar a tupla inserida. Na linguagem PL/SQL, o comportamento padro que os procedimentos A e B precisam ser executados com xito para que a transao seja feita com sucesso. Se B for uma transao autnoma, ento todas as operaes de B no tero ROLLBACK caso A (que invocou B) falhe. Isso feito atravs da Pragma AUTONOMOUS_TRANSACTION. ### Engenharia de Software EUP Extenso do RUP. Adiciona duas fases e 8 disciplinas.

Depois da fase de transio, vem as fases de produo e aposentadoria. Produo Objetivo: manter os programas teis e produtivos depois de implantados. Finaliza quando o sistema entra na aposentadoria e o suporte, para o sistema, termina. Ou outra verso o substitui. Aposentadoria Objetivo: remover, da produo, o release do sistema. Motivos para remoo: o produto tornou-se obsoleto; fim do suporte ao release; e substituio por um pacote de software. As atividades da aposentadoria so: - anlise compreensiva do sistema que est sendo aposentado para identificar seu acoplamento com outros sistemas; - um redesenho e retrabalho de outros sistemas existentes de forma que eles no precisem mais confiar no sistema que est sendo aposentado; - transformao dos dados legados via refatoramento de banco de dados porque eles no sero mais requeridos ou manipulados pelo sistema que est sendo aposentado; - arquivamento dos dados mantidos pelo sistema que no ser mais necessrio por outros sistemas; - gerncia de configurao do software removido de forma que ele possa ser reinstalado caso necessrio no futuro; - teste de integrao dos sistemas que foram mantidos para assegurar que eles continuaram funcionando com a aposentadoria do sistema. ### Engenharia de Software EUP Disciplina Operaes e suporte Tem como objetivos operar e dar apoio a um sistema de software em um ambiente de produo. Operar = manter o software rodando, a rede no ar, fazer backup e restore. Dar apoio = atender aos usurios (dvidas, problemas encontrados, solicitao de evoluo, correes) As disciplinas empresariais so: modelagem de negcio (no nvel empresarial), gesto de portflio, arquitetura empresarial, reuso estratgico, gesto de pessoas, administrao empresarial e melhoria no processo de software. ### Engenharia de Software EUP Disciplina modelagem de negcio empresarial

Realiza as mesmas atividades da modelagem de negcio do RUP, mas no nvel empresarial. Foca nos relacionamentos inter-projetos e o fator crtico de sucesso o relacionamento da equipe de TI com os stakeholders empresariais. ### Engenharia de Software EUP Disciplina gesto de portflio Seleo e gesto de projetos viveis de desenvolvimento de software tratando-os como um s. Visa aumentar a eficincia e a eficcia da TI dentro de uma organizao. Portflio de software: coleo de projetos de TI, em execuo ou propostos, alm dos sistemas j implantados. ### Engenharia de Software EUP Disciplina arquitetura empresarial - Compreende o ambiente onde todas as aplicaes da empresa esto implantadas; - Inclui redes, framework, configuraes de implantao, etc; - Difere da Arquitetura do Sistema no escopo: o arquiteto de sistemas empresariais trata de padres a serem usados por mltiplos sistemas. ### Engenharia de Software EUP Disciplina reuso estratgico Reuso entre projetos. S pode bem sucedido se for visto como investimento de longo prazo. O nvel mais fcil o reuso de cdigo. O nvel mais difcil o reuso via arquitetura empresarial. ### Engenharia de Software EUP Disciplina gesto de pessoas Melhorar a efetividade das pessoas que esto dentro da organizao de TI. Compreende organizar, educar, monitorar, fazer coaching e motivar as pessoas. ### Engenharia de Software

EUP Disciplina administrao empresarial Definir como a organizao cria, mantm, gerencia e implanta ativos fsicos e de informao de maneira segura. Define os papis de administrador de rede, de instalaes fsicas, de dados e informaes e de segurana. ### Engenharia de Software EUP Disciplina melhoria do processo de software Estende a disciplina Ambiente do RUP. Engloba o esforo de criar e dar suporte aos vrios casos de desenvolvimento da organizao de TI. ### Engenharia de Software RUP Viso (documento de viso): conjunto de descries sobre requisitos centrais pretendidos e que serve de base para os requisitos tcnicos mais detalhados. Ocorre no incio da fase de iniciao (concepo). ### Banco de dados Triggers. Aps fazer uma deleo, as tuplas deletadas ficam numa tabela especial chamada DELETED. Aps fazer uma insero, as tuplas inseridas ficam numa tabela especial chamada INSERTED. Aps fazer uma atualizao, as tuplas antigas ficam no DELETED e as novas ficam na INSERTED. Isso tudo somente durante a conexo. Se esta for finalizada, os valores de DELETED e INSERTED sero deletados. ### Banco de dados Atributo primrio: membro de alguma chave candidata de um esquema de relao R. ### Banco de dados SQL GRANT privilege_name ON object_name

TO {user_name |PUBLIC |role_name} [WITH GRANT OPTION]; D privilgio para usurio. - privilage_name pode ser ALL, EXECUTE, UPDATE, SELECT, DELETE, INSERT. - object_name nomes do objeto de banco de dados tais como tabelas, vises, sequncias e procedimentos de funes (lista separada por vrgula se for mais de um) - user_name nomes dos usurios que vo ganhar o privilgio (lista separada por vrgula se for mais de um) - PUBLIC garante acesso a todos os usurios. - role_name conjunto de privilgios agrupados. - WITH GRANT OPTION permite o usurio a dar privilgios a outros usurios. REVOKE privilege_name ON object_name FROM {user_name |PUBLIC |role_name} Tira os privilgios do usurio. ### Engenharia de software UML Relao entre classes 1) Associao simples: - estabelece uma relao semntica estrutural entre classes. Ex: uma Pessoa trabalha para uma Companhia, uma Companhia tem vrios Escritrios, etc. Representada por uma linha reta entre as duas classes. 2) Agregao: - estabelece uma relao todo-parte entre classes, sendo que a parte pode existir sem o todo. Ex: Carro e Roda. Uma Roda parte de um Carro, porm pode a Roda existe por si s fora do Carro. Voc pode por exemplo remover a roda de um carro para colocar em outro. Representada por uma linha tendo um losngo vazio na extremidade da classe que o todo. 3) Composio: -estabelece uma relao todo-parte entre classes, sendo que a parte NO existe sem o todo. Um objeto do lado parte s pode estar associado a um objeto do lado todo. Ex: Pedido e Itens de Pedido. Se voc destruir o Pedido, os Itens so destrudos junto, eles no tem sentido se no houver um Pedido. Representada por uma linha tendo um losngo preenchido na extremidade da classe que o todo.

### Engenharia de software Ferramentas para os processos: XPlanner: ferramenta de cdigo livre usada no auxiliando a fase de planejamento do XP. Rational RequisitePro: - captura aspectos textuais dos modelos de negcios; - captura e organiza os requisitos; - ajuda a escrever propriedades textuais dos casos de uso; Rational SoDA: - gera e mantm documentao dos modelos; - gerao automtica de documento de requisitos; - bom pra organizar o resultados de vrios fluxos de trabalho num s; - criao automtica de documentos e relatrios, extraindo e formatando informaes de outras ferramentas como o Rose e o Requisite Pro; Rational Rose: - produz modelos visuais sobre os modelos de negcios; - suporte automtico a atores e casos de uso; - mantm dependncias a elementos no modelo de design; Rational RealTime: - permite a execuo direta de um modelo de design; Defeitos em cdigo: Purify, Quantify, ClearQuest; ClearCase prov workspace; TestStudio uma srie de ferramentas para teste (Robot, LogViewer, TestManager, TestFactory). PerformanceStudio. DevelopmentStudio uma srie de ferramentas para teste (Purify, PureCoverage, Quantify). Na gerncia de configurao e mudana, tem-se: ClearCase, ClearQuest. ### Banco de dados Especializao entre entidades: gerao de subclasses com o intuito de estabelecer um conjunto de atributos especficos para cada subclasse e, tambm, estabelecer relacionamentos especficos entre as subclasses e outros tipos entidade (ou entre cada subclasse), coisa que no aconteceria com a superclasse em questo. Generalizao: definir uma entidade a partir de outras que compartilham atributos. Existem especializao definida por atributo (predicado) e especializao definida por usurio. Restrio de disjuno (Uma entidade pode ser membro de, no mximo, uma das subclasses. Representado pela letra D dentro do crculo), sobreposio (Uma entidade

pode ser membro de quaisquer subclasses. Representado pela letra O). Uma entidade pode ser derivada de mais de uma entidade. Nesse caso ela chamada de Restrio de totalidade (a entidade da superclasse , necessariamente, do tipo das subclasses. Indicado por uma seta dupla no crculo do diagrama) e parcialidade (a entidade da superclasse pode ser de outro tipo diferente das subclasses, indicado por uma seta simples). Deletar uma entidade de uma superclasse implica que ela deve ser excluda de todas as subclasses tambm. Inserir uma entidade em uma superclasse implica que ela deve ser inserida nas subclasses definidas por predicado para as quais a entidade satisfizer a definio por predicado. Inserir uma entidade em uma superclasse de especializao total implica que a entidade seja inserida em, pelo menos, uma das subclasses. ### Engenharia de software Gerncia de projetos - gerncia de integrao Engloba os processos necessrios para garantir que os vrios elementos do projeto estejam propriamente coordenados atravs da identificao, definio, combinao e, a sim, coordenao. Processos: - desenvolver o termo de abertura do projeto: processo de desenvolvimento de um documento que formalmente autoriza um projeto ou uma fase e a documentao dos requisitos iniciais que satisfaam as necessidades e expectativas das partes interessadas; - desenvolver o plano de gerenciamento do projeto: processo de documentao das aes necessrias para definir, preparar, integrar e coordenar todos os planos auxiliares; - orientar e gerenciar a execuo do projeto: processo de realizao do trabalho definido no plano de gerenciamento do projeto para atingir os objetivos do projeto; - monitorar e controlar o trabalho do projeto: processo de acompanhamento, reviso e regulao do progresso para atender aos objetivos de desempenho definidos no plano de gerenciamento do projeto; - realizar o controle integrado de mudanas: processo de reviso de todas as solicitaes de mudanas, aprovao de mudanas e gerenciamento de mudanas nas entregas, ativos de processos organizacionais, documentos de projeto e plano de gerenciamento do projeto; - encerar o projeto ou fase: o processo de finalizao de todas as atividades de todos os grupos de processos de gerenciamento do projeto para terminar formalmente o projeto ou a fase;

A necessidade do gerenciamento de integrao do projeto fica evidente quando processos distintos interagem. Exemplo: uma estimativa de custo necessria para um plano de contingncia envolve a integrao dos processos nas reas de conhecimentos de custos, tempo e riscos. Gerenciamento de integrao tambm inclui atividades necessrias para gerenciar documentos e assegurar consistncia no plano de gerenciamento de projeto e entregas. No h uma maneira nica de gerenciar um projeto. O gerente e a equipe deve sempre discutir todos os processos para determinar o nvel de execuo de cada processo para cada projeto. So exemplos de algumas atividades realizadas pela equipe de gerenciamento: - Analisar e entender o escopo. Isto inclui os requisitos do projeto e do produto, critrios, premissas, restries e outras influncias relacionadas ao projeto e como cada um ser gerenciado e discutido dentro do mesmo. - Entender como uma informao capturada e transform-la em um plano de gerenciamento de projeto usando uma abordagem estruturada como descrita pelo PMBOK. - Realizar as atividades para produzir as entregas do projeto. - Medir e monitorar todos os aspectos do progresso do projeto e tomar as medidas necessrias para atender os objetivos do mesmo. Termo de abertura do projeto: documento que inicia o projeto formalmente. Um gerente de projeto identificado e escolhido enquanto o termo de projetos est sendo feito e sempre antes do incio do planejamento. recomendado que ele participe do termo de abertura, uma vez que este supre o gerente com a autoridade para usar o recurso nas atividades do projeto. Entidades externas que autorizam um projeto: patrocinador, escritrio de projetos ou comit diretivo de portflio. Uma entrada da fase do termo de abertura do projeto a declarao do trabalho. Ela uma narrativa dos produtos e servios a serem fornecidos pelo projeto. Ela informa a necessidade de negcios, a descrio do escopo do produto e o plano estratgico. Outra entrada da fase do termo de abertura do projeto o business case que o documento que justifica o projeto. Nele estar a anlise de custo-benefcio. No caso de projetos com mltiplas fases, o business case pode ser revisado periodicamente para assegurar que o projeto est indo de acordo com os benefcios de negcios. Fatores ambientais podem influenciar o processo de desenvolvimento do termo de abertura do projeto. So eles: padres governamentais ou industriais, infraestrutura organizacional e condies do mercado. O plano de gerenciamento do projeto define como o mesmo ser executado, monitorado, controlado e encerrado. O contedo do plano de gerenciamento do projeto varia de acordo com a rea de aplicao e complexidade do mesmo. O plano de gerenciamento desenvolvido atravs de uma srie de processos integrados at o seu encerramento. Isto , ele elaborado

progressivamente atravs de atualizaes controladas e aprovadas pelo processo de Realizar o controle integrado de mudana. Orientar e gerenciar a execuo do projeto est definido no plano de gerenciamento do projeto. Nessa etapa acontece a execuo das atividades para realizar os objetivos do projeto; implementar os padres e mtodos planejados; gerar dados do projeto, tais como custo, cronograma, progresso tcnico e da qualidade e informaes sobre o andamento do projeto para facilitar previses. Monitorar e controlar o trabalho do projeto: nele tem monitoramento do incio ao fim do projeto para verificar melhorias no processo. O controle inclui a determinaes de aes corretivas ou preventivas ou o replanejamento e acompanhamento dos planos de ao para definir se as aes tomadas resolveram o problema. Est definida no plano de gerenciamento do projeto e compara o desempenho real do projeto com o plano de gerenciamento do projeto; avaliao do desempenho das medidas corretivas ou preventivas para saber se elas so recomendadas. O processo de realizar o controle integrado de mudanas conduzido do incio ao fim do projeto. Objetivos desta fase: fazer com que somente as mudanas aprovadas sejam implementadas; revisar, analisar e aprovar as solicitaes de mudana imediatamente j que uma deciso lenta pode afetar negativamente o tempo, custo ou viabilidade de mudana; gerenciar as mudanas aprovadas; revisar, aprovar ou rejeitar as aes corretivas e preventivas recomendadas; documentar o impacto completo das solicitaes de mudana. As mudanas podem ser solicitadas por qualquer um, podem ser verbais, porm h a necessidade de se registr-las. Realizar o controle integrado de mudanas envolve um comit de controle de mudana (CCM) responsvel pela aprovao ou rejeio das solicitaes. Solicitaes de mudana aprovadas podem requerer novas ou revisadas estimativas de custos, sequncias de atividades, datas de cronograma, requisitos de recursos e anlise de alternativas de respostas aos riscos. Essas mudanas podem requerer reajustes ao plano de gerenciamento de projeto ou a outros planos/documentos de gerenciamento do projeto. O nvel de controle de mudana depende da rea de aplicao, complexidade do projeto especfico, requisitos contratuais e o contexto e ambiento no qual o projeto executado. Um sistema de gerenciamento de configurao com controle integrado de mudanas fornece uma maneira padronizada, efetiva e eficiente de gerenciar (de maneira centralizada) as mudanas e linhas de base aprovadas dentro de um projeto. Na fase de encerramento do projeto, tem um passo sobre transferir os produtos, servios ou resultados do projeto para a prxima fase, produo e/ou operaes; tem, tambm, atividades para coletar registros do projeto ou da fase, auditor o sucesso ou fracasso, coletar lies aprendidas e arquivar informaes do projeto para o uso futuro da organizao. ### Engenharia de software Gerncia de projetos - gerncia de escopo

Engloba os processos necessrios para garantir que o projeto inclua todo o trabalho necessrio, e somente o trabalho necessrio, para ser completado com sucesso. Inclui o planejamento, definio, controle e verificao de escopo, alm de criar a WBS - Work breakdown structure (EAP - estrutura analtica do projeto). Este gerenciamento est relacionado principalmente com a definio e controle do que est e do que no est incluso no projeto. Processos: - coletar os requisitos: processo de definio e documentao das necessidades das partes interessadas para alcanar os objetivos do projeto; - definir o escopo: processo de desenvolvimento de uma descrio detalhada do projeto e do produto; - criar a EAP: processo de subdiviso das entregas e do trabalho do projeto em componentes menores e mais facilmente gerenciveis; - verificar o escopo: processo de formalizao da aceitao das entregas terminadas do projeto; - controlar o escopo: processo de monitoramento do progresso do escopo do projeto e escopo do produto e gerenciamento das mudanas feitas na linha base do escopo; No contexto do projeto, o termo escopo pode se referir a um deles: a) escopo do produto: as caractersticas que descrevem um produto, anlise ou resultado; b) escopo do projeto: o trabalho que precisa ser realizado para entregar um produto, servio ou resultado com as caractersticas e funes especificadas. Os processos, ferramentas e tcnicas de suporte para gerenciar o escopo variam de acordo com a aplicao e normalmente so definidos como parte do ciclo de vida do projeto. Os processos do gerenciamento do escopo so precedidos por um esforo de planejamento feito pela equipe de gerenciamento do projeto. Esse esforo parte do processo Desenvolver o plano de gerenciamento de projeto que produz um plano de gerenciamento do escopo fornecendo diretrizes sobre como o escopo do projeto ser definido, documentado, verificado, gerenciado e controlado. O plano de gerenciamento do escopo pode ser formal ou informal, detalhado ou conciso, dependendo das necessidades do projeto. A concluso do escopo do projeto comparada ao plano de gerenciamento do projeto. A concluso do escopo do produto comparada aos requisitos do produto. O sucesso do projeto diretamente influenciado pela ateno dada na captura e gerenciamento dos requisitos do projeto e do produto. Os requisitos incluem as necessidades quantificadas e documentadas, e as expectativas do patrocinador, cliente e outras partes interessadas. Estes requisitos precisam ser obtidos, analisados e registrados com detalhes suficientes para serem medidos uma vez que a execuo do projeto se inicie.

Os requisitos se transformam na fundao da EAP. O planejamento do custo, do cronograma e da qualidade so todos construdos com base nesses requisitos. O desenvolvimento dos requisitos comea com uma anlise da informao contida no termo de abertura do projeto (gerncia de integrao) e no registro das partes interessadas. Muitas organizaes os categorizam em requisitos do projeto e requisitos do produto. De projeto: requisitos de negcios, de gerenciamento do projeto, de entrega, etc. De produto: incluem informaes sobre os requisitos tcnicos, de segurana, de desempenho, etc. A preparao detalhada da declarao do escopo crtica para o sucesso e baseia-se nas entregas principais, premissas e restries que so documentadas durante a iniciao do projeto. Durante o planejamento, o escopo definido e descrito com maior especificidade conforme as informaes a respeito do projeto so conhecidas. O nvel mais baixo da EAP o pacote de trabalho. Ele pode ser agendado, ter seu custo estimado, monitorado e controlado. Conforme o trabalho decomposto em nveis maiores de detalhe, a habilidade de planej-lo, gerenci-lo e control-lo aumenta. Contudo, uma decomposio excessiva pode resultar num esforo de gerenciamento improdutivo, uso ineficiente de recursos e na diminuio da eficincia na execuo do trabalho. A equipe espera at que a entrega ou subprojeto seja clarificado para que os detalhes da EAP possam ser desenvolvidos. Para isso, d-se o nome de planejamento em ondas sucessivas. A EAP representa todo produto e trabalho do projeto, inclusive o trabalho de gerenciamento do mesmo. Regra dos 100% = todo o trabalho nos nveis mais baixos tem que escalar os nveis mais altos. Dicionrio da EAP um documento que possui uma descrio detalhada do trabalho e documentao tcnica para cada elemento da EAP. Verificar o escopo significa formalizar a aceitao das entregas concludas do projeto. Isso inclui o cliente e/ou o patrocinador para obter aceitao formal. Verificar escopo = aceitao das entregas. Controlar qualidade = preciso das entregas e o alcance dos requisitos de qualidade especificados para as entregas. O controle da qualidade geralmente feita antes da verificao do escopo, mas eles podem ser executados paralelamente. O controle do escopo assegura que todas as modificaes solicitadas e aes corretivas ou preventivas so processadas atravs do processo Realizar o controle integrado de mudanas. Gerenciar as mudanas reais quando essas ocorrerem e integrado aos outros processos de controle. As mudanas so inevitveis. Portanto exigem algum tipo de processo de controle. Mudanas no controladas = scope creep. ### Engenharia de software WBS (EAP): Processo necessrio para subdividir as principais entregas do projeto e do trabalho do projeto em componentes menores e mais facilmente gerenciveis. A EAP

decomposta em pacotes de trabalho. Deve ser completa, organizada e pequena o suficiente para que o progresso possa ser medido. Cada componente subdividido em componentes menores. A cada subdiviso, h um detalhamento maior. A EAP uma decomposio hierrquica orientada entrega do trabalho a ser executado pela equipe do projeto, para atingir os objetivos do projeto e criar as entregas necessrias. Ela organiza e define o escopo total do projeto. O nvel de atividades pode ser listado. Pacotes de trabalho so os itens no nvel mais baixo da EAP (e podem ser "quebrados" em atividades e tarefas). ### Engenharia de software Gerncia de projetos - gerncia de tempo Engloba os processos necessrios para garantir que o projeto termine dentro do prazo previsto. Processos: - definir as atividades: processo de identificao das aes especficas a serem realizadas para produzir as entregas do projeto; - sequenciar as atividades: processo de identificao e documentao dos relacionamentos entre as atividades; - estimar os recursos das atividades: processo de estimativa dos tipos e quantidades de material, pessoas, equipamentos ou suprimentos que sero necessrios para realizar cada atividade; - estimar duraes das atividades: processo de estimativa do nmero de perodos de trabalho que sero necessrios para terminar atividades especficas com os recursos estimados; - desenvolver o cronograma: processo de anlise das sequncias das atividades, suas duraes, recursos necessrios e restries do cronograma visando criar o cronograma do projeto; - controlar o cronograma: processo de monitoramento do projeto para atualizao do seu progresso e gerenciamento das mudanas feitas na linha de base do cronograma; Em projetos de escopo menor, os processos podem ser vistos como um nico processo. Antes destes processos, h um trabalho de planejamento pela equipe de gerenciamento. Esse planejamento faz parte do processo Desenvolver um plano de gerenciamento do projeto, que produz um sistema de gerenciar cronograma e que usa metodologia e uma ferramenta de elaborar cronograma, assim como estabelece critrios para o desenvolvimento e controle do cronograma. Mtodos conhecidos para elaborar cronograma: mtodo do caminho crtico (CPM) e mtodo da cadeia crtica.

Os processos para gerenciar tempo, juntamente com suas ferramentas e tcnicas so documentados no plano de gerenciamento do cronograma. A maioria do esforo est no processo controlar cronograma. Os pacotes de trabalho na EAP so tipicamente decompostos em atividades que representam o trabalho necessrio para completar o pacote de trabalho. As atividades proporcionam uma base para a estimativa, desenvolvimento do cronograma, execuo, monitoramento e controle do trabalho do projeto. A reviso e manuteno do cronograma continuam sendo executadas durante todo o projeto medida que o trabalho progride, o plano de gerenciamento do projeto muda e a natureza dos eventos de riscos evolui. Folga total a diferena entre as datas mais tarde e mais cedo. Caminho crtico tem uma folga total igual a zero ou negativa. Atividades do cronograma que esto no caminho crtico so chamadas de atividades crticas. Mtodo da cadeia crtica (MCC ou CCM): o cronograma feito e o mtodo do caminho crtico feito tambm. Depois disso, a disponibilidade de recurso informada e um novo cronograma (restringido por recursos) determinado. O cronograma resultante, geralmente, tem um caminho crtico diferente. Este novo caminho crtico a cadeia crtica. MCC utiliza buffers de durao que so atividades sem trabalho do cronograma. Buffer colocado no final da cadeia crtica o buffer do projeto e protege a data alvo de trmino contra o seu desvio ao longo da cadeia crtica. Buffers de alimentao so colocados em cada ponto que uma cadeia de tarefas (que no est na cadeia crtica) alimenta ou converge para a cadeia crtica. Anlise do cenrio "e se": analisar os problemas que podem acontecer (greve, mudana no processo de licenciamento) e ver se o projeto pode andar se acontecer estes problemas e pode preparar planos de contingncia e de resposta para superar ou mitigar o impacto de situaes inesperadas. Anlise de Monte Carlo a tcnica mais comum do cenrio e se, na qual uma distribuio das possveis duraes de atividades definida para cada atividade e usada para calcular uma distribuio de possveis resultados para o projeto como um todo. Tcnicas de compresso do cronograma - compresso: verificar se vale pena aumentar um pouco o custo para obter maior compresso. Exemplo: aprovao de hora extra, recursos adicionais ou o pagamento para acelerao da entrega das atividades no caminho crtico. A compresso nem sempre vivel e pode resultar num maior risco e/ou custo. - paralelismo: tcnica onde fases, que normalmente seriam executadas em sequncia, so executadas em paralelo. O paralelismo s funciona se as atividades podem ser sobrepostas para encurtar a durao. O controle do cronograma est relacionado determinao da situao atual do cronograma do projeto; influncia nos fatores que criam mudanas no cronograma; determinao de que o cronograma mudou e gerenciamento das mudanas reais conforme ocorrem.

### Engenharia de software Gerncia de projetos - gerncia de custos Engloba os processos necessrios para garantir que o projeto termine dentro do oramento aprovado. Processos: - estimar custos: processo de desenvolvimento de uma estimativa de custos dos recursos monetrios necessrios para terminar as atividades do projeto; - determinar o oramento: processo de agregao de custos estimados de atividades individuais ou pacotes de trabalho para estabelecer uma linha de base autorizada dos custos; - controlar os custos: processo de monitoramento do andamento do projeto para atualizao do seu oramento e gerenciamento das mudanas feitas na linha de base dos custos; Em projetos de menor escopo, a estimativa e o oramento de custos esto interligados to firmemente que so vistos como um nico processo que pode ser realizado por uma pessoa num perodo de tempo relativamente curto. Estes trs processos so precedidos por um esforo de planejamento da equipe de gerenciamento e este esforo faz parte do processo Desenvolver o plano de gerenciamento do projeto. Este, por sua vez, produz um plano de gerenciamento dos custos que pode estabelecer o seguinte: - nvel de exatido: h um arredondamento dos dados numa preciso prescrita ($100, $1.000) baseada no escopo das atividades e magnitude do projeto e podem incluir uma quantia para contingncias. - unidades de medida: cada unidade usada em medies definida para cada um dos recursos. - associaes com procedimentos organizacionais: a EAP fornece a estrutura para o plano de gerenciamento dos custos. O componente da EAP usado para a contabilidade de custos do projeto chamado de conta de controle. - limites de controle: tipicamente expressos em porcentagem. - regras para medio de desempenho: as regras para medio do desempenho do gerenciamento do valor agregado (GVA ou EVM em ingls) so estabelecidas. - formato dos relatrios; - descrio dos processos. Estimativas de custos so geralmente expressas em unidades de alguma moeda, mas pode ser dadas em horas ou dias de pessoal, com a vantagem de eliminao dos efeitos das flutuaes das moedas. As estimativas de custos so refinadas durante o projeto. Elas so atualizadas iterativamente.

Uma estimativa dos custos uma avaliao quantitativa dos custos provveis dos recursos necessrios para completar a atividade. Tcnicas para estimar os custos: - estimativa anloga: olhar o histrico de custo de outros projetos semelhantes anteriores para estimar o custo do projeto atual. - estimativa paramtrica: utiliza uma relao estatstica entre dados histricos e outras variveis para calcular uma estimativa para parmetros de atividade como custo, oramento e durao. Os oramentos do projeto compem os recursos financeiros autorizados para executar o projeto. O desempenho dos custos ser medido em relao ao oramento autorizado. A atualizao do oramento envolve o registro de custos gastos at a data. Qualquer aumento do oramento autorizado somente pode ser aprovado atravs do processo Controle Integrado de Mudanas. A chave para o controle eficaz de custos o gerenciamento da linha de base do desempenho de custos aprovada e as mudanas nas mesmas. O gerenciamento de custos deve considerar os requisitos das partes interessadas para captura de custos. O sistema de controle de mudanas de custo define os procedimentos atravs dos quais a linha base do custo pode ser modificada. Consiste de formulrios, documentaes, sistema de rastreamento e nveis de aprovao necessrios para autorizar mudanas. Entre os objetivos do controle de custo, esto: - controlar os fatores que criam mudanas na linha base dos custos. - gerenciar as mudanas reais conforme ocorrem. - monitorar o desempenho de custo para isolar e entender as variaes a partir da linha de base de custos. - monitorar o desempenho do trabalho em relao aos recursos financeiros gastos. - registrar as mudanas adequadas. - garantir que estouros nos custos no excedam o financiamento autorizado. - prevenir que mudanas no autorizadas sejam includas no relatrio de custo ou uso de recursos. - agir para manter os excessos de custos no previstos dentro de limites aceitveis. O controle de custos do projeto procura pelas causas positivas e negativas e parte do processo Controle integrado de mudanas. Gerenciamento do valor agregado: tcnica para relato do status do projeto em termos de custo e tempo. VP (valor planejado): valor do oramento alocado original com o custo orado do trabalho agendado. COTA: custo orado do trabalho agendado. VP = qual o valor estimado do trabalho planejado? VA (valor agregado): valor cumulativo do custo orado do trabalho realizado. COTR: custo orado do trabalho realizado.

VA = qual o valor estimado do trabalho realizado? CR (custo real): custo real do trabalho realizado. CR = qual o custo real incorrido para o trabalho realizado? ONT (oramento no trmino): soma de todos os valores de oramento estabelecidos para o trabalho a ser realizado em um projeto. o valor planejado total do projeto. ONT = qual o oramento para o esforo total do projeto. ENT (estimativa no trmino): neste momento, qual a nossa previso para o custo total do projeto? ENT = CR + EPT ENT = CR + ONT VA ENT = CR + (ONT VA)/IDC (Considera-se que as variaes atuais sero tpicas no futuro) ENT = ONT/IDC EPT (estimativa para terminar): a partir deste momento, quanto mais esperamos gastar para concluir o projeto? EPT = ENT - CR VNC (variao na concluso): o quanto acima ou abaixo do oramento espera-se estar ao final do projeto? VNC = ONT ENT VariaoCusto = VA CR VariaoPrazo = VA VP IDC (ndice de desempenho de custos): VA/CR IDC < 1 => estouro nos custos estimados. IDC > 1 => custos estimados no atingidos. IDP (ndice de desempenho de prazo): VA/VP ### Engenharia de software Gerncia de projetos - gerncia de qualidade A gerncia de qualidade inclui todas as atividades da organizao executora que determinam as responsabilidades, os objetivos e as polticas de qualidade, de modo que o projeto atenda s necessidades que motivaram sua realizao. O sistema de gerenciamento de qualidade implementado atravs de polticas, dos procedimentos e processos de planejamento de qualidade, garantia e controle da qualidade, com atividades de melhoria contnua dos processos conduzidas do incio ao fim. Os processos de gerenciamento de qualidade incluem: - planejamento da qualidade: identificar padres de qualidades relevantes para o projeto e determinar como faz-los. - realizar a garantia da qualidade: aplicar atividades de qualidade planejadas e sistemticas para garantir que o projeto empregue todos os processos necessrios para atender aos requisitos.

- realizar o controle da qualidade: monitorar os resultados a fim de determinar se eles esto de acordo com os padres relevantes de qualidade e, tambm, identificar as causas de um desempenho insatisfatrio. Alm disso, recomendar as mudanas necessrias. Deixar de cumprir os requisitos de qualidade do produto ou do projeto pode ter consequncias negativas graves para uma ou todas as partes interessadas do projeto. Exemplo: cumprir os requisitos do cliente sobrecarregando a equipe do projeto pode resultar em aumento de atritos entre funcionrios, erros e retrabalho; cumprir os objetivos do cronograma do projeto apressando as inspees de qualidade planejadas pode resultar em erros no detectados. Qualidade o grau at o qual um conjunto de caractersticas inerentes satisfaz as necessidades. Qualidade baixa ruim, mas um grau baixo no indica qualidade baixa. Preciso a homogeneidade de medies repetidas que so agrupadas com pouca disperso. Exatido a correo com o que o valor medido se aproxima do valor real. O gerenciamento moderno da qualidade reconhece a importncia de: - satisfao do cliente; - preveno ao invs de inspeco: um dos princpios fundamentais do moderno gerenciamento de qualidade determina que a qualidade deve ser planejada, projetada e incorporada, em vez de inspecionada. O custo de prevenir erros geralmente muito menor do que o custo de corrig-los quando so encontrados pela inspeo; - melhoria contnua: o ciclo PDCA (plan-do-check-act, planejar-fazer-verificar-agir) a base para a melhoria da qualidade conforme definida por Shewhart e modificada por Deming. - responsabilidade da gerncia: o sucesso depende de todos os membros da equipe, mas continua sendo a responsabilidade da gerncia fornecer os recursos necessrios ao xito. O custo da qualidade (CDQ) refere-se ao custo total de todos os esforos relativos qualidade durante todo o ciclo de vida do produto. O planejamento de qualidade deve ser realizado em paralelo com outros processos de planejamento do projeto. Por exemplo, modificaes nas propostas do produto para atender aos padres de qualidade podem exigir custos ou ajustes nos cronogramas e uma anlise de risco detalhada dos seus impactos nos planos. O processo Realizar a garantia da qualidade inclui a melhoria contnua do processo, que um meio iterativo de melhorar a qualidade de todos os processos. A melhoria contnua do processo reduz o desperdcio e elimina as atividades que no agregam valor, aumentando a eficincia e eficcia. Auditoria de qualidade: uma reviso estruturada e independente para determinar se as atividades do projeto esto cumprindo as polticas, os processos e os procedimentos da organizao e do projeto. Os objetivos de uma auditoria: identificar as melhores prticas que esto sendo implementadas; identificar deficincias; compartilhar boas prticas utilizadas em projetos similares; oferecer apoio de forma proativa a fim de ajudar a

equipe para aumentar a produtividade; destacar as contribuies de cada auditoria no repositrio de lies aprendidas na organizao. As atividades de controle da qualidade identificam as causas de baixa qualidade do processo ou produto e recomendam e/ou executam as aes necessrias para eliminlas. Definies necessrias do processo Realizar o controle da qualidade: - Preveno: manter os erros fora do processo. - Inspeo: manter os erros fora do alcance do cliente - Amostragem de atributos: o resultado est em conformidade ou no. - Amostragem de variveis: escala contnua que mede o grau de conformidade. - Tolerncia: intervalo especificado de resultados aceitveis. - Limites de controle: limites que podem indicar se o processo est fora de controle. ### Engenharia de software Gerncia de projetos - gerncia de pessoas (recursos humanos) Engloba os processos necessrios para garantir o uso mais efetivo das pessoas envolvidas no projeto. Inclui todos os stakeholders do projeto. Processos: - desenvolver o plano de recursos humanos: processo de identificao e documentao de funes, responsabilidades, habilidades necessrias e relaes hierrquicas do projeto, alm da criao de um plano de gerenciamento do pessoal. - mobilizar a equipe do projeto: processo de confirmao da disponibilidade dos recursos humanos e obteno da equipe necessria para concluir as designaes do projeto. - desenvolver a equipe do projeto: processo de melhoria de competncias, interao da equipe e ambiente global da equipe para aprimorar o desempenho do projeto; - gerenciar a equipe do projeto: processo de acompanhar o desempenho de membros da equipe, fornecer feedback, resolver questes e gerenciar mudanas para otimizar o desempenho do projeto; A equipe de gerenciamento de projetos um subconjunto da equipe do projeto. Ela pode ser chamada de equipe principal, executiva ou de liderana. O patrocinador do projeto trabalha com a equipe do gerenciamento de projetos, geralmente com apoio em questes como financiamento do projeto, esclarecimento do escopo e monitoramento do progresso. Gerenciar e liderar a equipe tambm inclui: - influenciar a equipe do projeto. - comportamento profissional e tico. Alguns exemplos de interaes dos processos de gerenciamento de pessoas com outras reas:

- depois de feito o EAP, pode ser necessrio contratar ou mobilizar pessoal adicional. - quando membros adicionais so includos na equipe, seus nveis de experincia podem aumentar ou diminuir o risco do projeto, criando a necessidade de atualizaes complementares no planejamento de riscos. - quando a durao das atividades estimada, oradas, delimitadas ou planejadas antes da identificao de todos os membros da equipe do projeto e seus nveis de competncias, as duraes das atividades estaro sujeitas a alteraes. Ideia central do gerenciamento de recursos humanos determinar e identificar pessoas com as habilidades necessrias para o xito do projeto. As pessoas ou grupos (que iro fazer um determinado papel no projeto) podem ser internos ou externos organizao executora do projeto. Outros projetos podem concorrer por recursos com as mesmas competncias ou conjunto de habilidades. Considerando estes fatores, outras reas como custo, cronogramas, riscos, qualidade, etc podem ser significativamente afetadas. Um planejamento de recursos humanos eficaz deve considerar e planejar estes fatores e desenvolver opes de recursos humanos. Deixar de mobilizar os recursos humanos necessrios para o projeto pode afetar os cronogramas e oramentos, a satisfao do cliente, a qualidade e os riscos. Pode reduzir a probabilidade de xito e, na pior das hipteses, cancelar o projeto. Se os recursos humanos no estiverem disponveis, o gerente pode designar recursos alternativos, talvez com menos competncias, desde que dentro da lei. Estes fatores devem ser considerados e planejados nas etapas de planejamento do projeto. O gerente do projeto ou a equipe de gerncia de projeto deve refletir o impacto de qualquer indisponibilidade de recursos humanos necessrios no cronograma, no oramento, nos riscos, na qualidade, nos planos de treinamento e nos outros planos de gerenciamento do projeto. Uma habilidade importante requerida do gestor para a soluo de dificuldades na execuo de um projeto a delegao de autoridade, tambm denominada empowerment. ### Engenharia de software Gerncia de projetos - gerncia de comunicao Engloba os processos necessrios para garantir a correta gerao, distribuio, armazenamento, coleta e disposio final das informaes relativas ao projeto. Processos: - identificar as partes interessadas: processo de identificao de todas as pessoas ou organizaes que podem ser afetadas pelo projeto e de documentao das informaes relevantes relacionadas aos seus interesses, envolvimento e impacto no sucesso do projeto;

- planejar as comunicaes: processo de determinao das necessidades de informao das partes interessadas no projeto e definio de uma abordagem de comunicao; - distribuir informaes: processo de colocar as informaes necessrias disposio das partes interessadas no projeto, conforme planejado; - gerenciar as expectativas das partes interessadas: processo de comunicao e interao com as partes interessadas para atender s suas necessidades e solucionar as questes medida que ocorrerem; - reportar o desempenho: processo de coleta e distribuio de desempenho, incluindo relatrios de andamento, medies do progresso e previses; Canais ou caminhos de comunicao = n(n - 1)/2, sendo n = nmero de partes interessadas. O gerente de projetos deve considerar este nmero como um indicador de complexidade. (Dentro do processo de planejamento das comunicaes) Os gerentes de projetos gastam a maior parte do tempo se comunicando com os membros da equipe e outras partes interessadas, sejam internas, sejam externas. Uma comunicao eficaz cria uma ponte entre as diversas partes interessadas envolvidas no projeto, conectando vrios ambientes culturais e organizacionais. Dimenses da atividade de comunicao: - interna (dentro do projeto) e externa (cliente, outros projetos, meios de comunicao, o pblico); - formal (relatrio, memorandos, instrues) e informal (emails, discusses ad hoc); - vertical (dos nveis superiores e inferiores da organizao) e horizontal (com colegas); - oficial (boletins informativos, relatrio anual) e no oficial (comunicaes confidenciais); - escrita e oral; - verbal e no verbal. fundamental para o sucesso do projeto identificar as partes interessadas desde o incio e analisar seus nveis de interesse, expectativas, importncia e influncia. Em seguida possvel desenvolver uma estratgia para abordar cada parte interessada e determinar o nvel e a oportunidade para o envolvimento das partes interessadas. A avaliao e a estratgia correspondente devem ser revistas periodicamente. As partes interessadas do projeto devem ser classificadas de acordo com o nvel de interesse, a influncia e o envolvimento no projeto. O processo Planejar as comunicaes responde s necessidades de informaes: quem precisa de quais informaes, quando elas sero necessrias, como so fornecidas e por quem. As necessidades e a forma (mtodos) de comunicao variam muito. O importante para o sucesso do projeto identificar as necessidades de informaes e determinar os meios mais adequados. Tcnicas para distribuio eficaz de informao: - modelos de emissor-receptor: realimentaes de feedback e barreiras comunicao.

- escolha dos meios de comunicao: situaes do tipo quando mandar um memorando, quando mandar um email, quando se comunicar sobre escrito e quando se comunicar oralmente. - estilo da redao: voz passiva ou ativa, estrutura das frases e escolha das palavras. - tcnicas de gerenciamento de reunies: preparao de uma agenda e tratamento de conflitos. - tcnicas de apresentao: linguagem corporal e planejamento de apoios visuais. - tcnicas de facilitao: obteno de consenso e superao de obstculos. Os relatrios de desempenho precisam fornecer informaes no nvel adequado para cada pblico. ### Engenharia de software Gerncia de projetos - gerncia de riscos Engloba os processos necessrios para garantir a correta identificao, anlise e resposta aos riscos do projeto, maximizando os efeitos positivos e minimizando os efeitos negativos. Processos: - planejar o gerenciamento dos riscos: processo de definio de como conduzir as atividades de gerenciamento de riscos de um projeto; - identificar os riscos: processo de determinao dos riscos que podem afetar o projeto e de documentao de suas caractersticas; - realizar a anlise qualitativa dos riscos: processo de priorizao dos riscos para anlise ou ao adicional atravs da avaliao e combinao de sua probabilidade de ocorrncia e impacto; - realizar a anlise quantitativa dos riscos: processo de analisar numericamente o efeito dos riscos identificados nos objetivos gerais do projeto; - planejar as respostas aos riscos: processo de desenvolvimento de opes e aes para aumentar as oportunidades e reduzir as ameaas ao objetivo do projeto; - monitorar e controlar os riscos: processo de implementao de planos de respostas aos riscos, acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificao de novos riscos e avaliao eficcia dos processos de tratamento dos riscos durante todo o projeto; O risco coisa do futuro. Se ocorrer, tem um efeito em pelo menos um objetivo do projeto, como escopo, cronograma, custo e qualidade. Riscos existem em todos os projetos. Alguns riscos no podem ser gerenciados de forma positiva, o que sugere que a equipe deve criar um plano de contingncia. Um risco de projeto que j ocorreu tambm pode ser considerado um problema.

As organizaes e as partes interessadas esto dispostas a aceitar vrios graus de riscos, o que chamado de tolerncia a riscos. Essa tolerncia para aceitar ou no os riscos (aceitar se eles estiverem dentro da tolerncia). O risco existe assim que o projeto concebido. O processo Planejar o gerenciamento dos riscos deve comear no incio do projeto e ir at as fases inicias do planejamento do projeto. Identificar um risco um processo iterativo, pois novos riscos podem surgir com o andamento do projeto. O formato das declaraes de riscos deve ser consistente para garantir a capacidade de comparar o efeito relativo de um evento de risco com outros no projeto. Tcnicas para identificar riscos: - Brainstorming: obteno da lista completa dos riscos de um projeto. - Tcnica Delphi: especialistas em riscos do projeto respondem questionrios sobre riscos importantes do projeto. As respostas so resumidas e redistribudas aos especialistas para comentrios adicionais. Esta tcnica pode ajudar a reduzir a parcialidade nos dados e evita que algum possa influenciar indevidamente o resultado. - Entrevista: feitas com participantes experientes. - Anlise da causa-raiz: a anlise da causa-raz uma tcnica especfica para identificar um problema, descobrir as causas adjacentes que levaram a ele e desenvolver aes preventivas. Anlise SWOT (strength, weakness, opportunity e threat): tem a finalidade de aumentar a abrangncia dos riscos identificados. Primeiramente, a tcnica identifica foras e fraquezas da organizao. Geralmente esses fatores so identificados pela tcnica de Brainstorming. Depois a tcnica identifica as oportunidades do projeto. Elas so resultantes das foras da organizao, bem como as ameaas decorrentes da fraqueza. EAR (estrutura analtica de riscos): uma representao, organizada hierarquicamente, dos riscos identificados do projeto, ordenados por categoria e subcategoria de risco, que identifica diversas reas e causas de riscos potenciais. As organizaes podem aumentar o desempenho do projeto se concentrando nos riscos de alta probabilidade. O processo Realizar a anlise qualitativa dos riscos avalia a prioridade dos riscos identificados usando a sua relativa probabilidade, os seus impactos nos objetivos. A anlise qualitativa dos riscos um meio rpido e econmico de estabelecer prioridades do processo de Planejar as respostas aos riscos e define a base para a realizao da anlise quantitativa dos riscos. O que determina o(s) mtodo(s) a ser(em) usado(s) para analisar quantitativamente os riscos so a disponibilidade de tempo e oramento e necessidade de declaraes qualitativas e quantitativas sobre os riscos e impactos. O que pode influenciar o processo Realizar a anlise quantitativa de riscos: - informaes sobre projetos semelhantes j concludos; - estudos de projetos semelhantes feitos por especialistas em riscos; - bancos de dados de riscos disponibilizados pelo setor ou pelas fontes proprietrias.

Uma pessoa identificada e designada para assumir a responsabilidade de cada resposta ao risco. O processo de Monitorar e controlar os riscos mostra se um risco foi modificado ou que pode ser desativado; mostra se as polticas e os procedimentos do gerenciamento dos riscos esto sendo seguidos e determina se as reservas para contingncias de custo ou cronograma devem ser modificadas de acordo com a avaliao atual dos riscos. O processo de Monitorar e controlar os riscos engloba a atualizao dos bancos de dados de lies aprendidas e os modelos de gerenciamento dos riscos do projeto para benefcio de futuros projetos. ### Engenharia de software Gerncia de projetos - gerncia de aquisies Engloba os processos necessrios para compra/venda de produtos e servios de fora da organizao executora do projeto. Processos: - planejar as aquisies: processo de documentao das decises de compras do projeto, especificando a abordagem e identificando fornecedores em potencial; - realizar as aquisies: processo de obteno de respostas de fornecedores, seleo de um fornecedor e adjudicao; - administrar as aquisies: processo de gerenciamento das relaes de aquisio, monitorando o desempenho do contrato e realizao de mudanas e correes conforme necessrio; - encerrar as aquisies: o processo de finalizar todas as aquisies do projeto. A organizao pode ser tanto o comprador, quanto o vendedor dos produtos, servios ou resultados de um projeto. O gerenciamento de aquisies tambm abrange a administrao de todos os contratos emitidos por uma organizao externa e a administrao das obrigaes contratuais atribudas equipe do projeto pelo contrato. Os processos envolvem contratos que so documentos legais entre um comprador e um fornecedor. Com o gerenciamento ativo do ciclo de vida do contrato e uma redao cuidados dos termos e condies das aquisies, alguns riscos identificveis podem ser evitados, mitigados ou transferidos para um fornecedor. Um projeto complexo pode envolver o gerenciamento de mltiplos contratos ou sub-contratos simultaneamente ou em sequncia. Nesses casos, o ciclo de vida de cada contrato pode terminar durante qualquer fase do ciclo de vida do projeto.

Este processo de Adquirir aquisies envolve determinar se ser contratado apoio externo e, em caso de afirmativo, o que e como ser contratado, o quanto necessrio e quando ser realizado. No processo de Realizar aquisies recebe licitaes e propostas e aplica critrios de seleo previamente definidos para escolher um ou mais fornecedores que sejam qualificados para realizar o trabalho e aceitveis como fornecedor. Em projetos maiores com vrios fornecedores, um aspecto fundamental da Administrao de contratos gerenciar as interfaces entre os diversos fornecedores. Muitas organizaes tratam a administrao de contratos como uma funo administrativa separada da organizao do projeto. Uma das principais preocupaes ao fazer o pagamento dos fornecedores que exista uma relao rigorosa entre os pagamentos feitos e o trabalho realizado. ### Sistemas de informacao Data mining (DM) o processo de garimpar dados a fim de encontrar informaes "implcitas" nos bancos de dados. Atua junto a um data warehouse (armazm de dados) (DWH). O uso de data mining fortemente recomendvel desde o incio na fase de projeto do data warehouse. As ferramentas de DM deveriam ser projetadas para facilitar seu uso em conjunto com o DWH. A descoberta de conhecimento em banco de dados (KDD) mais do que DM. Envolve seleo de dados, limpeza, enriquecimento, transformao ou codificao, DM e construo de relatrios e apresentao da informao descoberta. O resultado da minerao pode ser descobrir os seguintes tipos de informao "nova": - regras de associao: por exemplo, se um cliente compra equipamentos de vdeo, ele pode tambm comprar outros componentes eletrnicos. - padres sequenciais: por exemplo, suponha que um cliente compre uma cmera, e que dentro de 3 meses ele compre materiais fotogrficos de forma que dentro dos prximos 6 meses, ele dever comprar um acessrio. Isso define um padro sequencial de transaes. - rvores de classificao: por exemplo, clientes podem ser classificados por frequncia de visitas por tipo de financiamento utilizado por quantidade comprada, ou por afinidade com tipos de itens. Algumas estatsticas podem ser geradas para cada classe de cliente. A data mining precisa ser precedida por significativa preparao de dados antes que ela possa gerar informao significativa que influencie as decises de negcio. Os resultados do DM podem ser mostrados em grficos, listagens ou tabelas resumidas. Predio: data mining pode mostrar como certos atributos dos dados iro se comportar no futuro. Identificao: padres de dados podem ser usados para identificar uma atividade, um evento ou existncia de um item. Classificao: data mining pode particionar os dados e as diferentes categorias podem ser identificadas em combinao de parmetros.

Otimizao: um objetivo do data mining pode ser otimizar o uso de recursos limitados como espao, tempo, dinheiro ou materiais. Pode ser, tambm, maximizar lucros sob certas restries como estudado em PO. comum descrever o conhecimento descoberto a partir da data mining de cinco modos: - regras de associao: relacionam a presena de um conjunto de itens com outros. Uma mulher que compra bolsa est propensa a comprar sapatos. Um raio X que indique a presena de A e B, provavelmente indicar a presena de C. - hierarquia de classificao: criar uma hierarquia de classes a partir de eventos ou transaes. Uma populao pode ser dividida em N faixas de risco de crdito baseado no histrico de transaes de crdito dessa populao. - padres sequncia: um conjunto de aes ou eventos investigado tentando deduzir outros. - padres com sries temporais: similaridades podem ser encontradas em uma srie temporal de dados. - clustering (agrupamento): uma dada populao de eventos ou novos itens pode ser dividida em conjuntos de elementos similares. Para a maioria das aplicaes, o conhecimento desejvel uma combinao dos tipos citados. Mtodos tradicionais de Data Mining: Classificao: associa ou classifica um item a uma ou vrias classes categricas prdefinidas. Uma tcnica estatstica apropriada para classificao a anlise discriminante. Os objetivos dessa tcnica envolvem a descrio grfica ou algbrica das caractersticas diferenciais das observaes de vrias populaes, alm da classificao das observaes em uma ou mais classes predeterminadas. Anlise de outliers: um banco de dados pode conter dados que no apresentam o comportamento geral da maioria. Eles so denominados outliers (excees). Muitos mtodos de minerao descartam esses outliers como rudo indesejado. Entretanto, em algumas aplicaes, tais eventos raros podem ser mais interessantes do que os que ocorrem regularmente. Exemplo: descobrir padres de comportamento de professores que publicam um nmero muito grande de artigos e que fogem ao padro dos demais professores. Clustering: ramo da Estatstica Multivariada que engloba mtodos utilizados para descobrir estruturas em um conjunto complexo de dados. O objetivo principal de clustering separar objetos ou observaes em classes naturais de forma que os elementos pertencentes a um mesmo grupo tenham um alto grau de semelhana ou similaridade, enquanto que, quaisquer elementos pertencentes a grupos distintos, tenham pouca semelhana entre si. Anlise de Sries Temporais: determina caractersticas seqenciais, como dados com dependncia no tempo. Seu objetivo modelar o estado do processo extraindo e registrando desvios e tendncias no tempo. Regras de Associao: determinam relaes entre campos de um banco de dados. A idia a derivao de correlaes multivariadas que permitam subsidiar as tomadas de deciso. A busca de associao entre variveis , freqentemente, um dos propsitos das

pesquisas empricas. A possvel existncia de relao entre variveis orienta anlises, concluses e evidenciao de achados da investigao. Uma regra de associao definida como se X ento Y, ou X Y, onde X e Y so conjuntos de itens e X Y = . Diz-se que X o antecedente da regra, enquanto Y o seu conseqente. ### Sistemas de informacao Data Warehouse (DWH) Data warehouse tem por caracterstica ser orientado por assuntos, por manter dados histricos, centralizado, focado em aspectos estratgicos e no normalizado. Data Warehouses virtuais proporcionam vises de bancos de dados operacionais que so materializadas para acesso eficiente. Diferem dos bancos de dados tradicionais em vrios aspectos. Os BD tradicionais so feitos para transaes, enquanto os DWH so feitos especificamente para tomadas de deciso. Estes so otimizados para a recuperao de dados, enquanto aqueles so para processamento rotineiro de transaes. Por isso os DWH so bem diferentes dos BD tradicionais em sua estrutura, funcionalidade, desempenho e propsito. Vrios tipos de aplicaes so suportados: OLAP, DSS e data mining. OLAP (Online analytical processing): anlise de dados complexos a partir do DWH. Ferramentas OLAP empregam capacidade de computao distribuda para anlises que requerem mais armazenamento e processamento. DSS (decision support system): tambm conhecido como EIS (enterprise information systems), do apoio aos tomadores de decises com dados de alto nvel para decises complexas e importantes. Os DWH tem quantidades grandes de dados podendo ser originadas de mltiplas fontes. Os modelos nos DWH podem ser multidimensionais. Exemplos seriam os perodos fiscais de uma organizao, os produtos e as regies. Os DWH so livres de restries do ambiente transacional. Com isso h um ganho de eficincia no processamento das consultas. Ferramentas e tcnicas utilizadas: transformao de consultas, interseo e unio de ndices, funes especiais ROLAP (OLAP relacional) e MOLAP (OLAP multidimensional), extenses de SQL, mtodos avanados de juno e varredura inteligente. DOLAP (Desktop OLAP): oferece maior portabilidade para usurios do OLAP. O processamento feito no cliente. Funcionalidades das ferramentas OLAP em DWH: - Roll up: dados so resumidos com generalizao crescentes. - Drill down: nveis crescentes de detalhes so revelados (complemento de roll-up). - Drill across: ex.: pular da viso de ano para dia (sem passar por ms) - Drill through: Estou na dimenso de tempo e mudo para produto. - Pivoteamento (ou rotao): mudana de uma hierarquia dimensional para outra.

- Slice and dice (fatiar e cortar em cubos): execuo de operaes de projeo nas dimenses. - classificao: os dados so classificados segundo o valor ordinal. - seleo: os dados esto disponveis por valor ou faixa de valores. - atributos derivados: atributos so calculados por operaes sobre valores armazenados e derivados. O desempenho dos processamentos em DWH so melhorados com os SMP (symmetric multiprocessor), cluster, MPP (massive parallel processor) e a combinao entre eles. O gerenciamento de projeto (projeto, construo e a implementao de um DWH) uma considerao importante e desafiadora. Pode-se consumir anos desde a conceituao at a implementao. So projetados para leitura, mas no uma estrutura totalmente esttica. O esquema deve mudar para tratar essas mudanas. A qualidade e a consistncia de dados so duas questes muito importantes no DWH. Os dados vem de mltiplas fontes onde a nomenclatura diferente, definies de domnio, coisas do tipo. Toda vez que um banco de dado fonte muda, o administrador do DWH deve considerar essas mudanas. Latncia de dados, em data warehouse, significa a rapidez de entrega dos dados ao usurio final. Medidas aditivas so as que podem ser calculadas atravs de funes de agregao SUM e COUNT. Medidas no aditivas so as que no podem ser calculadas por funes de agragao. Elas precisam ser recalculadas. ODS - operational data storage: um banco de dados que geralmente usado e designado para integrar dados de mltiplas fontes para operao adicionais nos dados. Os dados so passados de volta para o SO para mais operaes e para o DW fazer relatrios. Normalmente, um ODS feito para conter dados atmicos com histrico limitado que capturado em tempo real ou quase em tempo real. Comparativamente, um ODS como uma memria de curto prazo, enquanto o DW como uma memria de longo prazo. DDS - dynamic data stores: usada para extrair, transformar e migrar resultados. Armazena, limpa e transforma dados extrados dos SO's e tambm prepara os dados para carregar nos armazns de dados DSS. Os dados do DWH devem estar em um nvel baixo de granularidade e na 3FN. Baixo nvel de granularidade = muitos detalhes. Alto nvel de granularidade = poucos detalhes. Uma chave surrogate (substituta) uma chave que substitui a chave primria. Ela nica para cada linha na tabela. A vantagem dela, em DW, que, se a coluna da chave primria mudar, ela (surrogate key) no precisa mudar. Se no houvesse a SK, toda vez que a coluna da chave primria mudar, a chave primria precisaria ser "passada" pra outra coluna.

### Sistemas de informacao BPM um conceito para otimizar os resultados das organizaes atravs da melhoria dos processos de negcios. Processos de negcios so um conjunto de atividades que estruturar a organizao com o objetivo de produzir resultado para o cliente. BPM pode ser pensado, tambm, como enfoque disciplinado para identificar, desenhar, executar, documentar, medir, monitorar, controlar e melhorar processos de negcio, automatizados ou no, para alcanar resultados consistentes e alinhados com os objetivos estratgicos da organizao. O BPM CBOK diz o que fazer e no como fazer. Negcio se refere a pessoas que interagem para executar um conjunto de atividades de entrega de valor a cliente e gerar retorno de investimento a partes interessadas. No Guia CBOK "negcio" abrange todos os tipos de organizaes com ou sem fins lucrativos, incluindo governamentais. Nesse contexto, "processo" um conjunto definido de atividades ou comportamentos executados por pessoas ou mquinas para alcanar uma ou mais metas. Os processos so disparados por eventos especficos e apresentam um ou mais resultados que podem conduzir ao trmino do processo ou a transferncia de controle para outro processo. Processos so compostos por vrias tarefas ou atividades inter-relacionadas que solucionam uma questo especfica. No contexto do gerenciamento de processos de negcio, um "processo de negcio" definido como um trabalho ponta-a-ponta que entrega valor aos clientes. A noo de trabalho ponta-a-ponta chave, pois, envolve todo o trabalho cruzando limites funcionais necessrios para entregar valor aos clientes. Gerenciamento de Processo de Negcio (BPM) uma abordagem disciplinada para identificar, desenhar, executar, documentar, medir, monitorar, controlar e melhorar processos de negcio automatizados ou no para alcanar os resultados pretendidos consistentes e alinhados com as metas estratgicas de uma organizao. (Lembrar que pode ser automatizado ou no.) BPM requer um compromisso significativo da organizao que, frequentemente, introduz novos papis, responsabilidades e estruturas s organizaes tradicionais orientadas a funes. BPM habilitada por tecnologia atravs de ferramentas para modelagem, simulao, automao, integrao, controle e monitoramento de processos de negcio e de sistemas de informao que suportam esses processos. BPMS um sistema que auxilia a realizao de BPM. um software que executa os processos. - Automatiza o ciclo completo de gesto de processos (execuo, controle e monitorao).

- Ele tem habilidade de visualizar e antever problemas de processos de negcios antes de serem traduzidos em software; - Forar ou reforar melhores prticas e procedimentos requeridos; - Gerenciar e monitorar desempenho de operaes e pessoas; - Automatizar tarefas repetitivas; - Alterar regras de negcio e lgica de softwares corporativos sem requerer recursos de TI; - Assegurar entrada precisa de dados; Tirado do BPMS Adeptia (BPMS1.pdf): - documentar e formalizar processos de negcios, tarefas e regras; - forar decises de negcios especificando os em processos; - assegurar que processos so constantes e repetitivos e no ad-hoc; - gerar novas oportunidades de renda trazendo produtos e servios para o mercado mais rpido do que competidores; - acelerar retorno no investimento realizando economia de custo significativa na integrao de projetos; - encurtar os ciclos de vida de processos e gerenciar excees. Caractersticas esperadas de um profissional de processos: atitude, liderana, disposio para correr riscos e conhecimentos de modelos de referncia, metodologias, tcnicas e ferramentas. - Processos Primrios: So processos ponta-a-ponta, interfuncionais e que entregam valor diretamente ao cliente. Eles representam as atividades essenciais da organizao para cumprir sua misso. Geralmente fazem parte da Cadeia de Valor da organizao. Os processos primrios tambm so chamados de processos de negcio. - Processos de Suporte: So os processos que do suporte aos processos de primrios, geralmente estes processos so recursos, infraestrutura e/ou requeridos pelos processos primrios. Os processos de suporte no geram valor diretamente para o negcio, mas isto no significa que eles no so importantes para a organizao. - Processos de Gerenciamento: So processos que usados para medir, monitorar e controlar as atividades. No adicionam valor ao cliente, mas garantem que a organizao opere com efetividade e eficincia. Papis de gerenciamento de processos: - Dono do processo: dar suporte ao processo; responsvel pelo desenho e desempenho final do processo; facilitar aes e fluxo de trabalho interno; monitorar indicadores de desempenho; incorporar melhorias ao processo; - Analista de processo: responsvel por projetos de transformao de processos; responsvel por desenvolver e manter um repositrio de modelos de referncia e padres, processos de negcio, medies; dar suporte para o desenho de novos processos de negcio. Ele tem como objetivo ajudar o dono do processo no diagnstico

e nas propostas de melhorias contnuas. Ele deve ter uma viso sistmica, comunicao, liderana e conhecimento em tcnicas (BPMN) e ferramentas (BPMS). - Gerente funcional: responsvel por unidade organizacional; reas do conhecimento do BPM: 1. Gerenciamento de processos de negcios: trata dos conceitos fundamentais do BPM. Os principais conceitos so estabelecidos. Definies como o que negcio?, o que processo?, o que BPM?, etc. BPM uma disciplina de gesto, e no apenas uma tecnologia (BPMS). necessrio um compromisso contnuo da organizao para que as atividades de BPM tenham impacto esperado. 2. Modelagem de processos: conjunto de habilidades e processos que permitem pessoas a compreender, comunicar, medir e gerenciar os componentes primrios de processos de negcio. Nesta rea temos as definies gerais sobre tudo que envolve a modelagem de processos e no apenas a sua diagramao. Reconhecimento das notaes e das formas de representao de processos, independente do seu fabricante. Nesta rea tem o reconhecimento formal das vrias notaes (linguagem grfica visual para desenho de processo) e formas de representao de processos, cobrindo as seguintes notaes como fluxograma, IDEF0, EPC, BPMN, etc. 3. Anlise de processos: nesta rea, h uma necessidade de se buscar uma viso realista do atual estado dos processos. Esta rea trata das atividades, princpios e tcnicas utilizados para a compreenso dos processos de negcio. So apresentadas atividades que buscam avaliar o ambiente do negcio, o levantamento e a definio das necessidades do negcio. Neste ponto de ciclo de vida, a anlise se concentra na situao atual, tambm conhecida como anlise "As is". 4. Desenho de processos: nessa rea, as especificaes dos processos de negcios so criadas aps a realizao da sua anlise, cobrindo desde atividades mais essenciais at as atividades mais especficas tal qual a simulao de cenrios. Os princpios de desenho de processos de negcios so estabelecidos. Realizao do projeto de novos ou melhores processos. nessa rea que ser feito o modelo "To be". 5. Gerenciamento de desempenho de processos: trata das definies nas formas de monitoramento e gerenciamento do desempenho. O monitoramento deve estar relacionado ao controle efetivo das operaes corporativas, com tudo isso voltado aos objetivos da organizao. Uma premissa desta rea "tudo aquilo que no pode ser medido, tambm no pode ser gerenciado.", sendo assim, a melhoria e a transformao de processos devem estar diretamente relacionados capacidade corporativa em monitorar e gerenciar o resultado. Nesta rea estabelecem-se os objetivos da medio, especificao clara dos medidores e das medidas, provimento da comunicao dos resultados e a anlise dos dados coletados. 6. Transformao de processos: o objetivo desta abordagem assegurar que os processos continuem suportando os objetivos do negcio e que a evoluo seja tratada de forma planejada e estruturada por mtodos conhecidos e largamente adotados no mercado como Seis Sigma, Lean, TQM, SCOR, VCOR, Custeio Baseado em Atividades, APQC entre outros. Para ter a transformao de processo, precisa-se da fase

de implantao de processos, isto , um produto de software precisa respeitar as etapas de validao e testes para ento entrar em execuo, mesmo que de forma humana. A transformao de processos est diretamente norteada pela melhoria contnua com entendimento de modelos e padres. 7. Organizao de gerenciamento de processos: trata das mudanas estruturais decorrentes da aplicao da gesto por processos. Caracteriza claramente como uma organizao centrada em processos, descrevendo sua estrutura, organizao, gerenciamento e medio a partir dos seus componentes primrios. Pode-se considerar a declarao das responsabilidades e caractersticas dos participantes de uma organizao gerenciadas por processos, tais como dono do processo, gerente do processo, analistas e desenhistas de processos, arquitetos de processos, etc. 8. Gerenciamento de processos corporativos (EPM): grande necessidade de se maximizar resultados dos processos de negcios de acordo com as estratgias de negcio. Estas estratgias precisam ser bem definidas e os objetivos funcionais estabelecidos precisam ser baseados nestas estratgias. Alm disso, h trs requisitos essenciais ao gerenciamento de processos corporativos: a) a medio centrada em clientes, b) processos em nvel organizacional e c) plano de gerenciamento e melhoria de processos em nvel organizacional. 9. Tecnologias de gerenciamento de processos de negcios: trata das tecnologias que facilitam a aplicao prtica do BPM e apresenta a arquitetura comum aos produtos encontrados no mercado atual, bem como suas caractersticas especficas que os caracterizam formalmente como ferramentas de execuo, monitoria e gerenciamento de processos ou BPMS. As caractersticas comuns s arquiteturas vigentes nas ferramentas BPMS so: - Visualizao e simulao de processos; - Gerenciamento e monitoria de atividades; - Estabelecimento, uso e gesto das regras de negcio; - Capacidade de integrao sistmica e de dados; - Adoo e realizao de atividades segundo Workflow; - Adoo de elementos de notaes de processos; - Suporte e biblioteca de melhores prticas. Fatores-Chave de Sucesso BPM: Esforos bem sucedidos de BPM tipicamente envolvem vrios fatores incluindo prticas organizacionais, de gerenciamento, de processo e tecnolgicos. O guia BPM CBOK cobre muitos fatores-chave de sucesso para iniciativas de BPM no escopo organizacional. Estratgia de Negcio: Alinhamento de estratgia, cadeia de valor e processo de negcio a experincia tem mostrado que as organizaes mais bem sucedidas na implementao de BPM dedicam ateno especial ao alinhamento da estratgia de negcio, definies da cadeia de valor e processos de negcio. ### Sistemas de informao

BPM Ciclo de Gerenciamento de Processos Processo de Planejamento e Estratgia: Nessa etapa so vistas as necessidades de alinhamento estratgico dos processos. Segundo o Guia CBOK, deve-se desenvolver um plano e uma estratgia dirigida a processos para a organizao, onde sejam analisadas suas estratgias e metas, fornecendo uma estrutura e o direcionamento para gerenciamento contnuo de processos centrados no cliente. Alm disso, so identificados papis e responsabilidades organizacionais associados ao gerenciamento de processos, aspectos relacionados a patrocnio, metas, expectativas de desempenho e metodologias. Anlise de Processos de Negcio: A anlise tem por objetivo entender os atuais processos organizacionais no contexto das metas e objetivos desejados. Ela rene informaes oriundas de planos estratgicos, modelos de processo, medies de desempenho, mudanas no ambiente externo e outros fatores, a fim de compreender os processos no escopo da organizao como um todo. Durante essa etapa so vistos pontos como: objetivos da modelagem de negcio, ambiente do negcio que ser modelado, principais partes interessadas e escopo da modelagem (processos relacionados com o objetivo geral). A anlise de processos incorpora vrias tcnicas e metodologias, de forma a facilitar as atividades dos envolvidos com a identificao do contexto e diagnstico da situao atual do negcio. Dentre as possveis tcnicas, temos: Brainstorming, Grupo Focal, Entrevista, Cenrios, Survey/Questionrio e 5W1H. Parte dessas tcnicas ser empregada pelo analista de negcios para entender e documentar um processo ou reelaborar sua verso. A Metodologia de Modelagem de Processos apresenta, em detalhes, tcnicas teis etapa de anlise de processos, alm de fornecer uma anlise comparativa de cada uma delas, discutindo pontos fortes e deficincias com base em uma avaliao conceitual e operacional. Desenho e Modelagem de Processo de Negcio: Segundo o Guia CBoK, o desenho de processo consiste na criao de especificaes para processos de negcio novos ou modificados dentro do contexto dos objetivos de negcio, objetivos de desempenho de processo, fluxo de trabalho, aplicaes de negcio, plataformas tecnolgicas, recursos de dados, controles financeiros e operacionais, e integrao com outros processos internos e externos". J a modelagem de processo definida como "um conjunto de atividades envolvidas na criao de representaes de um processo de negcio existente ou proposto", tendo por objetivo "criar uma representao do processo em uma perspectiva ponta-a-ponta que o descreva de forma necessria e suficiente para a tarefa em questo". Alternativamente chamada de fase de identificao, a modelagem pode ser tambm definida como fase onde ocorre a representao do processo presente exatamente como o mesmo se apresenta na realidade, buscando-se ao mximo no recorrer reduo ou simplificao de qualquer tipo. O Guia CBOK ressalta, no entanto, que a modelagem de processos pode ser executada tanto para o mapeamento dos processos atuais como para o mapeamento de propostas de melhoria. Implementao de Processos:

A etapa de implementao definida pelo Guia CBOK como a fase que tem por objetivo realizar o desenho aprovado do processo de negcio na forma de procedimentos e fluxos de trabalho documentados, testados e operacionais, prevendo tambm a elaborao e execuo de polticas e procedimentos novos ou revisados. Monitoramento e Controle de Processo: de suma importncia a contnua medio e monitoramento dos processos de negcio, fornecendo informaes-chave para os gestores de processo ajustarem recursos a fim de atingir os objetivos dos processos. Dessa forma, a etapa de implementao avalia o desempenho do processo atravs de mtricas relacionadas s metas e ao valor para a organizao, podendo resultar em atividades de melhoria, redesenho ou reengenharia. Refinamento de Processo: A etapa de refinamento ou transformao , segundo o Guia CBOK, responsvel pela transformao dos processos, implementando o resultado da anlise de desempenho. Ela ainda trata de desafios associados gesto de mudanas na organizao, melhoria contnua e otimizao de processo. Alternativamente, chamada de encenao, revendo o modelo de processo e implantando na prtica as mudanas propostas aps o estudo de variados cenrios. ### Sistemas de informao BPM Nvel de Maturidade de Processos: A viso atualmente utilizada de Gesto de Processos de Negcio define um ciclo de vida de um processo que parte de sua descoberta e segue at sua implementao. De modo a tornar a instituio apta implantao de uma soluo tecnolgica de gerenciamento de processos, desenvolveu-se um modelo de maturidade de processos de negcio, o Business Process Maturity Model. O modelo encontra-se dividido em cinco nveis de maturidade, assim como os demais modelos baseados no Process Maturity Framework. Cada um de seus estgios representa a maneira como a organizao transformada na medida em que seus processos. Nvel 1 Inicial Os processos so executados de maneira ad-hoc, o gerenciamento no consistente e difcil prever os resultados. Nvel 2 Gerenciado A gesto equilibra os esforos nas unidades de trabalho, garantindo que sejam executados de modo que se possa repetir o procedimento e satisfazer os compromissos primrios dos grupos de trabalho. No entanto, outras unidades de trabalho que executam tarefas similares podem usar diferentes procedimentos. Nvel 3 Padronizado Os processos padres so consolidados com base nas melhores prticas identificadas pelos grupos de trabalho, e procedimentos de adaptao so oferecidos para suportar

diferentes necessidades do negcio. Os processos padronizados propiciam uma economia de escala e base para o aprendizado atravs de meios comuns e experincias. Nvel 4 Previsvel As capacidades habilitadas pelos processos padronizados so exploradas e devolvidas s unidades de trabalho. O desempenho dos processos gerenciado estatisticamente durante a execuo de todo o workflow, entendendo e controlando a variao, de forma que os resultados dos processos sejam previstos ainda em estados intermedirios. Nvel 5 Otimizado Aes de melhorias pr-ativas e oportunistas buscam inovaes que possam fechar os gaps entre a capacidade atual da organizao e a capacidade requerida para alcanar seus objetivos de negcio. Cada um dos nveis de maturidade (2 a 5) composto por reas de processos que habilitam a capacidade respectiva de cada nvel. Dessa forma, a rea de processo estruturada para alcanar metas especficas na criao, suporte e sustentao do estado organizacional caracterstico de cada nvel. Cada uma dessas reas composta por uma coleo de melhores prticas integradas, as quais dizem o que deve ser feito, mas no de que forma deve ser feito. As organizaes ficam, ento, livres para estabelecer os mtodos e abordagens que considerem mais adequados para satisfazer as metas e objetivos de cada rea de negcio. ### Sistemas de informao SOA (Arquitetura orientada a servios) uma abordagem arquitetural corporativa que permite a criao de servios de negcio interoperveis que podem ser facilmente reutilizados e compartilhados entre aplicaes e empresas. Estes servios acontecem por meio de um conjunto de interfaces de servios fracamente acoplados, onde um servio no necessita de detalhes tcnicos da plataforma dos outros servios para a troca de informao ser realizada. Os servios so implementados atravs de componentes com baixo acoplamento. SOA prov independncia de plataforma, linguagem e tecnologia. um estilo que promove integrao entre o negcio e a TI atravs de servios. SOA preconiza como resultado: maior agilidade para atender as novas demandas, flexibilidade para atender as mudanas, reduo de custo e reuso de ativos (servios). Utiliza topologia de rede para a troca de mensagens. Servio: tarefa repetitiva de negcios. Recebe requisies e responde encapsulando todo o detalhe do seu processamento. uma unidade de trabalho feita por um fornecedor de servio para fornecer resultados finais requeridos por um consumidor de servio. invocado atravs de protocolos de comunicao independentes da localizao e da tecnologia de suporte. Arquitetura a estrutura do sistema composta pelos elementos de software, propriedades visveis destes elementos e o relacionamento entre eles. SOA no tecnologia, produto, ferramenta, apenas o uso de WebService, BPM. Os servios so funes de negcio que implementam as processos de negcio. Pode haver composio de servios.

Os servios devem ser descobertos dinamicamente. Devem evitar que recursos sejam alocados por muito tempo. Servios devem ser reusados. SOA prov integrao de sistemas. Componentes bsicos de uma SOA: provedor de servio; consumidor de servio; registro de servio. ESB (Enterprise Service Bus) (Barramento de servios corporativos) um padro arquitetural que otimiza a distribuio da informao entre diferentes tipos de aplicaes provendo transparncia de localizao. (SOA 6.pdf, slide 17). ### Sistemas de informacao Workflow Workflow o movimento de documentos e/ou tarefas atravs de um processo de trabalho. o aspecto operacional de um procedimento de trabalho: como as tarefas so realizadas, quem as executa, suas ordens de execuo, como elas so sincronizadas, como estas tarefas esto sendo acompanhadas. Nada mais que resultado da evoluo da expresso "automao de processos". Vantagens do workflow: - usurios no perdem tempo escolhendo em qual item trabalhar; - possibilidade de processamento paralelo, onde duas tarefas so executadas ao mesmo tempo; - garantia de que o trabalho seja executado da forma como foi planejado; - os gerentes podem cuidar da equipe e das tarefas de negcios, tais como desempenhos individuais, otimizao de processos e casos especiais. Um exrcito de empregadas no mais necessrio. Workflows podem ser caracterizados de formas distintas: Ad hoc: descrevem processos simples onde difcil encontrar um esquema para a coordenao e cooperao de tarefas, onde no h um padro fixo para o fluxo de informaes entre as pessoas envolvidas. Geralmente usa-se o email como plataforma quando informatizado. Exemplo: processos de escritrio, documentao de produtos e propostas de vendas. Produo: workflow de produo pr-definido e priorizado, suportando assim um grande volume. O trabalho pode ser pr-definido ou seguir um procedimento geral. Exemplo: processamento de requisio de seguros, de faturas bancrias e de carto de crdito. Administrativo: meio termo entre o ad hoc e o de produo. Envolve atividades fracamente estruturadas, repetitivas, previsveis e com regras simples de coordenao de tarefa. Exemplo: processamento de ordem de compras e autorizao de viagens e frias. ### Sistemas de informacao

ERP (Enterprise resource planning): Planejamento de recurso empresarial ou sistemas integrados de gesto empresarial. Pode-se definir ERP como um pacote de software de negcios que permite companhia automatizar e integrar a maioria dos processos de negcios, compartilhar prticas e dados comuns atravs de toda a empresa e produzir e acessar em um ambiente de tempo real. Os pacotes ERP so pacotes comerciais de software, so integrados, so desenvolvidos a partir de modelos-padro de processos, tem grande abrangncia funcional, utilizam um banco de dados corporativo e requerem procedimentos de ajuste (precisam ser adaptados para atender a uma determinada empresa). Os sistemas ERP so geralmente divididos em mdulos que se comunicam e atualizam um banco de dados, de modo que, informaes alimentadas num mdulo, so instantaneamente disponibilizadas para os demais mdulos que delas dependam. Os sistemas ERP so uma evoluo dos sistemas MRP II (manufacturing resource planning) cujo princpio o clculo de necessidades, uma tcnica de gesto que permite o clculo, viabilizado pelo uso de computador, das quantidades e dos momentos em que so necessrios os recursos de manufatura (pessoas, materiais, equipamentos, etc.) para que se cumpram os programas de entrega de produtos com um mnimo de formao de estoques. Os sistemas ERP garantem que as empresas no tomem decises sem levar em considerao seus impactos sobre a cadeia de fornecimento. As decises de produo so afetadas e afetam todas as outras reas da empresa. Para tomar melhores decises, essas interaes devem ser levadas em considerao. O software o meio para conseguir esta interao dos processos de deciso. Os sistemas ERP: - so pacotes de softwares comerciais; - so desenvolvidos a partir de modelos-padro de processos de negcio (uso do termo "best practices"); - so integrados; - tem grande abrangncia funcional; - utilizam um banco de dados corporativo; - requerem procedimentos de ajuste; Genericamente, sistemas integrados podem ser caracterizados como sistemas informatizados que so utilizados em conjunto por membros de diferentes departamentos dentro de uma mesma organizao. Os sistemas ERP realmente integrados so construdos como um nico sistema empresarial que atende aos diversos departamentos da empresa. O fato de um sistema ERP ser integrado no significa necessariamente que uma empresa est integrada. O sistema meramente uma ferramenta para a empresa atingir este objetivo.

A utilizao de um banco de dados centralizado traz desafios organizacionais significativos para a empresa, mas traz bastante compensao o que faz valer a pena. Esta prtica preconizada (recomendada) pelos sistemas ERP. Uma diferena dos sistemas ERP e outros sistemas de software tradicionais a abrangncia funcional dos primeiros, isto , os sistemas ERP abrangem uma ampla gama de funes empresariais. Normalmente nos sistemas tradicionais, somente uma funo empresarial era atendida. Nos sistemas ERP vrias so atendidas. A ideia tentar atender ao mximo possvel de atividades. claro que existem pacotes que superam as funes relacionadas nos sistemas ERP. A necessidade de utilizao destas funes obriga a criao de uma interface de comunicao entre os sistemas ERP e outros sistemas. A adaptao o meio atravs do qual o sistema ERP preparado para ser utilizado em uma determinada empresa. improvvel que um pacote v atender exatamente aos requisitos da empresa, o que gera discrepncia entre os dois (pacote e empresa). ### Sistemas de informacao ECM (Enterprise Content Management) As empresas precisam administrar seus documentos. Alguns esto em banco de dados. Outros esto em lugares diversos sem uma relao entre si. Com o aumento destes documentos, h uma dificuldade de encontrar o que se procura, leva-se muito tempo. O uso de sistemas ECM confere maior agilidade e segurana nos processos crticos de uma oganizao. Os sistemas ECM permitem o gerenciamento das informaes noestruturadas, enquanto elas existirem. Os sistemas ECM, associados s informaes de banco de dados estruturados e disponibilizados na internet, permite s organizaes maximizar o valor das informaes perante seus fornecedores, clientes e, tambm, internamente, de forma online e em tempo real. ### Banco de dados Regras de integridade So condies impostas qualquer atualizao nos banco de dados para que os dados sejam precisos/corretos. Tipos de restries: - declarativa: diz respeito ao uso de constraints e rules. - procedural: diz respeito ao uso de stored procedures e triggers. Aspectos: - integridade de domnio: dados que so permitidos nas colunas da tabela. - integridade de entidade: refere-se unicidade de registros na tabela. - integridade referencial: usada para manter consistncia entre as tuplas. ###

Banco de dados Indexao ndices densos: possuem uma entrada de ndice para cada registro. ndices esparsos: possuem entradas de ndices para apenas alguns dos valores. ndices primrios: contem dois campos. Um indica a chave primria e o outro indica um ponteiro para um bloco de disco. Ordenado pela chave primria. um ndice esparso. Gasta menos espao, mas no to eficiente quanto o secundrio. ndices clustering: quando o campo de classificao pode ter valores repetidos. Nesse caso, os campos so agrupados e ordenados. Esparso. Gasta menos espao, mas no to eficiente quanto o secundrio. ndices secundrios: ordenado atravs de qualquer campo. Gasta mais espao, mas mais rpido do que o primrio. Existem, tambm, ndices com mltiplos nveis. ### Banco de dados Controle de concorrncia Bloqueio binrio: lock(x), unlock(x), read(x), write(x). varivel de bloqueio binrio. 1 = bloqueado. 0 = desbloqueado. Vantagem: simples de se implementar. Desvantagem: restrito (se uma transao precisar de X somente para leitura, mesmo se X estiver bloqueado, seria bom se a transao pudesse acessar mesmo assim.) - Uma transao T deve garantir o lock antes de read e write; - Uma transao T deve garantir o unlock depois de read e write; - Uma transao T no resultar em um lock em X se ele j estiver bloqueado. Bloqueio de mltiplo modo: os estados de X, agora, so: read_lock (leitura compartilhada: resolve o problema da restrio do bloqueio binrio), write_lock (escrita exclusiva: somente uma transao pode escrever no item) e unlock. - Uma transao T deve garantir read_lock ou write_lock antes de ler_item; - Uma transao T deve garantir write_lock antes de escrever_item; - Uma transao T deve garantir unlock depois de escrever ou ler item; - Uma transao T no vai gerar uma operao read_lock ou write_lock se ela j controlar o bloqueio de leitura (compartilhado) ou de escrita (exclusivo). H exceo; - Uma transao T s pode resultar em unlock se ela tiver controle de leitura ou escrita sobre o item. A exceo se somente T controlar o item X, ento pode haver uma promoo de bloqueio. Caso contrrio, T deve esperar. (Promoo de bloqueio = de read para write. Rebaixamento de bloqueio = write para read). Bloqueio de 2-fases bsico: uma transao pode usar X e no pode liber-lo por precisar de bloquear Y. Ela pode bloquear Y antes de us-lo e depois usar X. Garante escalonamento seriveis por conflito.

Requer que cada transao emita solicitaes de bloqueio e desbloqueio em duas fases: 1: fase de expanso/crescimento * transao pode obter bloqueios; * transao no pode liberar bloqueios; 2: fase de encolhimento * transao pode liberar bloqueios; * transao no pode obter bloqueios; O algoritmo garante serializao. No garante ausncia de deadlock. Bloqueio compartilhado: usados para operao de leitura que no alteram ou atualizam dados, como uma instruo SELECT. 2PL conservador: bloqueia todos os itens antes de comear a us-los. Dead-lock free. Difcil de us-lo na prtica. 2PL estrito (mais popular): no libera nenhum dos seus bloqueios exclusivos (escritos) at que ela efetive ou aborte. No dead-lock free. 2PL rigoroso: no libera nenhum dos seus bloqueios exclusivos e compartilhados at que ela efetive ou aborte. Problemas: starvation (quando uma transao no pode continuar por um perodo indefinido enquanto as outras transaes podem. Acontece quando o esquema de espera para itens bloqueados for parcial, dando prioridade para algumas transaes sobre as outras)e deadlock. * Ordenao das transaes por timestamp. * Controle de concorrncia otimista: faz tudo que tiver que fazer. Depois tem uma fase de verificao pra ver se alguma atualizao violou a serializao. Atualizao perdida: ocorre quando duas transaes, que acessam o mesmo item do BD, possuem operaes intercaladas entre si, tornando o valor do item incorreto. ### Banco de dados Recuperao de falhas Garantia da atomicidade e durabilidade de transaes. tcnicas: - steal: dados na cache podem ser gravados antes do commit. (no h necessidade de manter blocos bloqueados por transao) - not steal: dados na cache no podem ser gravados antes do commit. (processo de recovery mais simples; evita dados de transao inacabada sendo gravados no BD) - force: assim que os dados alcanam o commit, eles so gravados no BD. (garante a durabilidade da transao o mais cedo. permite o REDO se necessrio).

- not force: os dados no precisam ser gravados no BD ao atingir o commit. (permanecendo em cache, eles podem ser utilizados por outras transaes de forma mais rpida) Implementao de um meio estvel: - replicao da informao em vrios meios de armazenamento no-voltil independentes; - uso de sistemas RAID; - armazenar backups em locais fisicamente diferentes; - manter cada bloco de armazenamento em sites remotos; - Atualizao in-place: grava o item no mesmo lugar do valor antigo. necessrio Log gravado antes do BD. - Shadowing: grava o item em uma localizao diferente. No necessrio o Log gravado. - Write-ahead logging: na atualizao in-place, o valor da imagem anterior deve ser gravado em Log antes que o valor da imagem depois seja gravada no BD. ### Banco de dados BD distribudos (BDD) Os bancos de dados esto num mesmo local fsico. 12 regras para um SGBDD: 1. autonomia local: cada n deve prover mecanismos de segurana, bloqueio, acesso, integridade e recuperao aps falha. 2. no dependncia de um n central: ele seria um nico ponto de falha e o sobrecarregaria com perda de desempenho. 3. operao contnua. 4. transparncia/independncia de localizao. 5. independncia de fragmentao: as tabelas podem estar fragmentadas localizadas fisicamente em diferentes ns. 6. independncia de replicao: os dados podem estar replicados em vrios ns da rede. 7. processamento de consultas distribudo. 8. gerenciamento de transaes distribudas: as regras para transaes locais devem ser as mesmas para transaes distribudas (ACID). 9. independncia de hardware. 10. independncia de sistema operacional. 11. independncia de rede. 12. independncia de SGBD. vantagens: - compartilhamento de dados e controle distribudo. - maior confiabilidade. - maior disponibilidade. - maior desempenho no processamento. - maior escalabilidade.

desvantagens: - custo maior. - grande potencial para bugs. - aumento de overhead de processamento. - questes de projeto especficas. - dificuldades para obter conhecimento global. ### Banco de dados Arquitetura de 3 camadas: apresentao (servios de aplicativo), negcio (servios de negcios) e acesso aos dados (servios de dados). A funcionalidade de particionamento ao longo destas camadas fornece um padro relativamente confivel para fins de escalabilidade: adicionando servidores e equilibrando novamente o processamento entre os servidores de dados e de negcios, um grau maior de escalabilidade atingido. Apresentao: oferece o contedo esttico e dinmico personalizado. Disponveis em vrios formatos. As classes desta camada utilizam os servios oferecidos pela camada de negcio. Lidam com as questes de apresentao da GUI e tendem a ser executados em uma estao de trabalho de desktop dedicada com um ambiente operacional grfico de janelas. As alteraes na funcionalidade tendem a ser ditadas pela facilidade de uso. Negcio: nela esto todas as classes inerentes ao domnio da aplicao. Refletem o conhecimento codificado pelos processos de negcio. Eles manipulam e sintetizam as informaes vindas da camada de acesso aos dados e mandam para a camda de apresentao. Os servios de negcio so geralmente usados por mais de um usurio e, por isso, tendem a ser alocados em servidores especializados, embora possa residir nos mesmos ns que os servios de dados. Acesso aos dados: persistncia e acesso aos dados da aplicao. Ela isola o resto da aplicao. Tendem a ser implementados atravs de uma tecnologia de servidor de banco de dados que tendem a ser executados em um ou mais ns de alto desempenho e alta largura de banda que atendem a centenas ou milhares de usurios. bem provvel que esta camada seja alterada quando a representao e o relacionamento entre as informaes armazenadas tambm forem alterados. Vantagens: modularidade, manutenibilidade, extensibilidade, reusabilidade. Desvantagens: qualquer alterao em um nome de campo de tabela ter que ser feita em diversas partes da aplicao. ### Engenharia de software Arquitetura de projeto

Padro MVC: model-view-controller Um dos mais utilizados na atualidade. - modelo contm as funcionalidades e os dados. - viso mostra as informaes para o usurio. - controlador manipula as entradas. A idia que uma mesma lgica de negcios possa ser acessada e visualizadas atravs de diversas interfaces. ### Engenharia de software Padres de projeto (Padro criacional) Abrange a configurao e inicializao de objetos e classes. Fbrica abstrata: Prov uma interface para criar famlias de objetos relacionados ou dependentes sem especificar suas classes concretas. Adia a criao de objetos de sua subclasse concreta. S cria os produtos, obrigao das subclasses concretas cri-los de fato. Mtodo fbrica: Prov uma interface para criar um objeto, mas deixa a subclasse decidir qual classe instanciar. til quando uma classe no pode antecipar a classe de objetos que deve ser criada. Builder: Separa a construo de um objeto complexo da sua representao, de forma que o mesmo processo de construo possa criar diferentes representaes. ( o caso de um conversor de formatos de textos. Existe a classe TextConverter que chamar as subclasses especficas, por exemplo, ASCIIConverter, TeXConverter, etc. Toda vez que o RTFReader ler um tipo de texto, ele envia o pedido de converso para o TextConverter. Este, por sua vez, chama a subclasse correta.) A classe que converte se chama Builder (TextConverter). A que l se chama Director (RTFReader). Prototype: Especifica novos tipos de objetos a criar usando uma instncia prototpica e cria novos objetos copiando este prottipo. Singleton: Assegura que uma classe tenha somente uma instncia e prov um ponto de acesso a ela. ### Engenharia de sotware Projeto arquitetural

Consiste em um mapeamento do sistema de forma que sejam representadas as diferentes partes com suas interaes e mecanismos de interconexes. Ou seja, ele representa a estrutura dos componentes de dados e programas que so necessrios para construir um sistema. Elementos de um projeto arquitetural: arquitetura do computador, o SO, o SGBD, a linguagem de programao, a anlise de sistemas legados e tratamentos de requisitos no funcionais. Toda a tecnologia do sistema deve ser definida no projeto arquitetural. Um projeto arquitetural facilita no desenvolvimento do sistema, prev possveis problemas que poderiam ter impacto e estrutura o sistema e diz como os componentes trabalham em conjunto. A elaborao de um documento de projeto arquitetural (DPA) consiste em: - confirmao do entendimento de um DRS (documento de requisito de software): esta etapa importante quando o desenvolvedor no participou da fase de requisitos. - construo de um modelo sistmico: propicia a produo de um modelo abstrato que descreve de forma simplificada o sistema. Utiliza um critrio de decomposio hierrquico, composto de smbolos organizados de acordo com algumas convenes, construdos com ajuda de mtodos e ferramentas. - especificao do projeto arquitetural: atribuem-se funes aos componentes maiores obtidos dos requisitos de software e definem-se as estruturas de dados, fluxos de controle, utilizao de recursos computacionais e especifica a linguagem de programao. Devem-se modelar os processamentos utilizando-se diagramas estruturais, esquemas de transformao e diagramas de objetos e comportamento. Os recursos do computador precisam ser estimados e colocados no DPA. - especificao dos testes de integrao: so documentados os testes de integrao, o plano de verificao e de validao do software. Neste documento descreve-se a abrangncia, a abordagem e os recursos requeridos para os testes de integrao. - refinamento dos planos gerenciais: abrange a gerncia de projeto, gerncia de configurao, verificao, validao e garantia de qualidade. - execuo de uma reviso tcnica formal (RTF): h uma reviso tcnica formal nos documentos gerados anteriormente garantindo, a eles, atualizao atravs de uma rede distribuda. ### Engenharia de software Planejamento de projeto de software Caractersticas:

problemas: o software intangvel; no h um processo de software padro; a ES no possui a mesma tradio que a engenharia civil, mecnica e eltrica; grandes projetos de software so nicos normalmente. pontos comuns: tcnicas de planejamento e gerenciamento so amplamente aplicadas em outras reas, alm de serem atividades comuns em outras engenharia. Principais atividades: elaborao de propostas, planejamento e cronograma de projeto, oramento do projeto, monitoramento e revises, seleo e avaliao do pessoal, elaborao de relatrios e apresentaes. Estrutura de um plano de projeto: - introduo; - organizao de projeto; - anlise de riscos; - requisitos necessrios de hardware e software; - estrutura analtica de trabalho; - cronograma de projeto; - mecanismo de monitoramento e elaborao de relatrios. Tipos de planos: - plano de projeto de software: descreve atividades, oramento, recursos, cronograma, equipe, etc. - plano de qualidade: descreve os procedimentos de testes de qualidade que sero utilizados. - plano de validao: descreve a abordagem, os recursos e os mtodos utilizados para validao. - plano de manuteno: prev requisitos, custos e esforo necessrio para a manuteno. - plano de desenvolvimento da equipe: descreve como habilidades e a experincia so desenvolvidas. ### Engenharia de software Gesto de qualidade ISO 9000: disse como produz, produziu como disse, provar que produziu como disse. ISO 9000-3: aplicao da ISO 9000 para software; considera que o processo produtivo orientado a projetos e no a operaes. ISO 9126: mtricas para determinao da qualidade do produto. ISO 14598: processo de avaliao de qualidade do produto. ### Engenharia de software Gerncia de configurao Tarefas: - tarefas preliminares: identificar os itens a serem gerenciados; descrever como os itens selecionados se relacionam (relao de equivalncia, dependncia, derivao, sucesso e

variante); planejar as linhas-base dentro do ciclo de vida do projeto; descrever como os itens sero arquivados e recuperados do repositrio. - identificao: atribuir nomes nicos a cada componente; pelo nome deve ser possvel reconhecer a hierarquia entre os componentes e a evoluo de cada um dos componentes. - controle de mudanas: durante o processo de desenvolvimento de software, mudanas descontroladas podem levar rapidamente ao caos; deve ser institudo na organizao um processo que combine procedimentos humanos e ferramentas automatizadas para proporcionar um mecanismo de controle das mudanas; o processo de controle de mudana deve ser implementado depois que uma linha-base for fixada; - controle de verso: todas as verses devem ser armazenadas e identificadas (isso assegura o controle sobre as verses), sendo que isso feito com uma ferramenta geralmente; conveniente que a identificao das verses seja feita em forma de rvores; - auditoria de configurao: assegura que alteraes foram feitas apropriadamente; a identificao e controle ajudam a manter a ordem, mas, para assegurar que a configurao foi implementada apropriadamente, h necessidade de auditorias; existem dois tipos de auditorias: funcional (preocupa-se com aspectos internos dos arquivos, compreendendo uma verificao tcnica formal nos itens de configurao. Tenta descobrir omisses ou erros na configurao que degradam os padres de construo de software) e fsica (complementa a auditoria funcional, determinando caractersticas que no foram consideradas durante a reviso); - relato de situao: relatar todas as pessoas envolvidas no desenvolvimento e manuteno de software; - controle de interface: controla os itens de configurao que so afetados por itens que no estejam sendo controlados; - controle de subcontratados e fornecedores: coordenam a forma como os itens (que foram adquiridos por outra empresa ou j prontos) so testados e incorporados ao repositrio do projeto. Linhas-base: ajuda a controlar as mudanas sem impedir seriamente as mudanas justificveis. Geralmente cria-se uma linha-base ao final do ciclo de vida de um projeto ou depois de uma manuteno. Um item de configurao (produto de software, produto de desenvolvimento) que passou pela linha-base se diz congelado. Suas caractersticas so: - revisto formalmente e teve a concordncia das partes; - serve como base para um trabalho futuro; - armazenado como um repositrio de itens de configurao; - pode ser alterado somente atravs de procedimentos formais de controle de mudana.

Repositrio de itens de configurao um local sob controle de acesso onde os itens de configurao so armazenados depois de terem sido liberados por uma linha-base. Nos pontos estabelecidos pelas linhas de referncia, os itens de configurao devem ser identificados, anlisados, corrigidos, aprovados e armazenados no repositrio de itens de configurao. Os itens de um repositrio s podem ser alterados mediante uma solicitao de alterao formalmente aprovada pelo gerente de configurao. <= evita inconsistncias. Check in/check out = mtodos para se trabalhar os itens de configurao que j esto no repositrio. Check out = quando uma alterao solicitada, uma cpia do item colocada na rea de trabalho do desenvolvedor. Dentro de sua rea de, o desenvolvedor tem total liberdade de trabalho. Check in = reviso e recolocao do item de configurao no repositrio. Neste caso, uma nova linha base traada de forma que uma nova configurao (contendo o item alterado) seja formada e congelada no repositrio. Aps o check in, libera-se a permisso de alterao deste item de configurao. Os itens de configurao tem controle de acesso. Ao se fazer check out em algum item de configurao, este passa a ficar bloqueado. Ferraments de gerncia de configurao de software: CVS (concurrent version system), RCS (revision control system), SCCS (source code control system), VersionWeb (web pages versions management). ### Engenharia de software Engenharia reversa e reengenharia Os elementos da engenharia reversa: nvel de abstrao (quanto maior o nvel de abstrao, mais compreensveis se tornam as informaes); completitude do processo (nvel de detalhes que fornecido em cada nvel de abstrao); interatividade (grau de participao do ser humano na engenharia reversa - quanto maior a abstrao, maior deve ser a interatividade ou a completitude ser prejudicada); direcionalidade (sentido nico: toda informao extrada do cdigo fonte usada para manuteno. sentido duplo: a informao usada para alimentar uma ferramenta de reengenharia). Documentos utilizados para realizar engenharia reversa: cdigo fonte, informaes do usurio e/ou analista, documentao existente (manual do usurio, manual do sistema, DFD's, fluxogramas, etc.). Manutenes adaptativas: adequar o software ao ambiente. Manutenes evolutivas: adicionar funcionalidades ao software. Manutenes corretivas: correo de erros. Mudanas preventivas: reduo de esforo em futuras mudanas.

Reengenharia de software melhora o entendimento do software, prepara ou melhora o software aumentando sua manuteno, seu reuso e sua extenso. ### Engenharia de software Padres de projeto (Padro estrutural) Lida com as interfaces e a implementao das classes e dos objetos. Adapter: Converte a interface de uma classe em outra que o cliente espera. Ele permite que classes trabalhem juntas sendo que no seria possvel devido s suas incompatibilidades. Bridge: Desacopla uma abstrao de sua implementao de forma que as duas podem variar independentemente. Composite: Compe objetos em estruturas de rvores para representar hierarquias todo-parte. Permite o cliente a tratar os objetos individuais e grupos de objetos de forma uniforme. Decorator: Adiciona responsabilidades individuais a um objeto dinamicamente. Prov uma alternativa flexvel herana extendendo funcionalidade. O decorator precisa de uma classe abstrata decoradora e componentes concretos para o padro ser til. Faade: Prov uma interface unificada para um conjunto de interfaces em um subsistema. Define uma interface de nvel maior que faz o subsistema mais fcil para usar. Flyweight: Minimiza o uso de memria por compartilhar o mximo de dados possveis com objetos similares. Proxy: Prov um substituto para outro objeto para controlar o acesso a esse objeto. ### Engenharia de software Padres de projeto (Padro comportamental) Lida com as interaes dinmicas entre grupos de classes e objetos. Chain of responsability:

Evita o acoplamento entre o remetente e o destinatrio. Encadeia os objetos destinatrios a passar a requisio ao longo de uma cadeia at que um objeto a manipula. Command: Encapsula uma requisio em um objeto. Assim permite parametrizar clientes com diferentes requisies, filas ou requisio de log e suporta operaes de desfazer. Interpreter: Dada uma linguagem, define uma representao para a sua gramtica junto com um interpretador que usa a representao para interpretar sentenas na linguagem. Iterator: Prov um meio de acessar, sequencialmente, os elementos de um objeto agregado sem expor sua representao. Mediator: Define um objeto que encapsula como um conjunto de objetos interage. Promove um acoplamento fraco evitando que os objetos se refiram uns aos outros explicitamente e permite que voc varie as interaes deles indepentemente. Memento: Sem violar a encapsulamento, captura e externaliza o estado interno de um objeto de forma que este estado possa ser restaurado mais tarde. Observer: Define uma dependncia entre objetos de um para muitos de forma que, quando um objeto muda de estado, os outros so notificados e atualizam automaticamente. State: Permite um objeto a mudar seu comportamento quando seu estado interno muda. Strategy: Define uma famlia de algoritmos, encapsula cada um e os faz trocveis. Permite que o algoritmo varie independentemente dos clientes que o usam. Template Method: Define um esqueleto de um algoritmo em uma operao, adiando alguns passos da herana. Permite s subclasses redefinirem certos passos de um algoritmo sem alterar a estrutura do algoritmo. Visitor: Representa uma operao a ser realizada nos elementos da estrutura de um objeto. Permite voc definir uma operao sem mudar as classes dos elementos no qual ele opera. ### Linguagem de programao J2EE

Camadas: Cliente: corresponde camada de apresentao que roda no cliente. - Thin client: Usualmente no fazem consultas a banco de dados, no executam regras de negcio complexas ou se conectam apliaes legadas. - Applets: pequena aplicao java que executa na JVM instalada no web browser. - application clients: prov uma interface para que os usurios executem suas tarefas remotamente. Apresentao: corresponde camada de apresentao que roda no servidor (ex. processos que tratam requisies HTTP, pginas servidoras). Componentes so criados usando tecnologia JSP. Servlets so classes criadas programaticamente e que, dinamicamente, processam requisies e constroem uma resposta. Negcio: corresponde camada de domnio. responsvel por implementar, via enterprise beans, a lgica de negcio da aplicao referente a um domnio de negcio particular. Existem trs tipos de enterprise beans: - session beans: representam a comunicao com o cliente. Quando o cliente finaliza a conexo, o session bean e seus dados tambm so removidos da memria. - entity beans: representam os dados persistentes armazenados no banco de dados. - message-driven beans: combina caractersticas de session beans e java message service (JMS) message listener, o que permite que este receba mensagens JMS assincronamente. Integrao: fonte de dados. Recursos: recursos externos com os quais a fonte de dados se comunica. ### Sistemas de informacao Data warehouse Ferramenta SSIS (SQL Server Integration Service) permite alterar os dados-fonte para um formato nico. Utilizado na gerao de dados OLAP utilizando tabelas unificadas. O armazenamento dos cubos pode ser MOLAP, HOLAP e ROLAP. MOLAP: cubos e fonte de dados ficam gravados no OLAP (rpido, mas ocupa muito espao). HOLAP: cubos ficam no OLAP e os dados ficam no OLTP (relativamente rpido e ocupa relativamente pouco espao - modelo mais utilizado). ROLAP: a cada consulta o cubo deve ser inteiramente processado (lento, mas ocupa pouco espao). ### Banco de dados

RAID O objetivo melhorar o desempenho de modo a equiparar as taxas (muitos diferentes) entre os discos e as memrias dos processadores. Striping (separao em tiras) de dados usa o paralelismo para melhorar o desempenho do disco. Permite que diversas entradas e sadas sejam realizadas em paralelo, fornecendo, assim, altas taxas globais de transferncia. Alm disso, por meio de informaes redundantes, usando paridade ou outro cdigo para correo de erros, a confiabilidade pode ser melhorada. Desvantagens: operaes adicionais de entradas e sadas para a gravao, processamento adicional para a manuteno da redundncia e para a execuo de recuperao de erros, alm da capacidade de disco adicional para armazenar as informaes redundantes. Existem 7 tipos de RAID (0 at 6). RAID 0: utiliza striping de dados, no possui redundncia, apresenta melhor desempenho de gravao (j que as atualizaes no precisam ser duplicadas). A reconstruo, em caso de falha, mais fcil neste nvel. RAID 1: utiliza o espelhamento de disco. Neste nvel, h um agendamento de pedido de leitura no disco com menor expectativa de atrasos de busca e rotacional. Usado em aplicaes crticas como transaes de entrada e sada. RAID 2: utiliza redundncia estilo memria atravs do uso de cdigos Hamming, os quais contm bits de paridade. Inclui tanto a deteco e a correo de erros, embora hoje isso no seja mais necessrio j que os HD's j vm com essa propriedade. RAID 3: usa um nico disco de paridade, contando com a controladora para identificar qual deles falhou. Taxas de transferncia mais altas. Usada em armazenamento de grandes volumes. RAID 4 e 5: usam striping de dados no nvel de bloco. O nvel 5 distribui dados e informao de paridade por todos os discos. O nvel 5 usado em armazenamento de grandes volumes. RAID 6: aplica o esquema de redundncia P+Q usando os cdigos Reed-Solomon para proteo contra at duas falhas de discos por meio de apenas dois discos redundantes. RAID 1 + 0: combina o striping com espelhamento. ### Engenharia de software Mtrica

Duas tcnicas de medio importantes: FPA (Anlise por ponto de funo) e COCOMO (Construtive Cost Model). O FPA mede a complexidade do software pela quantificao de funcionalidade. O COCOMO busca medir esforo, prazo e tamanho da equipe. Ambos medem esforo necessrio para a construo do software. Outras mtricas podem ser: nmero de classes e mtodos, linhas de cdigo por mtodo, profundidade mxima da hierarquia de classes, nmero de defeitos relatados, nmero de pessoas-dia para desenvolver um componente, nmero de funes que chamam outra funo (alto acoplamento), nmero de funes chamadas por outra funo (alta complexidade), extenso do cdigo (quanto maior, mais propenso a erro), quantidade de declaraes aninhadas (quanto mais, mais propensa a erro), profundidade de rvore de herana (mais profundo, mais complexo), nmero de operaes sobrescritas (um nmero alto indica que a classe me possa ser inadequada), etc. No contexto de orientao a objeto, mtricas associadas a classes podem ser usadas para avaliao da reusabilidade. Algumas mtricas so de uso abrangente, enquanto outras so dependentes de paradigma de programao ou da linguagem em questo. O resultado pode variar muito dependendo do processo utilizado. Existem 4 categorias bsicas no desenvolvimento de software orientados a objetos: tamanho do sistema, tamanho de classe ou mtodo, acoplamento e herana, classes ou mtodos internos. Medir pontos de funo: - (funes transacionais) entrada externa (fornece dados a uma aplicao originados de um usurio ou transmitidas de outras aplicaes), - sada externa (so originados de uma aplicao e fornece informaes para o usurio), - consulta externa (entradas online que resultam na resposta imediata da aplicao sob a forma de uma sada online), - (funes de dados) arquivo lgico interno (grupo lgico de dados relacionados ou informao de controle identificado pelo usurio) e - interface externa (grupo lgico de dados relacionados ou informao de controle referenciado pela aplicao). Em uma tela sero exibidos os nomes, cpf's e empresas de cada indivduo. Nesta tela tem somente uma funo transacional (sada externa). Complexidade ciclomtica: determina a complexidade de um programa estruturado (cclico). Foi desenvolvida em 1976 por Thomas J. McCabe e reflete diretamente o nmero de caminhos independentes que um programa pode tomar durante sua execuo. Ela determina o limite superior para o nmero de testes que devem ser executados garantindo que todas as instrues sero executadas pelo menos uma vez. Existe uma frmula para calcular a complexidade ciclomtica: CC = E - N + 2 (E = edge, aresta, arco; N = node, n). Outro modo contar o nmero de loops fechados (que so formados por condicionais e loops) e somar ao nmero de pontos de sada (return). Segundo McCabe, se CC est entre: 1 e 10 = mtodo simples, sem risco; 11 e 20 = mtodos medianamente complexos, com risco moderado; 21 e 50 = mtodos complexos, de alto risco; 51 ou mais = mtodos instveis de altssimo risco.

Se no tiver goto, ento CC = nmero de comparaes (sem e ou ou) + 1. Se uma comparao tiver e, ento ela deve ser contada mais de 1 vez. Exemplo: if(x == 1 || x == 2) igual a 2 comparaes. ### Engenharia de software Certificados CMMI valem por trs anos*. CMMI e Mtodos geis podem ser compatveis*. CMMI diz o que se espera de um processo, e no qual processo usar e como usar. CMMI tem que atender a expectativa do cliente (e no superar). Arquivo posts_cmmi.pdf Categorias: - Gerenciamento de projetos aparece no nvel 2 at o 4. Nvel 2: planejamento do projeto; monitoramento e controle do projeto; gesto de acordo com o fornecedor. Nvel 3: gesto integrada do projeto; gesto integrada de fornecedores; gesto de risco; integrao de equipes. Nvel 4: gesto quantitativa do projeto. - Gerenciamento de processos s aparece no nvel 3 pra cima. Nvel 3: treinamento organizacional; foco no processo organizacional; definio do processo organizacional. Nvel 4: desempenho do processo organizacional. Nvel 5: inovao e implantao organizacional. - Processos de engenharia Nvel 2: gerenciamento de requisitos. Nvel 3: desenvolvimento de requisitos; soluo tcnica; integrao de produtos; verificao e validao. - Suporte Nvel 2: gerenciamento de configurao; garantia de qualidade de processo e produto; medio e anlise. Nvel 3: anlise e soluo de decises; ambiente organizacional para integrao. Nvel 5: anlise e soluo de causas. * Fonte: www.sei.cmu.edu ### Linguagem de programao J2EE

Reflexo um mecanismo para descobrir dados a respeito de um programa em tempo de execuo. Com ela, permitido conseguir descobrir informaes sobre membros (campos), mtodos, construtores de classes e superclasses de uma classe. Pode-se operar nos campos e mtodos que foram descobertos. Pode-se determinar a classe de um objeto. Pode-se descobrir quais constantes e declaraes de mtodos pertencem a uma interface. Pode-se criar uma instncia de uma classe cujo nome no sabemos at o tempo de execuo. Pode-se obter e definir o valor do campo de um objeto. Pode-se invocar um mtodo em um objeto. Pode-se criar um novo array cujo tamanho e tipo de dados s sero sabidos em tempo de execuo. A Java Reflection API geralmente usada para criar ferramentas tais como debuggers, class browsers e construtores de GUI. ### Engenharia de software Gerncia de projeto Redes PERT Mtodo dos 3 pontos: Frmula para o valor esperado da atividade = (pessimista + otimista + 4 x provvel)/6 Frmula para o desvio padro = (pessimista - otimista)/6 ### Engenharia de software UML Smbolos: + pblico - privado # protegido ~ pacote itlico = abstrato ou virtual sublinhado = esttico ### Engenharia de software Diagrama de classes Navegabilidade: serve pra indicar a associao entre duas classes. representada por uma seta aberta. Quando no h setas, pressupe-se que a associao navegvel nas duas direes. Qualificadores: servem para definir e restringir ainda mais um conjunto de instncias associadas a uma outra instncia. Normalmente um qualificador reduz a multiplicidade

do papel oposto. Os qualificadores so desenhados como pequenas caixas na extremidade da associao, anexados classe qualificadora. Eles fazem parte da associao e no da classe. Uma caixa qualificadora pode conter vrios valores de qualificador. Uma associao qualificadora uma variante do atributo de associao. Nomeao: o nome de uma associao. Ele fica no caminho da associao ou adjacente ao caminho. Multiplicidade: identifica a quantidade de entidades possveis em uma associao. Restrio: especifica uma condio que tem que ser verificada. Fica entre chaves. ### Linguagem de programao J2EE Padres da camada de apresentao: - Intercepting filter: viabiliza pr e ps processamentos de requisies. - Front controller: oferece um controlador centralizado para gerenciar o processamento de requisies. - Context object: encapsula estado de forma independente de protocolo para compartilhamento pela aplicao. - Application controller: centraliza e modulariza o gerenciamento de Views e de aes. - View helper: encapsula lgica no-relacionada formatao. - Composite view: cria uma view composta de componentes menores. - Service to worker: combina front controller com um dispatcher e helper. Concentra-se em despachar a requisio. - Dispatcher view: combina front controller com um dispatcher e helper. Realiza mais processamento depois. Padres da camada de negcio: - Business delegate: desacopla camada de apresentao e de servios. - Service locator: encapsula lgica de consulta e criao de objetos de servio. - Session faade: oculta a complexidade de objetos de negcio e centraliza controle. - Application service: centraliza e agrega comportamento para oferecer uma camada de servios uniforme. - Business object: separa dados de negcio e lgica usando modelo de objetos. - Composite entity: implementa business object persistentes combinando Entity beans locais e POJO's (plain old java objects). - Transfer object (value object): reduz o trfego e facilita transferncias de dados entre camadas. Antigamente chamado de value object ou DTO. - Transfer object assembler: constri um value object composto de mltiplas fontes. Antigamente chamado de value object assembler. - Value list handler: lida com execuo de queries, caching de resultados, etc. Padres da camada de integrao

- Data access object: abstrai fontes de dados e oferece acesso tranparente aos dados. - Service activator: facilita o processamento assncrono para componentes EJB. - Domain store: oferece um mecanismo transparente de persistncia para objetos de negcio. - Web service broker: expe um ou mais servios usando XML e protocolos web. Roadmap associa inteno com padres. "Se voc procura por isso, ento use o padro tal." Padres se encaixam bem quando se procura alterar uma arquitetura para melhorar algum aspecto de um sistema, tal como performance, escalabilidade, reuso e manuteno. ### Linguagem de programao Antipadres JEE uma soluo repetida de cdigo ou de projeto que leva a um mau resultado: - Baixo desempenho; - Cdigo difcil de manter; - Completo insucesso do projeto; AntiPatterns so padres. Tambm so solues que ocorrem comumente no desenvolvimento de software. Como os padres, so organizados em catlogos seguindo um determinado template: - Descrio da forma geral - Sintomas e causas - Conseqncias Ao contrrio dos padres, geram conseqncias negativas: - Estratgias de reestruturao (refatorao) da soluo so sugeridas. ### Engenharia de software Engenharia de requisito A anlise estruturada uma atividade de construo de modelos onde os usurios obtem uma ideia mais clara do sistema atravs do diagrama de fluxo de dados. O DFD uma ferramenta de modelagem que representa um sistema de informaes como uma rede de processos interligados por fluxos e depsitos de dados. A anlise estruturada no se preocupava com a organizao, ou seja, no existiam conceitos de requisitos organizacionais, e tambm no existiam conceitos claros e relacionados distino entre requisitos funcionais e no funcionais. A anlise essencial uma anlise estruturada moderna que preservou todos os modelos de anlise estruturada, porm definiu mais claramente os passos da metodologia.

Um DFD est em equilbrio com um DER se cada depsito do DFD corresponder a uma entidade, ou a um relacionamento ou combinao de um tipo objeto e de um relacionamento do DER. Os nomes das entidades e dos depsitos devem coincidir. No h fluxo de dados diretamente de um depsito para o outro (ou para uma entidade), ou de uma entidade para outra (ou para um depsito) sem passar por um processo. Ele necessrio como intermediador. A especificao de processos de um DFD pode ser feita atravs de tabelas de deciso, linguagem estruturada, condies pr-ps, fluxogramas e diagramas de NassiShneiderman. - DFD's ajudam o analista a: resumir a informao de como o sistema funciona; compreender os componentes principais do sistema; a definir funes reutilizveis; compreender as interdependncias entre subsistemas; desenvolver eficientemente uma aplicao. - uma boa ferramenta de comunicao entre utilizadores e analistas. - Permite obter uma melhor estimativa dos recursos envolvidos no projeto global, em funo dos recursos envolvidos em cada um dos processos. - Em geral, o detalhamento de um processo feito por exploso. - Os processos primitivos so detalhados usando um dos muitos mtodos para especificao de processos, tais como: subconjunto do portugus, pseudo-cdigo, tabelas de deciso, rvores de deciso, condies pr-ps, fluxogramas, diagramas de Nassi-Shneiderman. Tabelas de deciso so uma representao de aes com a indicao das condies em que devem ser executadas. Tem 4 quadrantes (condies: lista de todas as condies possveis que surgem dentro de um processo. aes: lista de todas as aes possveis que surgem dentro de um processo. regras: lista das diferentes combinaes de condies possveis. decises: indicadores das aes a executar) Quadrante: condies | regras --------------------aes | decises Existem quadrantes com entradas limitadas (somente valores binrios no quadrante das regras) Existem quadrantes com entradas estendidas (admitem valores mltiplos no quadrante das regras) Existem quadrantes com entradas mistas (admitem valores mltiplos no quadrante das decises) Tabelas de deciso so teis na descrio de processos que produzem aes baseadas em decises complexas. So teis na anlise de regras complexas e processos de tomada de deciso. rvore de deciso uma alternativa grfica s tabelas de deciso.

Condies pr-ps: uma forma de dizer qual a transformao efetuada pelo processo sem explicitar o algoritmo utilizado. Com isso, o analista pode deixar a escolha do algoritmo para uma fase posterior. Fluxograma representa lgica procedimental de forma no estruturada. Componentes: terminador (retngulo com lados arredondados), deciso (losngo), entrada/sada (paralelogramo), processamento (retngulo), conector (crculo) e ponte de ligao (pentgono). Diagramas de Nassi-Shneiderman foram introduzidos como fluxogramas estruturados. Componentes de um DFD - fluxo de dados: pode ser considerado como um tubo que permite a passagem de um componente do DFD para outro componente do DFD. So responsveis pela conexo entre processos, processo e entidade externa (vice-versa) e depsitos de dado e processos (vice-versa). representado por um vetor com nome. - processo: transforma entradas em sadas. Mostra algum trabalho executado em cima dos dados. representado por uma bolha com nome dentro. O nome um verbo no infinitivo com o objeto direto. - arquivo: um depsito temporrio de dados. representado por duas retas paralelas horizontais com o nome entre elas. Uma seta do processo para o arquivo significa operao de incluso. Uma seta do arquivo para o processo significa operao de leitura. A seta dupla significa operao modificao ou excluso. - entidade externa: uma fonte ou destino, uma pessoa, ou empresa, ou departamento, ou sistema repousando fora do contexto do sistema que originador ou receptor de dados no sistema. representado por um quadrado com um nome dentro. Funciona sempre como origem/destino de dados. ### Sistemas de informacao Datamart - Pequenos data warehouse; - Eficincia, velocidade de resposta; - Necessidades especficas de uma rea; - Sistema de apoio ao gerenciamento de uma rea de negcio; - Baseado, em sua grande maioria, na informao do DWH; - Unifica os requisitos especficos de uma rea de negcio; Vantagens competitivas de um datamart: - adaptabilidade; - velocidade de resposta; - posicionamento e sustentabilidade; Resultado de um datamart: - aprendizagem;

- adaptabilidade; - prever o futuro; Quando um projeto inicia por datamarts departamentais especializados que mais tarde se consolidam em um data warehouse institucional, existe uma chance maior de surgirem problemas de inconsistncia de metadados do que quando um data warehouse institucional d origem a datamarts departamentais. ### Sistemas de informacao Datamart (caractersticas) Fato aditivo: so fatos que podem ser somados atravs de todas as dimenses da tabela fato. Fato semiaditivo: so fatos que podem ser somados atravs de algumas dimenses da tabela fato. Fato no aditivo: so fatos que no podem ser somados atravs de nenhuma dimenso da tabela fato. Tabelas que, aparentemente, devem ser uma dimenso, podem ser apenas parte da mtrica e no ser uma dimenso. Exemplo: CIDADE pode ser uma dimenso (quais cidades tiveram maior lucro?). Mas pode ser uma mtrica tambm (quantas cidades participam?) Tabelas fato: tabela que contm as medidas de interesse. Ex.: quantidade de vendas. Esta medida pode ser guardada com uma granularidade apropriada (grau de detalhe). Por exemplo, pode ser quantidade de vendas por loja por dia. Neste caso a tabela fato iria conter trs colunas: coluna data, coluna loja e coluna de quantidade de vendas. Tipos de tabelas fato Cumulativa (cumulative): descreve o que aconteceu durante um perodo de tempo. Os fatos so, em sua maioria, fatos aditivos. Instantneo (snapshot): descreve o estado de coisas em uma instncia particular de tempo. Usualmente inclui fatos semiaditivos e no aditivos. Tabela de dimenso: prov informaes detalhadas sobre os atributos. Por exemplo, uma tabela de dimenso para o atributo trimestre pode conter uma lista de todos os trimestres disponveis no data warehouse. Cada linha pode ter vrios campos, um para o ID que identifica o trimestre e um para informaes adicionais, por exemplo, como o trimestre particular representado em um relatrio. ### Sistemas de informacao Datamart (esquemas) Esquema em estrela: um objeto simples (a tabela fato) fica no meio e radialmente conectada a outras tabelas como uma estrela. Todas elas tem o mesmo nvel de

granularidade. Cada dimenso representada por uma simples tabela. A linha entre as tabelas indica a relao da chave primria e a chave estrangeira. Um esquema em estrela pode ser simples ou complexo. O simples tem somente uma tabela fato, enquanto que o complexo tem mais de uma tabela fato. As dimenses no so normalizadas. O esquema flocado (snowflake): extenso do esquema estrela, sendo que cada ponto da estrela explode em mais pontos. No esquema em estrela, cada dimenso representada por uma nica tabela dimensional, enquanto que em um esquema flocado, cada tabela dimensional normalizada em mltiplas tabelas de dimenso, cada uma representando um nvel na dimenso hierrquica. O nmero de dimenses aumenta para fins de normalizao. A principal vantagem do esquema flocado a melhoria na performance devido aos requisitos de armazenamento de disco minimizados e menores tabelas de dimenso. A principal desvantagem o esforo na manuteno pelo aumento no nmero de tabelas de dimenso. Usar um modelo ou outro dependente da deciso. ### Sistemas de informacao Datamart (conceitos) Modelo de dados dimensionais: so armazenados numa forma diferente da 3FN dos sistemas transacionais (OLTP). Dimenso: categoria de informao. Ex.: dimenso tempo. Atributo: nvel nico dentro de uma dimenso. Ex.: ms um atributo da dimenso tempo. Hierarquia: especificao dos nveis. Representa a relao entre os diferentes atributos dentro de uma dimenso. Um modelo dimensional inclui tabelas fato e de dimenso. Uma tabela fato se liga a vrias tabelas de dimenso. Duas tabelas fato no se relacionam entre si. ### Engenharia de software Gerncia de projeto (anlise do valor agregado - earned value analysis est em desuso. Agora PMI - project management institute) Ferramenta que mede a performance pela comparao do custo do projeto com seu valor agregado. De forma resumida, significa analisar trs curvas de desempenho: a do custo orado do trabalho agendado, a do custo orado do trabalho realizado e o custo real do trabalho realizado. Mtodo que permite um relato do status do projeto em termos de custo e tempo. Permite uma viso mais precisa do progresso do projeto.

SPI (schedule performance index) ou SV (schedule variance): representa o percentual do cumprimento do cronograma. dado pela razo do orado realizado pelo orado agendado. SPI < 100% -> o projeto est atrasado. O gerenciamento do valor agregado considera as medidas de escopo, custos e cronograma para auxiliar a equipe de gerenciamento a avaliar e medir o desempenho e progresso do projeto. Frmulas: - Variao de prazo = valor agregado (VA) - valor planejado (VP); (verifica se o projeto est se atrasando) - Variao de custo = valor agregado - custo real (CR); (indica a relao do desempenho fsico e os custos gastos. qualquer VC negativa irrecupervel) - Variao de custo no final do projeto = oramento no trmino (ONT) - quantia real gasta; - ndice de desempenho de prazos = VA/VP (< 1 => menos trabalho realizado do que planejado e vice-versa) - ndice de desempenho de custos = VA/CR (mtrica mais crtica do GVA. < 1 => excesso de custo. > 1 => desempenho de custo abaixo do limite) - Estimativa no trmino (ENT) = CR + EPT (estimativa para terminar) bottom-up - ENT para o trabalho EPT no ritmo orado = CR + ONT - VA; - ENT para o trabalho EPT executado ao IDC presente = ONT/IDC cumulativo; - ENT para o trabalho EPT considerando IDC e IDP = CR + [(ONT - VA)/(IDC cumulativo x IDP cumulativo)] - ndice de desempenho para trmino (IDPT) = (ONT - VA)/(ONT - CR); ### Engenharia de software Testes O plano de teste um documento que define o nvel de cobertura que dever ser alcanado nos testes e, juntamente com outros documentos, permite que os testes sejam repetidos e controlados. Um plano de teste deve conter os objetivos do teste, abordagem do teste e premissas do teste, quais caractersticas e funcionalidades devem ser testadas, dados do teste (valores que devero ser fornecidos como entrada para o sistema a ser testado), procedimentos do teste, tec. Script de teste so instrues passo a passo que permitem a execuo de um ou mais testes. Fornece informaes para a implementao efetiva e eficiente de um subconjunto de testes necessrios. Podem ser gerados automaticamente usando ferramentas de automao de teste. Prova de conceito um modelo prtico que possa prova o modelo terico estabelecido. Em TI, prova de conceito pode ser relacionado ao desenvolvimento de um prottipo como ferramenta para provar a viabilidade de um projeto.

A avaliao de teste apresenta os resultados dos testes em termos de defeitos e cobertura. ### Sistemas de informacao Ecommerce: comrcio utilizando a internet. Pode ser desde comrcio de produtos at servios. - Vantagens do ecommerce: aumento no acesso (os clientes podem agora ter acesso aos produtos por todo o pas e at mesmo no mundo inteiro, tudo isso estando em casa), custo reduzido, convenincia de compra, expanso (antes era custoso ter comrcio em vrias reas). - Desvantagens: segurana e sumio da taxa governamental. B2C (business to commerce) Define um comprador e uma interface do vendedor usando tecnologia da internet. D ajuda aos modelos consumidores B2C. Vendedores podem ser especializados como Intershop, Openshop ou provedores de softare padro como a Microsoft, Oracle, etc. - Funcionalidades centrais de uma venda online: gerenciamento de catlogo do produto, mquina de busca, gerenciamento de cesta de compra, identificao do cliente e a fatura e pagamento. - Funcionalidades desejadas: relatrios estatsticos, data mining, integrao da funcionalidade de CRM (dar um perfil pro cliente, classificao do cliente, integrao da central de chamada e gerenciamento de campanha), ponte com os sistemas ERP (planejamento de recurso empresarial). - Precaues: checar por certificados digitais, checar por preos de transporte, ver os produtos de clientes antigos, comprar com os cartes apropriados. B2B (business to business) Definido como comrcio eletrnico entre empresas. Algumas caractersticas: terceirizar funes no processo do comrcio eletrnico, uso de software de gerenciamento de contedo para facilitar o gerenciamento dos sites, ativadores de comrcio baseado em XML, etc. B2G (business to government) Geralmente definido como comrcio entre empresas e o setor pblico. Refere-se ao uso da internet para obteno pblica, procedimentos de licensa e outras operaes relacionadas com o governo. C2C (consumer to consumer) Comrcio entre indivduos privados e clientes. Aparece em 3 formas: leiles, sistemas P2P, classificados em portais. M-commerce (mobile commerce) Compra e venda de bens e servios atravs de tecnologia wireless. Ex.: uso de servios bancrios atravs do celular, servios de informao e emisso de bilhete atravs do celular.

### Linguagem de programao Java O modificador protected pode ser usado por classes do mesmo pacote da classe que tem a varivel protegida. Pode ser usado por subclasses mesmo que estas no pertenam ao pacote da classe que tem a varivel protegida. O modificador de acesso padro pode ser usado somente por classes do mesmo pacote. Subclasses de pacotes diferentes podem acessar o public e o protected. Classes de pacotes diferentes (sem ser subclasses) s podem acessar o public. Classes de mesmo pacote s no podem acessar o private. O modificador final, quando aplicado a uma classe, ela no pode ser extendida. Nos mtodos, impede que eles sejam sobrescritos nas subclasses. Nas variveis, impossibilita que elas sejam reinicializadas. Static no se aplica a classe. S a mtodos ou variveis. Faz com que eles pertenam s classes, e no aos objetos. Interface i = new ClasseQueImplementaInteface(); // isso pode. Mas, se i chamar mtodos de ClasseQueImplementaInteface e que no tenham em Interface, dar erro. ### Engenharia de software Decises de projeto: um dos interessados (stakeholders) pede para adiantar a entrega do projeto. Neste caso, deve-se reunir com o patrocinador para discutir o acrscimo de recurso ou diminuir o escopo. ### Sistemas de informacao Data warehouse: a tabela fato representa os dados que so necessrios para que os usurios possam realizar as anlises de negcio necessrias para tomadas de deciso. ### Engenharia de software PMBoK As atividades principais determinantes para o objetivo de um projeto: escopo, tempo, custo e qualidade. Os cinco grupos de processos de gerenciamento de projeto so: iniciao, planejamento, execuo, monitoramento e controle, encerramento. Nem todos os processos e procedimentos do PMBoK so realmente necessrios em todos os projetos.

O gerente de projetos a pessoa responsvel pela conduo do projeto para que o objetivo seja cumprido. Seu trabalho pode ser sintetizado em dois grandes grupos: planejar/controlar e comunicar. Ele, tambm, identifica requisitos do projeto, equilibra a demanda de tempo, custo, escopo e qualidade, estabelece objetivos de projeto claros e alcanveis. O PMBoK define um programa como um grupo de projetos relacionados, gerenciado de modo coordenado para a obteno de benefcios e controle que no estariam disponveis se eles fossem gerenciados individualmente. Um projeto pode estar ou no em um programa, mas um programa sempre ter projeto. O portflio um conjunto de projetos ou programas e outros trabalhos, agrupados para facilitar o gerenciamento eficaz desse trabalho a fim de atingir os objetivos estratgicos de negcios. Os projetos ou programas do portflio podem no ser interdependentes ou diretamente relacionados. PMO (project management office) usado frequentemente para o gerenciamento centralizado e coordenado dos projetos, programas e portflios. As responsabilidades de um PMO podem variar desde dar suporte ao gerenciamento de um projeto at gerenciar o projeto (programa e portflio) diretamente. De acordo com a definio original de Hammer e Champy, a reengenharia a implementao de mudanas radicais que, ao redesenhar os processos de trabalho, visam melhorar, de forma dramtica, a eficcia da empresa, em todos os seus aspectos tais como custos, qualidade, servio e velocidade. A Reengenharia est focada nos processos de grande amplitude, dentro de uma empresa, principalmente nos que atravessam vrias reas funcionais. A Reengenharia, a Melhoria Contnua e a inspeo so processos distintos e necessrios a uma empresa, mas complementares. Apesar de distintos, ambos: 1. Colocam nfase na satisfao dos clientes; 2. Usam processos de medida de eficcia; 3. Tm foco nos processos de negcio; 4. Fazem uso intensivo de trabalho de equipe; 5. Mudam os valores e as crenas; 6. Foram tomadas de deciso nos nveis mais baixos da empresa; 7. Necessitam do empenhamento absoluto dos nveis mais altos da empresa. ### Sistemas de informacao Portais corporativos um meio de conduzir a maioria (se no todas) das interaes de negcios, permitindo a clientes, parceiros, fornecedores, investidores, funcionrios e outros interessados, um acesso imediato (24/7) s informaes e servios da empresa.

### Lgica matemtica (Lembrar do c(ou)e e d(e)ou) Forma normal conjuntiva A e B (A = a1 ou a2 ou an, B = b1 ou b2 ou bn) Ex.: (a1 ou a2) e (b1 ou b2) Forma normal disjuntiva A ou B (A = a1 e a2 e an, B = b1 e b2 e bn) Ex.: (a1 e a2) ou (b1 e b2). No pode ter negao fora dos parnteses. Em um literal sozinho pode. (a1 e a2) ou (b1 e b2) <= no forma normal disjuntiva. Tem que fazer (a1 ou a2) ou (b1 e b2) <= porm, no forma normal nem conjuntiva, nem disjuntiva. ### Sistemas de informacao BPM Diferenas entre organizao funcional (OF) e organizao orientada a processo (OOP): - OF no entende como uma viso interfuncional de processos pode trazer benefcios. OOP entende. - Na OF, o foco primrio em gerencia de departamento. Numa OOP, em gerncia de processos. - Na OF no envolve BPM na estratgia. Na OOP, sim. - Na OF a mentalidade de punio. Na OOP a mentalidade de melhorar processos e treinar pessoas. ### Sistemas de informacao BPMN uma notao grfica padronizada para desenhar processos de workflow. Tem como objetivo primrio prover uma notao que seja compreendida por todos os usurios, como os analistas de negcios, desenvolvedores e as pessoas de negcios. uma notao grfica que tem por objetivo prover recursos para modelar (desenhar), de uma forma padro, os processos de negcio da empresa. Elementos de uma BPMN: objetos de fluxo, objetos de conexo, swimlanes e artefatos. Processo:

Para o BPMN, processo uma atividade realizada por uma empresa e composta por uma srie de etapas e controles que permitem o fluxo de informaes; O conceito de processo extremamente hierrquico, iniciando macro-processos e indo at o nvel de tarefa (menor nvel dentro de processo); Processo de Negcio (business process) conceituado como uma srie de atividades que so realizadas por uma ou mais empresas; Um BPD o local para modelar o processo de negcio que pode ser formado por um ou mais processos. Estes processos dentro do processo de negcio podem ser formados por sub-processos. O Mapeamento de Processo uma ferramenta gerencial e de comunicao que tem a finalidade de ajudar a melhorar os processos existentes ou de implantar uma nova estrutura voltada para processos. Os processos de negcio so os primeiros processos a serem identificados, depois os processos de apoio (aos processos de negcio) e por fim os processos de controle e/ou reguladores. O mapeamento tambm auxilia a empresa a enxergar claramente os pontos fortes, pontos fracos (pontos que precisam ser melhorados tais como: complexidade na operao, reduzir custos, gargalos, falhas de integrao, atividades redundantes, tarefas de baixo valor agregado, retrabalhos, excesso de documentao e aprovaes), alm de ser uma excelente forma de melhorar entendimento sobre os processos e aumentar a performance do negcio. Objetivo do Mapeamento de Processos: Identificar e buscar um melhor entendimento dos processos de negcios existentes (ASIS) e dos futuros (TO-BE) para melhorar o nvel de satisfao do cliente e aumentar desempenho do negcio. Tcnicas de Mapeamento de Processos: - Entrevistas, questionrios, reunies e workshops. - Observao de campo. - Anlise da documentao existente. - Anlise de sistemas legados. - Coleta de evidncias. O mapeamento a elaborao de um diagrama ou mapa do processo de negcio e a documentao que descreve suas propriedades e caractersticas, que identifica as atividades realizadas e as informaes que fluem entre elas. Aps o Mapeamento, inicia-se o trabalho de Modelagem. O primeiro documento resultante deste trabalho o Mapa de Processos, o objetivo deste mapa fornecer uma nica viso dos processos da empresa, seus relacionamentos, atividades/tarefas, stakeholders, papis e responsabilidades e o fluxo de valor dos processos. O Mapa de processos deve ser apresentado em uma linguagem grfica que seja simples e que facilite o entendimento de todos os envolvidos e que permita: - Exibir os detalhes dos processos de modo gradual e controlado; - Encorajar preciso na descrio do processo; - Focar a ateno nas interfaces entre os processos e - Prover uma anlise de processos poderosa e consistente com o vocabulrio de negcio

Benefcios do Mapeamento e da Modelagem de Processo: - Melhora a comunicao; - Facilita a visualizao; - Reduz o nvel de abstrao; - Ajuda no entendimento do que deve ser feito; - Auxilia na identificao de quem deve fazer o qu; - a base documentao;

### Engenharia de software Temas diversos - Um projeto mal gerido pode causar atrasos no cronograma, produto de baixa qualidade, gastos fora do oramento. - Um bom lder deve ter a habilidade de motivar a equipe, organizao, criatividade, entendimento do problema e comprometimento da qualidade. - Paradigmas de equipe: fechado (organizao hierrquica, cada um dos membros da equipe tem um papel definido na hierarquia), aleatrio (equipe fracamente estruturada e sua organizao depende da iniciativa individual), aberta (baseada na colaborao, com intensa comunicao e tomada de deciso baseada no consenso) e sncrono (baseada na decomposio de um problema e organiza os membros da equipe para trabalhar em cada parte, sem muita comunicao). - A primeira atividade na gesto de um projeto de software determinar o escopo. - As mtricas de processo so coletadas no decorrer de vrios projetos e sua inteno melhorar o processo de software em si. - Uma informao til na estimativa de projetos o histrico com projetos semelhantes.

- Viabilidade de software determina se um software pode ou no ser construdo dadas as condies tecnolgicas, financeiras, de tempo e de recursos. Ela deve ser estimada porque, se o software no for considerado vivel, a sua construo deve ser descartada at que as condies mudem. - Casos de uso no podem ser usados para estimar o tamanho de um projeto porque eles no tem um formato padro, so escritos em diferentes nveis de abstrao, representam uma viso externa e no indicam a complexidade de cada funo a ser desenvolvida. - Um gerente de software, se perceber que a data de entrega impraticvel, ele deve tentar proteger a equipe da presso do cronograma, modificando o projeto de alguma forma. Uma opo contratar mais pessoal. Outra soluo usar um modelo incremental e s garantir alguma funcionalidade no primeiro incremento. - Princpios bsicos de cronogramao: * compartimentalizao (o projeto deve ser decomposto em um certo nmero de tarefas e atividades). * interdependncia (a dependncia entre as tarefas e atividades deve ser determinada; algumas devem ocorrer em sequncia, outras podem ocorrer em paralelo). * definio de marcos de referncia (marcos de referncia devem ser definidos, indicando que, naquele ponto, um ou mais produtos de trabalho estaro prontos e revisados quanto qualidade). * atribuio do tempo: a cada tarefa, deve ser atribudo um certo nmero de unidades de trabalho (ex.: pessoa-dia). Devem ser atribudas tambm datas de incio e trmino, que so funes das interdependncia e trabalho. * validao do esforo: o gerente do projeto deve garantir que no mais do que o nmero disponvel de pessoas seja cronogramado em um determinado momento. * responsabilidades definidas: cada tarefa deve ser atribuda a um membro especfico. * resultados definidos: cada tarefa deve ter um resultado definido, normalmente um produto de trabalho. - A estratgia reativa reserva recursos para lidar com os riscos quando eles se tornam problemas. - A estratgia proativa estabelece um plano para administrar os riscos que comea a ser executado no incio do projeto. - A qualidade do software no se restringe somente aos requisitos. Alm deles, a qualidade inclui seguir normas de desenvolvimento explicitamente documentadas e outras caractersticas implcitas em qualquer projeto de software (manutenibilidade e usabilidade). - A medida de confiabilidade mais importante para o usurio do que o nmero de erros por linha de cdigo porque a primeira s vai ser percebida pelo usurio. - A engenharia reversa no contexto de engenharia de software recuperar o projeto a partir do cdigo fonte. - Reestruturao de cdigo altera a lgica interna de um programa sem afetar a arquitetura global.

- A engenharia avante reconstri um novo projeto a partir do projeto extrado atravs da engenharia reversa. - Anlise de inventrio, no processo de reengenharia, serve para selecionar os programas que devem ser submetidos ao processo de reengenharia. - Para decidir se vale a pena o processo de reengenharia deve-se levar em considerao o custo anual de manuteno do software antes e depois da reengenharia e o custo de investimento de reengenharia. ### Engenharia de software Gerncia de projeto - Operaes e projetos compartilham algumas caractersticas: so realizados por pessoas; esto sujeitos a limite no consumo de recursos; so planejados, executados e controlados; - Operaes so contnuas e repetitivas. Projetos so temporrios e exclusivos. - Operaes representam tarefas que se repetem no dia a dia da organizao (manuteno de servios e processos). - SOW ou DT = statement of work ou declarao do trabalho: descrio dos produtos, servios ou resultados a serem fornecidos. encontrada no processo "Desenvolver o termo de abertura do projeto". - O patrocinador quem fornece recurso financeiro, em dinheiro ou espcie. Tem papel significativa no escopo inicial e no termo de abertura. Ele pode autorizar mudanas no escopo do projeto, anlises de final de fase e decises de continuao ou cancelamento quando os riscos so particularmente altos. ### Engenharia de software Testes de software - Um bom caso de teste aquele que tem alta probabilidade de achar erros ainda no descobertos. - Um teste bem sucedido aquele que acha erros. - Os testes devem seguir os requisitos dos usurios. - Devem ser planejados antes de serem iniciados. - Devem ser realizados dos aspectos menos crticos aos mais crticos. - Testes exaustivos no so possveis. - Devem ser realizados por diferentes pessoas, principalmente aquelas que no participaram do desenvolvimento. - O processo de teste deve iniciar junto com o projeto de desenvolvimento da aplicao. Teste de unidade: teste da classe ou parte da classe. realizado um teste de caixa branca. Teste de integrao: grupo de classes que colaboram ou se comunicam. Teste funcional: apoiado nos casos de uso (requisitos funcionais). realizado um teste de caixa preta.

Teste do sistema: aplicao funcionando como um todo. Teste de aceitao: requisitos funcionais e de desempenho de acordo com a especificao do software. Teste de instalao: instalao da aplicao (hardware, software e documentao). Sistema em uso. ### Engenharia de software Prototipagem: existem prottipos para validar requisitos no funcionais. ### Linguagem de programao J2EE Web continer cuida dos JSP e Servlets. A partir do EJB 3.0, o EJB tipo entity bean cedeu lugar ao JPA, passando a contemplar apenas os session e message-driven beans. Com isso o web continer pode gerenciar EJB's. Antes de 3.0 no podia. Web continer (tambm conhecido como servlet continer) o componente de um servidor web que interagem com os servlets. - Enterprise bean um corpo de cdigo com campos ou mtodos para implementar mdulos da lgica de negcio. - H 3 tipos de enterprise beans: session beans, entity beans e message-driven beans. - Enterprise beans geralmente interagem com banco de dados. - Um dos benefcios do entity beans que voc no precisa escrever nenhum cdigo SQL ou usar a API JDBC diretamente para realizar operaes de acesso a banco de dados. O continer EJB faz isso. Entretanto se voc sobrescrever a persistncia container-managed padro, voc precisar de usar o JDBC diretamente. Se voc escolher fazer o session beans acessar o banco de dados, voc vai ter que usar o JBDC diretamente tambm. - O JDBC API te permite executar comandos SQL com a linguagem java. Pode-se, tambm, usar o JDBC API a partir de um servlet ou pgina JSP para acessar o banco de dados diretamente sem precisar de um enterprise bean. - Um servlet uma classe java usada para extender as capacidades dos servidores. No est amarrado a nenhum protocolo, mas usado geralmente com o protocolo HTTP. Para desenvolver e rodar um servlet, um continer web deve ser usado. O continer web responsvel por gerenciar o ciclo de vida dos servlets, mapeando uma URL para um servlet particular assegurando que o usurio que pediu a URL tenha os direitos de acesso corretos. - Servlet um objeto que recebe um pedido e gera uma resposta baseado naquele pedido. Servlets podem ser gerados a partir de pginas JSP pelo compilador de JSP. - A diferena entre servlet e JSP que servlet tipicamente embute HTML dentro de cdigo java. JSP embute cdigo java em HTML. ### Engenharia de software Gerncia de projetos

- As distribuies contnuas de probabilidade auxiliam a representao da incerteza nos valores de atividades do cronograma e custos dos componentes do projeto. - A anlise de sensibilidade ajuda a determinar quais riscos tem mais impacto potencial no projeto. - A anlise do valor monetrio esperado um conceito estatstico que calcula o resultado mdio quando o futuro inclui cenrios que podem ocorrer ou no. - Simulao de um projeto utiliza um modelo que converte incertezas especificadas de maneira detalhada no seu possvel impacto nos objetivos do projeto. ### Engenharia de software Diagrama de classes Modelo de classes composto por diagrama de classes e da descrio textual associada. medida que o sistema desenvolvido, o modelo de classes incrementado com novos detalhes. Pode existir 3 tipos de modelo de classes: - De domnio: representa as classes no domnio do negcio em questo. No leva em considerao as restries inerentes tecnologia a ser utilizada na soluo de um problema. construdo na fase de anlise do sistema. - De especificao: obtido atravs da adio de detalhes ao modelo anterior conforme a soluo escolhida do software. - De implementao: corresponde implementao das classes em alguma linguagem de programao. ### Engenharia de software Diagrama de objeto Pode ser visto como uma instncia do diagrama de classes. Representa uma "fotografia" do sistema em um certo momento. Exibe as informaes formadas entre objetos conforme estes interagem e os valores dos seus atributos. ### Engenharia de software Diagramas de atividades Parties: sem o conceito de parties, o diagrama de atividades seria meramente uma extenso de um fluxograma. Com as parties, passa a ser possvel indicar quem realiza qual atividade. ### Engenharia de software Diagramas de componente

- Componente um pedao de software reutilizvel, bem encapsulado e facilmente substituvel. So blocos que, combinados, constroem o sistema pretendido. Obviamente, a dimenso dos componentes no homognea. - Bons candidatos a serem componentes do sistema: itens que desempenham uma funcionalidade que utilizada recorrentemente no sistema. - Em UML, um componente pode efetuar as mesmas funcionalidades que uma classe faz: generalizao; associao com outros componentes ou classes; implementao de interfaces. - Um componente representa um empacotamento fsico de elementos relacionados logicamente (normalmente classes). - Os componentes, por serem facilmente trocados, devem ser independentes uns dos outros. ### Banco de dados MOLAP a tecnologia mais tradicional de anlise OLAP. Nele, os dados so armazenados em um cubo multidimensional (da o M na sigla MOLAP). A forma multidimensional significa que cada aresta do cubo ser um conjunto de dados. Um exemplo de tipo de dados que o cubo pode mostrar: todas as vendas, feitas no carto de crdito em todos os meses de um determinado ano (ou de vrios anos durante uma dcada). O armazenamento de dados no feito no banco de dados relacional, e sim, em um formato proprietrio. O MOLAP tem as vantagens de ser mais rpido na consulta j que o cubo prmontado. Com isso clculos complexos so otimizados. O problema dessa caracterstica a necessidade de se precisar de muita memria para o armazenamento. Outra desvantagem que o MOLAP uma tecnologia proprietria, o que significa que haver gastos com aquisio do produto e, provavelmente, com o treinamento de pessoas. ROLAP um mtodo para manipular dados de um banco de dados relacional (da o R da sigla ROLAP). Uma vantagem do ROLAP que ele no tem limitao nos dados que sero manipulados. , basicamente, "limitado" pelo tamanho limite dos dados do prprio banco de dados relacional. Exatamente por causa disso, ele lento, j que precisa montar os dados em cada consulta. Outro problema do ROLAP que ele dependente das funes SQL. Alguns clculos mais complexos so difceis utilizando SQL, ento ROLAP ficar limitado ao que o SQL pode fazer. Alguns software's j vem com algumas funes prontas e, tambm, permite ao usurio a criar prprias funes. ### Sistemas de informacao CRM (Customer Relationship Manager) Os sistemas CRM fornecem informaes para coordenar todos os processos de negcio que lidam com o cliente, em termos de venda, marketing e servios. O foco na reteno dos clientes e na aquisio de novos. Alm disso, o foco na criao de valores para os clientes. Quando clientes avaliam o "servio do cliente", menos provvel que o cliente procure por alternativas. Sistemas CRM permitem s organizaes a ganharem espao em relao s concorrncias.

Sistemas CRM focam estrategicamente em mercados significantes. Clientes diferentes tem importncias diferentes. Portanto, relacionamentos devem ser construdos com clientes que so provveis a prover valores por servios. Construir relaes com clientes que vo prover pouco valor pode resultar em perda de tempo, pessoas e recurso. Abordagens tecnolgicas envolvendo o uso de banco de dados, data mining, data warehouse, entre outros, podem ajudar as organizaes a aumentar o valor do cliente e sua rentabilidade. Este tipo de tecnologia pode ser usado para manter um registro dos nomes dos clientes, detalhes de contato e seu histrico de compra ou uso de servios. Estas informaes podem mirar clientes de uma forma personalizada e oferec-los servios que atendam s suas necessidades. Essa comunicao personalizada prov valores para o cliente e faz com que aumente a lealdade do cliente com o fornecedor. CRM pode ser feito face a face com o cliente. Os benefcios: custos reduzidos; aumenta a satisfao do cliente; aumento no nmero de clientes; rentabilidade e sustentabilidade a longo prazo, entre outros. ### Engenharia de software UML Modelo de domnio: representao de classes conceituais do mundo real, no de componentes de software. uma representao visual de classes conceituais, ou objetos do mundo real, em um domnio de problema. Modelo comportamental: representa a percepo de como o sistema se comporta em resposta a certos eventos externos. Focaliza os dados (objetos do sistema) ou as funes. Representa o comportamento interno do sistema. Tcnicas utilizadas: diagrama de fluxo de dados (DFD), dicionrio de dados (DD), diagrama de entidade e relacionamento (DER), especificao de processos (EP) e diagrama de transio de estado (DTE). Modelo de dados: representa a percepo dos dados que o sistema mantm. um subconjunto do modelo de implementao que descreve a representao fsica e lgica dos dados persistentes no sistema. Tambm abrange qualquer comportamento definido no banco de dados, como procedimentos armazenados, triggers, restries, etc. O modelo de dados criado na fase de Elaborao. O modelo refinado e expandido durante a fase de construo. Cenrio: uma instncia descrita de caso de uso; subconjunto de um caso de uso. Sequncia especfica de aes que ilustra um comportamento. Um cenrio pode ser usado para ilustrar uma interao ou execuo da instncia de um caso de uso. Uma coleo de cenrios pode ser utilizada na fase de testes. Durante a construo de um cenrio, novos detalhes podem aparecer, ou at mesmo, novos casos de uso podem aparecer. ### Engenharia de software

Ciclo de vida Modelo dirigido por prazo (time-boxed): aquilo que se consegue fazer dentro de determinado prazo. Eles podem ser razoveis quando se consegue definir um conjunto de requisitos indispensveis, para os quais se sabe que os prazos estabelecidos so suficientes, e as folgas so usadas apenas para implementar os requisitos opcionais. O ciclo de vida pode ser dirigido por ferramentas (que pode ser chamada de ferramenta CASE ou plataforma de desenvolvimento, pelos respectivos fabricantes). ### Engenharia de software Relacionamento de dependncia: uma mudana na especificao de um elemento pode alterar a especificao do elemento dependente. A dependncia entre classes indica que os objetos de uma classe usam servios dos objetos de outra classe. indicada por uma seta aberta. Parecida com a da herana, mas a seta aberta. ### Engenharia de software Diagramas de implantao (estrutural): mostra a configurao dos ns de processamento em tempo de execuo e os componentes, processos e objetos que neles vivem. Representa como realizada a distribuio do sistema atravs dos ns de hardware, componentes e dependncias de software e as suas devidas relaes de comunicaes. O diagrama de implantao pode ser representado de 2 formas: como descritor, onde mostra a configurao bsica do hardware; ou como instncia, onde mostra as reais caractersticas de configurao do hardware. Estes diagramas so empregados como modelagem esttica de implantao do sistema. ### Sistemas operacionais Processos , basicamente, um programa em execuo constitudo de um cdigo executvel, dados referentes ao cdigo, da pilha de execuo, do valor do PC (contador de programa indica a prxima instruo do programa a ser executada), do valor do apontador de pilha, dos valores dos demais registradores do hardware e outras informaes. Associado ao processo, est o espao de endereamento, uma lista de posies de memria que contm todas as informaes do processo. Os SO's tem uma tabela contendo as estruturas dos processos existentes no momento para gerenciar todos eles. Um processo pode criar mais processos (filhos). Para sincronizao entre processos, h a necessidade de uma comunicao interprocessos. Processos, que utilizam o mesmo recurso, podem entrar em deadlock.

Um processo tem uma rea de memria e recursos do sistema destinado a ele e uma ou mais threads so executadas no contexto do processo. Uma thread a unidade bsica de cdigo para a qual o sistema aloca tempo de processamento para execuo. o componente real do processo que executado a cada tempo. Espao de Endereamento: rea da memria do processo onde o programa ser executado e para os dados utilizados por ele; deve ser protegido do espao de endereamento dos demais processos. ### Sistemas operacionais Multiprogramao Um problema dos processos que, ao invocar os comandos de entrada/sada, o processador poderia ficar ocioso esperando o resultado. Isso resolvido com a multiprogramao. Com ela, o SO pode alternar os processos de forma que, quando um fica ocioso esperando pelo resultado dos comandos de entrada/sada, outro processo pode tomar o controle do processador e fazer o que tiver que fazer. Aps isso, ele pode devolver o processador para o processo anterior. ### Sistemas operacionais Comunicao interprocessos Os processos so entidades independentes, porm eles precisam, eventualmente, se comunicar com outros processos. Para gerenciar esta interao, o SO coloca os processos em estados. Os processos podem estar: - Em execuo: utilizando a CPU. - Pronto: est preparado, mas no est usando a CPU - Bloqueado: incapaz de utilizar a CPU. Numa comunicao entre processos, 3 pontos devem ser observados: a) troca de informaes entre processos; b) garantia de que um processo no invada o espao fsico do outro; c) garantia de que um processo no altere os dados utilizados pelo outro. O sistema operacional deve evitar que, quando dois processos acessam o mesmo recurso, o resultado no dependa do escalonamento dos mesmos. Isso chamado de condio de corrida (race condition). Regies que possam levar a condies de corrida so chamadas de regies crticas. Para evitar a condio de corrida, 4 regras foram definidas:

1. Dois processos nunca podem entrar ao mesmo tempo. 2. A velocidade ou quantidade de CPU's no interefe. 3. Nenhum processo executando fora da regio crtica pode bloquear outros processos. 4. Nenhum processo deve esperar eternamente para entrar numa regio crtica. Os escalonadores de processo devem se preocupar com as 5 regras: 1. Todos os processos devem ter acesso CPU (justia). 2. A meta fazer o processador chegar perto dos 100% (eficincia). 3. Minimizar o tempo de resposta (eficincia). 4. Minimizar os usurios batch (Turnaround). 5. Maximizar o nmero de jobs processados (throughput) Regio crtica: parte do cdigo onde feito o acesso ao recurso compartilhado. ### Sistemas operacionais Deadlock Quatro condies necessrias para o deadlock: 1. condio de excluso mtua: cada recurso, ou est alocado a exatamente um processo ou est disponvel. 2. Condio de posse de espera: processos que estejam de posse de recursos, obtidos anteriormente, podem solicitar novos recursos. 3. Condio de no-preempo: recursos j alocados a processos no podem ser tomados fora. Eles precisam ser liberados explicitamente pelo processo que os possui. 4. Condio de espera circular: deve existir uma cadeia circular de dois ou mais processos, cada um dos quais esperando por um recurso que est com o prximo membro da cadeia. Todos as 4 condies devem estar presentes para que possa ocorrer um deadlock. Caso uma no esteja, no h a menor possibilidade de ocorrer um deadlock. ### Sistemas operacionais Gerncia de memria O gerenciador de memria controla quais partes da memria esto ou no em uso. Controla, tambm, o swapping que a troca dos dados da memria principal (MP) para a secundria (MS). Swap out => de MP para MS. Swap in => de MS para MP. Tcnicas de alocao de memria: - alocao contgua simples: a MP dividida em duas reas (uma para o SO e outra para o programa do usurio). Era usado em sistemas antigos. Pode haver registrador que

delimita as reas do SO e do programa do usurio para este no acessar a rea do SO, mesmo que intencionalmente. - overlay: existem programas que tem vrios mdulos independentes. Isso significa que, enquanto um est executando, os outros no precisam estar na memria. Nesse caso, somente o mdulo em execuo ir para a memria. A rea reservada para o programa pode ser menor j que s alguns mdulos estaro na memria. - alocao particionada esttica/dinmica: a memria RAM dividida em parties onde os programas vo ser executados. Essa diviso pode ser esttica (mais rpido porque a diviso feita uma vez) ou dinmica (para evitar o desperdcio de memria no usada). O problema da esttica a fragmentao deixada pelos programas quando so alocados (fragmentao interna). O problema da dinmica a fragmentao que deixada aps a execuo dos programas (fragmentao externa). Os SO's mais recentes tentam evitar essas fragmentaes. Para isso, ele deve saber quais reas esto disponveis na MP e quais no esto. Um algoritmo o mapa de bits. A MP dividida em pequenas unidades de alocao. Ento marcado um 0, caso aquela unidade esteja livre, ou 1, caso no esteja. A o SO procura por N unidades consecutivas que estejam disponveis para o programa. Este algoritmo simples de implementar, mas muito lento procurar pela memria inteira. Uma forma mais eficiente utilizar listas encadeadas. O valor das posies destas listas ser o lugar da memria onde os processos esto alocados. O algoritmo pode procurar pela primeira alocao disponvel (rpida, mas pode ter desperdcio porque pode utilizar uma alocao grande demais), prxima disponvel (variao da anterior. Quando for procurar uma posio, a busca no inicia do incio, e sim, de onde parou a busca anterior), melhor alocao (lenta, mas procura o lugar onde gasta menos espao), pior alocao (procurar o maior espao disponvel) e alocao rpida (valores recorrentes de busca so guardados. Por exemplo, os valores de N, 2N e 4N so muito requisitados, ento a posio deles guardada para acesso rpido. A complexidade de implementao alta.) Outra forma o sistema buddy. Apesar de eficiente, h um desperdcio de memria. Ele aloca o programa para a parte da memria com o valor de prxima potncia de 2. Por exemplo, se um programa precisa de 35kb, ele procura um espao de 64kb. Essa busca rpida, mas h muito desperdcio de memria. ### Sistemas operacionais Memria virtual uma forma de combinar as memrias principal e secundria, dando uma iluso de uma memria principal maior do que realmente . Esta tcnica consiste em no vincular o endereamento feito pelos programas aos endereos fsicos da MP. Com isso, os programas e suas estruturas de dados deixam de estar limitados ao tamanho da memria fsica disponvel, pois podem possuir endereos associados memria secundria.

Outra vantagem permitir um nmero maior de processos compartilhando a MP j que apenas partes de cada processo estaro residentes. A desvantagem que a memria secundria lenta. ### Sistemas operacionais Paginao uma tcnica de gerenciamento de memria onde o espao de endereamento virtual e real so divididos em blocos de mesmo tamanho chamados pginas. Nesta tcnica, o endereo virtual formado por nmero da pgina virtual (NPV) e por um deslocamento. NPV = identifica unicamente a pgina virtual que contm o endereo, funcionando como um ndice na tabela de pginas. Deslocamento = indica a posio do endereo virtual em relao ao incio da pgina na qual se encontra. O endereo fsico obtido pela combinao do endereo do frame (na tabela de pginas) com o deslocamento. Valid bit = indica se a pgina est na memria principal ou no. Falta de pgina (page fault) = quando a pgina no est na MP. Nesse caso, o sistema realiza o page in = transferir a pgina da MS para a MP. Page out = transferir da MP para a MS. Taxa de paginao = nmero de falta de pginas por processo em um determinado intervalo de tempo. ### Rede de computadores Modelo OSI Camada fsica: formada pelo hardware usado na conexo dos diferentes sistemas de rede como cabo, fibras e conectores. Nesta camada, a informao est codificada na forma de sinais eltricos. Camada de link ou MAC: define como a informao ser transmitida pela camada fsica e garante o bom funcionamento desta camada. Se houver algum erro na transmisso da informao na camada fsica, o MAC deve tratar esses erros e avisar as camadas superiores sobre o ocorrido. Camada de rede: identificar os endereos dos sistemas na rede e transmitir os dados de fato. Ela deve conhecer o meio fsico da rede e transportar os dados de tal forma que a camada de link possa enviar os dados para o meio fsico. Em algumas redes, no h verificao de integridade da informao e a camada simplesmente executa o empacotamento da informao. Camada de transporte: responsvel pela integridade da informao (envio de sinais ACK entre as partes). nesta camada que opera o TCP.

Camada de sesso: sesso um canal de comunicao entre duas aplicaes que esto sendo executadas em computadores diferentes. Esta camada responsvel por gerenciar a comunicao entre os aplicativos de forma que eles possam abrir, usar e fechar uma sesso. Camada de apresentao: responsvel por definir o formato da troca de dados entre os computadores. Funciona como um tradutor para os protocolos, criptografia, compresso de dados, etc. Camada de aplicao: representa a comunicao com os usurios e fornece servios bsicos de comunicao. ### Rede de computadores Camada TCP/IP So 4 camadas: Camada de aplicao, que corresponde s camadas de aplicao, apresentao e sesso do modelo OSI. Camada de transporte, que corresponde prpria camada de transporte do modelo OSI. Camada de internet (ou inter-rede), que corresponde camada de rede do modelo OSI. Camada de interface com a rede, que corresponde camada de enlace de dados (link) e fsica do modelo OSI. ### Rede de computadores Arquitetura Ethernet As redes Ethernet podem transportar at 1500 bytes de dados. O modelo Ethernet tem 3 camadas, que so equivalentes Interface com a rede do modelo TCP/IP: LLC (controle do link lgico): adiciona informaes sobre qual protocolo da camada Internet foi responsvel por gerar dados. Com isso, durante a recepo, o receptor pode saber qual protocolo usar na camada Internet para receber dados. MAC (controle de acesso ao meio): monta o quadro que ser enviado para a rede. Responsvel por adicionar o endereo MAC de origem e destino ao pacote. Quando os pacotes so destinados a outras redes, que no a local, o endereo MAC ser o do roteador utilizado. O padro IEEE 802.3 responsvel pela rede cabeada e o 802.11 responsvel pela wireless. Fsica: responsvel por converter o quadro gerado pela camada MAC em sinais eltricos (no caso de rede cabeada) ou em sinais eletromagnticos (para rede wireless). No IEEE a camada fsica definida pelos mesmos protocolos do que a camada MAC.

### Sistemas operacionais Paginao Busca de pginas pode ser sob demanda ou pr-paginao. Alocao de pginas pode ser alocao fixa ou pr-alocao. Poltica de substituio local de pgina = somente as pginas do processo que gerou a falta de pgina so candidatas a realocao. Poltica de substituio global de pgina = todas as pginas alocadas na MP so candidatas a realocao independente do processo que gerou a falta de pgina. (Na verdade, nem todas as pginas podem ser realocadas. Algumas, como as do ncleo do sistema, so marcadas como bloqueadas e no podem ser realocadas.) ### Sistemas operacionais Paginao Algoritmos de substituio de pgina timo: o SO remove a pgina com maior rtulo (um rtulo = quanto falta para essa pgina ser usada). Impraticvel. FIFO: retirar as pginas que esto h mais tempo (as que esto no topo) na memria. Pode apresentar Anomalia de Belady (mesmo com maior page frame, pode ocorrer mais page fault). Segunda chance: cada pgina tem um bit R. Se R for 0, ela considerada velha, ao passo que, se for 1, ela zerada e colocada no fim da fila (jovem de novo). Relgio: o mesmo que a segunda chance, porm, com uma estrutura de dados otimizada. Utiliza uma lista encadeada circular. NRU (Not recently used): cada pgina tem 2 bits (R e M) para Referenciada e Modificada. melhor remover uma pgina no referenciada e modificada, do que uma no modificada, mas muito usada. LRU (Least recently used): numa page fault, pginas pouco referenciadas nas ltimas instrues so removidas, pois o algoritmo parte do pressuposto que as outras (as mais referenciadas) continuaro sendo referenciadas nas prximas instrues. ### Sistemas operacionais Paginao Segmentao: tcnica de gerncia de memria onde o espao de endereamento virtual dividido em blocos de tamanhos diferentes chamados segmentos. Existe uma relao

entre a lgica do programa e sua alocao na memria principal. Pode ocorrer fragmentao externa. Segmentao paginada: tcnica de gerncia de memria onde o espao de endereamento dividido em segmentos e cada segmento dividido em pginas. No h problemas de fragmentao externa. ### Sistemas operacionais Sistemas distribudos (SD): So aqueles que gerenciam as atividades e recursos distribudos. Com isso tem-se um processamento descentralizado e melhora o desempenho. A eficincia em SD complexa em relao aos SO's convencionais. O tempo gasto na propagao dos dados depende fortemente do protocolo de comunicao. Por isso, este deve ser bem projetado. Threads: fluxo de controle sequencial isolado dentro de um programa. Processos leves que compartilham o espao de endereos lgicos. Onde as threads devem ser implementados? Se o objetivo for agilidade: no espao do usurio. O gerenciamento menos complicado. Nesse caso, os SO's no tem controle sobre as threads e estas no podem usufruir das interrupes do SO. Portanto so no-preemptveis. Se o objetivo for eficincia: no ncleo do SO. Portanto passam a ser preemptveis. Nesse caso, no h necessidade de interromper o processo que gerou a thread. O SO pode interromper somente a thread. Quando uma thread deixa de existir? ### Sistemas de informao Business Intelligence (BI): habilidade de uma organizao em pegar todas as suas capacidades e transform-las em conhecimento. Isso produz grande quantidade de conhecimento que pode levar ao desenvolvimento de novas oportunidades. O conceito de BI - Business Intelligence, de forma mais ampla, pode ser entendido como a utilizao de vrias fontes de informao para se definir estratgias de competitividade nos negcios da empresa. Funes comuns de BI: relatar, OLAP, anlise, data mining, processamento de eventos complexos (complex event process), gerenciamento de desempenho de negcio (business performance management), etc. BI tem como objetivo melhorar a tomada de decises. Portanto, BI pode ser chamado de sistema de suporte deciso. Nem todos BIs requerem data warehouse e nem todos data warehouse so usados para BI.

Antes de implementar uma soluo de BI, vale a pena levar em considerao alguns fatores: - o nvel de comprometimento e patrocnio do projeto do gerente snior; - o nvel de necessidade de negcio para criar uma implementao BI; - a quantidade e qualidade de dados de negcio disponveis. Existem dados estruturados e dados no-estruturados (ou semi-estruturados). Dados no estruturados vem na forma de email, memorandos, notas, notcias, grupos de usurios, chats, relatrios, pginas web, apresentaes, arquivos de imagem e vdeo e materiais de marketing. Problemas com dados no estruturados: - guardados em vrios formatos; - terminologia no padronizada; - volume de dados: a maioria dos dados est neste formato; - busca de dados textuais no estruturados. Exemplo: a busca simples pela palavra "felonia" s encontrar links que fazem referncia palavra "felonia", e no acha referncia s palavras/expresses: "crime", "incndio culposo", "assassinato", "fraude", "homicdos veiculares", etc, mesmo estes termos so tipos de felonia. Para resolver problemas com busca e avaliao de dados, necessrio conhecer alguma coisa sobre o contedo. Isto pode ser feito adicionando contexto no uso de metadados. Os sistemas podem adicionar informaes sobre o autor, o tamanho do arquivo, o nome do arquivo, mas mais eficiente seria colocar informaes sobre o resumo, tpicos, pessoas ou inteno de empresas. Duas tecnologias designadas para gerar metadados sobre o contedo so categorizao automtica ou extrao de informao. ### Rede de computadores WDMA (Wavelength division multiple access) um mtodo de acesso de canal baseado no protocolo WDM (wavelength division multiplex). o WDM um protocolo utilizado geralmente em redes de fibra tica. Permite que, numa rede, se utilizem sinais ticos com diferentes frequncias no mesmo canal atravs da multiplexagem. CDMA (Code division muliple access) Desenvolvida durante a guerra, hoje, esta tecnologia usada em companias de celulares. Diferente de GSM e TDMA, o CDMA transmite pela frequncia inteira disponvel. Isso permite que vrias pessoas possam comunicar j que todas usaro o mesmo escopo de banda. CDMA uma tecnologia digital, ento qualquer sinal de udio analgico precisa ser digitalizado antes de ser transmitido na rede. MACA (Multiple access with collision avoidance)

Protocolo usado em LAN's wireless. A ideia bsica do protocolo que h um aviso antes de enviar o quadro de dados para informar os outros para ficar em silncio. Quando um n quer transmitir dados, ele manda um RTS (request to send) com o comprimento do quadro de dados a enviar. Se o receptor pode receber os dados, ele envia um CTS (clear to send) com o tamanho do frame que ele est pra receber. ### Banco de dados Operador summarize summarize A BY (A1, A2, ..., An) ADD agg-exp AS Z A1, ..., An so atributos distintos de A. O resultado da expresso uma relao composta pelos atributos {A1, ..., An, Z}. Os valores dos dados so todos os registros x onde x uma projeo de A sobre A1, ..., An com um novo atributo Z. O valor de Z calculado atravs da expresso agg-exp calculada sobre todos os atributos de A que tem os mesmos valores para A1, ..., An que o registro x. Exemplo: #forn 123 123 123 456 456 789 #produto Qtd 11111 200 22222 100 33333 300 11111 500 22222 200 11111 100

Summarize C by (#produto) ADD SUM(Qtd) AS qtdTotal #produto 11111 22222 33333 qtdTotal 800 300 300

### Banco de dados Uso de OID's (object identifier): o SGDBR gera um identificador nico (OID) para cada registro. O OID armazenado em uma coluna adicionado e a chave primria da tabela. Diz-se que uma identidade baseada na existncia. Vantagens:

- a chave primria um atributo nico, pequeno e uniforme em tamanho. - algumas tabelas no possuem uma combinao de atributos que possa ser chave primria. Desvantagens: - Alguns SGBD's podero no oferecer a gerao de identificadores nicos. - A gerao de OID's pode necessitar de acesso a dados globais, interferindo com o controle de concorrncia e deixando a aplicao mais lenta. - Pode complicar a depurao das aplicaes. ### Rede de computadores Comutadores de pacotes: no possvel determinar se os pacotes sero bloqueados, uma vez que os caminhos no so preestabelecidos. Para ajudar na reduo da perda de pacotes via bloqueio, crossbars so usadas. Padro 802.3z Gigabit ethernet - compatvel com as tecnologias 10baseT e 100baseT. - permite enlace de dados ponto a ponto, bem como canais broadcast compartilhados. - utiliza csma/cd para canais broadcast compartilhados. ### Engenharia de software Relaes intermodulares: so relaes entre os componentes que formam o sistema. Ex.: acoplamento. Relaes intramodulares: so relaes dentro do componente que forma o sistema. Ex.: coeso. Acoplamento: quanto um elemento conhece e depende de outro elemento. Elementos muito acoplados so muito dependentes um do outro. Se mudar um, com certeza, o outro ser mudado. Coeso: o quanto as tarefas (de um elemento) esto relacionadas entre si. Quanto mais relacionadas, mais coesas. Se uma classe tem duas funes totalmente diferentes, ento ela tem uma coeso baixa. ### Banco de dados Escalonamento = conjunto de transaes em um banco de dados. Para que ele seja considerado correto, deve haver a serializabilidade. o efeito de diversas execues em paralelo ser equivalente ao efeito da execuo sequencial. A importncia deste conceito que o conjunto, cujo conceito serializvel, atmico. Significa que o programa paralelo tem sua semntica definida.

### Banco de dados Data warehouse Tabelas fato sem fato (factless fact table): so tabelas que no tem nenhuma medida. essencialmente uma interseo de dimenses. Aparentemente, ela no faz sentido, mas h situaes em que ela importante. Imagine uma tabela fato para representar as faltas dos alunos nas aulas. Ela consistir de 3 dimenses: dimenso estudante, tempo e aula. A tabela fato sem fato vai parecer assim: Fato_Presenca {id_estudante, id_hora, id_aula} A nica medida que se pode fazer colocar "1"'s para mostrar a presena de uma combinao particular. Entretanto, adicionar esta tabela que s mostra 1 redudante porque ns podemos simplesmente usar a funo COUNT para responder as perguntas. Porm, pode-se responder facilmente as seguintes perguntas com esta tabela: - Quantos alunos foram numa aula especificamente em tal dia? - Quantas aulas, em mdia, um aluno vai em tal dia? Sem usar a tabela fato sem fato, precisaramos de duas tabelas fato para responder as perguntas. ### Banco de dados Data warehouse Tabela dimenso: tabela que contm atributos descritivos que so tipicamente campos de textos ou nmeros discretos que se comportam como texto. Estes atributos servem dois propsitos: filtro/restrio de consultas e rotular conjunto de resultados de busca. Atributos de dimenso so feitos para: - rtulos consistindo de palavras completas. - descritivos. - completos. - discretamente valorado: s um valor por linha na tabela dimenso. - qualidade assegurada: sem valores impossveis. Recomenda-se que as linhas da tabela dimenso seja identificadas por uma chave nica. Recomenadado que seja um inteiro simples pelo fato de o atributo ser necessrio somente para junes entre as tabelas fato e dimenso. Dimenso degenerada: uma chave de dimenso na tabela fato que no tem sua prpria tabela de dimenso, porque todos os atributos de interesse foram colocados em dimenses analticas. ### Engenharia de software Gerenciamento Integrado de Projetos

 o ncleo do gerenciamento de projetos, e composto dos processos do dia-a-dia com os quais o gerente de projetos conta para garantir que todas as partes do projeto funcionem juntas. um processo contnuo que o gerente completa para garantir que o projeto prossiga do incio ao fim - a atividade diria para completar o trabalho do projeto. O gerenciamento de projeto junto os planos de projeto, coordena atividades, recursos, restries e suposies do projeto, e os transforma em um modelo funcional. Gerenciar a integrao do projeto garantir a necessidade de os componentes do projeto trabalharem juntos, e papel do gerente de projetos fazer com que isso acontea. Exige habilidades em negociao, gerenciamento de conflitos de interesses, gerenciamento, boa comunicao, organizao, familiaridade tcnica com o produto, etc. ### Banco de dados Diferena entre BD relacional (BDR) e Multidimensional (BDM) As consultas no BDR so mais lentas devido ao SQL. Em BDM, os dados so mantidos em array para uma performance melhor. Um problema no BDM a grande quantidade de dados esparsos. Nem todo cruzamento de dado gera dado. Ocorre, ento, a exploso de armazenamento de dados, ou seja, um imenso banco de dados multidimensional contendo poucos dados armazenados. ### Banco de dados Data Staging Area (DSA) uma rea intermediria entre as fontes de informao e o Data Warehouse ou Data Mart. Usualmente de natureza temporria, e seu contedo pode ser apagado depois que o DW/DM for carregado. Esta rea pode ser usada com os seguintes propsitos: - recolher dados de fontes diferentes que estaro prontos para processar em diferentes tempos. - carregar informaes rapidamente de um banco de dados, liberando-as assim que possvel (da DSA). Todas as informaes podem ento ocorrer sem interferncia. - achar mudanas com relao aos valores de DW/DM. - limpeza de dados. - pr calcular agregados. - j que a estrutura de uma DSA no precisa se assemelhar com a estrutura da fonte ou do alvo, o processo de carregar a staging area pode ser um passo no prprio processo de ETL. Os usurios finais do DW, em geral, no tem acesso DSA. ### Banco de dados

Data warehouse Dimenso lixo ou sucata (junk dimension): uma dimenso abstrata onde se removem os flags e indicadores de baixa cardinalidade da tabela de fatos. Minidimenses: subconjuntos de dimenses grandes que so quebradas em dimenses artificiais menores para controlar o crescimento explosivo de uma dimenso grande, com mundana rpida. Os atributos demogrficos continuamente mutveis de um cliente, por exemplo, so frequentemente modelados como uma minidimenso separada. Dimenses outrigger: Soluo normalizada (snow flake) para conjuntos de atributos de baixa cardinalidade em dimenses grandes. A economia de espao vale a pena porque a dimenso grande, e a carga de dados separada do restante da dimenso porque os dados provem de fontes externas diferentes. ### Engenharia de software FURPS+ H muitos tipos de requerimentos. Um modo de categoriz-los descrito como o modelo FURPS+. Ele usado para descrever o conjunto de requisitos funcionais e no funcionais: Functionality, Usability, Reliability, Performance e Supportability. O "+" em FURPS+ te lembra de incluir alguns requisitos: Restries de design, requisitos de implementao, requisitos de interface e requisitos fsicos. ### Engenharia de software Testes de usabilidade: consistem em apresentar, para um usurio por vez, um prottipo da interface do sistema ou o prprio sistema, e solicitar que o usurio realize algum tipo de tarefa, observando suas reaes interface, erros cometidos, dificuldades e eficincia no cumprimento da tarefa. ### Engenharia de software Sistema ABCD do ERP (avalia o efeito das aplicaes ERP): A: No nvel de empresa dentro da aplicao efetiva do servio do cliente, produo e custos melhoraram muito. B: Liderana senior que apoia muito, aplicaes de gerenciamento mdio pelo sistema, qualidade de trabalho melhorou muito. C: O sistema principalmente usado para fazer pedidos de materiais, a principal contribuio para o gerenciamento de inventrio. D: O dado do sistema no preciso, falta compreenso por parte dos usurios dos negcios de pequena ajuda. ###

Rede de computadores Protocolos: ARP (address resolution protocol): usado para mapear endereos lgicos em endereos fsicos, quando do uso de IP sobre redes ethernet. Opera na camada de rede. SNMP (Simple network management protocol): usado em sistemas de gerenciamento de redes a fim de monitorar dispositivos conectados rede que exijam ateno por parte de seus administradores. Opera na camada de aplicao. Nele, os dados so obtidos atravs de requisies de um gerente a um ou mais agentes, utilizando servios do protocolo UDP para enviar/receber mensagens. Operaes do SNMP: - Get: o gerente solicita ao agente para obter o valor da varivel. - Set: o gerente solicita ao agente para alterar o valor de uma varivel. - Trap: o agente comunica ao gerente o acontecimento de um evento previamente determinado. Essa operao um exemplo de que o agente pode comunicar com o gerente sem que este envie algum pedido de comunicao. ICMP (Internet Control Message Protocol): usado para verificar se uma mquina est ligada, para controlar o TTL. Opera na camada de rede. ### Rede de computadores Componentes Cabo coaxial fino ou 10base2. Cabo coaxial grosso ou 10base5. Tipos de switches: gerenciveis e no gerenciveis. Gerenciveis: determinar a velocidade de operao para uma porta especfica para otimizar a banda de passagem e o desempenho global da rede; indicado para ser usado em redes maiores; No gerenciveis: indicado para usar em redes pequenas; Comum aos dois: comunicao full-duplex; auto MDI-MDIX ou autocrossing (Com isso, no h necessidade do uso de cabos cruzados (crossing) para interconectar os switches. O cabeamento fica uniforme.). Cabo de par tranado utiliza da tcnica de cancelamento para evitar rudos. Cabo de par tranado de 8 fios: 10baseT ### Rede de computadores

Sentido de transmisso Simplex: mo nica. Ex.: televiso, rdio. Em rede de computadores, normalmente, no assim. Half-duplex: mo dupla, mas alternada. Ex.: normalmente em rede de computadores isso que acontece. Full-duplex: mo dupla, simultaneamente. Ex.: Comunicao telefnica. ### Rede de computadores CSMA/CD: CSMA um protocolo que escuta a rede para transmitir. CD uma melhoria para deteco de coliso. Se houver coliso, um "32-bit jam sequence" enviado. O receptor, ao ver esta sequncia, informado de que a transmisso vai parar devido coliso. Assim que ocorre uma coliso, cada n (que estava enviando) calcula um tempo aleatrio e volta a enviar o frame de novo. A cada coliso, este n cria um conjunto de nmeros e um deles escolhido aleatoriamente. N = nmero de tentativas sem sucesso. Um conjunto formado por {0, 1, 2, ..., (2^N)1}. Cada valor multiplicado por 51.2 nanosegundos criando um novo conjunto {0, 51.2, 102.4, ..., ((2^N)-1)*51.2)}. Um valor destes escolhido aleatoriamente. IFG (inter frame gap). um intervalo de 9.6 microsegundos para os ns receptores se prepararem para uma nova transmisso. ### Estruturas de dados A pesquisa binria no recomendada para aplicaes dinmicas porque o custo para balancear a rvore excessivo. ### Rede de computadores Segurana de rede Certificado digital: carrega informaes (atributos) do proprietrio e a chave pblica do mesmo. ### Engenharia de software Modelo RAD: rapid application development um modelo de processo de software incremental que infatiza um ciclo de desenvolvimento curto. O modelo RAD uma adaptao, de alta velocidade, do modelo cascata, no qual a agilidade conseguida com o uso de uma abordagem de construo baseada em componentes. Precisa-se que os requisitos sejam bem compreendidos e o objetivo do projeto seja restrito para garantir o sucesso do projeto. As etapas do RAD apresentam as seguintes definies:

- Comunicao: trabalha para entender os problemas do negcio e as caractersticas de informao que o software precisa acomodar. - planejamento: essencial, porque vrias equipes de software trabalham em paralelo em diferentes funes do sistema. - modelagem: modelagem de negcio, modelagem de dados e modelagem dos processos. - construo: enfatiza o uso de componentes de software preexistentes e a aplicao da gerao automtica de cdigo. - implantao: estabelece a base para iteraes subsequentes, se necessrias. Desvantagens: - para projetos grandes, mas passveis de sofrer aumento, o RAD exige recursos humanos suficientes para criar um nmero adequado de equipes. - se o sistema no puder ser adequadamente modularizado, a construo dos componentes ser problemtica. - se for necessrio reajuste nas interfaces dos componentes do sistema, a abordagem RAD pode no funcionar. - o RAD pode no ser adequado quando os riscos tcnicos forem altos. As ferramentas includas em um ambiente RAD so: - linguagens de programao de banco de dados. - um gerador de interface. - links para aplicaes de escritrios, tais como planilhas para anlise. - gerador de relatrios usado para definir e criar relatrios baseados em informaes de um banco de dados. Sendo um sistema de gerao de telas, ele deve fornecer: - definio de formulrios interativos, nos quais o desenvolvedor define os campos que devem ser exibidos e como estes devem ser organizados. - ligao de formulrios em que o desenvolvedor pode especificar as entradas especficas que fazem com que formulrios adicionais sejam exibidos. - verificao de campos em que o desenvolvedor define intervalos de entrada de valores para os campos de formulrio. ### Engenharia de software UML Relacionamento entre as classes: associao, multiplicidade, classes associativas, qualificador (ou associaes qualificadas. Usadas em relacionamentos 1:N ou N:M. Um nome dado para um lado do relacionamento), agregao (ou agregao regular. Ppartes tem existncia sem o todo), agregao por composio (ou s composio. Partes no vivem sem o todo.), navegabilidade ( a seta da relao), generalizao/especializao, restries (restrio em cima da seta). ### Estruturas de dados

O software que usa delegao dinmico, mais difcil de ser compreendido do que um software esttico. ### Rede de computadores Mtodos do HTTP: - Options: requisita informaes sobre as opes de comunicao disponveis. - Get: captura informao na URL do navegador. - Head: igual ao Get, exceto que o servidor no deve retornar um corpo de mensagem na resposta. - Post - Put - Delete - Trace - Connect ### Sistemas de informao Os Sistemas de Informao so classificados quanto aos nveis de amplitude de suporte e organizacionais. O primeiro representado pelos sistemas de informao funcionais (departamentais), os sistemas de informao corporativos e os sistemas interorganizacionais. Em relao aos nveis organizacionais, os sistemas de informao so classificados, segundo Turban, de acordo com a hierarquia empresarial e proporcionam um suporte em cada nvel especfico. Estratgico: alto escalo. Atos com efeitos duradouros e mais difceis de inverter. Efeitos em longo prazo. Ex.: construo de uma nova fbrica, nova linha de produo, novos mercados, novos produtos, etc. Considera a estrutura organizacional de toda a empresa. O nvel de informao macro. Gerencial ou ttico: tem caracterstica de efeitos em curto prazo. Decises nos escales intermedirios da empresa. Nvel de informao em grupos. Operacional: decises que esto ligadas ao controle e s atividades operacionais da empresa. Decises que criam condies para a realizao diria de trabalhos na empresa. Nvel de informao detalhado (analtica). ### Engenharia de software Mtodos geis Scrum: um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento gil de software. Scrum no um processo prescribente, ou seja, ele no descreve o que fazer em cada situao. Ele usado para trabalhos complexos nos quais impossvel predizer tudo o que vai acontecer. Assim como o XP, o Scrum tambm faz reunies em p, dirias, com perguntas especficas.

Sprint: unidade bsica de desenvolvimento do Scrum. Tende a durar entre 1 semana e 1 ms. Cada sprint precedido de uma reunio de planejamento onde as tarefas para o sprint so identificadas e um compromisso estimado para o objetivo do sprint definido e seguido por uma reunio de reviso onde o progresso revisto e lies para os prximos sprints so identificadas. Cartes CRC (Classe, responsabilidade e colaboraes) so recomendados para os adeptos do XP. Cada classe que identificada tem sua responsabilidade. As colaboraes determinam as interaes entre as classes. As estrias de usurio descrevem cenrios com situaes de utilizao que os envolvidos gostariam que o sistema, em desenvolvimento, viesse a oferecer. ### Engenharia de software Tcnicas usadas na elaborao do cronograma de um projeto. Mtodo da cadeia crtica: combina abordagem determinstica com probabilstica. Mtodo do caminho crtico: utiliza o caminho que consome mais tempo. Nivelamento de recursos: evita super alocao dos recursos. ### Engenharia de software DFD Existe o DFD de contexto onde a viso macro do sistema, com poucos detalhes. Depois vem os nveis. Quanto mais se avana nos nveis, mais detalhes tem. ### Rede de computadores Transmisso de dados em redes que utiliza os bits START-STOP conhecida como assncrona. Assncrona: no tem relgios no meio de transmisso. Para sincronizar os dispositivos de acesso e transmisso, usado informao para delimitar os caracteres (como start/stop bits). Sncrona: o dispositivo de acesso compartilha um relgio com o dispositivo de transmisso. ### Banco de dados Funes

Administrador de banco de dados: ele responsvel pela autorizao de acesso ao banco de dados e pela coordenao e monitorao do seu uso. Ele administra o SGDB e os softwares relacionados. Projetista de banco de dados: responsvel pela escolha dos dados que faro parte do banco de dados, escolhendo a estrutura correta para representar e armazenar os dados. responsabilidade dele tambm avaliar a necessidade dos usurios com a finalidade de definir vises que sero necessrias. ### Engenharia de software Modelagem gil (Agile modeling) AM Tem 3 objetivos: 1) definir e mostrar como colocar em prtica uma coleo de valores, princpios e prticas pertinentes modelagem efetiva e "peso-leve". 2) explorar como aplicar tcnicas de modelagem em projetos de software atravs de uma abordagem gil tal como XP, DSDM ou SCRUM. 3) explorar como melhorar a modelagem sob processos prescritivos como o RUP. ### Sistemas de informao Sistemas de Informaes empresariais (EIS): do suporte aos administradores. Sistemas de Informaes gerenciais (SIG): esto relacionados ao suporte a atividades funcionais. Sistemas de Processamento de Transaes (SIT): esto relacionados s atividades repetitivas vitais. ### Sistemas Operacionais Tipos: Lote(batch) x Interativo(on-line) Monousurio x Multiusurio Monotarefa x Multitarefa Distribudos Paralelos Tempo real Mquinas virtuais ### Rede de computadores Protocolos de autenticao Centro de distribuio de chaves: composto por um servidor de autenticao e servidor de concesso de Tickets. O Kerberos trabalha baseado em tickets. Chave secreta compartilhada.

Intermdio da criptografia com chave pblica. Kerberos: principal protocolo de autenticao. Utiliza a autenticao mtua: autenticao entre cliente e servidor em ambas direes. ### Engenharia de software Top-down: decompor o sistema em sub-sistemas para melhor visualiz-los. No Topdown, viso geral do sistema formulada, especificando, mas no detalhando qualquer sistemas de primeiro nvel. Cada subsistema ento refinado em detalhes ainda maiores, s vezes em muitos nveis adicionais de subsistemas at que a especificao inteira reduzida a elementos bsicos. Bottom-up: juntar as partes dos sistemas para dar sistemas maiores. No bottom-up, os elementos base individuais do sistema so especificado em grande detalhe primeiro. Eles so unidos para formar subsistemas maiores at que um sistema completo de nvel alto formado. ### Rede de computadores Topologia de rede Barramento: todos os computadores so ligados no mesmo barramento fsico. Apenas uma mquina pode escrever no mesmo barramento num dado momento. Anel: estaes conectadas atravs de um circuito fechado e em srie. (Em desuso.) Estrela: computadores so interligados atravs de switches ou qualquer outro concentrador/comutador. No tem ligao direta entre computadores. rvore: equivalente a vrias estrelas interligadas entre si atravs de seus ns centrais. Ponto a ponto. ### Engenharia de software Usabilidade Princpios: fcil aprendizagem, utilizao eficaz e eficiente, satisfao subjetiva, facilidade para relembrar de como o uso, pequena taxa de "erros" (erro quando o usurio tenta obter num resultado e no consegue). ### Engenharia de software PERT/CPM PERT = Program Evaluation and Review Technique. CPM = Critical Path Method.

Os objetivos do mtodo PERT/CPM: - minimizar problemas localizados de projetos, tais como: atrasos, estrangulamentos da produo e interrupes de servios; - conhecer, antecipadamente, atividades crticas cujo cumprimento possa influenciar a durao total do programa; - manter a administrao informada quanto ao desenvolvimento, favorvel ou no, de cada etapa ou atividade do projeto, permitindo a constatao, antecipada, de qualquer fator crtico que possa turbar o desempenho e permitir uma adequada e corretiva tomada de deciso; - estabelecer o "quando" cada envolvido dever iniciar ou concluir suas atribuies. - ser um forte instrumento de planejamento, coordenao e controle. Folga de evento: definida como a diferena entre os tempos mais tarde de incio e o mais cedo de incio de um evento. Folga de atividade: definida como a disponibilidade de tempo que uma atividade pode ser executada, alm da sua durao prevista, sem afetar a durao pr-estabelecida para o projeto. As atividades de um caminho crtico so denominadas atividades crticas. ### Engenharia de software (qualidade.pdf e custosdaqualidade.pdf) Qualidade de software: conjunto de caractersticas que devem ser alcanadas em um determinado grau para que o produto atenda s necessidades de seus usurios. Ou ainda: totalidade de caractersticas de uma entidade que lhe confere capacidade de satisfazer a necessidade explcita e implcita. Modelo de qualidade segundo McCall et all, 1977: - caractersticas operacionais (operao): correo (o quanto ele cumpre os objetivos visados pelo cliente), confiabilidade (o quanto ele executa a funo pretendida com a preciso exigida), integridade (o quanto o acesso ao sw ou aos dados por pessoas no autorizados pode ser controlado), eficincia, usabilidade (o quanto de esforo necessrio pra aprender a usar o sw). - habilidade para ser alterado (reviso): manutenibilidade (localizar e eliminar erro), flexibilidade (mudar o programa), testabilidade. - adaptabilidade a novos ambientes (transio): portabilidade, reusabilidade (o quanto ele pode ser usado em outros programas), interoperabilidade (esforo para acoplar um programa a outro). Custos da qualidade so divididos em quatro categorias: custos de preveno*, custos de avaliao*, custos de falhas internas** e custos de falhas externas**. * custos inevitveis ** custos inevitveis ### Engenharia de software

Diagramas de pacotes Um pacote um conjunto de elementos agrupados. Estes elementos podem ser classes, diagramas ou at mesmo outros pacotes. Modelo de 3 camadas: - apresentao: janela, relatrios - aplicao: registrar vendas, autorizar pagamentos - armazenamento: BD ### Sistemas operacionais Sistemas distribudos Tipos de transparncias (ocultar o fato de que seus processos e recursos esto distribudos por vrios computadores): - acesso: oculta diferenas na representao de dados e no modo de acesso a um recurso. - localizao: oculta o lugar onde o recurso est sendo utilizado. - migrao: oculta que um recurso pode ser movido para outra localizao. - relocao: oculta que um recurso pode ser movido para outra localizao enquanto em uso. - replicao: oculta que um recurso replicado. - concorrncia: oculta que um recurso pode ser compartilhado por vrios usurios concorrentes. - falha: oculta a falha e a recuperao de um recurso. ### Engenharia de software Repositrio de configurao de software - lugar seguro onde artefatos so depositados; - permitem armazenamento, busca e recuperao de artefatos; - servem como um ponto de referncia; - apiam no aumento da memria organizacional; ### Engenharia de software Gerenciamento de riscos Componentes de riscos so: - risco de desempenho: grau de incerteza de que o produto atenda seus requisitos e seja adequado para seu uso planejado. - risco de custo: o grau de incerteza de que o oramento do projeto seja mantido. - risco de apoio: o grau de incerteza de que o software resultante seja fcil de corrigir, adaptar e aperfeioar. - risco de cronograma: o grau de incerteza de que o cronograma do projeto ser cumprido e de que o produto vai ser entregue no prazo.

### Rede de computadores Segurana Worms: no precisam de infectar outro arquivo como os vrus. Raramente causa dano a um arquivo igual os vrus. Causam dano na rede, mesmo que seja s consumindo a banda. Trojan: permite que hackers tenham acesso ao computador. Podem enviar informaes confidenciais tambm. ### Rede de computadores Tipos de backup - total: copia todos os arquivos selecionados e os marca como arquivos que passaram por backup. - vantagens: rpida localizao e restaurao dos dados. - desvantagens: geram um volume muito grande de dados e interferem bastante no ambiente operacional pois copiam todos arquivos (modificados ou no). - atualizao do total: atualiza o backup total copiando apenas os modificados. - vantagens: rpida realizao do backup e rpida localizao do backup. - desvantagens: os arquivos de backup so maiores. - incremental: copia todos os arquivos que foram alterados desde o ltimo backup total ou incremental mais recente. - vantagens: economia de tempo e espao - desvantagens: restaurao mais lenta porque precisa do backup inicial total e todos os backups incrementais at o mais recente. - diferencial: cpia de todos os arquivos que foram alterados desde o ltimo backup total. - vantagens: para a restaurao so necessrios apenas o backup inicial total e o ltimo diferencial. - desvantagens: so maiores e mais demorados que o incremental. - cpia auxiliar ou replicao: cria cpias exatas dos arquivos de backup para redundncia. ### Rede de computadores Segurana da informao - integridade: visa assegurar que o documento no foi alterado aps ter sido assinado. - autenticidade: visa estabelecer a validade da transmisso, da mensagem e do seu remetente. Comprovar a origem e autoria da mensagem. - no repdio: visa garantir que o autor no negue ter criado e assinado a mensagem. - irretroatividade: visa garantir que o sistema no permita a gerao de documento de forma retroativa no tempo. ### Sistemas de informacao

Sistemas ERP - a classificao ABCD avalia o grau de efetividade da implantao de um ERP em uma organizao. - a implantao de um ERP, em geral, demanda o envolvimento, virtualmente, de todos os departamentos de uma organizao e requer que as pessoas passem a trabalhar de uma forma diferente. - necessria uma reorganizao dos processos. - definio dos papis de cada pessoa na organizao. Com isso h maior segurana no acesso aos dados. ### Engenharia de software Processos de gerenciamento de projetos Adequao: processos que devem ser considerados ao gerenciar o projeto. Os processos de gerenciamento de projetos so agrupados em 5 categorias: - iniciao: so os processos realizados para definir um novo projeto ou uma nova fase de um projeto j existente atravs da obteno de autorizao para iniciar o projeto ou a nova fase. Processos de gerenciamento: desenvolver o termo de abertura do projeto e identificar as partes interessadas. - planejamento: processos realizados para definir escopo do projeto, refinar os objetivos e desenvolver o curso de ao necessrio para alcanar os objetivos para os quais o projeto foi criado. Ondas sucessivas so detalhamentos progressivos do plano de gerenciamento do projeto com frequncia. As atualizaes nos documentos do projeto fornecem uma maior preciso em relao ao cronograma, custos e requisitos de recursos para cumprir o escopo definido para o projeto. Processos de planejamento: desenvolver o plano de gerenciamento do projeto, coletar requisitos, definir o escopo, criar a EAP, definir as atividades, sequnciar as atividades, estimar os recursos das atividades, estimar as duraes das atividades, desenvolver o cronograma, estimar custos, determinar o oramento, planejar a qualidade, desenvolver o plano de recursos humanos, planejar as comunicaes, planejar o gerenciamento de riscos, identificar os riscos, realizar a anlise qualitativa dos riscos, realizar a anlise quantitativa dos riscos, planejar resposta aos riscos e planejar as aquisies. - execuo: processos realizados para executar o trabalho definido no plano de gerenciamento do projeto para satisfazer as especificaes do mesmo. Os processos de gerenciamento de projetos so: orientar e gerenciar a execuo do projeto, realizar a garantia da qualidade, mobilizar a equipe de projeto (confirmao da disponibilidade dos recursos humanos), desenvolver a equipe do projeto, gerenciar a equipe do projeto, distribuir informaes, gerenciar as expectativas das partes interessadas e realizar aquisies. - monitoramento e controle: processos necessrios para acompanhar, revisar e regular o progresso e o desempenho do projeto, identificar todas as reas nas quais sero

necessrias mudanas no plano e iniciar as mudanas correspondentes. O grupo de processos de monitoramento e controle inclui os seguintes processos de gerenciamento de projetos: monitorar e controlar o trabalho do projeto, realizar o controle integrado de mudanas, verificar o escopo, controlar o escopo, controlar o cronograma, controlar os custos, realizar o controle da qualidade, reportar o desempenho, monitorar e controlar os riscos e administrar as aquisies. - encerramento: processos executados para finalizar todas as atividades de todos os grupos de processos, visando encerrar formalmente o projeto ou uma fase. O grupo de processos de encerramento inclui os seguintes processos de gerenciamento de projetos: encerrar o projeto ou fase e encerrar as aquisies. ### Engenharia de Software REST: REpresentational State Transfer. uma arquitetura de comunicao heterognea de aplicao para aplicao, alm de SOAP, WSDL e WS-*. Ele um conjunto de princpios de como Web Standards (como HTTP e URI's) devem ser usados. No design de uma aplicao, se os princpios REST forem seguidos, haver um sistema que explora a arquitetura Web em seu benefcio. Cinco princpios: - d, a todas as coisas, um identificador: com um id para tudo, pode-se mandar o link de um cliente via email, favoritar no navegador, anotar em um papel, etc. A crtica dessa ideia com relao a expor valores de banco de dados nos links. - vincule as coisas: a ideia que se usem links para referenciar tudo que possa ser identificado sempre que for possvel. - utilize mtodos padronizados. - recursos com mltiplas representaes. - comunique sem estado. ### Rede de computadores Acordo de confidenciabilidade e de no-divulgao: um contrato legal entre, pelo menos duas partes, que destacam materiais confidenciais que as partes desejam compartilhar, mas cujo uso generalizado elas desejam restringir. O acordo cria um relacionamento confidencial entre as partes para proteger qualquer tipo de segredo comercial. O acordo pode ser mtuo, significando que ambas as partes sofrem restries no uso dos materiais providos ou pode ser unilateral. ###
Engenharia de software NBR/ISO 27002 Norma equivalente ISO/IEC 17799:2005. A segunda edio cancela e substitui a edio anterior (ABNT NBR ISO/IEC 17799:2001), que foi tecnicamente revisada. Requisitos legais: - proteo de dados e privacidade de informaes. - proteo de registros organizacionais.

- direitos de propriedade intelectual. Melhores prticas: - documento da poltica de segurana da informao. - atribuio de responsabilidades para a segurana da informao. - conscientizao, educao e treinamento em segurana da informao. - processamento correto nas aplicaes. - gesto de vulnerabilidades tcnicas. - gesto de continuidade de negcios. - gesto de incidentes de segurana da informao e melhorias. Fatores crticos de sucesso: - poltica de segurana da informao, objetivos e atividades, que reflitam os objetivos do negcio. - uma abordagem e uma estrutura para a implementao, manuteno, monitoramento e melhoria da segurana da informao que seja consistente com a cultura organizacional. - comprometimento e apoio visvel de todos os nveis gerenciais. - um bom entendimento dos requisitos de segurana da informao, da anlise/avaliao de riscos e da gesto de risco. - divulgao eficiente da segurana da informao para todos os gerentes, funcionrios e outras partes envolvidas para se alcanar a conscientizao. - distribuio de diretrizes e normas sobre a poltica de segurana da informao para todos os gerentes, funcionrios e outras partes envolvidas. - proviso de recursos financeiros para as atividades da gesto de segurana da informao. - proviso de conscientizao, treinamento e educao adequados. - estabelecimento de um eficiente processo de gesto de incidentes de segurana da informao. - implementao de um sistema de medio, que seja usado para avaliar o desempenho da gesto da segurana da informao e obteno de sugesto para a melhoria. A norma estruturada em 11 sees subdivididas em categorias. Cada categoria principal de segurana da informao contm: - um objetivo de controle que define o que deve ser alcanado. - um ou mais controles que podem ser aplicados para se alcanar o objetivo do controle. ### Sistemas de informao Rede de Petri: tcnica de modelagem que permite a representao de sistemas. Esta tcnica permite modelar sistemas paralelos, concorrentes, assncronos e no determinsticos. A representao grfica formada por dois componentes: um ativo chamado de transio (barra) e outro passivo denominado lugar (crculo). Os lugares equivalem s variveis de estado e as transies equivalem s aes realizadas pelo sistema. Eles so ligados entre si atravs de arcos dirigidos que podem ser mltiplos ou nicos.

Marcas so informaes atribudas aos lugares, para representar a situao da rede em um determinado momento. A marcao da rede de Petri modificada a cada ao realizada (transio disparada). ### Estruturas de dados rvore B. Adicionar: Para inserir um novo elemento em uma rvore B basta localizar o n folha X onde o novo elemento deva ser inserido. Se o n X estiver cheio, ser necessrio realizar uma subdiviso de ns que consiste em passar o elemento mediano de X para seu pai e subdividir X em dois novos ns com t - 1 elementos e depois inserir a nova chave. Grau mnimo t dita o nmero mnimo e mximo de elementos de um n. t deve ser >= 2. Nmero mnimo de elementos: t-1. Nmero mximo de elementos: 2t - 1. Nmero mnimo de filhos: t Nmero mximo de filhos: 2t ### Engenharia de software

Diagrama de Gantt: diagrama que mostra o cronograma do projeto, tanto real, quanto realizado e as tarefas em andamento. Criado por Henry Gantt em 1917, ela utilizado at hoje. ### Engenharia de software Data warehouse Tabelas fato: so as principais tabelas numa modelagem dimensional, pois nelas so guardadas as medidas numricas mais importantes do processo de negcio. Exemplos como valor do faturamento, quantidade de produtos entregues e a quantidade de entregas so os tipos de dados que esto alocados nesta tabela, ou seja, ela geralmente guarda informaes referentes s transaes ou eventos de negcios. As tabelas fato so compostas obrigatoriamente por uma chave primria composta pelas chaves primrias das tabelas que contem as descries do fato, as dimenses. Geralmente uma tabela fato apresenta poucas colunas, porm nela que a maior parte das informaes est contida e por este motivo que elas consomem em medida 90% do espao de um data warehouse. Tabelas dimenso: compostas pelas informaes complementares s tabelas fato. As tabelas de dimenso esto sempre acompanhadas de tabelas de fatos. Sem os fatos, no h informao para exibir. A partir da combinao das vrias dimenses com o fato, uma informao gerada, para que a alta gerncia possa tomar suas decises. Estas tabelas so compostas basicamente por colunas que contem elementos textuais que descrevem o negcio e uma chave primria que ir compor a chave composta de sua tabela fato. ### Estruturas de dados rvores AVL So rvores balanceadas. Isto , a diferena entre a sub-rvore direita e a esquerda pode ser -1, 0 ou +1, somente. A esta diferena d-se o nome de fator de balanceamento (FB). Para inserir um elemento, primeiro coloque-o na posio em que ele deveria estar sem se preocupar com o balanceamento. Depois que ocorre o balanceamento. Exemplo:

Da etapa 2 pra 3, houve uma rotao sobre o n 4 para a esquerda (pois ele tem FB positivo). De 3 para 4, h uma rotao sobre o n 8 para a direita (pois ele tem FB negativo).

Outro exemplo a insero do nmero 3 na rvore inicial do exemplo de cima.

Como os dois FB (o da raiz -2 e o do filho -1, do n 4) tem o mesmo sinal, ento uma rotao simples sobre o n desbalanceado (n 8) somente necessria (no caso para a direita pois o sinal negativo). ### Engenharia de software Modelagem esttica: diagrama de classes representa estrutura esttica do sistema; foco nas instrues relevantes para a construo do sistema; esse diagrama contm conceitos (classes) importantes para o domnio do problema e as ligaes entre eles; cada classe especificada em termos das informaes que armazena (atributos) e dos servios que ela prov (operaes). Modelagem dinmica identifica e modela os aspectos do sistema de software que podem mudar durante a sua execuo, devido ocorrncia de eventos; foco no comportamento que o sistema deve apresentar; usa os diagramas dinmicos da UML (sequncia, colaborao e estados); especifica uma verso inicial das interfaces pblicas das classes de anlise; sub-etapa de anlise OO foco no domnio do problema. A modelagem de classes de anlise fornece subsdios para a modelagem dinmica. Primeiro as classes so modelas. Depois, as interaes entre elas so pensadas. ### Engenharia de software Reviso de software Segundo CEI/CMMI, um processo de reviso pode ser entendido como uma avaliao crtica do produto. Walkthroughs, inspees e auditorias so consideradas processos de reviso. Os processos de reviso fornecem subsdios para os processos de avaliao de qualidade de software. Outros benefcios: - aumentar a qualidade do produto; - identificar e documentar defeitos; - identificar melhorias necessrias em um produto de trabalho; - verificar que o produto de trabalho est em conformidade com padres, especificaes e requerimentos adotados; - atingir consenso em relao aos produtos de trabalho;

- aumentar o conhecimento dos pares em relao ao produto; - ser uma via gerencial para, formalmente, completar uma tarefa. Pode-se envolver tanto engenheiros de software, quanto usurios, programadores, analistas, projetistas, etc. As revises so aplicadas a pedaos de software, mdulos do sistema como um todo. ### Engenharia de software Regras de negcio: so polticas, condies ou restries que devem ser consideradas na execuo dos processos existentes em uma organizao. uma parte importante dos processos organizacionais porque descrevem a maneira como a organizao funciona. Cada organizao pode ter vrias regras de negcio. As regras de negcio de uma organizao so normalmente identificadas nas fases de levantamento de requisitos de anlise. So documentadas no modelo de regras de negcio. Pode-se descrev-las utilizando textos informais do tipo Um cliente de banco no pode tirar mais de R$1.000,00 por dia., etc. As regras de negcio normalmente tem influncia sobre a lgica de execuo de um ou mais casos de uso. ### Banco de dados Sintonia de banco de dados (tuning): realizao de ajustes em um sistema de BD visando obter um melhor desempenho das aplicaes por meio da utilizao adequada dos recursos computacionais disponveis. uma das principais tarefas de manuteno do administrador de BD. Realizar sintonia pode ser especificar novos ndices, realizar o particionamento adequado de algumas tabelas ou desnormalizao de outras. As atividades podem ficar mais rpidas ou evitar processamentos desnecessrios. Outro ponto importante na sintonia o ajuste das configuraes dos SGBDs. ### Sistemas de informao Gesto por processo - de difcil implementao e depende de um ciclo de atividades gerenciadas. - A excelncia do desempenho e o sucesso no negcio requerem que todas as atividades inter-relacionadas sejam compreendidas e gerenciadas segundo uma viso de processos. - Enfoque administrativo aplicado por uma organizao que busca a otimizao e melhoria da cadeia de seus processos, desenvolvida para atender necessidades e expectativas das partes interessadas, assegurando o melhor desempenho possvel do sistema integrado a partir da mnima utilizao de recursos e do mximo ndice de acerto. Atributos 1 Foco 2 Relacionamento primrio 3 Orientao Viso tradicional Chefe Cadeia de comando Hierrquica Viso de processo Cliente Cliente fornecedor Processo

4 Quem toma deciso 5 Estilo

Gerncia Autoritrio

Todos os participantes Participativo

Cada processo um conjunto de sub-processos. Cada sub-processo um conjunto de atividades. Cada atividade um conjunto de tarefas. - Gesto por processos representa coloca em risco uma grande quantidade de recursos. - Seus resultados produzem alto impacto para os clientes. - Falhas nesses processos comprometem o desempenho de todo o sistema. - So crticos para a consecuo da estratgia da organizao. Ferramentas para anlise e melhoria de processo: - Grficos: monitorar desempenho para detectar tendncias. - Diagramas de afinidade: organizar e agrupar dados. - Grficos pareto: foca em esforo de melhoria em reas que tem os maiores impactos. - Diagramas de causa e efeito: identificar causas para um problema. - Scatter plot: exibir (visualmente) relacionamentos entre duas variveis independentes. - Brainstorming: gerar solues criativas para um problema. - Mapeamento de processo: entender e/ou melhorar um processo de trabalho. - Anlise do campo de fora: identificar fora motriz e contida. ### Sistemas de informao Indicadores de desempenho: termos e significados. Indicadores: resultados numricos que evitam decises baseadas em conceitos subjetivos, como bom, rpido, etc. ndices: refletem resultados efetivamente obtidos que, comparados aos padres, revelam os problemas representados pelos desvios. Padres: valores definidos como referncia para os processos. Metas: resultados a serem alcanados num perodo de tempo. ### Acessibilidade na Web reas ou princpios para acessibilidade rea da Percepo ou princpio perceptvel: trata de benefcios relacionados apresentao do contedo, da informao. Preocupa-se com percepo de elementos como grficos, sons, imagens, multimdia, etc. Isso significa, por exemplo, que poder ter uma descrio textual para as imagens da pgina. rea da operao ou princpio opervel: preocupa-se com a manipulao da informao, do contedo. Essa rea deve garantir formas alternativas ao acesso s informaes atravs de maneiras diferencias de navegao ou tcnica similar. Percebe-se, tambm, que de responsabilidade da Operao garantir sempre ao usurio o controle da navegao e interao com o stio. Um exemplo pode ser que todas as funes sejam acessadas pelo teclado, sendo o mouse opcional.

rea do entendimento ou princpio compreensvel: trata de questes relacionadas compreenso do contedo publicado. Deve-se garantir que todo o contedo apresentado seja de fcil compreenso para qualquer tipo de usurio. Evita que o usurio cometa erro, corrigindo e apresentando-o. rea da compatibilidade ou princpio robusto: aborda questes como a necessidade de utilizarmo-nos sempre de tecnologias acessveis e compatveis com o modelo proposta para acessibilidade na web, isto , o site criado maximizando a compatibilidade com a tecnologia assistiva presente e futura. ### Sistemas de informao Gesto por processo - O mapeamento do processo prov uma estrutura para que processos complexos possam ser avaliados de forma simples. - A equipe pode ver o processo completo. - possvel visualizar mudanas no processo que provocaro grandes impactos. - reas e etapas que no agregam valor podem ser facilmente identificadas. - Os tempos de ciclo de cada etapa podem ser estimados. Estabelecer um ponto inicial e final de um processo um ponto de partida crucial no mapeamento, pois ajuda a equipe a identificar as etapas importantes, eventos e operaes que constituem o processo. Tipicamente o ponto inicial de um processo o primeiro que recebe inputs de fornecedores. Normalmente o ponto final a entrega do produto principal ou servio ao cliente do processo. Qual a finalidade do mapeamento? - Adquire clara visibilidade e conhecimento a respeito da definio de um processo. - Realizar anlise crtica a respeito do processo. - Utilizar como linha de base para melhorias ou para reengenharia. O mapeamento fundamental para identificao dos processos essenciais e para anlise sistmica das organizaes. ### Sistemas de informao Tcnicas de levantamento de informao sobre os processos Questionrio: consiste em uma srie de questes ou perguntas formuladas previamente, podendo ser utilizado com ou sem presena de pessoas envolvidas no processo, quando h necessidade de obter respostas quantitativas; quando preciso obter informaes de diferentes pontos geogrficos e quando necessria uma anlise estatstica. No necessria a presena dos analistas quando da execuo, ou aplicao, mas as perguntas podem ser interpretadas de forma diferente por pessoas diferentes.

Pesquisa de documentao existente ou reviso de literatura: compreende a identificao, coleta e anlise de todos os instrumentos escritos internos ou externos organizao referentes ao tema que esta sendo desenvolvido. Um problema que esta tcnica no uma que possa ser utilizada independentemente das outras tcnicas de levantamento. Workshop: trata-se de uma tcnica de elicitao em grupo usada em uma reunio estruturada. Devem fazer parte do grupo uma equipe de analistas e uma seleo dos stakeholders que melhor representam a organizao e o contexto em que o sistema ser usado, obtendo assim um conjunto de requisitos bem definidos. Um problema que no abre espao para ideias externas. Outro problema questo de horrio disponvel para stakeholders. ### Sistemas de informao Cadeia de valor criada por Michael Porter em 1985. (http://www.strategy-train.eu/index.php?id=270&L=5) O modelo de cadeia de valor destaca as atividades especficas da empresa nas quais as estratgias competitivas podem ser melhor aplicadas. Tal modelo apresenta as seguintes caractersticas: - Encara uma empresa como uma srie ou cadeia de atividades bsicas que adicionam valor a seus produtos e servios e, com isso, adicionam uma margem de valor para a empresa. - Algumas atividades das empresas so consideradas atividades primrias e outras so atividades de apoio. Esse referencial pode destacar onde as estratgias competitivas podem ser melhor aplicadas em um negcio. O objetivo das atividades primrias a produo de valor que exceda o custo de fornecimento do produto ou servio, ou seja, para gerar um lucro. So elas: logstica interna ou de entrada, operaes, logstica externa ou de sada, marketing/vendas e servio. Atividades de Apoio ou de Suporte: as atividades primrias da cadeia de valor so facilitadas pelas atividades de apoio, organizadas por Porter em quatro categorias genricas, detalhadas de acordo com a especificidade da empresa. So elas: infraestrutura, gesto de recursos humanos, desenvolvimento tecnolgico e aquisio. ### Sistemas de informao PDSA plan, do, study, act. Anteriormente chamado de PDCA (C de check). PDCA Plan Nesta etapa so definidas as metas que se deseja atingir, geralmente, anuais. As metas devem relevar pontos importantes como as tendncias de mercado, os fornecedores, a situao poltica do pas e do mundo. Aps definidas as metas, deve-se buscar os meios e os procedimentos para alcan-las. Do

Aqui todos os envolvidos com as aes so treinados nos procedimentos que tem como base as metas estabelecidas, realizam as atividades e colhem dados, para a fase de verificao. a fase de implantao do planejamento. Check Esta uma etapa puramente gerencial, verificando se as aes executadas esto de acordo com as metas estabelecidas. Os dados utilizados so aqueles coletados na etapa anterior, que so analisados e comparados com o planejado (fase planejar). Normalmente, so empregadas as ferramentas da qualidade. Esta fase foi renomeada para study por Deming para enfatizar a importncia dos resultados, e evitar confund-la como sendo apenas inspeo. Act Nesta etapa, a atuao corretiva, ou seja, caso a operao realizada no esteja de acordo com o planejado, deve-se atuar corretivamente atravs de planos de ao para correo de rumo visando meta estabelecida. A melhoria contnua feita a partir do momento em que as metas estabelecidas sejam atingidas. Neste caso, deve-se voltar fase planejar e revisar as metas j atingidas traando novos desafios, procedimentos, etc. O ciclo PDCA um mtodo de gesto, que representa o caminho a ser seguido para que as metas estabelecidas sejam atingidas. Tambm conhecido por ciclo de Shewhart, que foi o idealizador do conceito; entretanto, Deming foi o responsvel pelo seu desenvolvimento. ### Sistemas de informao Histograma: na estatstica, um histograma uma representao grfica da distribuio de frequncias de uma massa de medies, normalmente um grfico de barras verticais. uma das Sete Ferramentas da Qualidade. Desdobramento da funo qualidade: O QFD (Quality Function Deployment Desdobramento da Funo Qualidade) uma das ferramentas da qualidade que foi criada na dcada de 60 pelo japons Yoji Akao e que tem como objetivo principal permitir que a equipe de desenvolvimento do produto incorpore as reais necessidades do cliente em seus projetos de melhoria. Podemos dizer que o QFD uma ferramenta que possibilita ouvir a voz do cliente e orden-la de modo a facilitar a anlise de suas necessidades que so transformadas em requisitos para a melhoria do produto na forma de especificaes tcnicas do mesmo. Diagrama de causa e efeito (Espinha de peixe, Diagrama 6M): Esta ferramenta uma representao grfica que nos possibilita organizar informaes, auxiliando na identificao das possveis causas de um determinado problema (efeito). Considerada uma das sete ferramentas da Qualidade, sendo uma importante ferramenta para o gerenciamento do controle da Qualidade, criada pelo engenheiro qumico Kaoru Ishikawa em 1943. Normalmente elaborado a partir de um brainstorming, e permite que ele seja colocado atravs de grupos as possveis causas do problema. Dicas para o melhor desempenho do estudo atravs do Diagrama de Causa e Efeito:

- Reunir todas as pessoas envolvidas no processo identificado para estudo; - Reunir informaes baseadas nas causas; - Objetividade no estudo. tambm chamado de Diagrama 6M: Mtodo: toda a causa envolvendo o mtodo que estava sendo executado o trabalho; Matria-prima: toda causa que envolve o material que estava sendo utilizado no trabalho; Mo-de-obra: toda causa que envolve uma atitude do colaborador (ex: procedimento inadequado, pressa, imprudncia, ato inseguro, etc.) Mquinas: toda causa envolvendo mquina que estava sendo operada; Medida: toda causa que envolve uma medida tomada anteriormente para modificar o processo, etc; Meio ambiente; toda causa que envolve o meio ambiente em si ( poluio, calor, poeira, etc.)e o ambiente de trabalho (layout, falta de espao, dimensionamento inadequado dos equipamentos, etc.). Diagrama de afinidades: Ferramenta utilizada com o objetivo de se conhecer o problema por meio da organizao das ideias. a representao grfica de grupos de dados afins, que so conjuntos de dados verbais que tm entre si, alguma relao natural que os distinguem dos demais. Ela utilizada para: - Direcionar a soluo de um problema; - Organizar as informaes necessrias soluo de um problema; - Organizar as causas de um problema; - Fornecer suporte para soluo de um problema; - Fornecer suporte para a inovao de conceitos tradicionais; - Prever situaes; - Organizar as ideias resultantes de algum processo de avaliao, como na auditoria da qualidade; - Planejar a coleta de dados para futura estratificao. ### Sistemas de informao Tcnicas de modelagem BPMN: notao de modelagem de processos de negcio, cujo objetivo seja facilitar o entendimento de todos os envolvidos na gesto e monitorao dos processos. Foi desenvolvido pela BPMI (Business Process Management Initiative).

IDEF (integrated definition) um grupo de mtodos de modelagem que podem ser usados para descrever operaes em uma empresa. Tem como objetivo modelar atividades necessrias para darem suporte anlise de sistema, design, melhoria ou integrao. Originalmente, IDEF foi criado para melhorar a comunicao entre as pessoas que tentavam entender o sistema. Hoje, IDEF usado para documentao, entendimento, design, anlise, planejamento e integrao.

EPC (Event-driven Process Chain) Pertence arquitetura ARIS (Architecture of Integrated Information Systems). EPC habilita a modelagem de processo como uma seqncia lgica de funes. Considera-se EPC como uma cadeia de processos que pode ser entendido como a quantidade de funes que so disparadas por um ou mais eventos.

Problemas: alto custo e dificuldade de utilizao. ### Sistemas de informao PCF (process classification framework) A decomposio funcional feita por: - categoria: o mais alto nvel indicado por nmeros inteiros.

- grupo de processos: 1 decomposio funcional so todos os itens do PCF com um dgito decimal. - processo: 2 decomposio funcional so todos os itens do PCF com dois dgitos decimais. - atividade: 3 decomposio funcional so todos os itens do PCF com trs dgitos decimais. Exemplos de Classificao - Gerenciar servio de atendimento ao cliente (5.0): categoria; - Dar ateno ao cliente/desenvolver estratgia de atendimento ao cliente (5.1): grupo de processos; - Desenvolver segmentao de cliente/priorizao do cliente (5.1.1): processo; - Receber pedidos de cliente/perguntas do cliente (5.2.1.1): atividade. ### Sistemas de informao Medidas de desempenho Segundo Harrington (1993) h trs controles principais de processo: - Eficcia - medida que permite o controle das sadas do processo, ou seja, a efetividade com que s necessidades e expectativas dos clientes esto sendo atendidas; - Eficincia - a maneira como o uso dos recursos minimizado para alcanar os objetivos da organizao, eliminando o desperdcio, procurando atingir a eficcia; - Adaptabilidade - consiste no controle de quanto o processo (ou subprocesso) flexvel em atender as necessidades e expectativas dos clientes, tanto aquelas rotineiras quanto as especiais. ### Sistemas de informao Matriz GUT (gravidade, urgncia, tendncia): Esta matriz uma forma de se tratar problemas com o objetivo de prioriz-los. Leva em conta a gravidade, a urgncia e a tendncia de cada problema. Gravidade: representa o impacto do problema analisado caso ele venha a acontecer. analisado sobre alguns aspectos, como: tarefas, pessoas, resultados, processos, organizaes etc. Analisando sempre seus efeitos a mdio e longo prazo, caso o problema em questo no seja resolvido; Urgncia: representa o prazo, o tempo disponvel ou necessrio para resolver um determinado problema analisado. Quanto maior a urgncia, menor ser o tempo disponvel para resolver esse problema. recomendado que seja feita a seguinte pergunta: A resoluo deste problema pode esperar ou deve ser realizada imediatamente?; Tendncia: representa o potencial de crescimento do problema, a probabilidade do problema se tornar maior com o passar do tempo. a avaliao da tendncia de crescimento, reduo ou desaparecimento do

problema. Recomenda-se fazer a seguinte pergunta: Se eu no resolver esse problema agora, ele vai piorar pouco a pouco ou vai piorar bruscamente?. Para cada problema, uma nota de 1 a 5 (5 mais grave, 1 menos grave) atribuda para cada uma das caractersticas e o produto entre G, U e T resultar em um nmero. As tarefas sero ordenadas decrescentemente de acordo com esse nmero. Esta ser a ordem em que as tarefas sero executadas. ### Sistemas de informao Princpio de Pareto ou Princpio 80/20 O Princpio 80/20 afirma que existe um forte desequilbrio entre causas e efeitos, entre esforos e resultados e entre aes e objetivos alcanados. O Princpio afirma, de uma maneira genrica, que 80% dos resultados que obtemos esto relacionados com 20% dos nossos esforos. Em outras palavras: uma minoria de aes leva a maior parte dos resultados, em contrapartida, uma maioria de aes leva a menor parte dos resultados. A lei foi sugerida por Joseph M. Juran, que deu o nome em honra ao economista italiano Vilfredo Pareto. Exemplo: Uma livraria no pode ter todos os ttulos do mercado, portanto ela aplica a regra de Pareto e foca em 20% dos ttulos que geram 80% da receita. - A maioria dos acidentes de carro ocorre em um nmero relativamente pequeno de cruzamentos, na faixa da esquerda em determinada hora do dia. - A maioria dos acidentes fatais ocorre com jovens. - Em vendas comissionadas, 20% dos vendedores ganharo mais de 80% das comisses. - Estudos mostram que 20% dos clientes respondem por mais de 80% dos lucros de qualquer negcio. - Menos de 20% das celebridades dominam mais de 80% da mdia, enquanto mais de 80% dos livros mais vendidos so de 20% dos autores. - Mais de 80% das descobertas cientficas so realizadas por 20% dos cientistas. Em cada poca, so uns poucos especialistas celebres que fazem a maioria delas. ### Engenharia de software Tpicos em gerncia de projetos Quando os recursos disponveis para a realizao de um projeto esto escassos: - Realiza-se uma classificao a partir de mtodos relacionados ao planejamento estratgico, em que os projetos so classificados como ofensivos, quando se busca ampliar o mercado, ou defensivos, em que a postura de manuteno dos clientes.

- preciso realizar uma avaliao preliminar de cada projeto de forma a analisar sua exequibilidade e, em caso afirmativo, proceder anlise de custo/benefcio para avaliar se a organizao deve realiz-lo. - Aps a seleo estratgica deve-se realizar a programao estratgica, quando considerado o nvel de tolerncia da organizao para o risco no conjunto dos projetos selecionados. Afirmativa errada: Estudo de viabilidade corresponde etapa do projeto em que se avalia, com base na receita da empresa, a mesma capacidade de executar o projeto. Errada, pois o estudo de viabilidade no est relacionado somente a recursos financeiros, um projeto pode no poder ser executado, por exemplo, se no tiver pessoal capacitado disponvel, se houver algum impedimento legal. Entradas do processo de gerenciamento do escopo: - Fatores ambientais da empresa; ativos de processos organizacionais; termo de abertura; declarao preliminar de escopo; plano de gerenciamento do projeto. Entradas do processo do planejamento das aquisies: Linha de base do escopo que consiste dos seguintes componentes: Declarao do escopo; EAP; Dicionrio EAP; Documentao dos requisitos; Acordos de cooperao; Registro de riscos; Decises contratuais relacionadas a riscos; Requisitos de recursos das atividades; Cronograma do projeto; Estimativas de custos das atividades; Linha de base de desempenho de custos; Fatores ambientais da empresa; Ativos dos processos organizacionais. Aps estas atividades descritas abaixo, tem-se a atualizao do registro de riscos: - monitorar e controlar os riscos. - planejar as respostas aos riscos. - realizar a anlise quantitativa dos riscos. - realizar a anlise qualitativa dos riscos. Aps identificar os riscos, tem-se a criao do registro de riscos. Segundo o PMBOK, so ferramentas adicionais planejamento de qualidade: - Brainstorming. - Diagramas de afinidade, usados para identificar visualmente os agrupamentos lgicos com base em relacionamentos naturais. - Anlise do campo de fora, que so diagramas das foras a favor e contra a mudana. - Tcnicas de grupos nominais, para permitir que as idias passem pelo brainstorming em pequenos grupos e depois sejam analisadas por um grupo maior. - Diagramas matriciais, que incluem dois, trs ou quatro grupos de informaes e mostram as relaes entre fatores, causas e objetivos. Os dados de uma matriz so organizados em linhas e colunas com clulas de

interseo que podem ser preenchidas com informaes que descrevam os relacionamentos demonstrados entre os itens localizados na linha e na coluna. - Matrizes de priorizao, que fornecem uma forma de classificar um conjunto variado de problemas e/ou questes (normalmente gerados durante o brainstorming) pela sua importncia. ### Engenharia de software Gerenciamento de programas - Um programa definido como um grupo de projetos relacionados gerenciados de modo coordenado para a obteno de benefcios e controle que no estariam disponveis se eles fossem gerenciados individualmente. A organizao PRS necessita gerenciar seus projetos, sob a luz do PMBOK, de forma a atender as seguintes necessidades: #a: Agrupar projetos para serem gerenciados de forma coordenada para a obteno de benefcios que no seriam disponveis se os projetos fossem gerenciados separadamente. #b: Determinar a sequncia de atividades do cronograma de um projeto, descrevendo seu caminho mais longo, atravs do projeto, obtendo assim a durao do projeto. #c: Identificar e desenvolver metodologia, melhores prticas e padres de gerenciamento de projetos, dentro da organizao, alm de realizar o gerenciamento de recursos compartilhados entre todos os projetos administrados em conjunto. #d: H projetos a serem gerenciados em ambientes dentro da PRS muito indefinidos, incertos e em rpida transformao. #e: necessrio customizar processos do PMBOK realidade da PRS, sobretudo os utilizados para definir o escopo do projeto, refinar os objetivos e desenvolver o curso de ao necessrio para alcanar os objetivos para os quais o projeto foi criado. #f: Analisar qualitativa e quantitativamente os riscos relacionados aos projetos. #g: Emitir e desenvolver relatrios de desempenho dos projetos. ### Engenharia de software Gerncia de projetos Referencial Lgico Ferramenta conceitual e analtica que rene as partes, o planejamento e a administrao do projeto. O modelo de lgica foi caracterizado inicialmente por um programa de avaliadores como uma ferramenta para a identificao de medidas de desempenho. Desde ento, a ferramenta tem sido adaptada para o programa planejamento. A aplicao do modelo de lgica como uma ferramenta de planejamento permite a comunicao precisa sobre os propsitos de um projeto, os componentes de um projeto, e a sequncia de atividades e realizaes. Alm disso, um projeto originalmente concebido

com a avaliao em mente tem uma maior probabilidade de produzir dados benficos. Os modelos lgicos, que comecem com as entradas e trabalho at os resultados desejados, podem refletir uma natural tendncia para limitar o pensamento s atividades existentes. ### Engenharia de software Tpicos em gerncia de projetos Entradas no processo de identificao de riscos: Fatores ambientais da empresa. Ativos de processos organizacionais. Declarao de escopo do projeto. Plano de gerenciamento de riscos. Plano de gerenciamento do projeto. O treinamento pode ser formal ou informal. Exemplos de mtodos incluem o treinamento na sala de aula, o online, o baseado em computador, o feito no trabalho com orientao de outro membro da equipe de projetos, a mentoria e a orientao. Se os membros da equipe do projeto no tm as habilidades gerenciais ou tcnicas necessrias, essas podem ser desenvolvidas como parte do trabalho do projeto. ### Engenharia de software Tpicos de UML Uma relao de realizao entre uma interface e uma classe denota que a classe tem a responsabilidade de implementar os mtodos declarados na interface. Uma relao de dependncia entre uma interface e uma classe denota que a classe no tem, necessariamente, a responsabilidade de implementar os mtodos declarados na interface. ### Engenharia de software UML Tipos de descrio Pode ser: contnua ( contada a histria de como o sistema funciona), numerada (descrita atravs de uma srie de passos), particionada (dividida em duas colunas, uma para os atores (cliente) e outra para o sistema nada impede de que as aes sejam enumeradas). Casos de uso essenciais ou reais (concretos). Essencial no cita detalhe de tecnologia utilizada. Real ou concreto cita detalhe de tecnologia. Regra dos 100 anos: pergunte-se, ao ler a narrativa, se ela seria vlida tanto h 100 anos, quanto a 100 anos. Se a resposta for sim, provavelmente esta

narrativa essencial. Caso contrrio, provavelmente ela dependente de tecnologia e real ou concreta. Atores primrios: so aqueles que iniciam uma sequncia de interaes de um caso de uso. So os agentes externos, para os quais, o caso de uso traz benefcio direto. Atores secundrios: so aqueles que auxiliam os atores primrios. Eles supervisionam, operam, mantem ou auxiliam o sistema. Estes atores existem apenas para que os atores primrios possam utilizar o sistema. Os atores e os casos de uso so identificados a partir de informao coletadas na fase de levantamento de requisitos. Identificao de casos de uso: casos de uso opostos; que precedem outro caso de uso; que sucedem um caso de uso; temporais (no h atores diretamente envolvidos; algumas tarefas podem ser realizadas automaticamente); casos de uso relacionados a alguma condio interna (tambm no h atores envolvidos diretamente; o sistema notifica o usurio de que h mensagens novas, por exemplo.). De 10 a 20% dos casos de uso mais importantes so identificados na fase de concepo dos modelos iterativos. Na fase de elaborao, a construo continua de tal forma que, ao seu trmino, 80% dos casos de uso j esto terminados. Na fase de construo, os casos de uso formam uma base natural atravs da qual se pode realizar as iteraes do desenvolvimento. Um grupo de casos de uso escolhido para cada iterao. Ele detalhado e desenvolvido. Pode ser o caso de um caso de uso complexo precisar de mais de uma iterao. Este processo continua at que todos os casos de uso tenham sido desenvolvidos e o sistema esteja completamente construdo. A esse processo todo, d-se o nome de desenvolvimento dirigido a caso de uso (use case driven development). Para considerar os casos de uso mais importantes h dois fatores: risco de desenvolvimento e prioridades estabelecidas pelo usurio. Casos de uso que mencionam detalhes de interface so indesejveis durante a anlise. O mais adequado utilizar casos de uso essenciais e, posteriormente, na etapa de projeto, transform-los em casos de uso reais adicionando detalhes. Na fase de anlise, descries devem capturar os requisitos funcionais do sistema e ignorar aspectos do projeto, como a interface grfica com o usurio. Um estado complexo pode ser dividido em diagramas de nvel inferior, denominados estados compostos ou subestados: Algumas simulaes de engenharia podem demorar vrios dias. Como os computadores falham, importante criar mecanismos que permitam o reincio da simulao do ponto em que parou. Para facilitar a criao destes pontos, os diagramas de mquina de estado acrescentaram o conceito de estado de histria que representado pela letra "H". As informaes do sistema so armazenadas de tal forma que permitam o reincio da simulao a partir deste ponto. ### Sistemas de informao

BPM Mapeamento de um processo se faz mediante a utilizao de um fluxograma.

### Sistemas de informao BPMN Pools - Representa um participante em um processo. Um participante pode ser uma entidade de negcio ou pode ser um papel. Lanes - Lane uma subdiviso dentro de um Pool usado para organizar e categorizar as atividades Gateways - usado para controlar a divergncia e/ou a convergncia da sequncia de um fluxo. Assim, determinar decises tradicionais, como unir trajetos ou dividir trajetos Data Object - Objeto de Dados considerado um artefato porque no afeta o fluxo de mesnagem e nem o fluxo de sequncia de um processo. Ele pode ser utilizado para representar documentos tais como: fatura, nota fiscal e etc. Sequence Flow - usado para mostrar a ordem (sequncia) com que as atividades sero executadas em um processo BPMN usa o conceito de swimlanes para ajudar a dividir e a organizar atividades. H dois tipos de swimlanes: Pool (Piscina) e Lane (Raia). Pools so utilizados quando o diagrama envolve duas entidades de negcio ou participantes que esto separados fisicamente no diagrama. Especifica "quem faz o que", colocando os eventos e os processos em reas protegidas, chamadas de pools. Os objetos do tipo lane so utilizados para separar as atividades associadas para uma funo ou papel especfico. Um

pool representa uma organizao e uma lane representa tipicamente um departamento dentro dessa organizao. ### Sistemas de informao BPM Segundo a FNQ, definimos processos por um conjunto de atividades preestabelecidas que, executadas numa seqncia determinada, vo conduzir a um resultado esperado que assegure o atendimento das necessidades e expectativas dos clientes e outras partes interessadas. Ainda segundo a FNQ, os processos esto inter-relacionados e interagem entre si (logo, no so considerados um fim em si mesmos), de tal forma que, produtos e servios deles provenientes, constituem a entrada para um ou mais processos na seqncia de execuo, que busca o atendimento das necessidades e expectativas dos clientes. Mapear os processos, a primeira etapa de uma gesto por processos efetiva, um dos trabalhos mais importantes nesta metodologia de gesto. a construo da principal ferramenta de gerenciamento e melhoria interna. (Aconselha-se que apenas os processos organizacionais crticos sejam otimizados, pois otimizar processos que no agregam valor, gerar custos sem retorno.) Resumindo: toda organizao um sistema. Ou seja, funciona como um conjunto de processos. A identificao e o mapeamento destes processos permitem um planejamento adequado das atividades, a definio de responsabilidades e o uso adequado dos recursos disponveis. (Lembrando que, deve-se levar em conta tanto os aspectos verticais como horizontais da empresa). ###

Engenharia de software Mtodos geis (MA)

Caractersticas comuns dos MA: - envolvimento do cliente: devem ser profundamente envolvidos para fornecer e avaliar os requisitos do sistema e avaliar as iteraes do sistema. - entrega incremental: o software construdo em incrementos e o cliente especifica os requisitos a serem includos. - pessoas, no processo: os membros da equipe devem trabalhar de acordo com as suas prprias maneiras de trabalho, sem processos prescritivos. - aceite as mudanas: criar o sistema de forma a acomodar as mudanas porque elas vo acontecer. - mantenha a simplicidade: concentre-se na simplicidade do software e, sempre que possvel, trabalhe para eliminar a complexidade do sistema. Problemas dos MA: - nem sempre o cliente est disponvel para a equipe. - membros individuais da equipe podem no se envolver muito bem com outros membros.

- priorizao de mudanas pode ser difcil j que cada stakeholder adota diferentes prioridades para cada mudana. - manter a simplicidade requer tempo extra, o que pode no ser possvel sob presso de cronograma. ###

Engenharia de software
Extreme Programming (XP) Requisitos so expressos em cenrios, chamados histrias do usurio, que so implementadas como uma srie de tarefas. Os programadores trabalham em pares e desenvolvem testes para cada tarefa antes da escrita do cdigo. Todos os cdigos devem ser executados com sucesso quando um novo cdigo integrado com sucesso. Prticas do XP: - planejamento incremental: os requisitos so divididos em histrias e estas a serem includas em um release so determinadas pelo tempo disponvel e sua prioridade relativa. - pequenos releases: o conjunto mnimo til de funcionalidade que agrega valor ao negcio desenvolvido primeiro. - projeto simples: realizado um projeto suficiente para atender aos requisitos e nada alm. - desenvolvimento test-first: um framework automatizado de teste unitrio usado para escrever os testes para uma nova parte da funcionalidade antes que ela seja implementada. - refactoring: espera-se que todos os desenvolvedores recriem cdigo continuamente assim que os aprimoramentos do cdigo forem encontrados. Isso torna o cdigo simples e fcil de manter. - programao em pares. - propriedade coletiva: os desenvolvedores trabalham em todas as reas do sistema de forma que no se criem ilhas de conhecimentos, com todos os desenvolvedores de posse do cdigo. - integrao contnua: assim que o trabalho for concludo, ele integrado ao sistema como um todo e todos os testes unitrios do sistema devem ser realizados. - ritmo sustentvel: grande quantidade de hora extra no considerada aceitvel, pois, no mdio prazo, h uma reduo de produtividade. - cliente on-site: um representante do usurio final deve estar disponvel em tempo integral para apoiar a equipe do XP. Os desenvolvedores dividem as histrias em tarefas e estima o esforo e os recursos necessrios para a implementao. O cliente prioriza as histrias para implementao. XP descarta o princpio de que se deve projetar para o sistema aceitar mudanas. A justificativa que isso esforo intil j que muitas vezes, as mudanas no ocorrem e as solicitaes de mudanas so completamente diferentes. XP enfatiza o processo de teste mais do que outros mtodos geis. As caractersticas principais de teste no XP: - desenvolvimento test-first. - desenvolvimento incremental de teste a partir de cenrios.

- envolvimento do usurio no desenvolvimento e validao de testes. - o uso de ferramentas automatizadas de teste. ### Gesto de TI ITIL (IT Infrastructure Libray) Uma biblioteca composta das melhores prticas para Gerenciamento de Servios de TI. No se trata de uma metodologia e sim de um conjunto de melhores prticas adotadas em vrias empresas. Atualmente o framework mais adequado para o Gerenciamento de servios para os departamentos de TI, sendo utilizado por mais de 10.000 empresas no mundo todo. Os processos propostos so genricos, podendo ser utilizados por qualquer empresa, seja pblica ou privada, de grande ou pequeno porte. Estes processos devem ser adotados e adaptados ao negcio. No correto afirmar que um processo compatvel com a ITIL , nem mesmo falar em implantar a ITIL. O objetivo implementar o Gerenciamento de Servios de TI, e para isto pode ser utilizado a ITIL como base das melhores prticas. A biblioteca da ITIL foi desenvolvida pela CCTA (Central Computing and Telecommunications Agency), e tinha como objetivo melhorar os processos dos departamentos de TI do governo britnico. A ITIL oferece um framework comum para todas as atividades do departamento de TI, como a parte da proviso dos servios, baseada na infra-estrutura de TI. As melhores prticas da ITIL tm como objetivos: - Servir de inspirao para melhorar os processos de TI; - Sugerir onde possvel chegar, pois outras empresas j conseguiram resultados positivos; - Sugerir para qu os processos e prticas servem; - Sugerir por que adotar os processos e prticas. A vantagem da adoo das melhores prticas est no fato de no ter que reinventar a roda, adotar prticas j testadas propicia um ganho de tempo e retorno mais rpido sobre o projeto de implementao de uma Gesto de Servios. A ITIL define os objetivos e atividades, as entradas e sadas de cada um dos processos encontrados em uma organizao de TI. Entretanto, a ITIL no d uma descrio especfica de como estas atividades devem ser executadas, porque em cada organizao estas so diferentes, ou seja, no existe receita de bolo pronta para voc implementar a ITIL. A ITIL baseada na necessidade de fornecer os servios de alta qualidade, com uma nfase no servio e no relacionamento com cliente. Sete mdulos constituem o corpo da ITIL:

Suporte a Servios: descreve os processos associados ao suporte do dia-adia e atividades de manuteno associadas com a proviso de Servios de TI. Entrega de Servios: cobre os processos necessrios para o planejamento e entrega de Servios de TI com qualidade e se preocupa ao longo do tempo com o aperfeioamento desta qualidade. ICT - Gerenciamento da Infra-estrutura: cobre todos os aspectos do Gerenciamento da Inafra-estrutura como a identificao dos requisitos do negcio, testes, instalao, entrega, e otimizao das operaes normais dos componentes que fazem parte dos Servios de TI. Planejamento para Implementao do Gerenciamento de Servios: examina questes e tarefas envolvidas no planejamento, implementao e aperfeioamento dos processos do Gerenciamento de Servios dentro de uma organizao. Tambm foca em questes relacionadas Cultura e Mudana Organizacional. Gerenciamento de Aplicaes: descreve como gerenciar as aplicaes a partir das necessidades iniciais dos negcios, passando por todos os estgios do ciclo de vida de uma aplicao, incluindo at a sua sada do ambiente de produo (quando o sistema aposentado). Este processo d nfase em assegurar que os projetos de TI e as estratgias estejam corretamente alinhados com o ciclo de vida da aplicao, assegurando que o negcio consiga obter o retorno do valor investido. Perspectiva de Negcio: fornece um conselho e guia para ajudar o pessoal de TI a entender como eles podem contribuir para os objetivos do negcio e como suas funes e servios podem estar mais bem alinhados e aproveitados para maximizar sua contribuio para a organizao. Gerenciamento da Segurana: detalha o processo de planejamento e gerenciamento a um nvel mais detalhado da segurana da informao e Servios de TI, incluindo todos os aspectos associados com a reao da segurana dos incidentes. Tambm inclui uma avaliao e gerenciamento dos riscos e vulnerabilidade, e implementao de custos justificveis para a implementao de contra-recursos (estratgia de segurana). Entre os principais objetivos da adoo da melhores prticas da ITIL podemos destacar os seguintes: - Alinhar os Servios de TI com as necessidades atuais e futuras do negcio e seus clientes. Todos os processos da ITIL falam que a TI precisa entender os requisitos de negcio da empresa para poder planejar e prover seus servios para atender as expectativas. - Melhorar a qualidade dos servios de TI. Atravs de um programa de melhoria contnua deve-se buscar a consistncia na entrega dos servios, atendendo as necessidades de negcio. - Reduzir custos na proviso de servios. Este um dos motivos chaves que levam os gestores de TI a adotarem as melhores prticas, j existem vrios casos de sucesso onde houve grande reduo dos custos operacionais e investimentos em TI. - Processos mais eficientes e eficazes, buscando rapidez e resultados nos processos.

- Adoo das melhores prticas, evitando reinventar a roda. Problemas enfrentados pela adoo do ITIL: - Ausncia de patrocnio, comprometimento e entendimento. importante que todas as pessoas relacionadas com o projeto estejam conscientes das melhorias que a mudana poder trazer. O comprometimento de todos fundamental para fazer com que os processos sejam implementados. - Cultura da empresa. Se a empresa no tiver cultura para a gesto de servios se torna muito complicado a TI obter a colaborao dos demais departamentos. - Excesso de expectativa. Tenha em mente que a adoo das melhores prticas no se faz em dias, necessrio planejamento, insistncia, acompanhamento e adaptaes ao longo do projeto. - Problemas na Gesto do Projeto. A implementao de um Programa de Gerenciamentos de TI deve ser encarado como um projeto, com responsveis por cada etapa, prazos para implementao e recursos necessrios. - Falhas de Comunicao. - Objetivos no alcanados: melhoria de qualidade, reduo de custo, satisfao do usurio, alinhamento de TI com a estratgia de negcio. Vantagens ao adotar o ITIL: - Melhor qualidade no servio, com um suporte mais confivel. - Segurana e confiana da continuidade dos servios de TI, aumentando a habilidade para restaurar os servios quando houver necessidade. - Viso mais clara da capacidade atual. - Fornecimento de informaes gerenciais para acompanhamento de desempenho, possibilitando traar melhorias. - Equipe de TI mais motivada: conhecendo a carga de trabalho possvel gerenciar melhor as expectativas. - Maior satisfao para os clientes e usurios, entregando o servio com mais qualidade e rapidez. - Reduo de custos: a partir do melhor planejamento e controle dos processos internos possvel otimizar os custos operacionais. - Maior agilidade e segurana para realizar as mudanas propostas pelo negcio. Com processos definidos e controlados mais fcil implementar vrias mudanas simultaneamente. Servio definido como um conjunto de componentes relacionados fornecidos para suporte a um ou mais processo de negcios. Exemplo: - Um sistema de faturamento fornecido usando uma base Oracle e uma rede. - E-mail utiliza recurso de rede, servidor e link internet. Para no dar confuso sobre o que servio e o que recurso de TI, tenha em mente que servio sempre o que o usurio interage diretamente. ### Gesto de TI CSF (Critical Success Factors)

- Liderana executiva forte: ela define os objetivos para implementar Gerenciamento de Servios de TI; ela d suporte para a transformao organizacional que necessrio para o sucesso; deve resistir a tendncia para permitir operaes que revertem a velhos hbitos. - Uma avaliao de maturidade dos processos existentes de TI que compara o quo voc faz com as melhores prticas deve ser tomada como o passo inicial no caminho para o gerenciamento de servios de TI. Se no se sabe onde est, quais lacunas existem no ambiente atual e no se sabe onde quer estar, muito improvvel que se tenha uma implementao de gerenciamento de servios de TI. crtico para a organizao saber o que j tem e construir a partir desta base. - Objetivos claros e mensurveis: eles tem que estar alinhados com os objetivos do projeto de implementao de ITSM, que so baseados em critrios no ambguos e que podem ser usados para determinar se os objetivos foram alcanados. - Papis e responsabilidades claramente definidos: tanto para o staff que implementar o ITSM como tambm para aqueles que executam-no em modo operacional. Os papis dos negcios, os vrios staffs de TI, fornecedores e organizaes externas de suporte precisam ser bem definidos. - Uma implementao bem definida e um plano de melhoria de servio contnuo so crticos: todo pessoal afetado deve ser treinado e pronto para as suas novas atribuies. Isso deve ocorrer antes que a implementao seja feita. - Sistematizar cada processo: utilizar medidas de performance de cada processo para ajudar identificar oportunidades de melhoria. O trabalho real comea quando o projeto de implementao termina. KPI (Key Performance Indicators) Representam um valor particular ou caracterstico que medido para avaliar se os objetivos de uma organizao esto sendo atingidos. Eles refletem os fatores de sucesso crticos, necessidades dos stakeholders e as expectativas da organizao. Para os KPIs e suas medidas serem efetivas, os objetivos da organizao precisam ser especficos, mensurveis, combinados, realistas e baseados no tempo. KPIs podem ser usados como mtricas financeiras ou no financeiras. Alguns conceitos importantes precisam ser destacados: - Objetivos da organizao: imperativo que KPIs no sejam atribudas aos objetivos de uma indstria padro e sim aos objetivos da prpria indstria. Eles devem refletir suas circunstncias. - KPIs precisam ser especficos, mensurveis, realistas e baseado no tempo: deve-se olhar para os KPIs atravs do tempo medida que se faz melhorias para os processos de ITSM baseado nos KPIs. - Combinado: imperativo que todo mundo deve estar na mesma pgina e os KPIs devem ser construdos por pessoas com diferentes pontos de vista no servio ou processo que est sendo medido. KPIs so usados em conjunto com CSFs e devem ser um alvo a ser atingido. O alvo para um KPI pode ser expresso como uma porcentagem, uma razo simples, um ndice, uma mdia composta, etc. Um KPI uma parte chave do objetivo mensurvel, que feito de direo, KPI, benchmark ou alvo e um quadro de tempo. Por exemplo: 5% de

reduo de CIs de erro em cada ms onde reduo de CIs de erro em cada ms o KPI. ### Gesto de TI Modelo RACI Um modelo usado para ajudar definir quem responsvel/encarregado. A matriz RACI um modelo usado para ajudar a definir papis e responsabilidades. RACI um acrnico para as quatro funes principais. Responsible Pessoa responsvel por fazer com que o trabalho seja feito. So os que colocam a mo na massa! Accountable quem presta conta pela atividade. Consulted Pessoas que so consultadas antes da execuo da tarefa, pois suas opinies so importantes para a execuo da atividade. Informed Pessoas que se mantm atualizadas constantemente. Normalmente so informadas depois da execuo da atividade. O modelo usado durante a anlise e esforos de documentao em todos os tipos de Gerenciamento de Servio, Gerenciamento de Qualidade, Gerenciamento de Processos e Projetos. O modelo RACI resultante um veculo de comunicao simples e poderoso. Definir e documentar responsabilidade so dois dos princpios fundamentais em todos os tipos de Governana.

Na Matriz RACI, representada na figura acima, podemos verificar que uma srie de informaes est disposta em forma de tabela, o que facilita a identificao dos responsveis por cada tarefa dentro de cada processo do ITIL. Apesar disso, existem potenciais problemas relacionados ao modelo RACI que devem ser tratados. Dentre eles podemos citar: ter mais de uma pessoa que presta conta (Accountable) por um processo (na prtica, processo com dois donos na verdade no tem nenhum), delegao de responsabilidade ou prestao de contas sem autoridade necessria para tanto, foco na correlao de processos e atividades com os departamentos, etc. Passos para se construir uma tabela RACI: - Identificar as atividades;

- Identificar os papis funcionais; - Atribuir os cdigos RACI; - Identificar quaisquer lacunas ou sobreposies por exemplo, onde tem dois As ou nenhum R. - Distribuir o grfico, incorporar feedback; - Alcanar um acordo com os stakeholders envolvidos; - Assegurar que as alocaes esto sendo seguidas. Fonte: http://www.continentalsoftware.com/raci-model/ ### Gesto de TI Service Desk o primeiro e, idealmente, o nico ponto de contato para usurios (SPOC single point of contact for users). No um processo. Os dois principais focos so: comunicao e controle de incidente. Idealmente, o Service Desk ter acesso a uma base de conhecimento que conter uma lista de solues conhecidas para incidentes comuns. Desse modo, dvidas e incidentes podero ser resolvidos pelo pessoal do Service Desk sem tomar tempo dos tcnicos de TI. Para o cliente, a vantagem que eles no tem que ficar procurando pela pessoa certa para resolver seu problema. Para o pessoal de TI, significa que eles s tem que lidar com problemas relacionados s suas habilidades ou reas de responsabilidade. O Service Desk responsvel por manter o cliente informado do status do seu pedido. Um catlogo de servio deve estar disponvel que lista todos os servios que o TI prov ao negcio. Este catlogo deve listar servios de uma perspectiva dos usurios. CSFs: - garantir, a longo termo, reteno e satisfao do cliente; - ajudar na identificao de oportunidades de negcio; - reduzir custos de suporte pelo uso eficiente de recursos e tecnologia. KPIs: - percentual de clientes dados os exames de satisfao; - taxa de satisfao do cliente do Service Desk; - percentual de vezes que uma pessoa fica na linha dentro dos alvos do servio; - percentual de chamadas respondidas para dentro dos alvos do servio; - nmero de registros de incidentes ainda no fechados; - nmero de chamadas abandonadas. No existe dvida que a implantao da Central de Servios ter barreiras de sucesso. Algumas barreiras tpicas que podero ocorrer:

- Usurios no ligarem para Central de Servios, mas tentarem buscar uma soluo diretamente com uma pessoa que conhece, ou que a ajudou da ltima vez. - A equipe tcnica no estar preparada para atender as necessidades do negcio ou usurios. - Nem todas as partes esto informadas sobre os servios fornecidos e os nveis de servios acordados, resultando em frustrao por parte dos usurios. ### Gesto de TI ITIL v3 tem cinco volumes: 1) Estratgia de Servio: Os servios, para serem bem sucedidos, devem atender s expectativas dos clientes entregando um valor diferenciado para os mesmos. O provedor de servios deve entender o mercado que opera para ento entender as necessidades dos clientes. A Estratgia de Servios no pode existir de forma isolada. O Servio de Estratgia traz orientaes a todos os prestadores de servios de TI e seus clientes, para ajud-los a operar e prosperar no longo prazo atravs da construo de uma estratgia clara de servio. Para tanto se necessita de: - quais os servios que devem ser oferecidos; - a quem os servios devem ser oferecidos; - como os clientes e os acionistas percebero e mediro o valor, e como o valor ser criado; - como o desempenho do servio ser medido; - entre outros. Processos chave da Estratgia de Servio: - Gerao de Estratgia - Gerenciamento Financeiro - Gerenciamento de Portflio de Servio - Gerenciamento de Demanda 2) Desenho de Servio: Representa o desenho de servios de TI apropriados e inovadores, incluindo arquitetura, processos, polticas e documentao para satisfazer requisitos, presentes e futuros, de acordos de negcios. Os principais objetivos do Desenho de Servio so: - identificar e gerenciar riscos; - desenvolver habilidades e capacidades dentro da TI; - produzir e manter planos, processos, polticas, padres, arquiteturas, modelos e documentos para suportar o desenho de qualidade das solues de TI; - contribui para melhorar toda a qualidade do servio de TI. O Desenho de Servio comea com um conjunto de necessidades empresariais e termina com o desenvolvimento de uma soluo de servio

concebido para satisfazer as necessidades empresariais para em seguida seguir para a fase da Transio de Servio. O bom desempenho da fase de Desenho de Servio depende do eficiente uso dos quatros P's" do Desenho: - Pessoas: pessoas, habilidades e competncias para o fornecimento de servios de TI; - Produtos: a tecnologia e gerenciamento de sistemas usados na entrega dos servios de TI; - Processos: os processos, papis e atividades envolvendo o fornecimento de servios de TI; - Parceiros: os vendedores, fabricantes e fornecedores usados para assistir e suportar o fornecimento de servios de TI. Processos chave do Desenho de Servio: - Gerenciamento do Catlogo de Servios; - Gerenciamento do Nvel de Servio; - Gerenciamento de Capacidade; - Gerenciamento de Avaliao; - Gerenciamento contnuo do servio de TI; - Gerenciamento da Segurana da Informao; - Gerenciamento de Fornecimento. 3) Transio de Servio: Incide sobre todos os aspectos da execuo do servio. necessrio assegurar que o servio pode funcionar em circunstncias anormais previsveis ou no e apoio s falhas e erros. Processos chaves da Transio de Servios: - Gerenciamento de Mudanas; - Gerenciamento de Configurao e Servio de Ativos; - Gesto do Conhecimento; - Planejamento de Transio e Suporte; - Gerenciamento de Desdobramento e Reparo; - Validao de Servio e Teste; - Avaliao. 4) Operao de servio O propsito da Operao de Servio entregar nveis aceitos do servio para usurios e clientes, e administrar as aplicaes, tecnologia e infraestrutura que suporte a entrega dos servios. Somente durante este estgio que o ciclo de vida dos servios realmente entrega valor ao negcio, e de responsabilidade da Operao de Servio assegurar que este valor entregue. importante que este servio equilibre a qualidade do servio versus o custo do servio, de maneira a evitar conflito de metas. Processos chaves de Operao de Servios - Gesto de Eventos; - Gerenciamento de Incidentes; - Gerenciamento de Problemas; - Gesto de Solicitaes;

- Gesto de Acesso; - Gerenciamento de Monitoramento e Controle; - Operaes de TI. 5) Melhoria Contnua do Servio Representa a contnua avaliao e melhora da qualidade dos servios e toda a maturidade do gerenciamento dos servios de TI. Melhoria Contnua do Servio combina princpios, prticas e mtodos para gerenciamento da qualidade, gerenciamento da mudana e melhoria da capacidade, gerando melhorias em cada estgio do ciclo de vida do servio, bem como os servios correntes, processos e atividades relacionadas e tecnologia. Tipos de mtricas Mtrica de servio: resultado de um servio de ponta a ponta; Mtrica de Processo: FCs, KPIs, e mtricas de atividades para os processos de gerenciamento de Servio; Mtricas de tecnologias: Mtricas baseadas em componentes e aplicao, tais como: utilizao, desenho, disponibilidade. Processos chave da Melhoria Contnua do Servio: - Sete passos do processo de melhoria - Medio do Servio - Relatrio de Servio Esses livros seguem uma ordem prtica: 1 Como desenvolver uma estratgia orientada para negcios dos servios de TI? 2 Como desenhar um sistema de apoio estratgia escolhida? 3 Como fazer a transio do sistema recm desenhado para o ambiente de produo? 4 Como fazer com que as operaes em curso faam parte da cultura da empresa? 5 Como fazer a continua melhoria dos processos e operaes? ### Gesto de TI Gerncias em ITIL (estratgica) Gerncia de Demanda O processo de gerenciamento de demanda analisa, rastreia, monitora e documenta os padres de atividade do negcio (PAN Patterns of Business Activity PBA) para prever as demandas atuais e futuras por servios. Os padres de atividade vo dizer como o cliente usa os servios e quais so os perodos de pico. Por exemplo: o sistema de faturamento mais usado no final do ms para fechamento financeiro da organizao. Papel: Gerente de Demanda - Criar e gerenciar polticas de incentivos e penalidades - Participar na criao dos acordos de nvel de servio (ANSs ou SLAs)

- Monitorar toda a demanda e capacidade - Gerenciar recursos do processo - Responde as mudanas do PAN (Padro de Atividade do Negcio) Aconselham-se atividades baseadas no Gerenciamento da Demanda e no relacionamento de padres de demanda para assegurar que os planos de negcio do cliente estejam sincronizados com os planos de negcio do provedor de servio. Gerncia de Portflio de Servios O Portflio o conjunto de todos os servios que eram ofertados, que esto em operao e que pretendem entrar em produo. O prprio Catlogo faz parte do Portflio, que dividido em trs partes: Pipeline (tambm conhecido como funil) que onde entram todas as demandas e passam por um processo que decide se sero servios ou no; o Catlogo de Servios, onde esto os servios em produo ou liberados para entrar em operao e o Servios Obsoletos que mantm as informaes dos servios que existiram e j no so mais ofertados. Olhando dessa forma, o Portflio gera conhecimento sobre todos os servios: a histria da TI. Tambm permite aprender com os erros do passado, pois um servio obsoleto uma lio aprendida, uma experincia que serve para averiguar e no repetir eventuais enganos, e ajuda a prospectar o alcance de um servio e seus riscos antes mesmo que ele seja colocado em produo. Para gerenciar o Portflio existe um processo no livro de Estratgia que prev quatro etapas: Definir, Analisar, Aprovar e Contratar. Em cada mudana de etapa o servio ou demanda muda de status. Quando esse processo est sendo estabelecido definem-se os responsveis por cada atividade, gerando assim a transparncia porque mostra em que fase est o servio e quem o responsvel por ele naquele momento. Depois de aprovado, o servio desenvolvido e liberado para produo. A sim ele vai para o Catlogo de Servios. O Gerente do Catlogo vai receber todas as informaes sobre aquele servio, o que vai permitir a acuracidade e qualidade do Catlogo. E o que fica registrado com esse processo? Relao custo x benefcio, oferta x demanda, riscos e recursos, viabilidade tcnica, alm da deciso de aprovao. ### Gesto de TI ITIL Gerncia de Nvel de servio O gerenciamento do nvel de servio visa melhoria da qualidade dos servios de TI atravs de um ciclo contnuo de negociao e monitorao, promovendo aes para eliminar nveis de servio inaceitveis. ANS (Acordo de nvel de servio SLA, Service level agreement) funciona como um contrato entre o cliente e a TI. O ANS deve descrever, em detalhes, os servios fornecidos, alm de especific-los quanto qualidade, quantidade, desempenho e disponibilidade. Objetivos: - Melhorar a especificao dos servios; - Reduzir demandas imprevistas; - Avaliar o custo dos servios;

- Controlar o nvel de servio; - Promover a melhoria da qualidade do servio; - Manter alinhamento com o negcio. Para atingir os objetivos, necessrio: - Catlogo de servios: define os servios fornecidos; - ANS: ele deve conter informaes como descrio do servio, agenda, suporte, procedimentos para mudanas, metas para disponibilidade, confiabilidade, segurana, capacidade, etc; - Requisies de nvel de servio (SLR): documento usado para fornecer uma viso detalhada do cliente, usados para ajustar ou criar novos servios; ### Gesto de TI Gerncia de capacidade O processo de Gerenciamento da Capacidade foi desenhado para assegurar que a capacidade da infra-estrutura de TI esteja alinhada com as necessidades do negcio. O propsito principal do Gerenciamento da Capacidade entender e manter os nveis de entrega de servios requisitados a um custo aceitvel. Atravs da investigao sobre as necessidades de capacidade tcnicas e do negcio, este processo ir planejar a capacidade necessria para que a infra-estrutura de TI cumpra os requisitos do negcio. O objetivo principal do Gerenciamento da Capacidade entender os requisitos de capacidade do negcio e controlar a entrega desta capacidade no presente e no futuro. O Gerenciamento da Capacidade tambm responsvel por entender as vantagens potenciais que as novas tecnologias podem trazer para a organizao. O processo de Gerenciamento da Capacidade dividido em trs subprocessos listados abaixo: Gerenciamento da Capacidade de Negcio Este sub-processo tem foco no longo prazo. Ele responsvel por assegurar que os requisitos futuros do negcio sejam levados em considerao, estejam sendo planejados e implantados quando necessrio. Gerenciamento da Capacidade de Servio responsvel por assegurar que a performance de todos os Servios de TI atuais estejam dentro dos parmetros definidos nos ANSs. Gerenciamento da Capacidade de Recursos responsvel pelo gerenciamento de componentes individuais dentro da infra-estrutura.

Este processo tem foco mais tcnico. ### Gesto de TI ITIL Gerncia de disponibilidade O processo de gerenciamento de disponibilidade visa garantir que os servios de TI estaro disponveis sempre que os clientes necessitarem deles, de acordo com os nveis de disponibilidade acordados. Os principais elementos de disponibilidade de um servio so: - Disponibilidade: Tempo durante o qual o servio estar disponvel; - Conabilidade: Capacidade de se manter operacional dentro de um determinado perodo de tempo; - Sustentabilidade: Capacidade de retorno ao estado normal aps algum incidente; - Resilincia: Capacidade de se manter operacional mesmo na falta de um ou mais componentes; - Oficiosidade: Obrigaes contratuais com terceiros (Contratos de Apoio); - Segurana: Confidencialidade, Integridade e Segurana. Se um incidente ocorre em t1. reparado em t2. E volta a ocorrer em t3, ento: TMPR (tempo mdio para reparo): t2 t1. TMEF (tempo mdio entre falhas): t3 t2. TMEIS (tempo mdio entre incidentes de sistemas): t3 t1. Gerncia de continuidade Principal objeto dar continuidade operacional aos servios de TI em ocasies de desastre, a fim de dar suporte aos requisitos mnimos de negcio. O principal produto desse processo um documento chamado Plano de continuidade dos Negcios (Business Continuity Plan BCP). Os principais componentes de um plano de continuidade so: - administrao: quando e como invocar o plano; - infraestrutura de TI: quais os itens envolvidos; - procedimentos operacionais: instrues de trabalho; - pessoal: responsveis, contatos e substitutos; - site de convergncia: localizao, contato e transporte; - retorno ao normal: como, onde e quanto tempo para o retorno. Mtricas de retorno: RTO (recovery time objective): ltimo instante no tempo, a partir do qual, a operao deve ser restabelecida aps um desastre. RPO (recovery point objective): determina o ponto, a partir do qual, os dados devem ser recuperados aps um desastre. Nessa gerncia de continuidade, anlises detalhadas de riscos e impactos so realizadas, utilizando metodologias de anlise e risco como CRAMM, OCTAVE, CORAS, etc.

Todas elas so baseadas nas normas da ISO 27001. Uma elaborao de anlise de risco e impacto, geralmente, se baseia na identificao de trs elementos: ativos, ameaas e vulnerabilidade. Os estgios so: - Incio: obteno do aval gerencial e levantamento dos servios de TI crticos para o negcio; - Requisitos estratgicos: anlise de risco e de impacto e elaborao da estratgia de continuidade; - Implementao: planejamento e implementao das instalaes para recuperao, elaborao do plano de continuidade, medidas para reduo de riscos e realizao de testes iniciais. - Gerenciamento operacional: educao, reviso, auditoria, testes, treinamento e gerenciamento de mudanas. Tipos de continuidade: - solues de contorno manuais: medidas temporrias at que os servios sejam restabelecidos; - acordos de reciprocidade: organizaes concordam auxiliar uma a outra em caso de desastres; - recuperao gradual (cold standby): ambiente computacional vazio, exceto por energia e telecomunicaes. Mnimo de 72 horas para restabelecimento dos servios. - recuperao intermediria (warm standby): ambiente com equipamentos para recuperao dos servios mais crticos entre 24 e 72 horas; - recuperao imediata (hot standby): instalao alternativa com espelhamento contnuo de equipamentos e dados. ### Gesto de TI ITIL Gerncia de segurana da informao O objetivo alinhar a segurana de TI do negcio e garantir que a segurana da infraestrutura seja gerenciada eficazmente em todos os servios e atividades. Trata da segurana alinhada governana corporativa. Alm de garantir o CID (confidencialidade, integridade e disponibilidade) tambm cuida da Autenticidade e no repdio. Este processo de gerenciamento de SI baseado na norma ISO/IEC 27001, que aponta um ciclo para a gesto de segurana da informao: EIOMAMM (ciclo PDCA) = Estabelecer / Implementar e Operar / Monitorar e Analisar (Criticamente) / Manter e Melhorar. O ciclo descrito no ITIL usa a seguinte terminologia CPIAM: - controlar: a primeira atividade do gerenciamento de segurana e trata da organizao e do gerenciamento do processo. - planejar: define os aspectos de segurana do SLA em conjunto com o Gerenciamento de nvel de servio, detalhando em ANOs posteriormente. Tambm define as atividades em contratos com terceiros relacionados segurana. Importante lembrar que os ANOs (acordos de nvel operacional)

so planejamentos para uma unidade do provedor de servio, como por exemplo, para cada plataforma de TI, aplicao e rede. - implantar: implanta todas as medidas especificadas nos planejamentos. Classifica e gerencia os recursos de TI, trata da segurana pessoal (jobdescription, seleo, treinamentos) e gerencia a segurana como um todo (implantao de responsabilidades e tarefas, desenvolve regulamentos e instrues, cobre todo o ciclo de vida, tratamento de ambientes, mdias, proteo contra vrus e ameaas). - avaliar: avalia o desempenho das medidas planejadas e atende aos requisitos de clientes e terceiros. Os resultados podem ser usados para atualizar medidas acordadas em consulta com os clientes e para sugerir mudanas. Pode ser feita de trs formas: autoavaliao, auditorias internas e auditorias externas. - manuteno: mantm a parte do SLA que trata de segurana e mantm os planos detalhados de segurana. feita baseada nos resultados da avaliao e na anlise de mudanas nos riscos. ### Gesto de TI ITIL Gerenciamento de mudana Assegurar que mudanas so feitas de forma controlada, e so avaliadas, priorizadas, planejadas, testadas, implantadas e documentadas. Os riscos devem ser mapeados e gerenciados. A rea de TI precisa ser responsiva s mudanas no negcio. O escopo deste processo cobre as mudanas desde a base de ativos de servio e itens de configurao at o completo ciclo de vida do servio. Isso implica dizer que este processo pode ser usado para implantar melhorias nos processos de Gerenciamento de servios de TI. Requisies de mudana (RDM ou RFC) so requisies formais para mudar um ou mais itens de configurao. Comit consultivo de mudanas (CCM ou change advisory board CAB) rene pessoas que autorizam a mudana e auxiliam na sua avaliao e priorizao. O processo de mudana comea com uma RDM. Uma RDM pode conter proposta de mudana que crie novas facilidades ao negcio, ou conter justificativa do gerente de problema para implantar mudana que corrija um problema. A RDM verificada em termos de conformidade, se necessria, se est completa e j no havia outro registro aberto. Aqui se aplicam os 7Rs. Depois da anlise e avaliao, o comit decide pela implementao, priorizando com base no impacto e na urgncia. Em seguida coordenada a implantao que, aps feita, deve ser avaliada para saber se cumpriu o seu propsito. Resultados esperados: - reduo de erros em servios novos ou alterados; - maior velocidade e preciso na realizao de mudanas; - priorizao de mudanas com maior benefcio para o negcio. Os 7 Rs so:

- Raise: quem submeteu a mudana? - Reason: qual a razo da mudana? - Return: qual o retorno requerido a partir da mudana? - Risks: quais os riscos com a mudana? - Resources: quais so os recursos necessrios para a mudana? - Responsible: quem o responsvel por construir, testar e implantar a mudana? - Relationship: qual a relao desta mudana com as outras mudanas? ### Gesto de TI ITIL Gerncia de configurao Identifica todos os itens de configurao necessrios para entregar os servios de TI, fornecendo um modelo lgico da estrutura de TI. Item de configurao um ativo, um componente de servio ou qualquer outro item sob controle do processo de gerenciamento de configurao. Quanto mais dependente dos sistemas de TI as organizaes so, mais importante se torna o Gerenciamento de configurao. As informaes sobre os itens de configurao so mantidas na base de dados do gerenciamento de configurao. BDGC ou CMDB (banco de dados de gerenciamento de configurao) um repositrio de informaes relacionado aos registros de itens de configurao. Este processo identifica, controla e presta contas por ativos de servio e itens de configurao protegendo e garantindo sua integridade ao longo do ciclo de vida. Incluem ativos que no sejam de TI e ativos provedores de servios, quando necessrio. Objetivos em resumo: - gerenciar a TI com maior controle sobre os itens de configurao da organizao; - fornecer informao precisa para outros processos da ITIL; - Criar e manter uma base de dados do gerenciamento da configurao (BDGC). Diferena entre gerenciamento de ativos e gerenciamento da configurao que o primeiro fornece uma lista de itens (normalmente software e hardware), enquanto o segundo define o relacionamento entre os itens de configurao. A principal entrada no processo vem do Gerenciamento de Mudanas, requisitando informaes sobre itens que sero afetados ou reportando o status dos itens mudados. O processo inicia com o projeto, populao e implantao do BDGC (Banco de Dados do Gerenciamento da Configurao).

 responsabilidade do Gerenciamento da Configurao manter o BDGC. A populao do BDGC pode ser cara e um exerccio prolongado dependendo do escopo da infra-estrutura de TI que est sendo gerenciado e do nvel de detalhes sobre cada item requisitado. Ferramentas de auditoria automtica podem ajudar em grande parte nesse aspecto. As Sadas do Processo so relatrios para o gerenciamento de TI e tambm a constante disponibilidade de informao que podem ser fornecidas a partir do BDGC a outros processos. Termos relacionados: - Biblioteca segura (secure library): coleo de itens de configurao de software, eletrnicos ou documentos. - Armazm seguro (secure store): o local onde se armazenam os ativos de TI. - Biblioteca de mdia definitiva (BMD ou DSL em ingls): biblioteca onde se armazenam as verses de software autorizadas. - Peas definitivas (definitive spares): armazena peas sobressalentes (reserva) de hardware. - Linha de base de configurao: a configurao aprovada de um servio, produto ou infraestrutura. - Snapshot (instantneo): cpia do estado atual de um item de configurao ou ambiente. Ferramentas de inventrio mantem a rastreabilidade desses estados. O produto desse processo o Sistema de Gerenciamento da Configurao. Este serve para gerenciar servios de TI. Consiste de quatro camadas: - Camada de apresentao: formatao das informaes em relatrios especficos para determinados pblicos. - Camada de processamento de conhecimento: onde se produzem as queries para extrair os dados a serem exibidos em relatrios. - Camada de integrao de informao: coleta e estrutura os dados. - Camada de dados: dados e informaes de diferentes origens, como BDGCs, ferramentas de inventrio, informaes de projeto, etc. ### Gesto de TI ITIL Gerenciamento de liberao To logo o gerenciamento de mudana aprovar a mudana (atravs do comit consultivo), ela passada para este processo, para que seja liberada e implantada no ambiente de produo. Este processo faz o controle de verses e controla as instalaes de software, hardware e outros componentes de infraestrutura, do ambiente de desenvolvimento ao ambiente de teste e depois para o ambiente de produo. No desenvolve a mudana, apenas sua liberao (ex: deployment de um software). Liberaes so planejadas e este processo deve atender at o suporte inicial da entrada em produo. Opes mais frequentes para o lanamento de liberaes:

- Big bang ou por fase: big bang implanta o servio para todos ao mesmo tempo, enquanto por fase a liberao feita para partes de usurios. - Empurrada ou Puxada (Push/Pull): na liberao empurrada o componente do servio implantado a partir da rea central para usurios em localizaes remota. Puxada os usurios Devem trazer para si as atualizaes, atravs de downloads ou requisies. - Automatizada ou manual: as automatizadas fazem uso de scripts que rodam atualizao em cada mquina na rede, atravs de um comando central, por exemplo. Alguns softwares fazem isso. J a liberao manual requer interveno ponto a ponto. - Atividades de liberao: Planejamento / Preparao para Construo, Teste e Implantao / Construo e Teste / Teste de Servio e Pilotos / Planejamento e Preparao para Implantao / Transferncia, Implantao e Retirada / Verificao / Suporte. Produtos/Sadas deste processo: - Aumento de valor para o negcio pela otimizao de velocidade, custo e risco das mudanas; - Consistncia e auditabilidade na implantao de servios teis ao negcio; - Correo de desvios no SDP. SDP (service design package): caractersticas dos servios. documento de especificaes e

Unidade de liberao: a poro de um servio ou infraestrutura de TI que normalmente liberada de acordo com a poltica de liberao da organizao. Esta unidade varia em termos de item, ativo de servio e componente de servio (hardware e software). ### Gesto de TI ITIL Validao de servio e teste Tem foco na qualidade. Deve checar que o servio atende ao requisito do SDP, dentro dos nveis de risco aceitos pelo negcio. Objetivo: certificar de que o servio (novo ou alterado) suporta os requisitos de negcio, incluindo os acordos de nvel de servio (SLA) estabelecidos. Gerncia do Conhecimento Tem como objetivo garantir que as pessoas certas tenham o conhecimento adequado e oportuno para entregar e dar suporte aos servios requeridos. Trata o conhecimento como forma de prover servios eficientes e com qualidade, de valor compreensvel a todos. Principal sada: SKMS ou SGCS (sistema de gesto do conhecimento de servios). ### Gesto de TI

ITIL Gerncia de evento Evento refere-se a qualquer ocorrncia identificvel que seja significativa para a gesto da infraestrutura de TI ou para a entrega do servio de TI. So tipicamente notificaes criadas por um servio de TI, item de configurao ou ferramenta de monitorao, indicando uma alterao de estado. Um evento pode indicar que algo no est funcionando como deveria, levando ao registro de um incidente. Mas tambm pode indicar atividade normal de servio, ou a necessidade de uma interveno de rotina, como a troca de uma fita de backup, ou o fim da execuo de um job. O processo de gerenciamento de eventos proporciona entradas para muitos processos e atividades da Operao de Servio. Tambm permite comparar o comportamento real com o planejado nos padres de desenho e Acordos de Nvel de Servio. Este processo tambm inclui quaisquer aspectos do gerenciamento de servio que precisem ser controlados, tais como itens de configurao, condies do ambiente, licenciamento de software, etc. Os eventos so classificados como Informativos (ex: o usurio fez logon), alertas (ex: tempo de transao est acima do normal) ou Excees (ex: o servidor de rede respondeu de maneira inesperada). ### Gesto de TI ITIL Gerncia de incidentes Objetivo restaurar o servio o mais rpido possvel, alm de minimizar o impacto no negcio. Incidentes so: - frequentemente detectados pelo gerenciamento de eventos, ou por usurios entrando em contato no central de servios; - categorizados para identificar quem dever trabalhar neles e para anlises de tendncia; - priorizados de acordo com a urgncia e os impactos para o negcio. - quaisquer eventos que no fazem parte da operao padro de um servio e que causam, ou podem causar, uma interrupo ou uma reduo na qualidade deste servio. Se um incidente no puder ser resolvido rapidamente, ele pode ser escalado. H dois tipos: - escalao funcional: passa o incidente para uma equipe tcnica de suporte com habilidades apropriadas; - escalao hierrquica: envolve os nveis apropriados de gerncia. essencial uma ferramenta de gerenciamento de incidentes. Elementos que devem ser tratados no gerenciamento de incidentes:

- limites de tempo: os limites de tempo para todas as etapas na resoluo de incidentes devem ser definidos e acordados, usando as metas do ANS e contratos com fornecedores. - modelos de incidente: determinam os passos que so necessrios para executar a recuperao dos incidentes corretamente. Processa, com mais eficincia, incidentes que so mais comuns. - incidentes graves: ITIL recomenda que incidentes graves precisem de um processo de resoluo exclusivo. Atividades do gerenciamento de incidentes: 1. Identificao: o processo iniciado somente quando o incidente identificado. 2. Registro: todos os incidentes precisam ser registrados em um sistema. O registro deve conter data, hora e informaes relevantes. 3. Classificao: devem-se registrar todos os tipos de chamada e classificlas. Esta classificao ser til para o Gerenciamento de Problemas identificar quais so os tipos de incidentes mais recorrentes. 4. Priorizao: priorizao determinado pelo impacto e pela urgncia. 5. Diagnstico: o diagnstico inicial realizado pela Central de Servios, que averigua preliminarmente possveis causas para o incidente, bem como o que no est funcionando adequadamente. 6. Escalao: se o incidente no puder ser resolvido pela central de servios, ele ser escalado dentro do tempo hbil para outro nvel de suporte com maior capacidade. 7. Investigao e diagnstico: determina a natureza da requisio. Quando o incidente tratado, cada grupo de suporte investiga o que aconteceu de errado e faz um diagnstico. 8. Resoluo e recuperao: identifica uma soluo, a mesma deve ser aplicada e testada. 9. Fechamento: a central de servios dever categorizar o motivo do incidente, documentar, pedir para que o usurio responda a pesquisa de satisfao e fazer o fechamento formal junto ao mesmo. Os eventos do ciclo de vida de um incidente so: Deteco, Diagnstico, Reparo, Recuperao e Restaurao. Gerncia (Cumprimento) de requisio Uma requisio de servio a requisio de um usurio por informaes, ou por uma mudana padro, ou por acesso a um servio de TI. O propsito deste processo : - Permitir ao usurio requerer e receber servios padronizados; - Fornecer e entregar esses servios; - Prover informaes aos usurios e clientes sobre servios e procedimentos para obteno do que desejam; - Oferecer suporte com informaes gerais, reclamaes e sugestes. Todas as requisies devem ser registradas e rastreadas. O processo deve incluir aprovao apropriada antes de cumprir a requisio. Atividades: - Seleo de Menu: os usurios podem fazer solicitaes usando ferramentas de Gerenciamento de servio que possuem interfaces web. Nelas, o usurio solicita o que precisa.

- Autorizao financeira: muitas requisies podem ter implicaes financeiras. O custo de cada uma deve ser determinado e podem-se limitar as solicitaes de usurios para controlar o custo. - Cumprimento: a entrega do servio. Geralmente a central de servio envolvida em solues mais simples, enquanto mais complexas so encaminhadas para especialistas ou fornecedores externos. - Concluso: uma vez completa, a Central de Servio fecha o registro da requisio. No h nenhum papel especfico aqui neste processo, pois o cumprimento de requisies fica a cargo da Central de Servios. ### Gesto de TI Gerncia de problemas Os objetivos deste processo so a preveno de problemas e incidentes resultantes deles, eliminando incidentes recorrentes e minimizando o impacto de incidentes que no podem ser prevenidos. Os problemas so a causa de um ou mais incidentes. Mesmo assim, um incidente nunca vira problema: sempre h o registro dos dois separados, um para cada processo. Este processo tem a inteno de encontrar erros conhecidos na infraestrutura de TI. O foco : - Encontrar qual o erro conhecido (diagnstico); - Identificar solues alternativas para a remoo do erro conhecido (controle de erro); - Emitir uma requisio de mudana para requisitar que a supresso ocorra; - Depois que a mudana feita, checar se o erro conhecido foi removido. A meta do processo gerenciar o ciclo de vida de todos os problemas. O gerenciamento de problema tambm pode ter um elemento proativo de resoluo de problemas. A idia identificar e facilitar remoo de erros antes que eles se manifestem como reclamaes ou perguntas de usurios finais. O processo, ainda, mantm informaes sobre problemas e resolues, e solues de contorno apropriadas para que a organizao seja capaz de, com o tempo, reduzir o nmero de impacto de incidentes, tendo forte interface com o Gerenciamento do Conhecimento. As atividades do gerenciamento de problema so geralmente exercidas por times de suporte avanados. A central de servios j cuida das atividades de Incidente, portanto no tem habilidade e tempo para investigar as causas-raiz. o processo de Gerenciamento de Problemas que fica responsvel por manter a BDEC (base de dados de erros conhecidos). Erro conhecido (Known Error): um problema que tem causa raiz documentada e uma soluo de contorno identificada. Base de Erros Conhecidos: Local onde se registram erros conhecidos. Esses registros so utilizados pelo processo de gerenciamento de incidente para resolver incidentes. Faz parte de gerenciamento do conhecimento de servio. Gerncia de acesso

O gerenciamento de acesso deve prover os privilgios necessrios para usurios acessarem um servio ou um grupo de servios. No mesmo sentido, previne o acesso de usurios no-autorizados. O gerenciamento de acesso ajuda a gerenciar a confidencialidade, disponibilidade e integridade dos dados, alm da propriedade intelectual. Este processo se preocupa com a identidade (informao nica que distingue um indivduo) e direitos (configuraes que fornecem acesso a dados e servios). O processo inclui verificar identidade, conceder acesso a servios, registrar e rastrear acesso e remover ou modificar direitos quando o status ou os papis mudam. Atividades: - Verificao da legitimidade das requisies: verificar a cada requisio de servio se mesmo a pessoa que est solicitando o acesso e se esta pessoa tem motivos legtimos para usar o servio. - Fornecer os direitos: Executa a poltica e as regras definidas na Estratgia de Servio e Desenho de Servio. Esta atividade no tem poder decisrio sobre quem acessa a qual servio, apenas a execuo da poltica. - Monitorar o status da identidade (mudana de papis): caso um usurio mude de departamento, seja demitido da empresa, promovido, etc., seu perfil deve ser atualizado ou removido para acompanhar esta mudana. - Registrar e monitorar o acesso: garante que os direitos foram dados corretamente ao usurio, sem se preocupar em responder s requisies de acesso. - Remover e limitar direitos: assim como uma atividade d o direito de acesso ao uso de um servio, esta tambm responsvel por remover estes direitos. Obviamente aqui tambm h apenas a execuo, no a deciso para tal. ### Gesto de TI ITIL Melhoria contnua Para que uma organizao de TI possa funcionar como um negcio dentro de um negcio, preciso traar uma viso que inclua objetivos, metas e mtricas. O gerenciamento de servios deve ter um programa de melhoria contnua. A cada ciclo devem ser traados os objetivos que se espera atingir em determinado prazo, sendo avaliados continuamente os processos e adaptando-os para obter a melhor eficincia e eficcia nos resultados. A melhoria continuada de servio, ao contrrio dos demais livros da biblioteca, no uma fase separada, suas atividades so executadas durante todo o ciclo de vida. O foco aumentar a eficincia, maximizar a efetividade e otimizar o custo dos servios e processos relacionados ao Gerenciamento de Servio de TI. A melhoria de servio continuada atua integrando todo o ciclo de vida, fazendo melhorias em cada fase ou no total delas. Aqui importante observar que SEMPRE a viso do negcio dever nortear os servios. Alm disso, tem os seguintes objetivos:

- Aperfeioar a qualidade do servio, da eficincia e da eficcia dos processos; - Buscar o custo efetivo na entrega de servios de TI; - Verificar se os nveis de servios esto sendo alcanados; - Assegurar que os mtodos de Gerenciamento da Qualidade suportem as atividades de melhoria contnua. A mensurao e a anlise so cruciais para a Melhoria Continuada de Servio. Atravs da mensurao possvel identificar quais servios podem melhorar. Isso quer dizer que assim como processos devem ter metas e objetivos claros, a mensurao tambm deve ser definida de forma clara. MSC e PDCA A melhoria de servio continuada faz uso do ciclo PDCA para aperfeioar continuamente a qualidade dos servios e tambm a prpria implantao da melhoria continuada. Modelo de MSC recomendado pela ITIL, consiste em 6 fases: 1) determinar a viso; 2) identificar onde se est no momento; 3) identificar onde se quer chegar; 4) saber como se chegar meta; 5) verificar se os objetivos foram alcanados; 6) manter a continuidade deste ciclo. Validao da estratgia mtricas servem para validar decises da estratgia. O ITIL recomenda trs tipos de mtricas: - Mtricas de Servio: resultado de um servio de ponta a ponta; - Mtricas de Processo: Fcs (Fatores-chave), KPIs (Indices-chave de desempenho) e mtricas de atividades para os processos de Gerenciamento de Servio; - Mtricas de Tecnologia: baseadas em componentes e aplicaes. Atividades da Melhoria de Servio Continuada: - Verificar os resultados dos processos; - Reportar e propor melhorias para todas as fases do ciclo de vida; - Aperfeioar introduzindo atividades que aumentam qualidade, eficincia e eficcia para atingir a satisfao do cliente. ### Gesto de TI Conceitos de governana de TI Governana de TI um conjunto de prticas, padres e relacionamentos estruturados, assumidos por executivos, gestores, tcnicos e usurios de TI de uma organizao, com a finalidade de garantir controles efetivos, ampliar os processos de segurana, minimizar os riscos, ampliar o desempenho, otimizar a aplicao de recursos, reduzir os custos, suportar as melhores decises e conseqentemente alinhar TI aos negcios. Governana de TI o conjunto estruturado de polticas, normas, mtodos e procedimentos destinados a permitir alta administrao e aos executivos o planejamento, a direo e o controle da utilizao atual e futura de tecnologia da informao, de modo a assegurar, a um nvel aceitvel de risco, eficiente utilizao de recursos, apoio aos processos da organizao e

alinhamento estratgico com objetivos desta ltima. Seu objetivo, pois, garantir que o uso da TI agregue valor ao negcio da organizao. Dentro destes conceitos, uma governana de TI eficaz deve tratar de trs questes: 1. Quais decises devem ser tomadas para garantir a gesto e o uso eficaz de TI? 2. Quem deve tomar essas decises? 3. Como essas decises sero tomadas e monitoradas? Governana de TI capaz de entregar benefcios diversos, tais como: - Confiana: constri confiana entre os envolvidos, mediante transparncia e clara definio de responsabilidades. - Melhores Entregas: direciona a organizao para o desenvolvimento de projetos, servios e aquisies de TI que suportem as metas e os objetivos organizacionais e que, dessa forma, possam agregar valor organizao. - Sincronia: sincroniza a estratgia de TI com as estratgias de negcio/governo, permitindo que as atividades da TI reflitam as estratgias. - Encoraja comportamentos desejados: cria ambiente e princpios para comportamentos como diminuio de custos, compartilhamento de dados, flexibilidade ou estmulo inovao; alm de assegurar que os comportamentos de indivduos estejam alinhados s metas e objetivos organizacionais. Uma governana de TI efetiva exige, antes de tudo, que os envolvidos possuam conhecimento sobre seus principais fundamentos, componentes e requisitos para implementao. ### Gesto de TI COBIT Significa, em portugus, Objetivos de Controle para a Informao e Tecnologia Relacionada. baseado em prticas utilizadas por organizaes que foram reunidas e desenvolvidas em um framework baseado em controles, pela ITGI (antes ISACA). Inicialmente era um modelo voltado para auditoria, hoje considerado um framework de Governana de TI. O COBIT pode ser utilizado para alinhar os objetivos de negcio (obtidos atravs de planejamento estratgico) aos objetivos de TI. Fornece apoio a Governana de TI, Gerenciamento de projetos de TI e de Servios de TI. Pode ser utilizado para qualquer empresa, qualquer tamanho. No uma norma. No considerado um modelo de auditoria. Objetivos do COBIT: Investigar, desenvolver, publicar e proporcionar um conjunto de objetivos de controle geralmente aceitos para as tecnologias da informao que sejam autorizados (dados por algum com autoridade), autorizados (dados por algum com autoridade), atualizados, e internacionais para o uso do dia a dia dos gestores de negcios (e tambm diretores) e auditores.

- aceito por rgos reguladores; - compatvel com outros modelos e frameworks de qualidade e governana de TI e coorporativa; - Facilita auditorias internas e externas; - Pode ser utilizado como passo inicial para a aplicao de projetos de governana de TI; - Baseado em prticas vividas, experimentadas e documentadas por especialista. Caractersticas do COBIT: 1) Focado no negcio: - O COBIT deve ser utilizado de fora para dentro, ou seja, da rea de Negcio para a rea de TI; - Deve ser baseado em objetivos de Negcio da empresa; - Os Objetivos de negcio incluem: requisitos obrigatrios e requisitos de negcio (regulamentos e performance); - Os processos buscam traduzir os objetivos de processo em objetivos de TI. 2) Orientado a processos: - O COBIT divide os objetivos de controle em 34 processos; - Os processos esto distribudos em 4 domnios; - Os domnios so: Organizao e Planejamento; Implementao; Entrega e Suporte; Monitorao e Avaliao.

Aquisio

3) Baseado em controles: - Para cada processo de TI, existem objetivos de controle definidos; - So, ao todo, 210 objetivos de controle; - Cada objetivo de controle contm, ainda, prticas de controle para auxiliar em sua utilizao. 4) Orientado por mtricas: - Sugere um conjunto de indicadores que permitem medir o desempenho das atividades; - So Indicadores de Performance e Indicadores e Meta (eficincia e eficcia).

O COBIT foca em O que precisa ser alcanado em vez de Como alcanar. Para complementar o COBIT, existem outros padres de gesto e boas prticas que podem ser utilizados. O COBIT suporta os 05 requisitos que um framework de controle: Ele deve ser focado no Negcio, Orientado a Processos, ter uma Linguagem em comum, requisitos regulatrios e aceitabilidade geral. COBIT baseado na premissa de que Recursos de TI precisam ser gerenciados por um conjunto de processos de TI que fornecem informao para os processos de negcio com o fim de atingirem-se os objetivos do negcio. COBIT pode ser utilizado por qualquer empresa, qualquer tamanho. Os objetivos de controle no so projetados para atender apenas a regulamentos, mas tambm objetivos de performance de negcio. ### Gesto de TI COBIT Os quatro domnios: - Planejar e Organizar. - Adquirir e Implementar. - Entregar e Suportar. - Monitorar e Avaliar. Domnio Planejar e Organizar - o domnio que tem o foco em relacionar os objetivos do negcio aos objetivos de TI. - o domnio onde deve ser desenvolvido o Plano Estratgico de TI, alinhado ao Plano Estratgico de Negcio. - Garante que toda a organizao conhea as metas estratgicas. Domnio ttico e estratgico. No trata questes operacionais e de baixo nvel. o domnio de alto nvel, que cuida de questes de longo prazo, estratgicas e fundamentais para a sobrevivncia da empresa. Diz como a TI pode contribuir para o atendimento dos objetos de negcio e envolve planejamento, comunicao e gerenciamento em diversas perspectivas. Processos deste domnio: PO1 Definir um Plano Estratgico de TI Tudo comea neste processo. A empresa precisa saber como vai se posicionar no mercado e da criar um plano estratgico de TI. Integrar e alinhar a gesto de TI ao negcio. Traduz os objetivos de negcio em objetivos e servios de TI. Diz quais projetos e servios sero escolhidos e disponibilizados. PO2 Definir a Arquitetura da Informao Definir o modelo coorporativo de dados. importante ter uma arquitetura global de dados para a organizao. Sempre que um novo projeto comea,

j pode utilizar este modelo coorporativo. Criar tambm uma classificao das informaes na sua organizao. PO3 Determinar o Direcionamento Tecnolgico Define o padro tecnolgico da empresa. Aplicativos, plataformas, etc. Isso estratgico, j que ambientes muito heterogneos ou com pouca portabilidade podem prejudicar a estratgia da empresa. Algumas empresas utilizam toda a plataforma de um mesmo fornecedor. Exemplo: plataforma da Oracle ou Microsoft. PO4 Definir os Processos, Organizao e os Relacionamentos de TI Definir como a rea de TI vai funcionar. Escolher quais processos do COBIT voc vai usar. Definir os comits. Escolher quais coisas do modelo do COBIT aplicam-se a realidade da sua empresa. PO5 Gerenciar o Investimento de TI Definir os critrios para o investimento em TI. Decidir como e onde investir. Quais projetos so prioritrios e o quanto ser alocado em cada um deles. extremamente estratgico, pois pode levar a empresa falncia. A gerncia pode considerar o retorno de investimento ou outros fatores financeiros para tomar tal deciso. PO6 Comunicar as Diretrizes e Expectativas da Diretoria preciso comunicar as metas, polticas, procedimentos, guias e diretrizes s pessoas para que tudo, que foi definido, seja seguido. preciso disseminar o conhecimento. PO7 Gerenciar os Recursos Humanos de TI Gerenciar as pessoas. Contratar, definir competncias, responsabilidades e cargos. Definir quantas pessoas de cada perfil. Quantos programadores? Quantos analistas? Gerentes? Projetistas? PO8 Gerenciar a Qualidade importante definir os critrios de qualidade e uma forma de controlar a qualidade nos processos de TI. Determinar o que vai ser feito na TI para manter a qualidade. PO9 Avaliar e Gerenciar os Riscos de TI Definir uma forma para avaliar, mitigar e tratar os riscos. Mapear todos os riscos importantes que podem afetar a organizao, classific-los e definir estratgias para trat-los. PO10 Gerenciar Projetos Gerenciar os projetos com a integrao de todos os outros gerenciamentos. Integra todos os planos de gerenciamento de projetos. Domnio Adquirir e Implementar - o domnio que tem o foco no desenvolvimento ou aquisio da soluo. - Garante que mudanas necessrias em sistemas sero tratadas. - Cobre tambm a validao das solues implantadas e modificaes. Pega as diretrizes vindas dos processos de PO, que identifica o que deve ser implementado, e executa os processos de implementao. Cobre a identificao, desenvolvimento e aquisio de solues de TI. Neste domnio

voc decide se desenvolve a soluo desde o incio ou se adquire a soluo pronta. Processos deste domnio: AI1 Identificar Solues Automatizadas necessrio realizar uma anlise para certificar que os requerimentos sero satisfeitos antes de criar ou adquirir um software para automatizao de processos. O processo aborda a definio das necessidades, solues alternativas, viabilidade econmica e tecnolgica, anlise de risco e de custo-benefcio, e uma deciso final de comprar ou desenvolver o prprio software. AI2 Adquirir e Manter Software Aplicativo As aplicaes devem estar disponveis para atender s necessidades do negcio. Este processo aborda o design de aplicaes, incluso apropriada de controles e requerimentos de segurana, desenvolvimento e configurao de acordo com padres. Isto permitir s organizaes suportar as operaes de negcio corretamente por meio de aplicaes automatizadas. AI3 Adquirir e Manter Infraestrutura de Tecnologia Aborda o planejamento de aquisies, manuteno e proteo da infraestrutura alinhado com estratgias tecnolgicas, alm do provimento de ambientes de desenvolvimento e testes. Isto garantir um suporte tecnolgico para as aplicaes de negcio. AI4 Habilitar Operao e Uso Novos sistemas instalados devem ser divulgados na organizao. Por isso, necessria a produo de documentao e manuais para todos os usurios e a prpria TI, alm do treinamento para o uso adequado das aplicaes e infraestrutura. AI5 Adquirir Recursos de TI Os recursos de TI, como software, servios, equipamentos e pessoas precisam ser encontrados. Esse processo ir auxiliar na seleo de fornecedores, criao de contratos de aquisio e a prpria aquisio do produto. Isso garantir que todos os recursos necessrios estaro disponveis quando necessrios, em uma maneira eficiente de custos. AI6 Gerenciar Mudanas Todas as alteraes em softwares e os procedimentos devem ser gerenciados, mesmo aqueles feitos s pressas em uma situao de emergncia. Essas mudanas devem ser registradas, avaliadas e autorizadas antes da implementao, alm de revisadas depois para saber se est de acordo com os resultados esperados. Esses cuidados iro diminuir consideravelmente a possibilidade de falhas e instabilidades nos sistemas de produo. AI7 Instalar e Homologar Solues e Mudanas Novos sistemas precisam ser instalados aps o desenvolvimento ser concludo. Isso requer um ambiente de testes apropriado. Isso certificar que os novos softwares estaro de acordo com as expectativas e resultados esperados.

Domnio Entregar e Suportar - o domnio que mantm foco na operao, comunicao e funcionamento dos servios. - Deve garantir que os servios de TI estejam alinhados ao negcio conforme planejado e desenvolvido nos domnios anteriores. - Deve trabalhar de forma a otimizar custos, treinar equipe e manter a estabilidade e qualidade dos servios. Cobre a entrega propriamente dita dos servios. na execuo destes processos que colocam os servios para funcionar. onde o valor agregado de fato. Gerencia a segurana e a continuidade dos servios. D suporte aos usurios. Aqui esto os processos operacionais, como gesto dos dados e da infraestrutura. Processos deste domnio: DS1 Definir e Gerenciar Nveis de Servios Devem ser criados e cumpridos os Acordos de Nvel de Servio SLA, para manter os usurios cientes da disponibilidade dos servios. O processo inclui o monitoramento e avisos aos stakeholders sobre o cumprimento dessas metas de entrega de servio. DS2 Gerenciar Servios de Terceiros preciso definir os papis, responsabilidades e expectativas acerca dos servios prestados por terceiros, a fim de minimizar os riscos associados. DS3 Gerenciar Capacidade e Desempenho O processo deve, periodicamente, verificar a capacidade e performance dos sistemas em produo. Ainda deve fazer uma anlise de forecast, ou seja, prever as necessidades futuras de recursos de TI. Isto garantir um crescimento contnuo e sustentado da organizao. DS4 Assegurar Continuidade de Servios preciso prover servios contnuos de TI, e isso requer o desenvolvimento, manuteno e teste dos planos de continuidade, backup, etc. Esse processo minimiza os impactos de uma falha de algum servio de TI, por exemplo. DS5 Assegurar a Segurana dos Servios O processo aborda a criao de procedimentos de segurana, responsabilidades, polticas de uso e padres. Tambm inclui a tarefa de monitoramento e testes peridicos e implementao de aes corretivas para falhas identificadas ou incidentes. Isso minimizar o impacto de problemas relacionados segurana. DS6 Identificar e Alocar Custos preciso ter uma medida eficiente dos custos necessrios para o setor de TI. Por isso esse processo visa tornar pblico aos usurios todos os custos de TI a fim de melhorar o uso geral dos recursos. DS7 Educar e Treinar os Usurios preciso treinar todos os usurios dos servios de TI, alm dos prprios funcionrios de TI. Definir, executar uma estratgia de treinamento eficiente e aferir os resultados. Um treinamento efetivo ocasionar na reduo de erros dos usurios, aumentando a produtividade e observncia com controles-chave como medidas de segurana de usurios.

DS8 Gerenciar a Central de Servio e os Incidentes Um servio de suporte interno com respostas rpidas e eficientes necessita de um processo bem desenvolvido e executado. preciso criar um servio com registros, classificao dos incidentes, tendncias e anlises de causas, alm da resoluo. O benefcio esperado o aumento da produtividade por meio da resoluo rpida de problemas. Tambm ser possvel descobrir as causas principais de problemas (como falta de treinamento). DS9 Gerenciar a Configurao preciso garantir a integridade do hardware utilizado nos sistemas de produo. Para isso preciso ter um gerenciamento completo das configuraes dos equipamentos, a fim de minimizar problemas que podem ocorrer. DS10 Gerenciar os Problemas O processo prev a identificao e classificao dos problemas reportados, anlise de causa e resoluo de problemas. Identificao e recomendaes para melhoramento tambm abordado. Um correto gerenciamento de problemas ir melhorar os nveis de servios prestados, ir reduzir custos, alm de aumentar a satisfao do usurio. DS11 Gerenciar os Dados O gerenciamento de dados ser feito baseado nos requerimentos de dados da organizao. preciso ter um controle eficiente dos backups, recuperao de dados, descarte apropriado de mdias (simplesmente jogar um HD, que no funciona, no lixo uma pssima ideia algum mais tarde poderia obter dados sensveis.) DS12 Gerenciar o Ambiente Fsico A segurana dos equipamentos e das pessoas requer instalaes muito bem desenhadas e construdas. Esse processo inclui a definio das requisies para o ambiente, gerenciamento de acesso fsico de pessoas, etc. DS13 Gerenciar as Operaes O processamento de dados requer uma infraestrutura de hardware bem gerenciada. Definio de polticas e procedimentos para um gerenciamento efetivo de tarefas agendadas, proteo das sadas dos processos, monitoramento da infra-estrutura, e manuteno preventiva do hardware. Isso ajudar a manter a integridade dos dados, alm de reduzir atrasos nos processos de negcio e custos de operao de TI. Domnio Monitorar e Avaliar - o domnio que mantm foco na avaliao constante dos processos de TI. - Este domnio enderea o gerenciamento de desempenho e Governana de TI. - Responsvel por monitorar os controles internos. Visa assegurar a qualidade dos processos de TI e manter a conformidade com os objetivos de controle. um domnio voltado para melhoria continua da qualidade dos processos. Garante que os resultados prometidos e esperados esto sendo alcanados. Utiliza mecanismos de acompanhamento e monitoramento dos controles internos com avaliaes ou auditorias internas e externas.

Processos deste domnio: ME1 Monitorar e Avaliar o Desempenho de TI. O gerenciamento efetivo da performance de TI precisa de um processo prprio. So definidos indicadores de performance, um sistema de relatrios sistemticos sobre performance. O monitoramento necessrio para garantir que as coisas sero feitas e estaro de acordo com as diretivas e polticas estabelecidas. ME2 Monitorar e Avaliar os Controles Internos. Esse processo aborda o monitoramento de excees, resultados de autoavaliaes e revises de terceiros. Um benefcio desse processo ser o provimento de garantias acerca da efetividade e eficincia das operaes, alm da observncia das leis aplicveis e entidades reguladoras. ME3 Assegurar a Conformidade com Requisitos Externos (Garantir a conformidade regulatria). preciso o estabelecimento de um processo de reviso independente para garantir a conformidade com leis e rgos reguladores. ME4 Prover a Governana de TI. O estabelecimento de um framework de governana inclui a definio das estruturas organizacionais, processos, lideranas, papis e responsabilidades para garantir que os investimentos da organizao em TI estaro alinhados e entregues de acordo com as estratgias e objetivos. ### Gesto de TI COBIT Os recursos de TI precisam ser gerenciados por processos para gerar informao aos processos de negcio que buscam atingir aos objetivos. Os recursos so: Aplicativos: Sistemas de Informao para processar as informaes. Informaes: Dados que so processados por todos os sistemas de informao. Infraestrutura: Toda estrutura de tecnologia necessria, tal como hardware, SO, estrutura de rede. Pessoas: Recursos Humanos necessrios para Planejar, Desenvolver, Entregar e Avaliar os servios. Critrios da Informao do COBIT para atender ao negcio: Requisitos da Qualidade: - eficcia: est relacionada com atingir ao objetivo; informao eficaz aquela que entregue de um modo correto, consistente e til. - eficincia: capacidade de atingir o objetivo com a melhor performance possvel; pode estar relacionado com menor tempo ou custo e esforo (recursos). Requisitos Fiducirios:

- conformidade: disponibilizar informaes que comprovem o cumprimento dos regulamentos. - confiabilidade: informao confivel a informao livre de falhas; informao apropriada. Requisitos de segurana: - confidencialidade: informao disponvel apenas a quem tem direito. - integridade: exatido da informao. - disponibilidade: capacidade da informao de estar disponvel no momento que for requisitada. ### Gesto de TI reas de foco da Governana de TI 1. Alinhamento Estratgico: foca em garantir a ligao entre os planos de negcios e de TI, definindo, mantendo e validando a proposta de valor de TI, alinhando as operaes de TI com as operaes da organizao. O alinhamento corresponde aplicao da TI de forma apropriada e em harmonia com as estratgias, objetivos e necessidades organizacionais. O retorno sobre o investimento funo deste alinhamento. Entender e medir o alinhamento so um desafio para executivos que no so da TI. 2. Entrega de Valor: a execuo da proposta de valor de TI atravs do ciclo de entrega, garantindo que TI entrega os benefcios prometidos previstos na estratgia da organizao, se concentrado em otimizar custos e provendo o valor intrnseco de TI. Segundo o ITGI, o valor uma funo do grau pelo qual a organizao da TI est alinhada aos objetivos estratgicos e alcanar as expectativas de negcios. Avaliar o valor da TI e qual a sua magnitude continuam sendo um grande desafio. Weill sugere um conjunto de prticas de gerenciamento que ajudam na busca de valor: - padronizao de tecnologia; - gerenciamento de projetos; - clarificao do valor; - governana de TI. 3. Gesto de Recursos (Otimizao dos Investimentos): refere-se melhor utilizao possvel dos investimentos e o apropriado gerenciamento dos recursos crticos de TI: aplicativos, informaes, infraestrutura e pessoas. Questes relevantes referem-se otimizao do gerenciamento da infraestrutura. A TI precisa de boa infraestrutura tecnolgica, pessoal tcnico capacitado e bem treinado, oramento adequado para a manuteno dos servios de TI e realizao de novos investimentos. Aspectos relacionados ao bom uso de recursos e a definio do que deve ser terceirizado so importantes. Os ativos de TI podem ser tangveis (HWSW) e intangveis (conhecimento, relacionamento). O uso adequado dos recursos se d com o seu uso nas atividades e processos da organizao. 4. Gesto de Risco: requer a preocupao com riscos pelos funcionrios mais experientes da corporao, um entendimento claro do apetite de risco da empresa e dos requerimentos de conformidade, transparncia sobre os

riscos significantes para a organizao e insero do gerenciamento de riscos nas atividades da companhia. A informao um recurso da organizao, portanto falar de gesto de riscos de TI falar de gesto de riscos da Organizao. Assim necessrio identificar, mensurar e gerenciar os riscos de TI. Gerenciar os riscos corresponde ao processo de analisar e gerenciar o risco. A anlise de risco trata a identificao, estimativa e avaliao de riscos. 5. Mensurao de Desempenho (Transparncia): acompanha e monitora a implementao da estratgia, trmino do projeto, uso dos recursos, processo de performance e entrega dos servios, usando, por exemplo, balanced scorecards que traduzem as estratgia em aes para atingir os objetivos, medidos atravs de processos contbeis convencionais. Um sistema de mensurao de desempenho um conjunto de pessoas, mtodos, ferramentas e indicadores formatados para coletar, descrever e representar os dados, com a finalidade de gerar informaes que permitam a avaliao do desempenho da TI por diferentes nveis organizacionais. O uso de indicadores de desempenho uma forma de avaliar o desempenho da TI. O BSC muito utilizado para gerar os indicadores de desempenho da TI. Alguns autores definem ainda um sexto foco: 6. Accountability: A definio clara dos papis e responsabilidades foco importante da governana de TI. Inclui definir, comunicar, dar apoio e definir consequncias quando ocorrer uma no conformidade. ### Gesto de TI Modelo de maturidade para o COBIT - Inexistente. Ausncia total de processos identificveis. A organizao no reconhece que um aspecto a ser considerado. - Inicial. H evidncias de que a organizao reconhece que o aspecto existe e deve ser considerado. Entretanto, no h processos padronizados, apenas abordagens eventuais que tendem a ser aplicadas em bases isoladas ou caso a caso. A abordagem da administrao em geral no organizada. - Repetitivo. Os processos foram desenvolvidos at o estgio em que procedimentos similares so adotados por pessoas distintas que realizam a mesma tarefa. No h treinamento ou divulgao formal de procedimentos padronizados e as responsabilidades so deixadas a cargo das pessoas. H um alto grau de confiana no conhecimento pessoal e consequente tendncia a erros. - Definido. Os procedimentos foram padronizados e documentados, bem como divulgados atravs de treinamento. Contudo, cabe s pessoas seguir tais processos, sendo pouco provvel que desvios sejam detectados. Os procedimentos em si no so sofisticados, consistindo na formalizao de prticas existentes. - Gerenciado. possvel monitorar e mensurar o cumprimento dos procedimentos, bem como adotar medidas quando os processos aparentarem no funcionar efetivamente. Os processos esto sob constante melhoria e propiciam boas prticas. Automao e ferramentas so utilizadas de forma limitada ou fragmentada.

- Otimizado. Os processos foram refinados ao nvel das melhores prticas, com base nos resultados de melhorias contnuas e modelagem da maturidade com outras organizaes. A TI utilizada como uma forma integrada para automatizar os fluxos dos procedimentos (workflow), provendo ferramentas para melhorar a qualidade e a efetividade, tornando a empresa gil para adaptaes. ### Gesto de TI COBIT Medio de Performance Os objetivos e mtricas so definidos no CobiT em trs nveis: - Objetivos e mtricas de TI que definem o que os negcios esperam de TI e como medir isso. - Objetivos e mtricas dos processos que definem o que os processos de TI precisam entregar para dar suporte os objetivos de TI e como medir isso. - Objetivos e mtricas de atividades que estabelecem o que precisa acontecer dentro do processo para atingir a requerida performance e como medir isso. ### Arquitetura de computadores RISC x CISC Exemplos de RISC: RISC I, MIPS, RS6000, SPARC. Exemplos de CISC: 386, 68030. Principais caractersticas de mquinas CISC: conjunto de instrues de linguagem de mquina maior e mais complexa. Microprograma maior e mais lento. Principais caractersticas de mquinas RISC: - em uma mquina RISC, h um pequeno nmero de instrues executadas diretamente pelo hardware sem nenhum interpretador ou microprograma. - a unidade de dados da mquina RISC otimizada para garantir um mnimo de tempo de ciclos de dados. - poucas instrues e modos de endereamento. RISC Instrues simples levando um ciclo Apenas LOADs e STOREs referenciam a memria Altamente pipelined (2 ciclos: busca, executa) CISC Instrues complexas levando mltiplos ciclos Qualquer instruo pode referenciar a memria Pouco pipelined

Instrues executadas pelo hardware Instrues de formato fixo Poucas instrues e modos de endereamento Compilador complexo Muitos registradores (+/- 500) Menos transistores na pastilha Projeto mais rpido

Instrues interpretadas pelo microprograma Instrues de vrios formatos Muitas instrues e modos de endereamento Microprograma complexo Poucos registradores Mais transistores na pastilha Projeto mais lento

Linguagem de montagem ou assembly: notao legvel por humanos para o cdigo de mquina que uma arquitetura de computador especfica utiliza. Montador/Assembler: tradutor onde a linguagem fonte a linguagem de montagem e a linguagem alvo a linguagem de mquina. Linguagem de montagem: cdigo menor e mais rpido. Ligador cria um programa executvel a partir de um objeto. Arquitetura de computador oferece, pelo menos, dois modos de operao: Supervisor (privilegiado/protegido): - possibilita a execuo de todas as instrues do processador; - modo de execuo sistema operacional. Usurio: - certas instrues no podem ser executadas; - modo de execuo dos processos usurios. Chaveamento de modos: - interrupo (usurio -> protegido). - instruo (protegido -> usurio). ### Arquitetura de computadores Sincronizao - Usar a varivel busy: a regio crtica comea como falso. Quando o processo acessa a RC, ele muda a varivel para verdadeiro. O problema que se houver uma troca de contexto no momento de entrar na RC, mais de um processo pode acessar a RC. - Alternncia de uso: definir uma varivel vez para indicar qual processo pode acessar a RC. O problema que se um processo no acessar a RC, essa varivel vez no evolui. - Algoritmo de Peterson: antes dele, Dekker tinha criado um algoritmo correto e Peterson o deixou mais simples. Quando o processo tenta entrar, ele pega a vez e fica testando se a vez dele e se o outro est na RC. Quando isso der falso, ele entra na RC. - Instrues de mquina test-and-set.

Problemas: Ineficincia: as tarefas que aguardam o acesso a uma seo crtica ficam testando continuamente uma condio, consumindo tempo de processador sem necessidade. O procedimento adequado seria suspender essas tarefas at que a seo crtica solicitada seja liberada. Injustia: no h garantia de ordem no acesso seo crtica; dependendo da durao de quantum e da poltica de escalonamento, uma tarefa pode entrar e sair da seo crtica vrias vezes, antes que outras tarefas consigam acess-la. Semforos: counter e queue. Ao usar semforos, um programador define explicitamente os pontos de sincronizao necessrios em seu programa. Essa abordagem eficaz para programas pequenos e problemas de sincronizao simples, mas se torna invivel e suscetvel a erros em sistemas mais complexos. Variveis de condio: Uma varivel de condio no representa um valor, mas uma condio, que pode ser aguardada por uma tarefa. Quando uma tarefa aguarda uma condio, ela colocada para dormir at que a condio seja verdadeira. Assim, a tarefa no precisa testar continuamente aquela condio, evitando uma espera ocupada. Um monitor uma estrutura de sincronizao que requisita e libera a seo crtica associada a um recurso de forma transparente, sem que o programador tenha de se preocupar com isso. Um monitor consiste de: - um recurso compartilhado, visto como um conjunto de variveis internas ao monitor. - um conjunto de procedimentos que permitem o acesso a essas variveis; - um mutex ou semforo para controle de excluso mtua; cada procedimento de acesso ao recurso deve obter o semforo antes de iniciar e liberar o semforo ao concluir; - um invariante sobre o estado interno do recurso. ### Sistemas operacionais Gerenciamento de E/S Polling Na e/s com polling, o processador controla toda a transferncia de dados entre a memria e a interface de e/s. Normalmente, o registrador de estado possui um bit, chamado done bit, que desativado quando um dado escrito no registrador de dados, sendo ativado quando este dado escrito no setor do disco. Aps escrever um dado no registrador de dados, o processador l o registrador de estado e testa o done bit, para verificar se o mesmo j foi escrito no setor do disco. Este teste do bit de estado chamado polling. O processador continua realizando o polling at encontrar o done bit ativado, o que indica que o dado j foi escrito no setor do disco. Quando isto acontece, e se ainda existe algum dado a ser enviado, o processador escreve o novo dado no registrador de dados e reinicia o polling. Este ciclo repetido at que todos os dados tenham sido escritos no setor do disco.

A principal vantagem da e/s com polling a sua simplicidade. No entanto, esta tcnica possui a desvantagem de que o processador fica dedicado operao de e/s. Isto pode ser extremamente ineficiente, sob o ponto de vista da utilizao do processador. Considere uma operao de envio de um bloco de caracteres para uma impressora. O tempo de impresso de um caracter infinitamente maior que o tempo de execuo de uma instruo. Manter o processador em polling durante o tempo de impresso de cada caracter um desperdcio, j que durante este intervalo de tempo o processador poderia executar alguns milhes de instrues de um outro programa. Devido ao fato que o processador fica dedicado operao de e/s at o seu trmino, o uso da tcnica de e/s com polling restrito apenas a sistemas onde apenas um programa pode se encontrar em execuo a cada instante. Interrupo Nesta tcnica, a interface responsvel por notificar o processador quando um novo dado pode ser transferido. Enquanto a e/s com polling uma tcnica puramente de software, a e/s com interrupo requer um suporte de hardware. A interface deve gerar um sinal de interrupo, atravs do qual ela notifica o processador quando uma operao de e/s foi concluda. A interface inicia a fase de transferncia de dados fazendo um pedido de interrupo ao processador, atravs do sinal de interrupo. Ao receber o pedido de interrupo, o processador suspende a execuo do programa corrente e passa a executar uma rotina especial, chamada rotina de servio de interrupo (tambm chamada device driver ou device handler). Nesta rotina, o processador verifica inicialmente se o ltimo dado j foi enviado. Se este o caso, o processador conclui a escrita do setor do disco lendo o registrador de estado da interface. Caso contrrio, o processador envia um novo dado e retorna para o programa que se encontrava em execuo. Durante a fase de transferncia de dados, a interface faz um pedido de interrupo a cada dado escrito no setor do disco. O processador responde ao pedido de interrupo executando a rotina de servio e enviando um novo dado. Isto se repete at que todos os dados tenham sido escritos no setor do disco. Normalmente, a interface de disco conhece o tamanho do setor e mantm uma contagem dos dados j recebidos, de forma que ela pode determinar quando deve encerrar a seqncia de pedidos de interrupo. Em um sistema comum existirem vrias interfaces diferentes que fazem pedidos de interrupo ao processador. Cada interface deve ser atendida por uma rotina de servio de interrupo especfica para aquela interface. Assim, ao receber um pedido de interrupo, o processador deve determinar qual a rotina de servio a ser executada. Alm disso, quando duas ou mais interfaces fazem pedidos de interrupo simultneos, necessrio decidir qual o pedido de interrupo que ser atendido. Estas duas funes so suportadas por um componente do subsistema de e/s, chamado controlador de interrupo (interrupt controller). Acesso Direto Memria Na e/s com DMA (Direct Memory Access) um componente do sub-sistema de e/s, chamado controlador de DMA, responsvel por transferir os dados entre a memria e a interface de e/s.

O processador participa apenas da fase de disparo. Na fase de transferncia de dados, o controlador de DMA assume o controle dos barramentos para realizar a transferncia entre a memria e a interface. Para tanto, o controlador de DMA coloca o processador em um estado, chamado hold state, no qual o processador fica impedido de iniciar ciclos de barramento. ### Sistemas operacionais CPU Bound means the rate at which process progresses is limited by the speed of the CPU. A task that performs calculations on a small set of numbers, for example multiplying small matrices, is likely to be CPU bound. I/O Bound means the rate at which a process progresses is limited by the speed of the I/O subsystem. A task that processes data from disk, for example, counting the number of lines in a file is likely to be I/O bound. Chamadas ao sistema O conjunto de chamadas ao sistema oferecido pelo SO a interface entre o prprio SO e os programas do usurio. Fazer uma chamada ao SO como fazer uma chamada de procedimento, exceto que este em modo usurio e aquele em modo ncleo ou supervisor. ### Sistemas operacionais Comunicao com dispositivos As caractersticas que regem a comunicao de cada um dos dispositivos de E/S (entrada e sada) com o ncleo do computador (composto de UCP e memria principal) so muito diferentes entre si. Cada dispositivo de E/S se comunica com o ncleo de forma diversa do outro. Entre outras diferenas, os dispositivos de entrada e sada so muito mais lentos que o computador, caracterstica essa que impe restries comunicao, de vez que o computador precisaria esperar muito tempo pela resposta do dispositivo. Outra diferena fundamental diz respeito s caractersticas das ligaes dos sinais dos dispositivos. A UCP no se comunica diretamente com cada dispositivo de E/S e sim com "interfaces", de forma a compatibilizar as diferentes caractersticas. O processo de comunicao ("protocolo") feito atravs de transferncia de informaes de controle, endereos e dados propriamente ditos. Inicialmente, a UCP interroga o dispositivo, enviando o endereo do dispositivo e um sinal dizendo se quer mandar ou receber dados atravs da interface. O perifrico, reconhecendo seu endereo, responde quando est pronto para receber (ou enviar) os dados. A UCP ento transfere (ou recebe) os dados atravs da interface, e o dispositivo responde confirmando que recebeu (ou transferiu) os dados (acknowledge ou ACK) ou que no recebeu os dados, neste caso solicitando retransmisso (not-acknowledge ou NAK). Na transmisso sncrona, o intervalo de tempo entre dois caracteres subseqentes fixo. J na transmisso assncrona, o intervalo de tempo entre os caracteres no fixo.

Uma comunicao dita simplex quando permite comunicao apenas em um nico sentido, tendo em uma extremidade um dispositivo apenas transmissor (transmitter) e do outro um dispositivo apenas receptor (receiver). Uma comunicao dita half-duplex (tambm chamada semi-duplex) quando existem em ambas as extremidades dispositivos que podem transmitir e receber dados, porm no simultaneamente. Uma transmisso dita full-duplex (tambm chamada apenas duplex) quando dados podem ser transmitidos e recebidos simultaneamente em ambos os sentidos. ### Sistemas operacionais Estruturas dos discos As unidades de armazenamento em disco, como o HD, so divididas em crculos concntricos chamados trilhas. Essas trilhas por sua vez so divididas em pequenas unidades para armazenamento chamadas setores. Os setores so, efetivamente, locais onde os dados digitais so armazenados. No so todos os sistemas operacionais que conseguem entender a grande quantidade de setores quem h em um disco rgido (depende do sistema operacional); portanto, os setores so reunidos em pequenos grupos chamados clusters, que passam a ser a mnima quantidade de informao que um disco consegue entender. Um cluster um conjunto de setores contguos que so reunidos simplesmente para que seja possvel gerenciar o contedo do disco. Como um disco rgido tem muitos setores, gerenci-lo um a um seria muito custoso para o sistema operacional. Como um disco rgido pode possuir diversas parties de tamanhos variados. As parties tero seu prprio nmero estipulado de clusters dependendo da diviso ocorrida no disco. O particionamento muito mais comum quando se deseja instalar mais de um sistema operacional no computacional. Escalonamento dos discos A poltica de escalonamento dos acessos a discos rgidos tem um impacto importante no throughput de um sistema (nmero de bytes lidos ou escritos no disco por segundo). Algumas polticas bem conhecidas so: - First Come, First Served (FCFS): os pedidos so atendidos na ordem em que so gerados pelas tarefas; sua implementao simples, mas no oferece um bom desempenho; - Shortest Seek-Time First (SSTF): os acessos a disco so ordenados conforme sua distncia relativa: primeiro so atendidos os pedidos mais prximos posio atual da cabea de leitura do disco. - Circular Scan (CSCAN): os pedidos so atendidos sempre em ordem crescente de suas posies no disco; aps tratar o pedido com a maior posio, a cabea do disco retorna ao prximo pedido com a menor posio no disco.

### Sistemas operacionais Sistemas de arquivo Sistema de arquivos a forma que o sistema operacional usa para representar determinada informao em um espao de armazenagem. o mtodo de identificar e indexar as informaes que esto armazenadas em qualquer mdia: disquetes, discos rgidos, drives em memria, CDs, etc. Quando se prepara um disco para o trabalho atravs do processo de formatao fsica, criam-se os meios magnticos necessrios para armazenar os dados. Este processo faz uma preparao do dispositivo de armazenagem para que ele possa receber um sistema de arquivos e futuramente os dados do usurio. Um sistema de arquivos, portanto, necessrio para manter padres, para controlar o tamanho das parties, permisses de arquivos, tamanho dos arquivos e sua organizao, entre muitas outras funes. Diretrio: conjunto de entradas para identificao e localizao dos arquivos. Forma de organizao para facilitar acessos. Mtodos de acesso aos arquivos: Acesso sequencial - Leitura dos dados (bytes/registros) se d a partir do incio - No permite acesso fora de ordem - Primeiros SOs s armazenavam arquivos em fitas magnticas Acesso aleatrio - Leitura dos dados (bytes/registros) pode ser feito fora de ordem - Essencial para sistemas tal como base de dados - Sistemas de arquivo atuais empregam este tipo Modos de alocao de arquivos: Alocao contgua - Consiste em armazenar um arquivo em blocos contguos - Implementao bem simples - Endereo do bloco onde inicia o arquivo - Nmero de blocos que so empregados Problemas - Alocao de novos arquivos em espaos livres - Pode gerar fragmentao externa - E se o tamanho de arquivo armazenado precisar ser estendido Lista encadeada - S preciso conhecer o primeiro bloco - Primeira palavra utilizada como ponteiro para prximo bloco - ltimo bloco aponta para endereo nulo - No causa fragmentao externa Problemas

- Acesso aleatrio lento, pois os blocos tem de ser sequencialmente buscados - Para se chegar ao bloco n, deve-se passar por n-1 blocos antes - Vinculo est armazenado em disco - Bloco no usado somente para dados Exemplo - Bloco de 1kbytes e endereamento de 16 bits - 1022 bytes armazenam informaes - 2 bytes endeream o prximo bloco Alocao indexada (usada pelo Linux) - Cada arquivo possui um bloco de ndices - O diretrio possui o endereo do bloco de ndices de cada arquivo - Para acessar um bloco especfico do arquivo necessrio acessar o bloco de ndices para determinar o seu endereo fsico no disco - Os arquivos podem ser criados com tamanho zero - Permite acesso direto - Ocupa-se um setor inteiro para ndices - Para arquivos grandes so necessrios vrios setores de ndices Alocao por extenso (usada pelo windows) Usada pelo Windows NT. O SO aloca uma extenso para o arquivo conforme a sua necessidade. H uma estrutura de controle por arquivo que contm as informaes de bloco inicial, quantidade de blocos na extenso e o nmero do bloco do arquivo na extenso. H preocupao com a fragmentao do arquivo no disco, o que ir gerar o crescimento da estrutura de controle. ### Sistemas operacionais Cache de disco Quando o sistema operacional precisa de mais memria do que a instalada no micro, o sistema operacional precisa usar a memria virtual, movendo parte dos dados para o arquivo de troca (swap file) no HD. Por outro lado, quando voc tem instalado mais memria do que o sistema realmente precisa, feito o inverso. Ao invs de copiar arquivos da memria para o HD, arquivos do HD, contendo os programas, arquivos e bibliotecas que j foram anteriormente abertos que so copiados para a memria, fazendo com que o acesso a eles passe a ser instantneo. Os programas e arquivos passam a ser abertos de forma gritantemente mais rpida, como se voc tivesse um HD muito mais rpido do que realmente . Esse recurso chamado de cache de disco e (sobretudo no Linux) gerenciado de forma automtica pelo sistema, usando a memria disponvel. Naturalmente, o cache de disco descartado imediatamente quando a memria precisa ser usada para outras coisas. Ele apenas uma forma de aproveitar o excedente de memria, sem causar nenhum efeito desagradvel. Ironicamente, a forma mais eficiente de melhorar o desempenho do HD, na maioria das aplicaes, instalar mais memria, fazendo com que uma quantidade maior de arquivos possa ser armazenada no cache de disco.

por isso que servidores de arquivos, servidores proxy e servidores de banco de dados costumam usar muita memria RAM, em muitos casos 4 GB ou mais. Outra forma de melhorar o desempenho do HD usar RAID, onde dois ou quatro HDs passam a ser acessados como se fossem um s, multiplicando a velocidade de leitura e gravao. Esse tipo de RAID, usado para melhorar o desempenho, chamado de RAID 0. Existe ainda o RAID 1, onde so usados dois HDs, mas o segundo uma cpia exata do primeiro, que garante que os dados no sejam perdidos no caso de algum problema mecnico em qualquer um dos dois. O RAID tem se tornado um recurso relativamente popular, j que atualmente a maioria das placas-me j vem com controladoras RAID onboard. ### Arquitetura de computadores Representao de nmeros inteiros Mdulo e sinal Neste sistema de representao, o bit que est situado mais esquerda representa o sinal, e o seu valor ser 0 para o sinal + e um para o sinal -. Os bits restantes (N-1) representam o mdulo do nmero. Por exemplo, supondo que exista a limitao de 8 bits (N=8), o valor 00101010 representa o nmero +42 e o valor 10101010 representa o nmero -42. Complemento de 1 Este sistema de representao tambm utiliza o bit mais esquerda para o sinal, correspondendo o 0 ao sinal + e o 1 ao sinal -. Para os nmeros positivos, os N - 1 bits da direita representam o mdulo (assim como no MS). O simtrico de um nmero positivo obtido pelo complemento de todos os seus dgitos (trocando 0 por 1 e vice-versa), incluindo o bit de sinal. Por exemplo, supondo que exista a limitao de 8 bits (N=8 ), o valor 00101010 representa o nmero +42 e o valor 11010101 representa o nmero -42. Representao de nmeros reais Existe a parte fracionria, o expoente, o sinal do expoente e o sinal do nmero. A mantissa a parte fracionria normalizada. Normalizar a parte fracionria seria: -3,14 = 0,314 x 10 Mantissa = 0,314 Expoente = 1 Sinal do nmero (SN) = -1 Sinal do expoente (SE) = 1 SN SE Expoen te Mantis sa

### Arquitetura de computadores

A Unidade Central de Processamento - UCP (em ingls, Central Processing Unity - CPU) a responsvel pelo processamento e execuo dos programas armazenados na memria principal. As funes da UCP so: executar as instrues e controlar as operaes no computador. A UCP composta de duas partes: UAL - Unidade Aritmtica e Lgica - tem por funo a efetiva execuo das instrues. UC - Unidade de Controle - tem por funes a busca, interpretao e controle de execuo das instrues, e o controle dos demais componentes do computador. Um smbolo esquemtico tpico para uma ULA, onde "A" e "B" so operandos, "R" a sada, "F" a entrada da unidade de controle e "D" a sada de status.

### Arquitetura de computadores Conteno significa aguardar numa fila para poder ser servido. Existem vrias filas na execuo de tarefas em uma arquitetura moderna. Filas de disco, filas de espera da liberao do locking de certos registros ou tabelas do Banco de Dados, etc. Contenes so difceis de serem tratadas e podem causar deadlocks. Embora muitas ferramentas implementem schedulers que reordenam seqncias de operaes conflitantes (que o que acontece num Banco de Dados). ### Arquitetura de TI Principais Problemas com TI - Pouca eficcia nas solues de TI para o negcio - Falta de flexibilidade e alto custo para adaptao dos sistemas s mudanas - Baixa qualidade das informaes - Redundncias, inconsistncias, falta de semntica explcita e consensual - Mltiplas Tecnologias - Necessidade de solues de curto prazo

- Necessidade de contnuo gerenciamento e adaptao s mudanas tecnolgicas e de negcio Por que isto acontece? - Grandes distncias entre o planejamento do negcio e os desenvolvimentos de TI - Falta de viso da estratgia de TI ao longo prazo - Mercado de tecnologias muito volteis e geis para atendimento das exigncias do negcio - Ausncia de modelos conceituais de representao do domnio - Fraca integrao de dados e aplicaes - Baixo nvel de padronizao de tecnologia Mas, como resolver estes problemas? - Conhecendo a organizao: objetivos e metas, processos, conceitos e dados, sistemas e componentes, infra-estrutura - Promovendo alinhamento entre a TI e processos de negcio - Integrando e otimizando aplicaes, informaes e tecnologias - Definindo melhores prticas para TI - Definindo e organizando: modelos, mtodos e ferramentas para suporte ao desenvolvimento de TI - Estabelecendo padres - Gerindo os repositrios de informaes - Prospectando novas solues no mercado Durante os prximos 3 a 5 anos, tendncias no negcios e na tecnologia (excesso de informao, novos processos de negcio, crescimento de servios e o poder crescente dos indivduos) iro reforar a necessidade de um foco mais profundo e claro na Arquitetura Corporativa, e de investimentos mais altos em pessoas, processos e tecnologia. Conceitos de arquitetura Corporativa de TI - Conjunto estruturado de dados e modelos descritivos que definem o negcio, a informao e a tecnologia suportada para operar a empresa, num processo contnuo de alinhamento com o negcio. - Viso holstica e integrada do motivo, onde e quem utiliza sistemas de TI, alm de como e para qu eles so utilizados dentro de uma organizao. As arquiteturas so compostas por: arquitetura de negcio, arquitetura da informao, arquitetura de sistemas e arquitetura da tecnologia. 1) Arquitetura de negcio Domnio das reas de negcio - Processos do Negcio: suportar as estratgias da organizao e de cada rea do negcio - O corao de uma boa arquitetura de negcios a definio dos processos de negcio com suas caractersticas funcionais e operacionais, se tornando a base para manusear a aplicao das estratgias de negcio. Organizao e Estratgia do negcio - Vasta coletnea de pensamentos com os propsitos, metas, estruturas e planos da organizao

- Mltiplas formas possveis: principal objetivo contextualizar o desenho dos processos de negcio - Tecnicamente, no faz parte da Arquitetura Corporativa de TI, mas crtico o suficiente para que o desenho de arquitetura garanta o que est sendo levado em considerao como parte dos processos de TI Arquitetura de processos de negcio - Define os principais processos da empresa: desenvolvimento de produtos, vendas, distribuio, etc. - Detalha processos especficos e reflete parmetros operacionais: volumes de transaes, regras, operao centralizada ou distribuda, etc. - Primeiro ponto de contato entre o negcio e a arquitetura de TI - Apresenta a viso do negcio que ser detalhada o suficiente para que sejam definidos os planos e estratgias para a construo dos SI 2) Arquitetura da informao - No domnio da Gerncia de Dados - Orienta e organiza toda a informao que trafega em uma organizao: descreve a sua estrutura conceitual, lgica e fsica; viabiliza conhecimento da organizao sobre seus dados, facilita acesso e trata aspectos de eficincia - Viso dos Dados -> Informao -> Conhecimento: Operacionalizar e otimizar as estratgias e decises de negcio - Base para o desenho e implantao dos SI Arquitetura de Dados - Dados, Metadados, Modelos: Princpios e Polticas: quem o responsvel pela informao, pelo uso e gerenciamento; Estratgias de uso dos dados Semntica (conceitual) Estruturas de armazenamento (lgico) Eficincia no acesso (fsico) - Objetivos: Facilitar o acesso informao (abstrao; transformaes entre os modelos, rastreabilidade); Fornecer subsdios para: mapear a arquitetura de sistemas; definir a arquitetura futura - Orientar a arquitetura tecnolgica: bases de dados, servios de gerncia de dados, modelagem fsica Servios de Dados - Servios para acesso s informaes: Informao-como-um-Servio (information-as-a-service IaaS) - Camada que encapsula as necessidades de dados das aplicaes: transparncia - Altamente re-utilizvel - Implementao diversa: Remete abordagem SOA 3) Arquitetura de sistemas - Muitas vezes dispersa entre as mltiplas Gerncias de TI

- Compreende o mapeamento e planejamento adequado de todos os componentes de sistemas: para suportar o negcio e as atividades de uma organizao e para manipular as informaes que trafegam na organizao - Contempla: Identificao de quais SI so necessrios para suportar o negcio Desenho, construo (ou aquisio) e integrao dos sistemas - Composta por Arquitetura de Aplicaes Arquitetura de Integrao Arquitetura de Servios - Arquitetura de Aplicaes - Contempla - Documentao das aplicaes: Anlise, projeto, construo - Informao trafegada entre os sistemas - Processos suportados pelos sistemas - Objetivo promover desenvolvimento de aplicaes - De fcil integrao - Consistentes com os requisitos identificados - Que manipulam dados conhecidos - Adequadas s caractersticas do ambiente operacional Restries e requisitos no funcionais - Arquitetura de Integrao - Viso nica corporativa da integrao de sistemas Baseada no reuso e da distribuio de funcionalidades por um barramento (BUS) lgico Middleware de integrao entre aplicaes - Relacionamentos entre os diversos componentes implementados Servios, APIs, conectores, interfaces e protocolos de comunicao disponveis e padronizados. - Arquitetura de Servios - Servios como paradigma de construo das aplicaes Encapsulamento de detalhes de funcionamento e acesso s informaes, interoperabilidade - Cria uma camada que encapsula componentes da aplicao Conceito de barramento Enterprise Service Bus (ESB) - Aderente abordagem SOA 4) Arquitetura de Tecnologia - Tambm conhecida como arquitetura de infra-estrutura: muito prxima do operacional e produo da organizao - Abrange todos os elementos para suportar TI que devem ser operados no dia a dia, bem como software e processos para gerenci-los Hardware, infra-estrutura de rede, ambientes de desenvolvimento, plataformas de gerncia de dados, etc. Recursos que representam uma significativa parte dos ativos da organizao - Influencia diretamente a implementao dos SI - Arquitetura Tcnica

Infra-estrutura de hardware e software para as aplicaes e dados empresariais Plataformas de e-mail, compartilhamento de arquivos, especificao dos equipamentos Plataformas de SGBD, servidores, protocolos de rede, ambiente de data warehousing - Arquitetura de Operaes Ferramentas e processos necessrios para construir, monitorar, gerenciar e medir todos os aspectos de tecnologia, aplicaes e ativos de dados da empresa - Arquitetura de Segurana - Proteger a informao corporativa e os processos de negcio da organizao Polticas de privacidade das informaes, polticas para deteco e tratamento de invases e ataques, avaliao de incidentes de segurana - Aspectos de segurana de vrios itens de TI Especificao de sistemas de firewall, polticas de acesso a aplicaes e arquivos, perfis de acesso s bases de dados, proteo contra vrus e espionagem eletrnica, polticas de recuperao aps desastre - Tem ganhado cada vez mais projeo Lei Sarbanes Oxley, etc. Benefcios: - Melhoria no processo de planejamento de TI: mapa para a priorizao de projetos, estabelecimento de metas, dimensionamento de equipes - Apoio ao planejamento financeiro de TI: racional para oramentao de projetos; uso otimizado de recursos e de uma gerncia mais simplificada - Reduo da curva de aprendizado dos especialistas de TI - Melhoria dos trabalhos em equipe dentro da TI: todos passam a conhecer todo o ambiente - Reduo de prazos - Simplifica projeto - Reduo de riscos no desenvolvimento: maior clareza do escopo e misso da iniciativa; subsdios para planejamento de substituies de tecnologias e produtos obsoletos - Aumento da rastreabilidade: maior clareza do impacto da mudana dos processos e requisitos - Facilidade na divulgao de padres e produtos homologados ### Arquitetura de TI Anlise de GAP Tambm conhecida como anlise de diferena. Corresponde a uma anlise da situao atual existente na organizao em relao situao futura que se deseja alcanar. A anlise de diferena deve produzir um relatrio de diferenas entre a arquitetura atual e um detalhamento das atividades a serem executadas para implantao da nova

arquitetura (roadmap), atravs da definio de projetos que esto contemplados no escopo definido. Roadmap A technology roadmap is a plan that matches short-term and long-term goals with specific technology solutions to help meet those goals. It is a plan that applies to a new product or process, or to an emerging technology. Three uses: - It helps reach a consensus about a set of needs and the technologies required to satisfy those needs; - It provides a mechanism to help forecast technology developments; - It provides a framework to help plan and coordinate technology developments. The Technology Roadmapping Process conducts 3 phases: Phase 1: Preliminary phase The first phase, the preliminary phase consists of 3 steps: satisfy essential conditions (In this step it must become clear what the conditions are), provide leadership / sponsorship (Committed leadership is needed) and define the scope and boundaries for the technology roadmap (In this step the context for the roadmap will be specified). In this phase the key decision makers must identify that they have a problem and that technology roadmapping can help them in solving the problem. Phase 2: Development phase The second phase, the development of the technology roadmap phase consists of 7 steps: identify the product that will be the focus of the roadmap, identify the critical system requirements and their targets, specify the major technology areas, specify the technology drivers and their targets, identify technology alternatives and their timelines, recommend the technology alternatives that should be pursued and create the technology roadmap report. These steps create the actual roadmap. Phase 3: Follow-up activity phase This is the moment when the roadmap must be critiqued, validated and hopefully accepted by the group that will be involved in any implementation. For this a plan needs to be developed using the technology roadmap. Next there must be a periodical review and update point, because the needs from the participants and the technologies are evolving. ### Sistemas operacionais Cluster Conjunto de servidores agrupados com inteno de ganho de desempenho, disponibilidade, ou facilidade no gerenciamento. Normalmente um cluster composto por mquinas convencionais ligadas em uma rede de alto desempenho e fornecendo a abstrao ao usurio de uma nica mquina.

Balanceamento de carga Um sistema distribudo consiste numa coleo de computadores autnomos conectados por uma rede de comunicao. Devido a flutuaes na taxa de chegadas e no tempo de servio das tarefas submetidas pelos usurios durante certo intervalo de tempo, algumas mquinas podero estar ociosas enquanto outras estaro pesadamente carregadas [Livny & Melman, 1982]. Os algoritmos de compartilhamento ou distribuio de carga tentam melhorar o desempenho deste tipo de sistema compartilhando a carga de trabalho do sistema entre as mquinas que o compem. Os algoritmos de balanceamento de carga vo alm, visando equilibrar a carga de todas as mquinas O problema do balanceamento de carga um problema de escalonamento, que consiste em determinar qual mquina da rede ir executar uma determinada tarefa de maneira a otimizar o desempenho do sistema. Encontrar a soluo tima para este tipo de problema em geral um problema NP-Completo. ### Arquitetura de TI Portais corporativos Personalizao - cada usurio um usurio diferente e precisa receber informao de seu interesse apenas. Com essa premissa que as ferramentas de Portais Corporativos devem oferecer mecanismos de personalizao para que o contedo ideal seja entregue para o usurio, de acordo com seu interesse. A personalizao pode ser passiva, quando o contedo entregue de acordo com o perfil ou ativa quando o usurio define o que quer e o que no quer nas pginas de seu portal corporativo. Integrao de Sistemas - integrao com demais aplicaes indispensvel. Se no houver integrao o portal jamais conseguir ser a interface nica dos usurios de uma empresa. A integrao um dos pontos mais complexos no desenvolvimento de um Portal Corporativo. As boas ferramentas de Portais Corporativos possuem diversos componentes de integrao disponveis para facilitar essa tarefa. Colaborao Estabelecer a aproximao, mediada e apoiada pela tecnologia, dos crebros e talentos da organizao. Taxonomia Hierarquia lgica de termos, em torno da qual uma organizao estrutura sua vida. Web 2.0 Web 2.0 a mudana para uma internet como plataforma, um entendimento das regras para obter sucesso nesta nova plataforma. Entre outras, a regra mais importante desenvolver aplicativos que aproveitem os efeitos de rede para se tornarem melhores quanto mais so usados pelas pessoas, aproveitando a inteligncia coletiva. Gerenciador de Contedo

Segundo definio, Gerenciador de Contedo um sistema, software ou aplicao que permite aos usurios de negcio gerenciar os contedos de seus websites, Portais Corporativos, Intranets, Extranets, Sites Mveis ou Aplicaes Web, sem a necessidade de conhecimentos tcnicos (programao) e atravs de um software de Gerenciador de Contedo CMS. Um Sistema de Gerenciamento de Contedo (do ingls Content Management System CMS) um aplicativo usado para criar, editar, gerenciar e publicar contedo de forma consistentemente organizada permitindo que o mesmo seja modificado, removido e adicionado com facilidade. CMSs so frequentemente usados para armazenar, controlar, versionar, e publicar documentao empresarial tais como notcias, artigos, manuais de operao, manuais tcnicos, guias de vendas e brochuras de marketing. O contedo pode incluir arquivos de computador, imagens, udios, vdeos, documentos eletrnicos e contedo Web. Portlets So componentes de Portais Corporativos que oferecem contedo, colaborao ou mesmo informaes transacionais, vinda de sistemas j existentes que so integrados ao Portal como portlets. O conceito de um portlet o de um componente que, ao ser desenvolvido, pode ser reutilizado por quantas vezes forem necessrias e pelos mais diversos tipos de portais. Por conta disso, a especificao JSR 168 surgiu, um padro Java para portlets e portais corporativos, que os melhores softwares de portais e as melhores ferramentas de portais utilizam, como por exemplo, o Agile Portal. ### Arquitetura de software Inverso de controle Padro muito usado em projetos orientados a objeto e utiliza conceitos como interface, herana e polimorfismo, e, tem como objetivo reduzir o acoplamento, facilitar o reuso e os testes no projeto de software. Programao por contrato um paradigma de programao no qual o tratamento governado por regras. Estas regras, chamadas assertions, formam um contrato que especifica responsabilidade entre o cliente e o provedor de cdigo de software. um mtodo semi-formal de programar cujo propsito principal reduzir o nmero de bugs em um programa. ### Engenharia de software CMMI Desenvolvimento de requisitos - Identifica as necessidades do cliente; - Traduz essas necessidades em requisitos; - Os requisitos so analisados para gerar uma soluo conceitual de alto nvel; - Fornece requisitos para a rea de processo de Soluo tcnica, onde os requisitos so convertidos em arquitetura do produto, design de componentes de produto e no prprio componente do produto;

- Fornece requisitos para a rea de processo Integrao do produto, onde os componentes de produto so combinados e as interfaces so verificadas para assegurar que os requisitos de interface, fornecidos pelo Desenvolvimento de requisitos sejam atendidos; Aliada a essa rea, tem a rea de processo Gesto de requisitos. - Mantm os requisitos; - Descreve atividades para obter e controlar mudanas de requisitos e assegurar que outros planos e dados relevantes se mantenham atualizados; - Assegura que as mudanas ocorridas nos requisitos sejam refletidas em planos, atividades e produtos de trabalho de projeto; Soluo tcnica - Desenvolve pacotes de dados tcnicos para componentes de produto que sero utilizados pela rea de processo Integrao de produto ou pela rea de processo Gesto de contrato com fornecedores; - Solues alternativas so examinadas a fim de escolher o design timo com base em critrios previamente estabelecidos; - Apia-se nas prticas especficas da rea de processo Verificao para realizar verificaes de design e revises por pares durante o design e antes da construo final; Verificao - Assegura que os produtos de trabalho selecionados satisfaam aos seus requisitos especificados, selecionando mtodos para sua verificao em relao aos requisitos especificados; - Incremental e iniciado com a verificao de componentes de produto e concludo com a verificao de produtos completos; - Tambm envolve reviso por pares que um mtodo comprovado para a remoo efetiva e antecipada de defeitos e proporciona um conhecimento valioso sobre os produtos de trabalho e componentes de produto que esto sendo desenvolvidos; - Pode ser feito em ambiente real ou em um ambiente simulado; - Aspecto importante o alinhamento dos requisitos de validao com o cliente; - Engloba validao de produtos, componentes de produto, produtos intermedirios de trabalho e processos; - Questes crticas so solucionadas, normalmente, nas reas de processo Desenvolvimento de requisitos ou Soluo tcnica; Integrao de produto - Contm as prticas especficas associadas gerao da melhor sequncia de integrao possvel, envolvendo a integrao de componentes de produto e a entrega do produto ao cliente; - Utiliza prticas especficas das reas de processo Verificao e Validao; - As prticas de Verificao possibilitam a verificao das interfaces e dos requisitos de interface de componentes de produto antes da integrao do produto; ### Engenharia de software

Testes de software Teste de Carga Execuo de testes para verificar se o sistema suporta a carga prevista, e avaliar a sua robustez quando submetido a uma carga acima do previsto, assim como determinar o seu limite de capacidade com um tempo de resposta considerado aceitvel para o sistema e infra- estrutura em causa. Obter linhas de base de desempenho no sentido de permitir a comparao com resultados de testes futuros (testes de regresso) e avaliar eventuais impactos negativos ou positivos de alteraes efetuadas no sistema, arquitetura ou topologia. Teste de vulnerabilidade Mtodos para testar a vulnerabilidade do sistema Prova de conceito Usado para demonstrar a existncia de uma vulnerabilidade. Fornecido por um fornecedor ou um pesquisador em um frum aberto. uma demonstrao do problema atravs de um bloco pequeno de cdigo que no explora um sistema em benefcio do atacante. No uma descrio que mostra ao usurio como reproduzir o problema. Usada para identificar a origem do problema e recomendar uma soluo. Usada para notificar a comunidade de segurana, sobre um problema. O objetivo ganhar tempo entre o momento em que a vulnerabilidade anunciada e o momento em que usurios maliciosos comeam a produzir cdigo para tirar proveito dessa vulnerabilidade e lanar ataques. Cdigo de explorao Um programa escrito para tirar vantagem de um problema em alguma parte de um software. elaborado para mostrar mais detalhes de como uma vulnerabilidade pode ser explorada. Pode ser escrito em vrias linguagens. Fornece comunidade de segurana, um programa para demonstrar uma vulnerabilidade, produzir algum ganho para o usurio executando o programa. Tambm torna possvel o ataque a sistemas por usurios maliciosos. Oferece clareza na explorao da vulnerabilidade e motivao para fornecedores produzirem um patch. Lanar uma explorao funcional significa lanar um programa que tire proveito de um problema. Fruns que divulgam detalhes tcnicos sobre uma vulnerabilidade e compartilham exploraes funcionais so observados por muitos membros, todos com as suas motivaes. Ferramentas automatizadas So pacotes de software criados por fornecedores para permitir testes de segurana (descobertas de vulnerabilidades) de forma automtica. Geram relatrios sobre lista detalhada dos problemas de vulnerabilidades com o sistema. Permitem usurios legtimos realizarem auditorias para controlarem o andamento da proteo do sistema.

 Usurios maliciosos, com a mesma ferramenta, podem identificar vulnerabilidades em hosts. Usurios com pouco conhecimento tcnico tm a capacidade de identificar e proteger seus hosts. Versioning Consiste em identificar verses ou revises de software que um sistema est usando. Muitos pacotes de software possuem uma verso (Windows 2000 Professional ou Solaris 8). E muitos pacotes de software includos em um software versionalizado, tambm incluem uma verso (como uma distribuio LINUX, que uma coleo de pacotes de software, cada um com sua prprias verses). O mtodo consiste na observao de uma lista de pacotes de software com verses anunciadas contendo vulnerabilidades, por um fornecedor. Um mtodo de realizar Versioning executar o comando de verso em um pacote de software: Como, por exemplo, o comando uname a que fornece a reviso de kernel rodando em uma mquina LINUX. Outro modo usar uma ferramenta de gerenciamento de patch, provida por um fornecedor para verificar o software pela ltima verso. ### Engenharia de software Teste de Usabilidade - O Teste de Usabilidade avalia o sistema do ponto de vista do usurio final. - O teste de usabilidade no substitui o design adequado. - Ele mais eficaz quando combinado com o Design Centrado no Usurio. - O Teste de Usabilidade deve ocorrer logo no incio. O teste com o usurio no incio significa a criao inicial de prottipos, normalmente esboos e modelos descritos como prottipos de baixa fidelidade. Os prottipos de alta fidelidade sero criados posteriormente; ### Engenharia de software Validao e Verificao Objetivo: assegurar que o software que o software cumpra as suas especificaes e atenda s necessidades dos usurios e clientes. Verificao: Estamos construindo certo o produto? O software deve est de acordo com a sua especificao. Checar algo contra suas especificaes. Validao: Estamos construindo o produto certo? O software deve atender s necessidades dos usurios. Testar (homologar) se foi produzido o produto correto, no ambiente-alvo pretendido, atendendo s reais expectativas pretendidas, e no s aquelas que estavam especificadas.

 Ocorrem em todo o ciclo de vida completo Revises de requisitos, revises de design, testes de cdigo Tcnicas de V&V Inspees de software (V & V esttica) Anlise da documentao e cdigo fonte do software; Pode ser auxiliado por ferramentas de depurao; Testes de software (V & V dinmica) O programa ou um prottipo deve ser executado; Casos de testes devem ser elaborados: dados de entrada e comportamento esperado. O processo de V&V ocorre durante todo o ciclo de vida Precisa ser planejado em conjunto com outras atividades do processo de software ### Engenharia de software Medio e anlise O propsito do processo Medio coletar, analisar e relatar os dados relativos aos produtos desenvolvidos e aos processos implementados na organizao e em seus projetos, de forma a apoiar os objetivos organizacionais. Medio e Anlise 1. Identifica-se a necessidade de informao 2. Estabelece-se um mtodo para medio 3. Determinam-se medidas bsicas e derivadas 4. Determinam-se indicadores e critrios de deciso Exemplo 1. Necessidade de informao: quantos erros so identificados nos testes de aceitao? 2. Mtodo de medio: Coleta semanal atravs dos dados dos relatrios de testes; 3. Medidas bsicas: quantidade de erros introduzidos, iterao identificada, origem... 4. Indicador: x erros encontrados considerado severidade alta. Anlise de Deciso e Resoluo Processo que faz parte do nvel de maturidade C. O propsito do processo Anlise de Deciso e Resoluo analisar possveis decises usando um processo formal, com critrios estabelecidos, para avaliao das alternativas identificadas. Resultados esperados: ADR 1. Guias organizacionais para a anlise de deciso so estabelecidos e mantidos; ADR 2. O problema ou questo a ser objeto de um processo formal de tomada de deciso definido;

ADR 3. Critrios para avaliao das alternativas de soluo so estabelecidos e mantidos em ordem de importncia, de forma que os critrios mais importantes exeram mais influncia na avaliao; ADR 4. Alternativas de soluo aceitveis para o problema ou questo so identificadas; ADR 5. Os mtodos de avaliao das alternativas de soluo so selecionados de acordo com sua viabilidade de aplicao; ADR 6. Solues alternativas so avaliadas usando os critrios e mtodos estabelecidos; ADR 7. Decises so baseadas na avaliao das alternativas utilizando os critrios de avaliao estabelecidos. ### Engenharia de software Manuteno 1) Identificar e Corrigir Erros Manuteno Corretiva 2) Atender Pedidos do Usurio para Modificar Funes Existentes, Incluir Novas Funes e Efetuar Melhoramentos Gerais Manuteno Evolutiva 3) Melhorar a manutenibilidade ou confiabilidade futuras e fornecer uma base melhor para futuros melhoramentos Manuteno Preventiva Fase mais problemtica do Ciclo de Vida de Software; Pode despender mais de 70% de todo esforo de uma Organizao; Esses sistemas devem continuar rodando e as alteraes inevitveis .

so

Por que exigida tanta Manuteno e por que despendido tanto Esforo nessa atividade? o Idade Mdia dos sistemas so de 10 a 15 anos; o Quando foram implementados, o tamanho do programa e o espao de armazenamento eram o principal interesse; o Migrao Para Novas Plataformas; o Sistemas mal estruturados. A maioria dos problemas com a manuteno do software causada por deficincias na maneira como o software foi planejado e desenvolvido

PROBLEMAS CLSSICOS difcil ou impossvel traar a evoluo do software atravs das vrias verses. As alteraes no so adequadamente documentadas difcil ou impossvel traar o processo atravs do qual o software foi criado. muito difcil entender programas "de outras pessoas". "As outras pessoas" freqentemente no esto presentes para explicar. A documentao no existe, incompreensvel ou est desatualizada. A maioria dos processos de construo de softwares no foi projetada para suportar alteraes. A manuteno no vista como um trabalho glamouroso.

- A Manutenibilidade pode ser definida qualitativamente como a facilidade com que o software pode ser entendido, corrigido, adaptado e ou melhorado. ### Engenharia de software Anlise de pontos de funo (APF) uma tcnica de medio das funcionalidades fornecidas por um software do ponto de vista de seus usurios. Ponto de funo (PF) a sua unidade de medida, que tem por objetivo tornar a medio independente da tecnologia utilizada para a construo do software. A APF mede o que o software faz, e no como ele foi construdo. Mede apenas as funcionalidades do software (ou requisitos funcionais) solicitadas e recebidas pelo usurio Requisitos funcionais representam as prticas e procedimentos de negcio que o software deve executar para atender s necessidades do usurio, em termos de tarefas e servios O gestor do negcio quem define requisitos funcionais Em fases iniciais do projeto os requisitos costumam no estar detalhados, mas ainda assim possvel estimar o tamanho em PFs O que a APF no mede No mede diretamente esforo, produtividade ou custo. exclusivamente uma medida de tamanho funcional do software. Este tamanho, junto com outras variveis, que pode ser usado para derivar produtividade, esforo e custo do projeto de software. Requisitos no funcionais so desconsiderados na medio de PFs Tecnologia: sistema operacional, linguagem de programao, etc Qualidade: performance, usabilidade, portabilidade, etc Padres: interface, segurana, auditoria, etc Manutenes que no mudam funes no so medidas em PF Em contratos por PF, o que a APF no mede pode afetar o R$/PF ou ser alvo de uma mtrica diferente. Para que medir? Derivar indicadores do processo de desenvolvimento e manuteno Permitem avaliar o impacto da introduo de mudanas no processo de desenvolvimento de software (novas ferramentas, mtodos, etc.) Comparar software e processos (benchmarking) Apoiar gesto do projeto de software (escopo, requisitos) Estimar custo, esforo de projetos de software Unidade de medio de contratos de software Enfim, medir para poder gerenciar! ### Engenharia de software

Integrao contnua a integrao do trabalho da equipe frequentemente ao dia. Sendo que teremos ao final de cada integrao a garantia de cdigo consistente. Segundo Martim Fowler, a integrao contnua : Integrao Contnua uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho freqentemente, geralmente cada pessoa integra pelo menos diariamente podendo haver mltiplas integraes por dia. Cada integrao verificada por um build automatizado (incluindo testes) para detectar erros de integrao o mais rpido possvel. Muitos times acham que essa abordagem leva a uma significante reduo nos problemas de integrao e permite que um time desenvolva software coeso mais rapidamente. O processo da integrao contnua Executa freqentemente: Build automtico, testes, analise esttica de cdigo, estimativas e mtricas. Disponibiliza o ltimo executvel; Informa a equipe sobre o estado atual do projeto. Isso significa que a cada build e bateria de testes, a equipe ser informada automaticamente se algum teste quebrar. Assim, a equipe poder providenciar o conserto o mais rpido possvel do problema. ### Engenharia de software Refatorao - Refatorao o processo de mudana do design uma aplicao sem modificar o seu comportamento original. - Uma [pequena] modificao no sistema que no altera o seu comportamento funcional, mas que melhora alguma qualidade no funcional. Possveis aspectos de qualidade no-funcional melhorados: simplicidade flexibilidade clareza desempenho Objetivos & aplicaes - Prevenir o envelhecimento do design e garantir a flexibilidade adequada para permitir a integrao tranquila de futuras extenses/alteraes [Mens e Tourw, 2004] - Cdigo legado. - Mtodos geis incorporam como uma prtica Extreme Programming. Exemplos de refatorao - Mudana do nome de variveis; - Mudanas nas interfaces dos objetos; - Pequenas mudanas arquiteturais; - Encapsular cdigo repetido em um novo mtodo; - Generalizao de mtodos: raizQuadrada(float x) raiz(float x, int n).

- Em geral, uma refatorao to simples que parece que no vai ajudar muito. - Mas quando se juntam 50 refatoraes, bem escolhidas, em seqncia, o cdigo melhora radicalmente. Passos para refatorao: - Detectar quando uma aplicao precisa ser refatorada. - Identificar quais refatoraes devem ser aplicadas e onde. - Realizar (automaticamente) as refatoraes. Problemas - Cdigo duplicado; - Mtodo muito longo; - Classe muito grande; - Intimidade inapropriada. - Antes de comear a refatorao, verifique se voc tem um conjunto slido de testes para verificar a funcionalidade do cdigo a ser refatorado. - Refatoraes podem adicionar erros. - Os testes ajud-lo-o a detectar erros se eles forem criados. ### Engenharia de software Mtodos geis Kanban um mtodo gil de desenvolvimento de software baseado nas prticas Lean (evitar desperdcio) e tem como objetivo otimizar o processo de desenvolvimento de software. O Kanban tem como foco o trabalho em progresso, apresentando a evoluo de forma visual, tornando os problemas evidentes e favorecendo uma cultura de melhoria contnua. Prs - Entregas a qualquer momento; - Muda a prioridade a qualquer instante; - Visualizao do fluxo de trabalho; - No quer se preocupar com iteraes; - No quer se preocupar com estimativas. Contra - Entregas baseadas em iteraes com tamanhos fixos; - Foco no desenvolvimento do produto; - Visualizao da Sprint; - Estrias devem ser estimadas; - Necessidade de ter papis bem definidos, tais como Product Owner. ### Arquitetura de TI Servidor de aplicao Um Servidor de Aplicaes (em ingls Applications Server) um servidor que disponibiliza um ambiente para a instalao e execuo de

certas aplicaes, centralizando e dispensando a instalao nos computadores clientes. Os servidores de aplicao tambm so conhecidos por middleware. O objetivo do servidor de aplicaes disponibilizar uma plataforma que separe do desenvolvedor de software algumas das complexidades de um sistema computacional. No desenvolvimento de aplicaes comerciais, por exemplo, o foco dos desenvolvedores deve ser a resoluo de problemas relacionados ao negcio da empresa, e no de questes de infraestrutura da aplicao. O servidor de aplicaes responde a algumas questes comuns a todas as aplicaes, como segurana, garantia de disponibilidade, balanceamento de carga e tratamento de excees. ### Linguagem de programao Em Java EE, o container contm os componentes construdos como Servlets (container para aplicaes Web) ou EJBs (container para componentes de negcio). Um exemplo de container para Web o Tomcat. Quando uma aplicao web faz uma solicitao para um Servlet, o servidor no entrega a solicitao diretamente ao Servlet, mas para o container que contm o Servlet. O container gerencia o ciclo de vida, d suporte ao multithread, segurana, e suporte para pginas JSP, no caso dos containers web. EJB ou Enterprise JavaBeans um dos principais componentes da plataforma J2EE (Java 2 Enterprise Edition). um componente do tipo servidor que executa no container do servidor de aplicao. Os principais objectivos da tecnologia EJB so fornecer um rpido e simplificado desenvolvimento de aplicaes Java baseado em componentes distribudos, transacionais, seguros e portveis. Trs tipos de EJBs Entity Beans Representa um objeto que vai persistir numa base de dados ou outra unidade de armazenamento. Session Beans Executa uma tarefa para o cliente. Pode manter o estado durante uma sesso com o cliente (Subtipo "Stateful") ou no (Subtipo "Stateless"). Message Driven Beans Processa mensagens de modo assncrono entre os EJB's e cuja API de mensagens Java Message Service (JMS). Interfaces de acesso Para acessar os EJB necessrio definir as suas interfaces de acesso que so: Interface Local, Interface Remota ou Ambas. AInterface Local define o acesso ao bean somente no computador onde est sendo executado o servidor de aplicao. A Interface Remota define o acesso ao bean somente a computadores externos. E ambas define acesso ao bean tanto do computador com o servidor de aplicao ou computadores externos. Entity Beans

They can be used to map an entry in a database table to a class. (Object Relational Mapping) instead of using result Sets from a database query you work with a class. The application server provides the functionality to load, update or delete the values of a class instance to the database. Session Beans Session beans are used to implement the functionality of your application. There are two kind of session beans: Stateful and Stateless. A stateful session bean is for example a shopping cart class. The state is the cart holding the shopping items and the quantity. The cart class is old in your application session and disposed at the end when the user checked out. A stateless bean is a short living class. A typical example is a MailSender class sending a message. You call a method and dispose it. With an application server you do not instantiate the class each time you need it. The application server passes an instance from a pool. This is more efficient. Message Driven Beans Message beans provide functionality to implement messaging in your business logic. When you want to send a message to one or more recipients to start another business logic, you can use message beans. A Shop application could send an order message to the Warehouse management. Once the warehouse management software is started, it receives the orders from the shop application. RMI RMI (Remote Method Invocation) uma forma que Java adotou para trabalhar com objetos Java/Java distribudos. A idia bsica do RMI obter um conjunto de objetos colaboradores que se comuniquem atravs de uma rede. Para entender as aplicaes RMI, vamos analisar um problema: supondo a existncia de sistema bancrio implementado em Java. Neste sistema, cada terminal bancrio pode requerer informaes dos clientes do banco para um centro de informaes. Estas informaes, uma vez obtidas, devem retornar ao terminal. Sob o ponto de vista de programao, pode se pensar que o terminal bancrio o cliente e o centro de informaes o servidor. A implementao deste problema pode ser realizada de vrias formas, tais como: * Abrir uma conexo atravs de sockets para o envio de dados puros; * Utilizar JDBC caso o servidor tenha as informaes implementadas em um banco de dados relacional; * Utilizar outras tecnologias como CORBA (Common Object Request Broker Architecture), caso se esteja trabalhando com aplicativos Java/Java e Java/outras linguagens como C++ e SmallTalk; * Ou implementar o pedido e a resposta da informao como objetos. Neste modelo, atravs de RMI, os objetos podem ser transportados entre o cliente e o servidor. Com RMI possvel transportar objetos pela rede e tambm chamar

mtodos que estejam em outro computador, mantendo o objeto na mquina remota. Supondo que o cdigo do computador cliente invoca um mtodo de um objeto no servidor. Para um cliente invocar um mtodo RMI, ele cria um objeto stub que encapsula o pedido do cliente em um pacote de bytes composto por: * Um identificador do objeto remoto a ser usado; * Um nmero de operao para descrever o mtodo a ser invocado; * Um conjunto de parmetros codificados (marshalling processo de codificao dos parmetros para um formato apropriado para o transporte de rede). Para o servidor receber a informao que est no stub, ele cria um objeto skeleton. O skeleton executa as seguintes aes: * * * * Decodifica os parmetros; Chama o mtodo desejado; Captura o valor de retorno ou exceo e codifica (marshalling); Retorna o valor codificado para o cliente.

O stub decodifica o valor de retorno do servidor, que pode ser uma exceo, mas que em geral o retorno da chamada do mtodo remoto. Deve-se ter um cuidado especial no momento em que no esto mais sendo utilizados os objetos remotos. Isto porque o Garbage Collection no pode detectar ligaes de objetos remotos no referenciados. Desta forma as ligaes devem ser explicitamente quebradas pelo programador. Sempre que evocado um mtodo remoto, as classes stub e skeleton sero carregadas com um gerenciador de segurana, que determina o que uma classe pode fazer. Semelhante aos gerenciadores de segurana dos browsers. O gerenciador de segurana definido pelo programador, no momento da implementao do programa. Java j dispe de gerenciadores de segurana bastante eficazes, porm, o programador pode criar novos gerenciadores, caso ache necessrio. Para realizar uma operao RMI, preciso criar, tanto do lado do cliente, quanto do lado do servidor, uma interface para o objeto que ser referenciado. Isto porque o cliente, embora no tenha o objeto real, que est no servidor, deve saber as aes que pode executar sobre este objeto (o protocolo). ### Linguagem de programao JavaServer Faces (JSF) um framework MVC de aplicaes Web baseado em Java que se destina a simplificar o desenvolvimento de interfaces de usurio baseadas em web. Caractersticas - Permite que o desenvolvedor crie UIs atravs de um conjunto de componentes UIs pr-definidos;

- Fornece um conjunto de tags JSP para acessar os componentes; - Reutiliza componentes da pgina; - Associa os eventos do lado cliente com os manipuladores dos eventos do lado do servidor (os componentes de entrada possuem um valor local representando o estado no lado servidor); - Fornece separao de funes que envolvem a construo de aplicaes Web. - Utiliza Ajax em alguns de seus componentes tornando alguns processos mais rpidos e eficientes. O framework JSF permite a insero, via IDE, de: Folhas de estilo (CSS); Comandos em JavaScript; Metodologia Ajax.

### Linguagem de programao In computing, Facelets is an open source Web template system under the Apache license and the default view handler technology (aka view declaration language) for JavaServer Faces (JSF). The language requires valid input XML documents to work. Facelets supports all of the JSF UI components and focuses completely on building the JSF component tree, reflecting the view for a JSF application. Although both JSP and JSF technologies have been improved to work better together, Facelets eliminates the issues noted in Hans Bergsten's article "Improving JSF by Dumping JSP"[1] Facelets draws on some of the ideas from Apache Tapestry, and is similar enough to draw comparison. The project is conceptually similar to Tapestry's, which converts HTML elements into the corresponding framework components. Facelets also has some similarities to the Tiles framework with respect to support templating as well as composition. Filtros em Java A filter is an object that performs filtering tasks on either the request to a resource (a servlet or static content), or on the response from a resource, or both. Filters perform filtering in the doFilter method. Every Filter has access to a FilterConfig object from which it can obtain its initialization parameters, a reference to the ServletContext which it can use, for example, to load resources needed for filtering tasks. Filters are configured in the deployment descriptor of a web application Examples that have been identified for this design are 1) 2) 3) 4) 5) 6) 7) Authentication Filters Logging and Auditing Filters Image conversion Filters Data compression Filters Encryption Filters Tokenizing Filters Filters that trigger resource access events

8) XSL/T filters 9) Mime-type chain Filter Funes da interface Filter: init(FilterConfig fc), doFilter(ServletRequest, ServletResponse, FilterChain) throws IOException, ServletException e destroy(). ### Linguagem de programao Arquitetura Java Persistence API (JPA) Persistncia de dados, a capacidade de manter os dados entre as execues de aplicativos, vital para aplicativos corporativos por causa do acesso necessrio aos bancos de dados relacionais. Os aplicativos desenvolvidos para esse ambiente devem gerenciar, sozinhos, a persistncia ou utilizar solues de terceiros para manipular atualizaes e recuperaes do banco de dados com a persistncia. O Java Persistence API (JPA) fornece um mecanismo para gerenciar persistncia e mapeamento de objeto relacional e funes para as especificaes EJB 3.0 e mais recentes. A especificao JPA define o mapeamento relacional de objetos internamente, em vez de depender das implementaes de mapeamento especficas do fornecedor. A JPA est baseada no modelo de programao Java que se aplica aos ambientes Java EE, mas a JPA pode funcionar em um ambiente Java SE para teste das funes do aplicativo. A JPA representa uma simplificao do modelo de programao de persistncia. A especificao JPA define explicitamente o mapeamento relacional de objetos, em vez de depender das implementaes de mapeamento especficas do fornecedor. A JPA padroniza a importante tarefa de mapeamento relacional de objetos utilizando anotaes ou o XML para mapear objetos para uma ou mais tabelas de um banco de dados. Para simplificar ainda mais o modelo de programao de persistncia: A API EntityManager pode persistir, atualizar, recuperar ou remover objetos de um banco de dados A API EntityManager e os metadados do mapeamento relacional de objetos manipulam a maioria das operaes do banco de dados sem exigir a gravao de cdigo JDBC ou SQL para manter a persistncia A JPA fornece uma linguagem de consulta, estendendo a linguagem de consulta EJB independente (tambm conhecida como JPQL), que pode ser utilizada para recuperar objetos sem a gravao de consultas SQL especficas do banco de dados com o qual se est trabalhando. A JPA foi projetada para operar dentro e fora de um continer Java Enterprise Edition (Java EE). Ao executar a JPA em um continer, os aplicativos podem utilizar o continer para gerenciar o contexto de persistncia. Se no houver continer para gerenciar a JPA, o aplicativo dever manipular o gerenciamento do contexto de persistncia sozinho. Os aplicativos projetados para persistncia gerenciada por continer no exigem muita implementao de cdigo para tratar a persistncia, mas esses aplicativos no podem ser utilizados fora de um continer. Os aplicativos que gerenciam sua prpria persistncia podem funcionar em um ambiente de continer ou em um ambiente Java SE. Java messaging system (JMS)

Enterprise messaging systems The Java Message Service was developed by Sun Microsystems to provide a means for Java programs to access enterprise messaging systems. Before we discuss JMS, let's take a look at enterprise messaging systems. Enterprise messaging systems, often known as message oriented middleware (MOM), provide a mechanism for integrating applications in a loosely coupled, flexible manner. They provide asynchronous delivery of data between applications on a store and forward basis; that is, the applications do not communicate directly with each other, but instead communicate with the MOM, which acts as an intermediary. The MOM provides assured delivery of messages (or at least makes its best effort) and relieves application programmers from knowing the details of remote procedure calls (RPC) and networking/communications protocols. Messaging flexibility As shown in the figure below, Application A communicates with Application B by sending a message through the MOM's application programming interface (API). The MOM routes the message to Application B, which can exist on a completely different computer; the MOM handles the network communications. If the network connection is not available, the MOM will store the message until the connection becomes available, and then forward it to Application B. Another aspect of flexibility is that Application B might not even be executing when Application A sends its message. The MOM will hold the message until Application B begins execution and attempts to retrieve its messages. This also prevents Application A from blocking while it waits for Application B to receive the message. This asynchronous communication requires applications to be designed somewhat differently from the way most are designed today, but it can be an extremely useful method for time-independent or parallel processing. Loose coupling The real power of enterprise messaging systems lies in the loose coupling of the applications. In the diagram on the previous section, Application A sends its messages indicating a particular destination, for example "order processing." Today, Application B provides order-processing capabilities. But, in the future, we can replace Application B with a different orderprocessing program, and Application A will be none the wiser. It will continue to send its messages to "order processing" and the messages will continue to be processed. Likewise, we could replace Application A, and as long as the replacement continued to send messages for "order processing," the order-processing program would not need to know there is a new application sending orders. Publish and subscribe Originally, enterprise messaging systems were developed to implement a point-to-point model (PTP) in which each message produced by an application is received by one other application. In recent years, a new model has emerged, called publish and subscribe (or pub/sub). Pub/sub replaces the single destination in the PTP model with a content hierarchy, known as topics. Sending applications publish their messages, indicating that the message represents information about a topic in the hierarchy.

Applications wishing to receive those messages subscribe to that topic. Subscribing to a topic in the hierarchy that contains subtopics allows the subscriber to receive all messages published to the topic and its subtopics. This figure illustrates the publish and subscribe model. Multiple applications can both subscribe and publish messages to a topic, and the applications remain anonymous to one another. The MOM acts as a broker, routing the published messages for a topic to all subscribers for that topic. What is JMS? JMS is a set of interfaces and associated semantics that define how a JMS client accesses the facilities of an enterprise messaging product. Prior to JMS, each MOM vendor provided application access to its product through a proprietary API, often available in multiple languages, including the Java language. JMS provides a standard, portable way for Java programs to send and receive messages through a MOM product. Programs written with JMS can run on any MOM that implements the JMS standard. The key to JMS portability is the fact that the JMS API is provided by Sun as a set of interfaces. Products that provide JMS functionality do so by supplying a provider that implements these interfaces. As a developer, you build a JMS application by defining a set of messages and a set of client applications that exchange those messages. JMS objectives To better understand JMS, it helps to know the objectives set by the authors of the JMS specification. There are many enterprise messaging products on the market today, and several of the companies that produce these products were involved in the development of JMS. These existing systems vary in capability and functionality. The authors knew that JMS would be too complicated and unwieldy if it incorporated all of the features of all existing systems. Likewise, they believed that they could not limit themselves to only the features that all of the systems had in common. The authors believed that it was important that JMS include all of the functionality required to implement "sophisticated enterprise applications." The objectives of JMS, as stated in the specification, are to: Define a common set of messaging concepts and facilities. Minimize the concepts a programmer must learn to use enterprise messaging. Maximize the portability of messaging applications. Minimize the work needed to implement a provider. Provide client interfaces for both point-to-point and pub/sub domains. "Domains" is the JMS term for the messaging models discussed earlier. (Note: A provider need not implement both domains.) ### Linguagem de programao Portlets are pluggable user interface software components that are managed and displayed in a web portal. Portlets produce fragments of markup code that are aggregated into a portal. Typically, following the desktop metaphor, a portal page is displayed as a collection of nonoverlapping portlet windows, where each portlet window displays a portlet.

Hence a portlet (or collection of portlets) resembles a web-based application that is hosted in a portal. Some examples of portlet applications are email, weather reports, discussion forums, and news. Portlet standards are intended to enable software developers to create portlets that can be plugged into any portal supporting the standards. The Java Portlet Specification defines a contract between the portlet container and portlets and provides a convenient programming model for Java portlet developers. JSR 168 The Java Portlet Specification V1.0 was developed under the Java Community Process as Java Specification Request JSR 168. The Java Portlet Specification V1.0 introduces the basic portlet programming model with: Two phases of action processing and rendering in order to support the Model-View-Controller pattern. Portlet modes, enabling the portal to advise the portlet what task it should perform and what content it should generate Window states, indicating the amount of portal page space that will be assigned to the content generated by the portlet Portlet data model, allowing the portlet to store view information in the render parameters, session related information in the portlet session and per user persistent data in the portlet preferences A packaging format in order to group different portlets and other Java EE artifacts needed by these portlets into one portlet application which can be deployed on the portal server. Portal development is a way to integrate the different web-based applications for supporting deliveries of information and services. JSR 286 JSR-286 is the Java Portlet specification v2.0 as developed under the JCP and created in alignment with the updated version 2.0 of WSRP. It was developed to improve on the short-comings on version 1.0 of the specification, JSR-168. Some of its major features include: Inter-Portlet Communication through events and public render parameters Serving dynamically generated resources directly through portlets Serving AJAX or JSON data directly through portlets Introduction of portlet filters and listeners ### Arquitetura de TI O controle de acesso mecanismo responsvel pela liberao ou no de recursos, operaes ou informaes a um usurio autenticado parte integrante da grande maioria dos sistemas computacionais. Ele responsvel por cruzar as informaes do usurio, da operao desejada (por exemplo, incluir, visualizar, alterar ou excluir) e do recurso computacional em questo e decidir se o acesso permitido ou no. Com origem nos sistemas militares, os estudos sobre modelos, mtodos e tcnicas de implementao de controle de acesso vm, desde os anos 70, se aprimorando e estendendo-se aos sistemas civis e comerciais. Muitos

modelos dentre os quais destacam-se o DAC (do ingls Discretionary AccessControl), o MAC (do ingls Mandatory Access Control) e o RBAC (do ingls RoleBased Access Control) foram formulados e esto hoje implementados em diversos dos sistemas que conhecemos e utilizamos. O modelo RBAC tem seu funcionamento baseado na definio de papis (ou perfis), que representam nveis funcionais hierrquicos dentro de uma organizao, e recursos que so objetos ou componentes do sistema. Cada usurio dever estar associado a um ou mais papis (relaes Usurio-Papel) e estes, por sua vez, estaro relacionados s autorizaes (relaes Permisso-Papel), que definem o tipo de acesso (leitura, execuo, criao, modificao, excluso etc.) permitido a cada recurso cadastrado. Em situaes reais, na maioria das vezes, as polticas de controle de acesso so mais complexas do que simplesmente definir papis e a eles associar permisses. H casos em que h restries de domnio como, por exemplo, em uma agncia bancria: h vrios gerentes, todos no mesmo nvel hierrquico; no entanto, cada um deles responsvel por um conjunto de clientes e no deve ter acesso aos dados das contas-correntes de outros clientes (aqueles que no esto em seu rol de administrao). Outro exemplo pode ser observado na situao hipottica de uma empresa de auditoria externa em que os Auditores, buscando evitar vcios e conivncia no processo de anlise, so anualmente revezados entre as diversas empresas-cliente. Assim, determinado Auditor somente possuir acesso aos dados de uma determinada empresa referentes ao perodo em que a esta estava sob sua anlise. O objetivo deste trabalho de pesquisa estudar, modelar, implementar um prottipo e validar um mecanismo de controle de acesso que implemente restries de domnio da forma como foram apresentadas nos pargrafos anteriores. Espera-se chegar a um modelo que possa ser implementado em plataformas distintas e que, principalmente, seja transparente aplicao principal, possibilitando todas as restries de acesso sejam implementadas sem a necessidade de promover alteraes significativas no cdigo originalmente escrito. ### Arquitetura de TI Auditoria O processo de auditar um sistema um dos mais importantes mecanismos de segurana que se pode fazer uso na hora de examinar, verificar e corrigir o funcionamento geral de um sistema. Conceitualmente o processo de auditar um sistema verifica se o mesmo est executando suas funes corretamente. Existem duas etapas bsicas de Auditoria, que na verdade, so apenas variaes do mesmo conceito. A primeira forma trata do registro de mudanas no estado do sistema, ou seja, eventos e/ou mudanas de estados so registrados. A segunda forma seria um processo sistemtico que examina e verifica o sistema, trata-se de

uma consulta ao ambiente para avaliao do funcionamento do mesmo, ou seja, verifica-se se o sistema est funcionando de forma correta. Para um processo de auditoria ser eficiente, ambas as formas mencionadas precisam estar construdas e sintonizadas, impossvel executar uma avaliao sistemtica de um sistema ou de um evento se esses no foram registrados, e mais, se os estados do sistema no forem gravados, no h a menor necessidade de se guardar, tambm, as mudanas no sistema, assim vamos consideramos que uma auditoria ser satisfatria se esta: Registrar os estados do sistema. Verificar, sistematicamente, os estados armazenados. Permitir que os registros sejam checados. ### Padres arquiteturais: http://martinfowler.com/eaaCatalog/ ### Engenharia de software CMMI O CMMI apresenta dois caminhos para melhoria. Um caminho permite que as organizaes melhorem de forma incremental os processos correspondentes a uma ou mais reas de processo individualmente selecionadas pela organizao. O outro caminho permite que as organizaes melhorem um conjunto de processos inter-relacionados e, de forma incremental, tratem sucessivos conjuntos de reas de processo. - Representao Contnua A representao contnua oferece mxima flexibilidade na utilizao de um modelo CMMI para melhoria de processo. Uma organizao pode focar na melhoria do desempenho de um ponto problemtico associado a um processo isolado, ou pode trabalhar em vrias reas que estejam fortemente ligadas aos objetivos estratgicos da organizao. A representao contnua tambm permite que uma organizao melhore diferentes processos com diferentes nfases ao longo do tempo. Existem algumas limitaes nas escolhas de uma organizao devido a dependncias entre algumas reas de processo. Se os processos da organizao que precisam ser melhorados so conhecidos e se as dependncias entre as reas de processo descritas no CMMI so bem compreendidas, a representao contnua uma boa escolha para essa organizao. - Representao por Estgios A representao por estgios oferece uma forma sistemtica e estruturada para abordar a melhoria de processo, baseada em modelo, enfocando um estgio por vez. A conquista de cada estgio assegura que foi estabelecida uma infraestrutura adequada de processos que servir de base para o prximo estgio. As reas de processo so organizadas em nveis de maturidade, o que reduz a necessidade de escolhas associadas melhoria de processo. A representao por estgios prescreve uma ordem de implementao das reas de processo de acordo com nveis de maturidade, definindo um caminho de melhoria para a organizao, do nvel inicial ao nvel em otimizao. A conquista de cada nvel de maturidade assegura que foi estabelecida uma base de melhoria adequada para o prximo nvel de maturidade, permitindo uma melhoria incremental e duradoura. Se no

se sabe por onde comear e quais processos escolher para serem melhorados, a representao por estgios uma boa opo. Ela fornece um conjunto especfico de processos para melhorar em cada estgio, determinado por mais de uma dcada de experincia e pesquisas em melhoria de processo. Esses dois caminhos de melhoria associam-se aos dois tipos de nveis correspondentes s duas representaes apresentadas anteriormente. Para a representao contnua, emprega-se a expresso nvel de capacidade e para a representao por estgios, emprega-se a expresso nvel de maturidade. Independentemente da representao escolhida, o conceito de nveis o mesmo. Os nveis caracterizam melhorias a partir de um estado em que processos esto mal definidos em direo a um estado que utilize informaes quantitativas a fim de determinar e gerenciar melhorias necessrias para satisfazer aos objetivos estratgicos da organizao. Nvel de Capacidade 0: Incompleto Um processo incompleto um processo que no executado ou executado parcialmente. Uma ou mais metas especficas da rea de processo no so satisfeitas e no existem metas genricas para este nvel, j que no h razo para institucionalizar um processo executado parcialmente. Nvel de Capacidade 1: Executado Um processo de nvel de capacidade 1 caracterizado como um processo executado. um processo que satisfaz s metas especficas da rea de processo, apoiando e viabilizando o trabalho necessrio para produzir os produtos de trabalho. Embora o nvel de capacidade 1 resulte em melhorias importantes, elas podem ser perdidas ao longo do tempo se no forem institucionalizadas. A institucionalizao, por meio da implementao das prticas genricas do CMMI nos nveis de capacidade de 2 a 5, contribui para que as melhorias sejam mantidas. Nvel de Capacidade 2: Gerenciado Um processo de nvel de capacidade 2 caracterizado como um processo gerenciado. um processo executado (nvel de capacidade 1) que dispe de infraestrutura adequada para apoiar o processo; planejado e executado de acordo com uma poltica; emprega pessoas experientes que possuem recursos adequados para produzir sadas controladas; envolve partes interessadas relevantes; monitorado, controlado e revisado; e sua aderncia em relao descrio de processo avaliada. A disciplina de processo refletida pelo nvel de capacidade 2 contribui para assegurar que as prticas existentes sejam mantidas durante perodos de stress. Nvel de Capacidade 3: Definido Um processo de nvel de capacidade 3 caracterizado como um processo definido. um processo gerenciado (nvel de capacidade 2), adaptado a partir do conjunto de processos-padro da organizao de acordo com as diretrizes para adaptao da organizao, e contribui com produtos de trabalho, medidas e outras informaes de melhoria de processo para os ativos de processo da organizao. Uma distino importante entre os nveis

de capacidade 2 e 3 o escopo de padres, descries de processo e procedimentos. No nvel de capacidade 2, os padres, as descries de processo e os procedimentos podem ser diferentes em cada instncia especfica do processo (por exemplo, em um projeto especfico). No nvel de capacidade 3, os padres, as descries de processo e os procedimentos para um projeto so adaptados a partir do conjunto de processos-padro da organizao para se ajustar s necessidades de um projeto especfico ou uma unidade organizacional. Desse modo, a adaptao conduz a uma maior homogeneidade, exceto por diferenas permitidas pelas diretrizes para adaptao. Outra distino importante que, no nvel de capacidade 3, os processos so geralmente descritos de forma mais rigorosa que no nvel de capacidade 2. Um processo definido estabelece claramente o objetivo, as entradas, os critrios de entrada, as atividades, os papis, as medidas, etapas de verificao, sadas e os critrios de sada. No nvel de capacidade 3, os processos so gerenciados mais proativamente, baseando-se na compreenso de como as atividades de processo relacionam-se e nas medidas detalhadas do processo, seus produtos de trabalho e servios. Nvel de Capacidade 4: Gerenciado Quantitativamente Um processo de nvel de capacidade 4 caracterizado como um processo gerenciado quantitativamente. um processo definido (nvel de capacidade 3), controlado por meio de tcnicas estatsticas e outras tcnicas quantitativas. Objetivos quantitativos para qualidade e para desempenho de processo so estabelecidos e utilizados como critrios na gesto de processo. A qualidade e o desempenho de processo so entendidos em termos estatsticos e gerenciados ao longo da vida do processo. Nvel de Capacidade 5: Em Otimizao Um processo de nvel de capacidade 5 caracterizado como um processo em otimizao. um processo gerenciado quantitativamente (nvel de capacidade 4) e melhorado com base no entendimento das causas comuns de variao inerentes ao processo. O foco de um processo em otimizao a melhoria contnua do desempenho de processo tanto por meio de melhorias incrementais quanto de inovao. Vale lembrar que os nveis de capacidade de 2 a 5 utilizam os mesmos termos em relao s metas genricas de 2 a 5. ---Nvel de Maturidade 1: Inicial No nvel de maturidade 1, geralmente os processos so ad hoc e caticos. Esse tipo de organizao no fornece um ambiente estvel para apoiar os processos. O sucesso depende da competncia e do herosmo das pessoas e no do uso dos processos comprovados. Apesar deste caos, organizaes no nvel de maturidade 1 frequentemente produzem produtos e servios que funcionam. Entretanto, com frequncia, eles extrapolam seus oramentos e no cumprem seus prazos. As organizaes no nvel de maturidade 1 so caracterizadas pela tendncia de se comprometer alm da sua capacidade, por abandonar o processo em um momento de crise, e por serem incapazes de repetir os prprios sucessos. Nvel de Maturidade 2: Gerenciado

No nvel de maturidade 2, os projetos da organizao tm a garantia de que os processos so planejados e executados de acordo com uma poltica; os projetos empregam pessoas experientes que possuem recursos adequados para produzir sadas controladas; envolvem partes interessadas relevantes; so monitorados, controlados e revisados; e so avaliados para verificar sua aderncia em relao descrio de processo. A disciplina de processo refletida pelo nvel de maturidade 2 contribui para que as prticas existentes sejam mantidas durante perodos de stress. Quando essas prticas esto em vigor, os projetos so executados e gerenciados de acordo com seus planos documentados. No nvel de maturidade 2, o status dos produtos de trabalho e a entrega dos servios esto visveis para a gesto em pontos definidos (por exemplo, nos principais marcos e no trmino das principais tarefas). Os compromissos com as partes interessadas relevantes so estabelecidos e revisados conforme necessrio. Os produtos de trabalho so controlados adequadamente. Os produtos de trabalho e servios satisfazem s descries de processo, aos padres e procedimentos especificados. Nvel de Maturidade 3: Definido No nvel de maturidade 3, os processos so bem caracterizados e entendidos, e so descritos em padres, procedimentos, ferramentas e mtodos. O conjunto de processos-padro da organizao, que a base para o nvel de maturidade 3, estabelecido e melhorado ao longo do tempo. Estes processos-padro so utilizados para estabelecer uniformidade no contexto da organizao. Os projetos estabelecem seus processos definidos ao adaptar o conjunto de processos-padro da organizao de acordo com as diretrizes para adaptao. Uma distino importante entre os nveis de maturidade 2 e 3 o escopo de padres, descries de processo e procedimentos. No nvel de maturidade 2, os padres, as descries de processo e os procedimentos podem ser diferentes em cada instncia especfica do processo (por exemplo, em um projeto especfico). No nvel de maturidade 3, os padres, as descries de processo e os procedimentos para um projeto so adaptados a partir do conjunto de processos-padro da organizao para se ajustar a um projeto especfico ou uma unidade organizacional e, portanto, mais homogneos, exceto por diferenas permitidas pelas diretrizes para adaptao. Outra distino importante que no nvel de maturidade 3, os processos so geralmente descritos de forma mais rigorosa que no nvel de maturidade 2. Um processo definido estabelece claramente o objetivo, as entradas, os critrios de entrada, as atividades, os papis, as medidas, etapas de verificao, sadas e os critrios de sada. No nvel de maturidade 3, os processos so gerenciados mais proativamente, com base na compreenso de como as atividades de processo relacionam-se e nas medidas detalhadas do processo, seus produtos de trabalho e servios. No nvel de maturidade 3, a organizao deve amadurecer mais as reas de processo do nvel de maturidade 2. As prticas genricas associadas meta genrica 3 que no foram tratadas no nvel de maturidade 2 so aplicadas para alcanar o nvel de maturidade 3. Nvel de Maturidade 4: Gerenciado Quantitativamente No nvel de maturidade 4, a organizao e os projetos estabelecem objetivos quantitativos para qualidade e para desempenho de processo, utilizando-os como critrios na gesto de processos. Objetivos quantitativos baseiam-se nas necessidades dos clientes, dos usurios finais, da

organizao e dos responsveis pela implementao de processos. A qualidade e o desempenho de processo so entendidos em termos estatsticos e gerenciados ao longo da vida dos processos [SEI2001]. Para subprocessos selecionados, medidas detalhadas de desempenho de processo so coletadas e analisadas estatisticamente. As medidas da qualidade e do desempenho de processo so incorporadas no repositrio de medies da organizao para apoiar a tomada de deciso baseada em fatos [McGarry 2000]. Identificam-se as causas especiais de variao de processo e, onde apropriado, as fontes dessas causas so corrigidas para prevenir sua recorrncia. Uma distino importante entre os nveis de maturidade 3 e 4 est relacionada previsibilidade do desempenho de processo. No nvel de maturidade 4, o desempenho dos processos controlado por meio de tcnicas estatsticas e outras tcnicas quantitativas, e previsvel quantitativamente. No nvel de maturidade 3, os processos geralmente so previsveis apenas qualitativamente. Nvel de Maturidade 5: Em Otimizao No nvel de maturidade 5, uma organizao melhora continuamente seus processos com base no entendimento quantitativo das causas comuns de variao inerentes ao processo. O nvel de maturidade 5 tem foco na melhoria contnua do desempenho de processo por meio de melhorias incrementais e inovadoras de processo e de tecnologia. Os objetivos quantitativos de melhoria de processo para a organizao so estabelecidos, continuamente revisados para refletir as mudanas nos objetivos estratgicos e so utilizados como critrios na gesto de melhoria de processo. Os efeitos das melhorias de processo implantadas so medidos e avaliados em relao aos objetivos quantitativos de melhoria de processo. Tanto os processos definidos quanto o conjunto de processos-padro da organizao so alvo de atividades de melhoria mensurveis. Uma distino importante entre os nveis de maturidade 4 e 5 o tipo de variao de processo. No nvel de maturidade 4, a organizao preocupa-se em tratar causas especiais de variao de processo e conseguir previsibilidade estatstica dos resultados. Embora os processos possam produzir resultados previsveis, os resultados podem ser insuficientes para satisfazer aos objetivos estabelecidos. No nvel de maturidade 5, a organizao preocupase em tratar as causas comuns de variao de processo e promover mudanas no processo (deslocando a mdia de desempenho de processo ou reduzindo a variao de processo observada) a fim de melhorar o desempenho de processo e satisfazer aos objetivos quantitativos de melhoria de processo estabelecidos. ### Engenharia de software MPS.BR Uma das metas do MPS.BR definir e aprimorar um modelo de melhoria e avaliao de processo de software, visando preferencialmente as micro, pequenas e mdias empresas, de forma a atender as suas necessidades de negcio e ser reconhecido nacional e internacionalmente como um modelo aplicvel indstria de software. O MPS.BR estabelece um modelo de processos de software e um processo e um mtodo de avaliao de processos que d sustentao e garante que o MPS.BR est sendo

empregado de forma coerente com as suas definies. O MPS.BR estabelece tambm um modelo de negcio para apoiar a sua adoo pelas empresas brasileiras desenvolvedoras de software. A capacidade do processo no MPS possui nove (9) atributos de processos (AP) que so: AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1,AP 4.2, AP 5.1 e AP 5.2. AP 1.1 O processo executado Este atributo uma medida do quanto o processo atinge o seu propsito. Resultado esperado: RAP 1. O processo atinge seus resultados definidos. AP 2.1 O processo gerenciado Este atributo uma medida do quanto a execuo do processo gerenciada. Resultados esperados: RAP 2. Existe uma poltica organizacional estabelecida e mantida para o processo; RAP 3. A execuo do processo planejada; RAP 4 (Para o Nvel G). A execuo do processo monitorada e ajustes so realizados para atender aos planos; RAP 4 (A partir do Nvel F). Medidas so planejadas e coletadas para monitorao da execuo do processo; RAP 5. Os recursos necessrios para a execuo do processo so identificados e disponibilizados; RAP 6. As pessoas que executam o processo so competentes em termos de formao, treinamento e experincia; RAP 7. A comunicao entre as partes interessadas no processo gerenciada de forma a garantir o seu envolvimento no projeto; RAP 8. Mtodos adequados para monitorar a eficcia e adequao do processo so determinados. RAP 9 (A partir do Nvel F). A aderncia dos processos executados s descries de processo, padres e procedimentos avaliada objetivamente e so tratadas as no-conformidades. AP 2.2 Os produtos de trabalho do processo so gerenciados Este atributo uma medida do quanto os produtos de trabalho produzidos pelo processo so gerenciados apropriadamente. Resultado esperado: RAP 10. Requisitos para documentao e controle dos produtos de trabalho so estabelecidos; RAP 11. Os produtos de trabalho so documentados e colocados em nveis apropriados de controle; RAP 12. Os produtos de trabalho so avaliados objetivamente com relao aos padres, procedimentos e requisitos aplicveis e so tratadas as noconformidades. AP 3.1. O processo definido Este atributo uma medida do quanto um processo padro mantido para apoiar a implementao do processo definido. Resultados esperados: RAP 13. Um processo padro definido, incluindo diretrizes para sua adaptao para o processo definido;

RAP 14. A seqncia e interao do processo padro com outros processos so determinadas. AP 3.2 O processo est implementado Este atributo uma medida do quanto o processo padro efetivamente implementado como um processo definido para atingir seus resultados. Resultado esperado: RAP 15. Dados apropriados so coletados e analisados, constituindo uma base para o entendimento do comportamento do processo, para demonstrar a adequao e a eficcia do processo, e avaliar onde pode ser feita a melhoria contnua do processo. AP 4.1 O processo medido Este atributo uma medida do quanto os resultados de medio so usados para assegurar que o desempenho do processo apia o alcance dos objetivos de desempenho relevantes como apoio aos objetivos de negcio definidos. Resultados esperados: RAP 16. As necessidades de informao requeridas para apoiar objetivos de negcio relevantes da organizao e dos projetos so identificadas; RAP 17. A partir do conjunto de processos padro da organizao e das necessidades de informao so selecionados os processos e/ou elementos do processo que sero objeto de anlise de desempenho; RAP 18. Objetivos de medio do processo e/ou sub-processo so derivados das necessidades de informao; RAP 19. Objetivos quantitativos de qualidade e de desempenho dos processos e/ou sub-processos so derivados das necessidades de informao; RAP 20. Medidas e a freqncia de realizao das medies so identificadas e definidas de acordo com os objetivos de medio do processo/sub-processo e os objetivos quantitativos de qualidade e de desempenho do processo; RAP 21. Resultados das medies so coletados, analisados e reportados para monitorar o atendimento dos objetivos quantitativos de qualidade e de desempenho do processo/sub-processo; RAP 22. Resultados de medio so utilizados para caracterizar o desempenho do processo/sub-processo. AP 4.2 O processo controlado Este atributo uma medida do quanto o processo controlado estatisticamente para produzir um processo estvel, capaz e previsvel dentro de limites estabelecidos. Resultados esperados: RAP 23. Tcnicas de anlise e de controle de desempenho so identificadas e aplicadas quando necessrio; RAP 24. Limites de controle de variao so estabelecidos para o desempenho normal do processo; RAP 25. Dados de medio so analisados com relao s causas especiais de variao; RAP 26. Aes corretivas so realizadas para tratar causas especiais de variao; RAP 27. Limites de controle so redefinidos, quando necessrio, seguindo as aes corretivas. RAP 28. Modelos de desempenho do processo so estabelecidos e mantidos.

AP 5.1 O processo objeto de inovaes Este atributo uma medida do quanto as mudanas no processo so identificadas a partir da anlise de causas comuns de variao do desempenho e da investigao de enfoques inovadores para a definio e implementao do processo. Resultados esperados: RAP 29. Objetivos de melhoria do processo so definidos de forma a apoiar os objetivos de negcio relevantes; RAP 30. Dados adequados so analisados para identificar causas comuns de variao no desempenho do processo; RAP 31. Dados adequados so analisados para identificar oportunidades para aplicar melhores prticas e inovaes; RAP 32. Oportunidades de melhoria derivadas de novas tecnologias e conceitos de processo so identificados; RAP 33. Uma estratgia de implementao estabelecida para alcanar os objetivos de melhoria do processo. AP 5.2 O processo otimizado continuamente Este atributo uma medida do quanto as mudanas na definio, gerncia e desempenho do processo tm impacto efetivo para o alcance dos objetivos relevantes de melhoria do processo. Resultados esperados: RAP 34. O impacto de todas as mudanas propostas avaliado com relao aos objetivos do processo definido e do processo padro; RAP 35. A implementao de todas as mudanas acordadas gerenciada para assegurar que qualquer alterao no desempenho do processo seja entendida e sejam tomadas as aes pertinentes; RAP 36. A efetividade das mudanas, levando em conta o seu desempenho resultante, avaliada com relao aos requisitos do produto e objetivos do processo, para determinar se os resultados so devidos a causas comuns ou a causas especiais. Nvel G Gerncia de Requisitos GRE Gerncia de Projetos GPR AP 1.1 e AP 2.1 Nvel F Medio MED Garantia da Qualidade GQA Gerncia de Configurao GCO Aquisio AQU AP 2.2 Nvel E Gerncia de Projetos GPR (evoluo) Gerncia de Reutilizao GRU Gerncia de Recursos Humanos GRH Definio do Processo Organizacional DFP Avaliao e Melhoria do Processo Organizacional AMP AP 3.1 e AP 3.2 Nvel D

Verificao VER Validao VAL Projeto e Construo do Produto PCP Integrao do Produto ITP Desenvolvimento de Requisitos DRE Nvel C Gerncia de Riscos GRI Desenvolvimento para Reutilizao DRU Anlise de Deciso e Resoluo ADR Gerncia de Reutilizao GRU (evoluo) Nvel B Gerncia de Projetos GPR (evoluo) AP 4.1 e AP 4.2 Nvel A Anlise de Causas de Problemas e Resoluo ACP AP 5.1 e AP 5.2 Gerncia de Projetos GPR O propsito do processo Gerncia de Projetos estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informaes sobre o andamento do projeto que permitam a realizao de correes quando houver desvios significativos no desempenho do projeto. O propsito deste processo evolui medida que a organizao cresce em maturidade. Assim, a partir do nvel E, alguns resultados evoluem e outros so incorporados, de forma que a gerncia de projetos passe a ser realizada com base no processo definido para o projeto e nos planos integrados. Gerncia de Configurao GCO O propsito do processo Gerncia de Configurao estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibiliz-los a todos os envolvidos. Avaliao e Melhoria do Processo Organizacional AMP O propsito do processo Avaliao e Melhoria do Processo Organizacional determinar o quanto os processos padro da organizao contribuem para alcanar os objetivos de negcio da organizao e para apoiar a organizao a planejar, realizar e implantar melhorias contnuas nos processos com base no entendimento de seus pontos fortes e fracos. Definio do Processo Organizacional DFP O propsito do processo Definio do Processo Organizacional estabelecer e manter um conjunto de ativos de processo organizacional e padres do ambiente de trabalho usveis e aplicveis s necessidades de negcio da organizao. Gerncia de Reutilizao GRU O propsito do processo Gerncia de Reutilizao gerenciar o ciclo de vida dos ativos reutilizveis.

Desenvolvimento para Reutilizao DRU O propsito do processo Desenvolvimento para Reutilizao identificar oportunidades de reutilizao sistemtica na organizao e, se possvel, estabelecer um programa de reutilizao para desenvolver ativos a partir de engenharia de domnios de aplicao. Nveis de maturidade: A (Em Otimizao), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado), G (Parcialmente Gerenciado). ### Banco de dados Arquitetura de banco de dados (Padro ANSI) Abordagens Baseada em componentes - Os componentes do sistema so definidos junto com as relaes entre os componentes. - Bom para projeto e implementao de sistemas. Baseada em funes - Classes de usurios so identificadas junto com a funcionalidade que o sistema fornecer a cada classe. - Os objetivos so identificados. Mas como alcanar? Baseada em dados - Identifica as diferentes formas de descrever dados e especifica as unidades funcionais que iro definir e usar os dados de acordo com as formas. 1) Propsito da Arquitetura O American National Standards Institute (ANSI) atravs do Standards Planning and Requirements Committee (SPARC) estabeleceu um padro para o desenvolvimento de tecnologias de Banco de Dados (BD), definindo uma arquitetura de 3 nveis independentes: Interno Conceitual Externo

Essa arquitetura deveria atender a uma srie de requisitos bsicos: All users should be able to access same data. A users view is immune to changes made in other views. Users should not need to know physical database storage details. DBA should be able to change database storage structures without affecting the users views. Internal structure of database should be unaffected by changes to physical aspects of storage. DBA should be able to change conceptual structure of database without affecting all users.

2) Nveis da Arquitetura External Level o Refere-se independncia programa/dados o Como cada utilizador no necessita de trabalhar com a totalidade do esquema conceptual, o SGBD permite definir para cada um, uma view, que determina a janela de dados com que necessita de trabalhar o Este conceito aplica-se tambm s aplicaes

Users view of the database Describes that part of database that is relevant to a particular user. Conceptual Level o tambm designado por esquema conceitual o Refere-se ao modelo conceitual dos dados, independente dos utilizadores e das aplicaes o Constitui a estrutura do Banco de Dados o o nvel que permite esconder os detalhes do armazenamento fsico dos dados, do nvel de aplicao o Community view of the database. o Describes what data is stored in database and relationships among the data. Internal Level o Refere-se ao armazenamento fsico dos dados, organizao de ficheiros, mtodos de acesso e organizao das estruturas fsicas o Deve ser organizado para permitir um melhor desempenho nas operaes que previsivelmente se realizem com maior frequncia o Physical representation of the database on the computer o Describes how the data is stored in the database
o o

### Banco de dados Commit em duas fases Commit em duas fases refere-se a uma transao que pode utilizar dois ou mais bancos de dados (multi-database), que podem estar localizados em servidores diferentes. Durante uma transao em bancos com essa caracterstica garante-se que o Commit seja realizado em todos os bancos participantes ou em nenhum, ou seja, ou grava tudo ou no grava nada. Por exemplo, se sua aplicao atualiza dados em 2 banco de dados e voc faz um commit, o recurso de commit em duas fases previne situaes como a de um dos bancos ficar indisponvel e suas mudanas serem atualizadas somente em um dos bancos envolvidos. Se qualquer um dos bancos em uma transao multi-database falhar no commit (realizando assim o roll back), a transao marcada com o status

de "limbo" em todos os bancos. Mais tarde voc pode utilizar o utilitrio de linha de comando GFIX ou o Interbase Server Manager para Windows para resolver a questo de transaes em limbo. ### Banco de dados Bloqueios Bloqueio Granular Bloqueio multigranular permite a uma transao bloquear diferentes tipos de recursos. Para minimizar o custo de bloqueio, o Mecanismo de Banco de Dados bloqueia recursos automaticamente, em um nvel apropriado para a tarefa. Bloquear em uma granularidade menor (por exemplo, linhas) aumenta a simultaneidade, mas tem uma sobrecarga maior, devido exigncia de mais bloqueios mantidos, se muitas linhas forem bloqueadas. Bloqueando em uma granularidade maior, como tabelas, dispendioso em termos de simultaneidade, porque bloquear a tabela inteira restringe o acesso a qualquer parte da tabela por outras transaes. No entanto, tem uma sobrecarga menor, porque menos bloqueios esto sendo mantidos. O Mecanismo de Banco de Dados precisa, freqentemente, adquirir bloqueios em vrios nveis de granularidade para proteger totalmente um recurso. Esse grupo de bloqueios em vrios nveis de granularidade chamado de uma hierarquia de bloqueio. Por exemplo, para proteger inteiramente a leitura de um ndice, uma instncia do Mecanismo de Banco de Dados pode ter que adquirir bloqueios compartilhados em linhas e tentar bloqueios compartilhados nas pginas e na tabela. Exclusivo Bloqueios exclusivos (X) evitam o acesso a um recurso atravs de transaes simultneas. Com um bloqueio exclusivo (X), nenhuma outra transao pode modificar os dados; operaes podem ser realizadas somente com o uso da dica NOLOCK ou nvel de isolamento no confirmado. Instrues de modificao de dados como INSERT, UPDATE e DELETE combinam operaes de modificao e de leitura. Primeiramente, a instruo executa as operaes de leitura para adquirir dados, antes de executar as operaes de modificao necessrias. Assim, as instrues de modificao de dados normalmente solicitam bloqueios compartilhados e bloqueios exclusivos. Por exemplo, uma instruo UPDATE poderia modificar linhas em uma tabela com base em uma juno com outra tabela. Nesse caso, a instruo UPDATE solicita bloqueios compartilhados nas linhas lidas na juno de tabela, alm de solicitar bloqueios exclusivos nas linhas atualizadas. Compartilhado Bloqueios compartilhados (S) permitem que transaes simultneas leiam um recurso (SELECT) sob controle de simultaneidade pessimista. Nenhuma outra transao pode modificar os dados enquanto bloqueios compartilhados (S) existirem no recurso. Bloqueios compartilhados (S) em um recurso so liberados quando a operao de leitura termina, exceto se o nvel de isolamento da transao for configurado para leitura repetida ou maior ou uma dica de bloqueio for usada para reter os bloqueios compartilhados (S) pela durao da transao.

Intencional O Mecanismo de Banco de Dados usa bloqueios intencionais para proteger a colocao de um bloqueio compartilhado (S) ou bloqueio exclusivo (X) em um recurso inferior na hierarquia de bloqueio. Bloqueios intencionais so assim chamados porque eles so adquiridos antes de um bloqueio em um nvel inferior, e dessa forma, sinalizam a inteno de colocar bloqueios em um nvel inferior. Os bloqueios intencionais tm duas finalidades: Para evitar que outras transaes modifiquem recursos de alto nvel de uma forma que inviabilizaria o bloqueio em um nvel inferior. Para melhorar a eficincia do Mecanismo de Banco de Dados, detectando conflitos de bloqueio em um nvel mais alto de granularidade. Por exemplo, um bloqueio de tentativa compartilhado solicitado no nvel de tabela antes que os bloqueios compartilhados (S) sejam solicitados em pginas ou linhas dentro dessa tabela. Configurar um bloqueio intencional no nvel de tabela evita que outra transao subseqentemente adquira um bloqueio exclusivo (X) em uma tabela contendo essa pgina. Bloqueios intencionais aumentam o desempenho porque o Mecanismo de Banco de Dados examina os bloqueios intencionais somente no nvel de tabela para determinar se a transao pode adquirir um bloqueio de forma segura nessa tabela. Isso remove a necessidade de examinar cada bloqueio de linha ou pgina na tabela para determinar se a transao pode bloquear a tabela inteira. ### Banco de dados Controles de concorrncia A teoria do controle de simultaneidade tem duas classificaes para os mtodos de instituio do controle de simultaneidade: Controle de simultaneidade pessimista Um sistema de bloqueios impede que os usurios modifiquem os dados de uma forma que afete outros usurios. Depois que um usurio executa uma ao que aplica um bloqueio, outros usurios no podem executar aes que estariam em conflito com o bloqueio at o proprietrio liberar o bloqueio. Isso chamado de controle pessimista porque principalmente usado em ambientes em que existe conteno elevada dos dados, e que o custo da proteo dos dados com bloqueios inferior ao custo de reverso de transaes, caso ocorram conflitos de simultaneidade. Controle de simultaneidade otimista No controle de simultaneidade otimista, os usurios no bloqueiam os dados quando os lem. Quando um usurio atualiza os dados, o sistema verifica se outro usurio alterou os dados depois de lidos. Se outro usurio tiver atualizado os dados, um erro ativado. Normalmente, o usurio que recebe o erro reverte a transao e inicia novamente. Isso chamado de controle otimista porque usado principalmente em ambientes em que existe conteno reduzida dos dados, e que o custo de reverso ocasional de uma transao inferior ao custo de bloqueio dos dados quando os mesmos so lidos.

### Banco de dados Isolamento de transao As transaes especificam um nvel de isolamento que define o grau em que uma transao deve ser isolada contra modificaes de recursos ou de dados feitas por outras transaes. Os nveis de isolamento so descritos em termos de quais efeitos colaterais de simultaneidade so permitidos, como leituras sujas ou leituras fantasma. Nveis de isolamento da transao controlam: Se so feitos bloqueios quando os dados so lidos, e que tipo de bloqueio solicitado. Por quanto tempo os bloqueios de leitura so mantidos. Se uma linha de referncia de operao de leitura foi modificada por outra transao: o Bloqueia at que o bloqueio exclusivo na linha seja liberado. o Recupera a verso confirmada da linha existente no momento em que a instruo ou transao foi iniciada. o L a modificao de dados no confirmados. Escolhendo um nvel de isolamento da transao no afeta os bloqueios obtidos para proteger as modificaes de dados. Uma transao sempre obtm um bloqueio exclusivo em quaisquer dados que modifica e mantm tal bloqueio at que a transao seja concluda, sem considerar o conjunto de nveis de isolamento para a transao em questo. Para operaes de leitura, nveis de isolamento da transao definem principalmente o nvel de proteo dos efeitos das modificaes feitas por outras transaes. Um nvel de isolamento inferior aumenta a capacidade de muitos usurios acessarem dados ao mesmo tempo, mas aumenta o nmero de efeitos de simultaneidade (como leituras sujas ou atualizaes perdidas) que os usurios podem encontrar. Inversamente, um nvel de isolamento mais alto reduz os tipos de efeito de simultaneidade que os usurios podem encontrar, mas requer mais recursos do sistema e aumenta as chances de uma transao bloquear outra. Escolher o nvel de isolamento apropriado depende de equilibrar os requisitos de integridade de dados do aplicativo em relao sobrecarga de cada nvel de isolamento. O nvel de isolamento mais alto, serializvel, garante que uma transao recuperar exatamente os mesmos dados toda vez que repetir uma operao de leitura, mas faz isto executando um nvel de bloqueio que provavelmente causar impacto em outros usurios em sistemas multiusurios. O mais baixo nvel de isolamento, leitura de dados no confirmados, pode recuperar dados que foram modificados, mas no foram confirmados por outras transaes. Todos os efeitos colaterais de simultaneidade podem acontecer em leitura no confirmada, mas no h nenhum bloqueio de leitura ou controle de verso, assim a sobrecarga minimizada. O padro ISO define os seguintes nveis de isolamento:

Leitura no confirmada (o mais baixo nvel onde transaes s esto isoladas o bastante para assegurar que dados corruptos fisicamente no so sejam lidos) Leitura confirmada (Mecanismo de Banco de Dados nvel padro) Leitura repetida

Serializvel (o nvel mais alto, onde completamente isoladas uma da outra) Leitura suja Sim No No No No Leitura no repetvel Sim Sim No No No

as

transaes

esto

Nvel de isolamento Leitura no confirmada Leitura confirmada Leitura repetvel Instantneo Serializvel

Fantasma Sim Sim Sim No No

Dependncia no confirmada (leitura suja) A dependncia no confirmada acontece quando uma segunda transao seleciona uma linha que est sendo atualizada por outra transao. A segunda transao est lendo dados que no foram confirmados ainda e podem ser alterados pela transao que atualiza a linha. Por exemplo, um editor est fazendo mudanas em um documento eletrnico. Durante as mudanas, um segundo editor pega uma cpia do documento que inclui todas as mudanas feitas at o momento e distribui o documento para a audincia destinada. O primeiro editor decide ento que as mudanas feitas at o momento esto erradas, remove as edies e salva o documento. O documento distribudo contm edies que j no existem e que deveriam ser tratadas como se nunca tivessem existido. Esse problema poderia ser evitado se ningum pudesse ler o documento alterado at que o primeiro editor salvasse a verso final com as modificaes e confirmasse a transao. Anlise inconsistente (leitura no-repetvel) Ocorre anlise inconsistente quando uma segunda transao acessa a mesma linha vrias vezes e l dados diferentes a cada vez. A anlise inconsistente semelhante dependncia no confirmada, no sentido em que outra transao est alterando os dados que uma segunda transao est lendo. No entanto, na anlise inconsistente os dados lidos pela segunda transao foram confirmados pela transao que fez as alteraes. Alm disso, a anlise inconsistente envolve leituras mltiplas (duas ou mais) da mesma fila, e a cada vez as informaes so alterada por outra transao; da a denominao leitura no-repetvel. Por exemplo, um editor l o mesmo documento duas vezes, mas entre cada leitura o escritor reescreve o documento. Quando o editor l o documento pela segunda vez, este j foi alterado. A leitura original no era repetvel. Esse problema poderia ser evitado se o escritor no pudesse alterar o documento at que o editor tivesse terminado de l-lo pela ltima vez. Leituras fantasma Leituras fantasma acontecem quando uma ao de insero ou excluso executada em uma linha que pertence a um intervalo de linhas que esto sendo lidas por uma transao. A primeira leitura do intervalo de linhas da transao mostra uma linha que j no existe mais na segunda leitura ou leitura posterior, como resultado de uma excluso por uma transao

diferente. De maneira semelhante, a segunda leitura ou leitura posterior da transao mostra uma linha que no existia na leitura original, como resultado de uma insero por uma transao diferente. Por exemplo, um editor faz alteraes em um documento enviado por um escritor, mas quando as alteraes so incorporadas na cpia mestra do documento pelo departamento de produo, descobre-se que material novo no editado foi acrescentado ao documento pelo autor. De modo semelhante situao de leitura no-repetvel, esse problema poderia ser evitado se ningum pudesse acrescentar material novo ao documento at o editor e o departamento de produo terminarem de trabalhar com o documento original. ### Banco de dados Data warehouse Agregados Um agregado um registro da tabela de fatos que representa o resumo dos registros de nvel bsico desta tabela, pois reduz o detalhamento das dimenses no importantes numa anlise (resumindo estes dados), detalhando apenas as dimenses necessrias a uma determinada restrio. A utilizao de agregados faz com que as consultas sejam mais rpidas. Porm, o grande aumento do espao necessrio para seu armazenamento e o efeito "disperso" causador de um excesso de registros de agregados so dois pontos negativos desta utilizao. Modos de utilizao de agregados Pr-Agregao A pr-agregao a mais utilizada em projetos de data warehouse. Segundo [MCG98], se a tabela de fatos relativamente pequena e a computao e estrutura complexas, ento a pr-agregao uma alternativa vivel. O processo de pr-agregao inicia com a determinao de quais dimenses devem ser agregadas (se parte de uma dimenso deve ser agregada, ento toda a dimenso deve ser agregada). Uma maneira prtica de medir os benefcios de uma pr-agregao para uma determinada dimenso determinar o fator de compresso para cada nvel da dimenso. Este o nmero de linhas produzidas por uma agregao divididas pelo nmero de linhas recuperadas. Este clculo deve ser feito para todas as dimenses, usando-se dados reais, durante um longo perodo. Uma vez que se tenham estes resultados, podem-se avaliar quais dimenses devem ser pr-agregadas [MCG98], usando o seguinte critrio: dimenses com menores fatores de compresso so melhores para serem agregadas. Agregao Dinmica Para tabelas de fatos muito grandes, porm simples em termos de estrutura e clculo, encontram-se casos em que a agregao dinmica prefervel [MCG98]. A grande vantagem da agregao dinmica economia de espao de armazenamento. Porm, fato que os meios de armazenamento vm sendo barateados continuamente nos ltimos anos.

### Banco de dados Data warehouse ETL Fase extremamente critica de um Data Warehouse, pois envolve a movimentao dos dados de origem nos sistemas transacionais e/ou sistemas legados, obedecendo as regras de negcio. Ela se d basicamente em trs passos: extrao (E), transformao (T) e carga (L Loader) dos dados. Esses so os mais trabalhosos, complexos e tambm muito detalhados, embora tenhamos vrias ferramentas (falaremos mais abaixo) que nos auxiliam na execuo desse trabalho. O primeiro passo a ser tomado no processo de ETL: a definio das fontes de dados e fazer a extrao deles. As origens deles podem ser vrias e tambm em diferentes formatos, onde poderemos encontrar desde os sistemas transacionais das empresas at planilhas, flat files (arquivos textos), dados do Mainframe, etc. O segundo passo: transformar e limpar esses dados. Mas, o que, afinal de contas, isso? muito comum, na obteno dos dados que, no mais das vezes, so antigos e desconhecidos, encontrarmos muito lixo e inconsistncias. Por exemplo. Quando um vendedor de linhas telefnicas for executar uma venda, ou inscrio, ele est preocupado em vender, e no na qualidade dos dados que est inserindo na base, ento se por acaso o cliente no tiver o nmero do CPF a mo, ele cadastra um nmero qualquer, desde que o sistema aceite, um dos mais utilizados o 999999999-99. Agora imagine um diretor de uma companhia telefnica consultar o seu Data Warehouse (DW) para ver quais so os seus maiores clientes, e aparecer em primeiro lugar o cliente que tem o CPF 999999999-99? Seria no mnimo estranho. Por isso, nessa fase do DW, fazemos a limpeza desses dados, para haver compatibilidade entre eles. Alm da limpeza, temos de fazer na maioria das vezes uma transformao, pois os dados provm de vrios sistemas, e por isso, geralmente uma mesma informao tem diferentes formatos, por exemplo: Em alguns sistemas a informao sobre o sexo do cliente pode estar armazenada no seguinte formato: M para Masculino e F para Feminino, porm em algum outro sistema est guardado como H para Masculino e M para Feminino, em outro ainda, podemos encontrar 1 para Masculino e 2 para Feminino, e assim sucessivamente. Quando levamos esses dados para o DW, deve-se ter uma padronizao deles, ou seja, quando o usurio for consultar o DW, ele no pode ver informaes iguais em formatos diferentes. Assim sendo, quando fazemos o processo de ETL, transformamos esses dados e deixamos num formato uniforme sugerido pelo prprio usurio, como por exemplo M para Masculino e F para Feminino. No DW, teremos somente M e F, fato esse que facilitar a anlise dos dados que sero recuperados pela ferramenta OLAP. Alm desses exemplos acima, ns podemos integrar todas as fontes de dados num nico banco. Com isso no existiro mais ilhas de dados, mas sim teremos informaes ricas e totalmente integradas.

Como o volume de dados muito grande, h muitos casos que no temos condies de processar as extraes e transformaes na janela de tempo em que o DW no est sendo usado, ento temos de fazer uso do que chamamos de staging rea para conseguirmos executar os processos com sucesso. Segundo Kimball, a Staging Area parte do Data Warehouse responsvel por receber a extrao, transformao e carga (ETL) das informaes dos sistemas transacionais legados, para posterior gerao dos Data Marts de destino, com as caractersticas: A Staging Area considerada rea fora do acesso dos usurios. A Staging Area no deve suportar queries dos Usurios. Ela pode ser composta por flat files (arquivos textos) ou tabelas de banco de dados na terceira forma normal (normalizadas). A seguir so apresentados alguns dos fatores que devem ser analisados antes de comear a fase de extrao dos dados: A extrao de dados do ambiente operacional para o ambiente de data warehouse demanda uma mudana na tecnologia. Os dados so transferidos de bancos de dados hierrquicos, tal como o adabas, ou de bases do grande porte, como o DB2, para uma nova estrutura de SGBD relacional para Data Warehouse, tal como o DB2 UDB, Oracle, Teradata e etc; A seleo de dados do ambiente operacional pode ser muito complexa, pois muitas vezes necessrio selecionar vrios campos de um sistema transacional para compor um nico campo no data warehouse; Outro fator que deve ser levado em conta que dificilmente h o modelo de dados dos sistemas antigos, e se existem no esto documentados; Os dados so reformatados. Por exemplo: um campo data do sistema operacional do tipo DD/MM/AAAA pode ser passado para o outro sistema do tipo ano e ms como AAAA/MM; Quando h vrios arquivos de entrada, a escolha das chaves deve ser feita antes que os arquivos sejam intercalados. Isso significa que se diferentes estruturas de chaves so usadas nos diferentes arquivos de entrada, ento se deve optar por apenas uma dessas estruturas;

Os arquivos devem ser gerados obedecendo mesma ordem das colunas estipuladas no ambiente de data warehouse; Pode haver vrios resultados. Dados podem ser produzidos em diferentes nveis de resumo pelo mesmo programa de gerao das cargas; Valores default devem ser fornecidos. s vezes pode existir um campo no data warehouse que no possui fonte de dados, ento a soluo definir um valor padro para estes campos. O data warehouse espelha as informaes histricas necessrias, enquanto o ambiente operacional focaliza as informaes pontuais correntes. A parte de carga dos dados tambm possui uma enorme complexidade, e os seguintes fatores devem ser levados em conta: A parte de Integridade dos dados. No momento da carga necessrio checar os campos que so chaves estrangeiras com suas respectivas tabelas para certificar-se de que os dados existentes na tabela da chave estrangeira esto de acordo com a tabela da chave primria; Se a tabela deve receber uma carga incremental ou a carga por cima dos dados. A carga incremental normalmente feita para tabelas fatos e a carga por cima dos dados feita em tabelas dimenses onde o analista ter que deletar os dados existentes e inclu-los novamente. Mas em alguns casos poder acontecer que as tabelas de dimenses tem de manter o histrico, ento o mesmo dever ser mantido (slowly change dimension); Apesar de existirem ferramentas de ETL como o DTS (Data Transformation Service), Data Stage, ETI, Business Objects Data Integration, Sunopsis atual Oracle Data Integrator, Oracle Warehouse Builder e o Informtica, ainda tem-se a necessidade de criar rotinas de carga para atender determinadas situaes que podero ocorrer. Pode ser em shell script, SQL puro ou em C, quando precisa de performance.

### Arquitetura de computadores Memria cache - comumente encontrada em processadores RISC. - No implementada pelo sistema operacional com suporte do hardware (essa a memria virtual). - Os dados nela armazenados so cpias de parte da memria principal. - Pode ser inserida diretamente no chip do processador. ### Sistemas operacionais Objetivos dos algoritmos de escalonamento de processos utilizados em sistemas voltados para o processamento em lote - Manter a CPU ocupada o tempo todo. - Manter os dispositivos de E/S ocupados o mximo de tempo possvel. - Maximizar o nmero de jobs processados por unidade de tempo. - Minimizar o tempo entre a submisso e o trmino de um job. Atender s requisies dos usurios o mais rpido possvel. <= um objetivo de sistemas online (ou interativos). ### Engenharia de software Mtrica de controle de software

Relacionada ao processo de software. Exemplos: - Tempo mdio para reparar defeito de software; - Tempo mdio para rastrear um mdulo. Mtrica de predio de software Relacionada a produtos de software. Exemplos: - Complexidade de um mdulo; - Nmero de mensagens de erro; - Nmero de atributos e operaes com objetos em um projeto. ### Engenharia de software Fator de estimativa de qualidade (EQF, estimate quality factor) definido como a rea sob a curva do valor atual pela rea entre o valor estimado e o atual. Isto o inverso da percentagem de erro ou o erro mdio relativo. ### Padres de arquitetura de aplicaes empresariais Padres de lgica de domnio Script de transao Most business applications can be thought of as a series of transactions. A transaction may view some information as organized in a particular way, another will make changes to it. Each interaction between a client system and a server system contains a certain amount of logic. In some cases this can be as simple as displaying information in the database. In others it may involve many steps of validations and calculations. A Transaction Script organizes all this logic primarily as a single procedure, making calls directly to the database or through a thin database wrapper. Each transaction will have its own Transaction Script, although common subtasks can be broken into subprocedures. Modelo de domnio At its worst business logic can be very complex. Rules and logic describe many different cases and slants of behavior, and it's this complexity that objects were designed to work with. A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual, whether as large as a corporation or as small as a single line on an order form. Mdulo de tabela A single instance that handles the business logic for all rows in a database table or view. One of the key messages of object orientation is bundling the data with the behavior that uses it. The traditional object-oriented approach is based on objects with identity, along the lines of Domain Model (116). Thus, if we have an Employee class, any instance of it corresponds to a particular

employee. This scheme works well because once we have a reference to an employee, we can execute operations, follow relationships, and gather data on him. One of the problems with Domain Model (116) is the interface with relational databases. In many ways this approach treats the relational database like a crazy aunt who's shut up in an attic and whom nobody wants to talk about. As a result you often need considerable programmatic gymnastics to pull data in and out of the database, transforming between two different representations of the data. A Table Module organizes domain logic with one class per table in the database, and a single instance of a class contains the various procedures that will act on the data. The primary distinction with Domain Model (116) is that, if you have many orders, a Domain Model (116) will have one order object per order while a Table Module will have one object to handle all orders. Camada de servio Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation. Enterprise applications typically require different kinds of interfaces to the data they store and the logic they implement: data loaders, user interfaces, integration gateways, and others. Despite their different purposes, these interfaces often need common interactions with the application to access and manipulate its data and invoke its business logic. The interactions may be complex, involving transactions across multiple resources and the coordination of several responses to an action. Encoding the logic of the interactions separately in each interface causes a lot of duplication. A Service Layer defines an application's boundary [Cockburn PloP] and its set of available operations from the perspective of interfacing client layers. It encapsulates the application's business logic, controlling transactions and coordinating responses in the implementation of its operations. ### Engenharia de software Tipos de escritrios de gerncia de projeto - Projeto Autnomo Escritrio de projeto separado das operaes da empresa; destinado ao gerenciamento de um projeto ou programa especfico. - Escritrio de Suporte a Projetos escritrio de projeto de esfera departamental para apoio a diversos projetos simultneos; fornece suporte, ferramentas e servios de planejamento, controle de prazos, custos, qualidade, dentre outros; ele fornece recursos tcnicos, metodologia de gerenciamento de projetos, metodologia de gesto do conhecimento, interfaces organizacionais. - Centro de Excelncia No assume responsabilidade pelo sucesso do projeto. Sponsorship: apoio de cima; Liderana: conhecimento e capacidade de gerenciar stakeholders;

influenciar

Valor agregado: demonstrar benefcio de se adotar as prticas de GP propostas; Desenvolvimento profissional: desenvolver GPs, lderes e membros de equipes competentes. - Escritrio de Projetos Corporativo escritrio de projetos de esfera corporativa, atuando no gerenciamento estratgico de todos os projetos da organizao. Suas principais funes so: Planejamento estratgico dos projetos; Gerenciamento de projetos interdepartamentais; Gesto do conhecimento empresarial. ### Engenharia de software Gesto de projeto Os 10 mandamentos do gerenciamento de projetos I Estreitars teus escopos. Nada pior do que um projeto interminvel. Ele pode sugar todos os recursos e esgotar at mesmo a equipe mais motivada. Para manter os projetos firmes e orientados, concentre seus maiores esforos em projetos menores, que tenham entregas (deliverables) alcanveis e que possam cumprir seus prazos. Em longo prazo, uma srie de vitrias pequenas tem mais impacto sobre a organizao do que uma gigantesca orquestra sinfnica que nunca chega a tocar. II No tolerars equipes inchadas. Uma boa maneira de comear com o p direito garantir que a equipe do projeto ter o tamanho certo. Equipes maiores so mais difceis de motivar e administrar, e as personalidades podem ficar no meio do caminho, atrapalhando o trabalho. No existe um tamanho ideal para a equipe, mas uma boa regra emprica ter uma pessoa para cada papel e um papel para cada pessoa. Se alguns integrantes tiverem que desempenhar mais de um papel, tudo bem se voc for errar o dimensionamento, erre a favor de uma equipe menor. III Exigirs dedicao de todas as reas envolvidas. Se a rea de TI aceitar um prazo apertado, mas parte dos documentos de projeto precisar ser aprovado pelas demais reas da organizao, e elas no estiverem comprometidas da mesma forma, o projeto acaba virando uma gincana. Se as reas de negcio aceitam um prazo apertado, mas dependem de um aplicativo a ser desenvolvido pela rea de TI, que no est comprometida da mesma forma, o projeto tambm acaba virando uma gincana. O gerente de projeto deve se posicionar de forma a que todas as reas diretamente envolvidas no sucesso do projeto estejam comprometidas, e disponveis na medida da necessidade, desde o princpio. IV Estabelecers um comit para analisar o andamento. O comit de acompanhamento, qualquer que seja seu ttulo oficial, o corpo diretivo do projeto. Ao mesmo tempo em que lida com questes relacionadas s polticas e estratgias da empresa, ele pode e deve remover

as lombadas e obstculos do caminho do projeto. Um arranjo tpico envolve reunies quinzenais das reas de gerncia intermediria envolvidas no projeto, para analisar seu andamento e verificar como se envolver das formas descritas acima. V No consumirs tua equipe. O burnout, ou esgotamento fsico e mental dos membros da equipe, causado pelo stress e esforo das atividades, no incomum. Fique atento s necessidades das pessoas e evite este efeito que reduz a efetividade da equipe no planeje de forma que o envolvimento das pessoas v exigir sacrifcios incomuns e continuados. Em particular, evite o efeito do envolvimento serial: o popular efeito sempre os mesmos pessoas que se destacam por resolver bem os problemas que recebem, e assim acabam sendo envolvidos em mais projetos do que seria racional, gerando stress para elas, e disputa de recursos para os projetos. VI Buscars apoio externo quando necessrio. Adotar consultores em gerenciamento de projetos uma forma de prevenir o esgotamento. Alm de aumentar as equipes, os especialistas externos muitas vezes podem trazer valiosas novas idias, perspectivas e energias. essencial trazer o profissional certo no momento certo: especialistas nos aspectos tcnicos e de mercado no so a mesma coisa que especialistas em gerenciamento de projetos. Considere as caractersticas do projeto e da equipe antes de definir o tipo de apoio externo necessrio. VII Dars poder s tuas equipes. Equipes de projeto que j estejam se esforando para cumprir seus escopos e prazos no precisam ter preocupaes adicionais com questes formais como o preenchimento de formulrios de registro de atividades para seus departamentos, ou participao em reunies peridicas de seu rgo de origem. Ao invs disso, eles devem ter o poder discricionrio de dedicar-se s atividades essenciais e que agregam valor ao projeto, e a estrutura deve se esforar para adaptar-se a estas condies. Mas importante que os membros da equipe correspondam a esta confiana, saibam claramente o que se espera deles e de que forma devem usar sua iniciativa. VIII Usars ferramentas de gerenciamento de projetos. Tarefas mundanas de gerenciamento de projetos podem ser automatizadas. Procure ferramentas que ofeream acompanhamento do andamento, gerenciamento de tarefas, gerenciamento do fluxo de trabalho e anlise de recursos, e que funcionam em uma plataforma de Intranet que promova o compartilhamento e a comunicao. Mas lembre-se de que usar tecnologias que acrescentem uma camada extra de complexidade a um projeto j desafiador por si pode no ser uma boa idia. IX Reconhecers o sucesso. Todos os participantes do projeto devem ser reconhecidos de forma positiva pelo esforo que praticaram. As recompensas no precisam ser extravagantes. fundamental que a origem real do reconhecimento seja a Presidncia, a direo da filial regional, o principal patrocinador do projeto ou o seu gerente fique clara para todos, e que se manifeste de forma to individual e personalizada quanto possvel. X No tolerars gambiarras.

Polticas slidas de gerenciamento de projetos devem eliminar antecipadamente a tentao de recorrer a alternativas rpidas e rasteiras, que s levam a erros, desperdcio, retrabalho e frustrao. ### Engenharia de software Mtodos geis FDD (Feature driven development) A FDD chama a ateno por algumas caractersticas peculiares: Resultados teis a cada duas semanas ou menos; Blocos bem pequenos de funcionalidade valorizada pelo cliente, chamados "Features"; Planejamento detalhado e guia para medio; Rastreabilidade e relatrios com incrvel preciso; Monitoramento detalhado dentro do projeto, com resumos de alto nvel para clientes e gerentes, tudo em termos de negcio; Fornece uma forma de saber, dentro dos primeiros 10% de um projeto, se o plano e a estimativa so slidos. A FDD uma metodologia muito objetiva. Possui apenas duas fases: Concepo & Planejamento: Pensar um pouco antes de fazer (tipicamente de 1 a 2 semanas) Construo: Fazer de forma iterativa (tipicamente em iteraes de 2 semanas) Os cinco processos so bem definidos e integrados: 1. DMA (Desenvolver um Modelo Abrangente): Anlise Orientada por Objetos 2. CLF (Construir a Lista de Funcionalidades): Decomposio Funcional 3. PPF (Planejar por Funcionalidade): Planejamento Incremental 4. DPF (Detalhar por Funcionalidade): Desenho (Projeto) Orientado por Objetos 5. CPF (Construir por Funcionalidade): Programao e Teste Orientados por Objetos DSDM (Dynamic System Development Method) Dynamic Systems Development Method (DSDM) is a framework based originally around Rapid Application Development (RAD), supported by its continuous user involvement in an iterative development and incremental approach which is responsive to changing requirements, in order to develop a system that meets the business needs on time and on budget. It is one of a number of agile methods for developing software and forms part of the Agile Alliance. There are 9 underlying principles of DSDM consisting of four foundations and five starting-points for the structure of the method. These principles form the cornerstones of development using DSDM.

User involvement is the main key in running an efficient and effective project, where both users and developers share a

workplace, so that the decisions can be made accurately. The project team must be empowered to make decisions that are important to the progress of the project, without waiting for higher-level approval. DSDM focuses on frequent delivery of products, with assumption that to deliver something "good enough" earlier is always better than to deliver everything "perfectly" in the end. By delivering product frequently from an early stage of the project, the product can be tested and reviewed where the test record and review document can be taken into account at the next iteration or phase. The main criterion for acceptance of deliverable in DSDM is on delivering a system that addresses the current business needs. It is not so much directed at delivering a perfect system addressing all possible business needs, but focuses its efforts on critical functionality. Development is iterative and incremental, driven by users feedback to converge on an effective business solution. All changes during the development are reversible. The high level scope and requirements should be base-lined before the project starts. Testing is carried out throughout the project life-cycle. Communication and cooperation among all project stakeholders are required to be efficient and effective.

The Phases of DSDM The DSDM framework consists of three sequential phases, namely the preproject, project life-cycle and post-project phases. The project phase of DSDM is the most elaborate of the three phases. The project life-cycle phase consists of 5 stages that form an iterative step-by-step approach in developing an IS (Information System). The three phases and corresponding stages are explained extensively in the subsequent sections. For each stage/phase, the most important activities are addressed and the deliverables are mentioned. Phase 1: The Pre-Project In the pre-project phase candidate projects are identified, project funding is realized and project commitment is ensured. Handling these issues at an early stage avoids problems at later stages of the project. Phase 2: The Project life-cycle The process overview in the figure above shows the project life-cycle of this phase of DSDM. It depicts the 5 stages a project will have to go through to create an IS. The first two stages, the Feasibility Study and Business Study are sequential phases that complement to each other. After these phases have been concluded, the system is developed iteratively and incrementally in the Functional Model Iteration, Design & Build Iteration and Implementation stages. The iterative and incremental nature of DSDM will be addressed further in a later section. Feasibility Study Business Study Functional Model Iteration Design and Build Iteration Implementation

Phase 3: Post-project The post-project phase ensures the system operating effectively and efficiently. This is realized by maintenance, enhancements and fixes according to DSDM principles. The maintenance can be viewed as continuing development based on the iterative and incremental nature of DSDM. Instead of finishing the project in one cycle usually the project can return to the previous phases or stages so that the previous step and the deliverable products can be refined. ### Gesto de TI Help Desk ITIL Primeiro nvel de atendimento Destino das ligaes dos usurios quando em busca de ajuda para a tecnologia em uso. Esse primeiro nvel pode ser caracterizado em dois modelos: Solucionador Grupo de atendentes que resolve o problema durante a prpria ligao do usurio. Atravs do uso de ferramentas complementares (base de conhecimento, software de controle remoto) e treinamento adequado, o atendente tem como objetivo o encerramento do problema sem a necessidade de transferir (ou escalar) o assunto para outro colega. Em alguns centros de suporte, o primeiro nvel solucionador pode ser particionado por especialidades, facilitando com que tcnicos com a habilidade adequada resolvam mais rapidamente o problema (exemplo: clulas de atendentes peritos em Microsoft Office, outros em redes e segurana etc.). Direcionador Ainda dentro do primeiro nvel, conforme o tipo de atendimento realizado, a equipe que recepciona o problema apenas registra o assunto, anota os detalhes e direciona o atendimento para um colega com maior conhecimento no tema. Isso faz com que o registro seja feito de maneira rpida, garantida e o direcionamento conduz para uma equipe mais apropriada. Segundo nvel de atendimento Existem controvrsias no mercado, mas em geral assume-se que um time com maiores conhecimentos sobre o problema em questo. Significa que se o atendente de primeiro nvel no conseguiu resolver um problema do usurio para se conectar na rede e ele ir transferir a responsabilidade desse atendimento para a equipe de administrao de redes. O segundo nvel pode tambm se caracterizar por uma equipe de campo (ou deskside) que vai at o local do usurio para solucionar um problema que, por telefone, seria impossvel (uma impressora quebrada, cabos soltos, etc.). Terceiro nvel de atendimento

So os terceiros especialistas (ou ainda, outro nvel interno mais especializado no assunto) que podem ser os fabricantes de determinados hardwares ou softwares, consultores contratados e assim por diante. Esses so pessoas que tem a capacidade de resolver os problemas no solucionados nos nveis anteriores. ### Gesto de TI ITIL Gerncia de Continuidade de Servio O objetivo da Gerncia da Continuidade dos Servios de TI proteger o desempenho dos servios em qualquer eventualidade baseado no planejamento e na execuo de medidas preventivas. As empresas dependem de uma significante extenso da disponibilidade e funcionalidade da Tecnologia da Informao em uso. Portanto, o preparo para qualquer eventualidade, combinado com gerenciamento da continuidade do negcio, assume uma grande importncia, com metas especficas para proteger a disponibilidade dos servios, tomando medidas preventivas para reduzir a probabilidade de falhas e, se um evento catastrfico ocorrer, restaurar os servios dentro do tempo requerido. O planejamento da Continuidade dos Servios de TI est sempre baseado no Plano de Continuidade de Negcio de alto nvel (BCM). A estratgia e a poltica de avaliao de riscos nos Servios de TI devem ser de responsabilidade da Gerncia de Negcio. A viabilidade e custos so determinados pela TI; ao final de certa forma eles tm uma influncia sobre o nvel de servio requerido. Tarefas Realizar a anlise de riscos como parte do gerenciamento da continuidade do negcio; Preparar o plano de recuperao para os Servios de TI; Fornecer os recursos requeridos; Fornecer treinamento para o pessoal envolvido; Testar e verificar os planos para capacitar os servios de recuperao em uma emergncia dentro do tempo requerido, com segurana e de forma controlada; Implementar programas de melhoria do servio; Manter os planos de recuperao atualizados. Benefcios Em caso de evento catastrfico as restries do negcio dirio sero reduzidas; Reduo do nmero de falhas so reduzidas ao mnimo, pela implementao de medidas preventivas; A perda de dados em caso de evento catastrfico pode ser evitada, com uma infra-estrutura de TI moderna; Em caso de evento catastrfico, os servios da TI so ativados e colocados de volta dentro da normalidade por pessoal treinado. Indicadores de Performance

Nvel de servio da continuidade do negcio (o tempo de atraso e a perda dos dados no caso que de um evento catastrfico); Custos do investimento e de manuteno da soluo de recuperao da TI; Teste com sucesso (tecnologia, casos de negcio, e situao atual dos dados); Custos do processo.

### Sistemas de informao SOA (Arquitetura orientada a servios) WPDL O formato especfico para definio e troca de processo de negcio entre WfMS (ou entre a engine de um WfMS e uma ferramenta de especificao), que seguem o padro de referncia da WfMC (Workflow Management Coalition) e a gramtica usada para sua descrio. ### Gesto de TI ITIL OLA An operational level agreement (OLA) is a contract that defines how various IT groups within a company plan to deliver a service or set of services. OLAs are designed to address and solve the problem of IT silos by setting forth a specific set of criteria and defining the specific set of IT services that each department is responsible for. It should be noted that the term Service Level Agreement (SLA) is used in many companies when discussing agreements between two internal groups, but according to the Information Technology Infrastructure Library (ITIL) framework for best practices, this type of internal contract should be called an Operational Level Agreement. Six tips for crafting an OLA 1. Define all the services IT is responsible for in a Service Catalog. 2. As CIO, get involved in the process by understanding what each service entails. 3. Define the key players (the networking team, the server group, etc.) and their responsibilities. 4. Lay out each IT group's expectations for delivering each service. 5. Come up with contingency plans for unexpected events. 6. Test and retest OLAs, and make changes when needed. OLAs, like SLAs, shouldn't be static and should have a beginning, middle and end date. UC Concept 1: Where an external supplier provides services that underpin the delivery of an IT service, it is essential that the provisions of the contract with the external supplier are consistent with the targets built into any SLA that depends on the external supplier. SLM must avoid making commitments in SLAs that cannot be guaranteed because the Underpinning Contract with an external supplier offers a lower standard. For example, it would make little

sense for SLM to base an SLA availability target on a projected server availability of 99.9 per cent when the support and maintenance contract for the server guarantees no better than 98 per cent. It is the responsibility of SLM to ensure consistency, seeking to renegotiate UCs where contractual commitments fall short of customer needs. The ongoing relationship between the IT service provider & the customer will be covered in future in the chapter on Supplier Management, but it is important to recognize here that UCs must always be kept in line with the needs of the business. This means that as business requirements change, the IT service provider must ensure that UCs are renegotiated or replaced, if cost-effective to do so, to ensure they continue to serve the business. Concept 2: Purpose An underpinning contract is an agreement on the level of IT services that a service provider is able to provide, at a price that is acceptable to the service recipient. The recipient must define the services required and determine whether the provider is capable of delivering those services at the required level. Contents This type of contract must be carefully worded in relation to how and when breaches of contract are to be measured. Any obligations on the customer, such as timely reporting of problems, must also be clearly stated. Operational and Service Level Agreements A UC is a supporting document for a service level agreement (SLA), and the external equivalent of an operational level agreement (OLA). It is, however, a legally binding contract, so failure to meet agreed targets may well result in legal action. ### Gesto de TI ITIL Diferenas entre V2 e V3 (http://pt.scribd.com/doc/34267921/Resumo-Diferencas-entre-a-ITIL-V2-E-V3) ITIL V2 Viso Modular (Todo formado por partes lembra um quebra cabea) 2 Livros Principais (Entrega e Suporte) No existe linha do tempo para lidar com o Servio, ele abordado na sua forma adulta Maior relao com a equipe de TI e com os Clientes Pode se escolher um livro e adot-lo sem se preocupar com os demais Mais flexvel e menos complexa do que a ITIL V3 Pode ser adotada facilmente em pequenas empresas ITIL V3 Viso Holstica (Todo misturado lembra um liquido) 5 Livros Principais (Melhoria Contnua, Service Strategy, Service Design, Service Transition e Service Operation)

Aborda os Servios sobre a perspectiva da Governana de TI Maior relao com o Negcio (antes era alinhamento, agora integrao) Introduzido conceito de Ciclo de Vida do Servio Servios so abordados desde seu nascimento at a sua morte Difcil ou at mesmo invivel adotar apenas um livro, todos devem ser adotados Abriu mo de boa parte da flexibilidade ITIL V2 ao incorporar os conceitos de Governana de TI Difcil de ser adotada em empresas pequenas Maior integrao com outros modelos de Governana de TI e Normas ISO (CMMi, COBIT, PMBOK, ISO 20000, ISO 27001, Six Sigma)

(http://alexvillaverde.blogspot.com.br/2009/05/diferencas-entre-as-vesoesda-itil-v2-e.html) As mudanas entre as verses so substanciais, a abordagem dos processos e o modo de pensar em ITIL com certeza mudou, na nova verso os processos esto agrupados por "mdulos" e seguem uma sequncia lgica para o entendimento das boas prticas. A grande mudana foi separar os processos atravs de um ciclo de vida: Estratgia, Desenho, Transio, Operao e Melhoria de servio continuada. A ITIL V2 foi lanada em 2000 com nove livros, mas apenas dois eram usados. J a V3 foi lanada em 2007 e possui cinco livros principais que formam a base do ciclo de vida. Cada livro contm a viso geral, fundamentos, processos, papis, consideraes, diretriz de implementao, desafios, oportunidades e riscos. Na ITIL V2 falavam em alinhamento com o negcio, hoje na V3 existe a integrao com o negcio, isto pela demanda e pela necessidade das empresas que ao passar dos tempos passaram cada vez mais depender de TI, hoje conseguimos pensar em algum produto novo que no tenha a participao de TI em alguma fase do negcio? Um dos fatores Importantes na ITIL V3 o Portflio de Servios que englobam todos os servios prestados, controlam status e separam entre servios obsoletos, novos e em funcionamento. Outro fator importante o Gerenciamento de Demanda que visa reduzir o risco do negcio, gerenciar os custos e equilibrar o fornecimento com a demanda de recursos. Houve melhoras na Operao do Servio, criando o Comprimento de Servio, mudanas de baixo impacto ou simplesmente requisio de servios pode ser tratada por este processo e no como na V2 que era realizado pelo Gerenciamento de Incidentes. Outro ponto importante incorporado aos processos na ITIL V3 o Gerenciamento de Segurana que garante a disponibilidade, confidencialidade e integridade da informao, tem a tarefa de produzir e manter as Polticas de Segurana. Esta questo de ITIL V2 e ITIL V3, tem a tendncia de sumir com o tempo, o que vai prosseguir a biblioteca ITIL, o que vai interessar so as empresas seguirem um padro, seguirem as boas prticas do mercado, adotarem uma

biblioteca

para

orientar

criar

responsveis

para

cada

processo.

Em breve, a ISSO Tecnologia estar lanando o curso de ITIL Foundations V3, importante realizar a certificao j na verso 3, existe consultorias e centros de treinamento que esto oferecendo e aconselhando os alunos a fazerem o curso na ITIL V2 e depois um upgrade para a verso 3, um caminho totalmente incorreto pois na verso 3 como comentei acima a forma de pensar e aplicar alguns processos mudou, principalmente por ter um ciclo de vida de servio. Se existe uma verso nova e disponvel, quais so os motivos para fazer a certificao na verso antiga e depois fazer um upgrade, para aqueles que j so certificados na verso 2 esta prtica vivel, mas eu aconselho mesmo assim realizar um curso de ITIL V3 porque as mudanas foram grandes e com um alto nvel de impacto. ### Gesto de TI COBIT Controle genricos aplicveis a todos os processos - PC1 Metas e Objetivos do Processo (Process Goals and Objectives) Define e comunica as metas e objetivos especficos, mensurveis, acionveis, realsticos, orientados a resultados e no tempo apropriado. Assegura que os processos esto ligados aos objetivos de negcio e que so suportados por mtricas apropriadas. - PC2 Propriedade dos Processos (Process Ownewship) Designa um proprietrio para cada processo de TI e claramente define os papis e responsabilidades de cada proprietrio. - PC3 Repetibilidade dos Processos (Process Repeatability) Elabora e estabelece cada processo de TI de maneira que possa ser repetido. Fornece uma sequncia lgica (mas flexvel) das atividades que levaro ao resultado desejado. Usa processos consistentes, quando possvel, e processos personalizados apenas quando inevitvel. - PC4 Papis e Responsabilidades (Roles and Responsabilities) Define as atividades-chaves e as entregas do processo. Designa e comunica papis e responsabilidades para uma efetiva e eficiente execuo das atividades-chaves e sua documentao bem como a responsabilizao pelo processo e suas entregas. - PC5 Polticas, Planos e Procedimentos (Policy, Plans and Procedures) As polticas, planos e procedimentos devem ser documentados, revisados, atualizados, aprovados e comunicados a todos os envolvidos, tambm designa responsveis para cada uma dessas atividades. - PC6 Melhoria do Processo de Performance (Process Performance Improvement) Os processos devem ter o seu desempenho medido. Estabelece metas a serem atingidas, e como os dados sero obtidos Controles de Aplicativos AC1 Preparao e Autorizao de Dados Originais: assegura que os documentos fonte sejam preparados por pessoal autorizado e qualificado seguindo os procedimentos estabelecidos,

levando em considerao uma adequada segregao de funes relacionadas com a criao e aprovao desses documentos; AC2 Entrada e Coleta de Dados Fontes: estabelece que a entrada de dados seja executada de maneira apropriada por pessoal autorizado e qualificado; AC3 Testes de Veracidade, Totalidade e Autenticidade: assegura que as transaessejam exatas, completas e vlidas; AC4 Processamento ntegro e Vlido: mantm a integridade e validade dos dados nociclo de processamento; AC5 Reviso das Sadas, Reconciliao e Manuseio de Erros: estabelece procedimentos e responsabilidades associadas para assegurar que as sadas sejam manuseadas de uma forma autorizada, entregues para os destinatrios corretos e protegidas durante a transmisso; AC6 Autenticao e Integridade das Transaes: antes de transportar os dados das transaes entre os aplicativos e as funes de negcios/operacionais (internas ou externas organizao), verifica endereamento adequado, autenticidade da origem e integridade do contedo.

### Banco de dados The ROLLUP, CUBE, and GROUPING SETS operators are extensions of the GROUP BY clause. The ROLLUP, CUBE, or GROUPING SETS operators can generate the same result set as when you use UNION ALL to combine single grouping queries; however, using one of the GROUP BY operators is usually more efficient. The GROUPING SETS operator can generate the same result set as that generated by using a simple GROUP BY, ROLLUP, or CUBE operator. When all the groupings that are generated by using a full ROLLUP or CUBE operator are not required, you can use GROUPING SETS to specify only the groupings that you want. The GROUPING SETS list can contain duplicate groupings; and, when GROUPING SETS is used with ROLLUP and CUBE, it might generate duplicate groupings. Duplicate groupings are retained as they would be by using UNION ALL. Tcnica de indexao em DWH Uma tcnica chamada indexao bitmap (mapa de bits) constri um vetor de bits para cada valor em um domnio (coluna) que est sendo indexado. Essa tcnica funciona muito bem para domnios de baixa cardinalidade. Em um esquema estrela, os dados dimensionais podem ser indexados para tuplas na tabela de fatos por uma indexao de juno. ndices de juno so ndices tradicionais para a manuteno de relacionamentos entre os valores da chave primria e da chave estrangeira. Eles relacionam os valores de dimenso de um esquema estrela s linhas na tabela de fato. ### Linguagem de programao J2EE

Backing bean A JavaBeans component that corresponds to a JSP page that includes JavaServer Faces components. The backing bean defines properties for the components on the page and methods that perform processing for the component. This processing includes event handling, validation, and processing associated with navigation. ### Governana de TI Normas ISO/IEC 15504 - Avaliao de Maturidade e Capacidade de Processos A norma internacional ISO/IEC 15504 Process Assessment estabelece os princpios, requisitos e metodologias a aplicar na avaliao (assessment) do estado de capacidade e maturidade das empresas, de acordo com o modelo de processos definido pela norma ISO/IEC 12207 Software Life Cycle Processes. ISO/IEC 9126 uma norma ISO para qualidade de produto de software, que se enquadra no modelo de qualidade das normas da famlia 9000. A norma brasileira correspondente a NBR ISO/IEC 9126. ### Governana de TI CMMI reas de processo Nvel 2 Nome Gerncia de configurao (CM) Objetivo Manter a integridade dos produtos de trabalho usando a identificao, controle, contabilidade de status e auditoria de configurao. Desenvolver e manter uma capacidade de medida usada para dar suporte ao gerenciamento das necessidades de informao. Desempenho de sistema de servio efetivo; recursos so providos para serem usados eficientemente para dar suporte aos requisitos de servios. Estabelecer e manter um conjunto utilizvel de ativos de processos organizacionais, padres de ambiente de trabalho e regras/diretrizes para equipes.

Medies e anlise (MA)

Gerncia de capacidade e disponibilidade (CAM)

Definio de processo organizacional (OPD)

Foco no processo organizacional (OPF)

Resoluo e anlise de deciso (DAR)

Gernciamento de projeto integrado (IPM)

4 5

Desempenho do processo organizacional (OPP) Resoluo e anlise causal (CAR)

Gerenciamento de desempenho organizacional (OPM)

Planejar, implementar e implantar melhorias nos processos organizacionais baseado num completo entendimento das foras atuais e fraquezas dos processos da organizao e ativos dos processos. Analisar possveis decises usando um processo de avaliao formal que avalia alternativas identificadas contra critrios estabelecidos. Estabelecer e gerenciar o projeto e o envolvimento dos stakeholders de acordo com um processo integrado e definido que adaptado do conjunto de processos-padro da organizao. Estabelecer e manter um entendimento quantitativo Identificar causas de resultados selecionados; tomar providncia para melhorar o desempenho do processo. Gerenciar, proativamente, o desempenho da organizao para encontrar seus objetivos de negcio.

### Gesto de TI Princpios bsicos da Governana Corporativa Transparncia Mais do que "a obrigao de informar", a Administrao deve cultivar o "desejo de informar", sabendo que da boa comunicao interna e externa (particularmente quando espontnea, franca e rpida) resulta um clima de confiana, tanto internamente, quanto nas relaes da empresa com terceiros. A comunicao no deve restringir-se ao desempenho econmicofinanceiro, mas deve contemplar tambm os demais fatores (inclusive intangveis) que norteiam a ao empresarial e que conduzem criao de valor. Equidade Caracteriza-se pelo tratamento justo e igualitrio de todos os grupos minoritrios, sejam do capital ou das demais "partes interessadas" (stakeholders), como colaboradores, clientes, fornecedores ou credores. Atitudes ou polticas discriminatrias, sob qualquer pretexto, so totalmente inaceitveis.

Prestao de contas (accountability) Os agentes da governana corporativa devem prestar contas de sua atuao a quem os elegeu e respondem integralmente por todos os atos que praticarem no exerccio de seus mandatos. Responsabilidade Corporativa Conselheiros e executivos devem zelar pela perenidade das organizaes (viso de longo prazo, sustentabilidade) e, portanto, devem incorporar consideraes de ordem social e ambiental na definio dos negcios e operaes. ### Linguagens de programao Extract method antes Funo() { Bla.print; Bla2.print; } depois Funo() { Imprimir(); } Imprimir() { Bla.print; Bla2.print; } Move method Antes class Project { Person[] participants; } class Person { int id; boolean participate(Project p) { for(int i=0; i<p.participants.length; i++) { if (p.participants[i].id == id) return(true); } return(false); } } Depois class Project { Person[] participants; boolean participate(Person x) { for(int i=0; i<participants.length; i++) { if (participants[i].id == x.id) return(true); }

return(false); } } class Person { int id; } Extract class

### Arquitetura de computadores Pipeline - A tcnica Pipelining permite ao processador executar mltiplas instrues paralelamente em estgios diferentes. - Tcnica que divide a execuo da instruo em muitas partes, cada uma manipulada por uma parte dedicada do hardware, e todas elas podendo ser executadas em paralelo Pipeline de 5 estgios 1) Busca de instruo na memria. 2) Leitura dos registradores e decodificao das instrues. 3) Execuo da instruo e clculo do endereo de desvio. 4) Acesso a um operando na memria. 5) Escrita de um resultado em um registrador. ### Arquitetura de computadores Caractersticas de projeto de I/O: robustez entre falhas e expansibilidade. Desempenho depende: caracterstica do dispositivo, conexo do dispositivo e o resto do sistema, hierarquia de memria e do sistema operacional. Tipos de barramentos: - Barramento processador-memria: curtos, geralmente de grande velocidade. - Barramento de I/O: longos, podem ter muitos tipos de dispositivos ligados a ele. No so ligados diretamente na memria. So ligados a um barramento backplane ligado memria. - Barramento backplane: construdo em uma estrutura de interconexo com o chassi (backplane). - Baramentos backplane e I/O: padres. - Barramento processador-memria: proprietrio.

Barramento sncrono: existe um sinal de clock para controle e um protocolo fixo de comunicao relativo ao clock. Vantagens: fcil implementao, mquina de estados para controle pequeno e, portanto, rpido. Desvantagens: cada dispositivo deve funcionar na mesma frequncia do clock; no podem ter distncias longas se a frequncia for grande. O PCI Express oferece as seguintes vantagens sobre PCI: usa tecnologia serial provendo performance escalvel; alta banda passante; link ponto a ponto para cada dispositivo em vez de um barramento compartilhado. ### Sistemas operacionais Multiprogramao: quando se tem um CPU multiprocessamento. Multiprocessamento: quando se tem vrios CPUs de fato. ### Arquitetura de computadores Dispositivos de E/S As funes mais importantes de um mdulo de E/S podem ser divididas nas seguintes categorias: controle e temporizao, comunicao com o processador, comunicao com dispositivos, rea de armazenamento temporrio de dados e deteco de erros. ### simulando o