Modelagem, Sistemas e Informao

Volume I
Casos, conceitos e complexidades.

Mrcio Francisco Campos

camposmf@gmail.com

Todos os direitos reservados

Verso 21 de outubro de 2008

ndice
INTRODUO............................................................................................................6 PARTE I CASOS......................................................................................................8 1 . O AMBIENTE ACADMICO...............................................................................9 1.1 CARACTERIZAO DO AMBIENTE..................................................................................9 1.2 O CADASTRO ACADMICO.........................................................................................9 1.3 O WORKSHOP........................................................................................................10 1.4 PROJETOS DE PESQUISA............................................................................................11 1.5 SELEO DE MONITORES DE DISCIPLINA.....................................................................12 1.6 AVALIAO DE DISCIPLINAS.....................................................................................13 1.7 ACOMPANHAMENTO DE ESTGIO...............................................................................14 1.8 PROVA ON-LINE......................................................................................................15 1.9 LABORATRIO........................................................................................................16 1.10 CURSOS LIVRES....................................................................................................17 1.11 AVALIAES E TRABALHOS.....................................................................................18 1.12 SISTEMA PESSOAL DE LANAMENTO DE NOTAS.........................................................18 1.13 PLANEJAMENTO E ACOMPANHAMENTO DAS DISCIPLINAS.............................................19 1.14 BIBLIOTECA DE PROJETOS DE SOFTWARE.................................................................19 1.15 RESERVA DE ESPAO E DE RECURSOS.....................................................................20 1.16 SALA VIRTUAL....................................................................................................21 1.17 ACOMPANHAMENTO DE ATIVIDADES COMPLEMENTARES.............................................21 1.18 PROJETO PEDAGGICO..........................................................................................22 1.19 VESTIBULAR........................................................................................................23 1.20 SELEO DE ARTIGOS PARA O WORKSHOP...............................................................24 1.21 ELABORAO DE HORRIO.....................................................................................25 1.22 GRUPOS DE TRABALHO..........................................................................................26 1.23 ELABORAO DE PROVAS UNIFICADAS.....................................................................27 1.24 APLICAO DE PROVAS UNIFICADAS........................................................................28 1.25 SOLICITAO DE REVISO DE PROVAS.......................................................................29 1.26 AVALIAO DE TRABALHO DE CONCLUSO DE CURSO...............................................31 1.27 SISTEMA DE PAGAMENTOS DE CONTRATOS.................................................................32 2 . A EMPRESA JNIOR..........................................................................................33 2.1 CARACTERIZAO DO AMBIENTE................................................................................33 2.2 PRODUTOS INTERNOS DE GERNCIA.............................................................................33 2.2.1 Estimativas..................................................................................................33 2.2.2 Avaliao de produto..................................................................................34 2.2.3 Gerenciamento de Grupos de Trabalho......................................................34 2.2.4 Qualificao profissional............................................................................35 2.2.5 Banco de Horas...........................................................................................36 2.2.6 Identificao de requisitos..........................................................................36 2.2.7 Especificao de requisitos.........................................................................37 2.2.8 Gerenciamento de riscos de projeto............................................................38
2

2.2.9 Verificao/Inspeo de software...............................................................39 2.3 SOLICITAO DE CLIENTES.......................................................................................40 2.3.1 O pipoqueiro da esquina.............................................................................40 2.3.2 O vendedor de sandwich natural.................................................................41 2.3.3 A casa de festas...........................................................................................42 2.3.4 A festa de casamento...................................................................................43 2.3.5 Economia Domstica...................................................................................44 2.3.6 Finanas Domsticas..................................................................................45 2.3.7 Estudante Organizado.................................................................................45 2.3.8 Personal Professor......................................................................................46 2.3.9 Ambulante de Software Livre......................................................................47 2.3.10 Liga dos Blocos Unidos.............................................................................48 2.3.11 Bloco Cores Unidas do Arco ris..............................................................48 2.3.12 Dieta Alimentar.........................................................................................49 2.3.13 Agenda Domstica.....................................................................................50 2.4 BIBLIOGRAFIA.........................................................................................................50 PARTE II CONCEITOS........................................................................................52 1 INTRODUO........................................................................................................53 2 A TECNOLOGIA DA INFORMAO E IMPACTOS......................................54 2.1 CONCEITOS.............................................................................................................54 2.2 TECNOLOGIA DA INFORMAO: ORIGEM E DEFINIO....................................................54 2.3 EVOLUO DA TECNOLOGIA DA INFORMAO..............................................................56 2.3.1 Hardware.....................................................................................................56 2.3.2 Software.......................................................................................................57 2.3.3 Rede e telecomunicaes.............................................................................58 2.3.4 Banco de dados...........................................................................................59 2.3.5 Internet........................................................................................................60 2.4 TECNOLOGIA DA INFORMAO E IMPACTOS..............................................................60 2.4.1 Perspectiva interna: a administrao da tecnologia da informao..........60 2.4.2 Perspectiva externa: da organizao e seu meio........................................61 2.4.3 Perspectiva transversal: os sistemas de informao..................................69 2.4.4 Perspectiva antropolgica: a Cultural........................................................72 2.5 CONCLUSO...........................................................................................................72 2.6 BIBLIOGRAFIA.........................................................................................................73 3 PROJETOS DE TI. ................................................................................................76 3.1 INTRODUO...........................................................................................................76 3.2 GERENCIAMENTO DE MUDANAS...............................................................................77 3.3 COMPRAR OU DESENVOLVER......................................................................................79 3.4 REQUISITOS DE UM PROJETO DE SOFTWARE..................................................................79 3.5 CICLOS DE VIDA DE UM PROJETO DE TI/SOFTWARE......................................................80 3.6 CICLOS DE VIDA DE ADOO DE PROJETOS ERP...........................................................82 3.7 MTRICAS DE PROJETOS...........................................................................................82 3.8 NORMAS E PADRES INTERNACIONAIS PARA A GERNCIA DE PROJETO...............................83 3.9 PARTICIPAO DO CLIENTE........................................................................................84
3

3.10 CONCLUSO........................................................................................................85 3.11 BIBLIOGRAFIA.......................................................................................................86 4 A ENGENHARIA DE REQUISITOS..................................................................87 4.1 INTRODUO...........................................................................................................87 4.2 CARACTERIZAO...................................................................................................87 4.2.1 Etapa de Identificao.................................................................................88 4.2.2 Etapa de Especificao...............................................................................92 4.3 ATRIBUTOS DA ENGENHARIA DE REQUISITOS...............................................................93 4.4 BIBLIOGRAFIA.........................................................................................................96 PARTE III COMPLEXIDADES...........................................................................98 1 INTRODUO.......................................................................................................99 2 DO OBJETO SISTEMA DE INFORMAO....................................................99 2.1 INTRODUO...........................................................................................................99 2.2 CARACTERSTICAS GERAIS.........................................................................................99 2.3 CARACTERSTICAS PARTICULARES.............................................................................100 2.4 DA MANIFESTAO DOS SISTEMAS DE INFORMAO....................................................102 2.5 BIBLIOGRAFIA.......................................................................................................103 3 DO OBJETO SOFTWARE.................................................................................104 3.1 DA CARACTERIZAO.............................................................................................104 3.2 DA SUA HISTRIA..................................................................................................104 3.3 DO SEU PROCESSO DE PRODUO.............................................................................105 3.4 DA SUA NATUREZA................................................................................................105 4 BENEFCIOS DA ABORDAGEM ESSENCIAL. ...........................................106 4.1 EVENTOS E ANLISE ESSENCIAL..............................................................................106 4.2 SISTEMAS DE RESPOSTAS PLANEJADOS.......................................................................106 4.3 EVENTOS..............................................................................................................107 4.4 PRIORIZAO DOS EVENTOS.....................................................................................109 4.5 DA CLASSIFICAO DOS EVENTOS. ...........................................................................110 4.6 DA TEMPORALIDADE DOS EVENTOS. .........................................................................111 4.7 VALIDANDO OS EVENTOS........................................................................................111 4.8 UTILIZANDO EVENTOS PARA DESCOBRIR PROCESSOS, CLASSES E SUBSISTEMAS..................112 4.9 BIBLIOGRAFIA.......................................................................................................116 PARTE IV APLICAO DIDTICA...............................................................118 1 DA MODELAGEM DE SISTEMAS DE INFORMAO..............................119 1.1 INTRODUO.........................................................................................................119 1.2 DO CONTEXTO......................................................................................................119 1.3 A ABORDAGEM DE MODELAGEM CORRENTE................................................................120 1.4 MODELAGEM. .....................................................................................................121 1.5 SISTEMAS.............................................................................................................124 1.6 DADO E INFORMAO............................................................................................125 1.7 A MODELAGEM DE SISTEMAS DE INFORMAO...........................................................126
4

1.8 CONCLUSO.........................................................................................................127 1.9 BIBLIOGRAFIA.......................................................................................................128 2 USO DE UM PROCESSO...................................................................................130 2.1 EXEMPLO,............................................................................................................130 2.1.1 O processo/Pasta de desenvolvimento......................................................130 2.1.2 Artefatos....................................................................................................130 2.1.3 Avaliao...................................................................................................132 2.1.4 Perfil da equipe.........................................................................................133

Introduo.
Este livro est dividido em quatro partes: Parte I Casos, Parte II Conceitos, Parte II Complexidades e Parte IV Aplicao Didtica. A parte I casos tem como objetivo servir de referncia para o exerccio de modelagem. Quando inicio um curso de Modelagem de Sistemas de Informao costumo dizer que o objetivo do curso no a formao de analistas de sistemas em sua essncia. Acredito que a formao deste Profissional no se resume a um mero aprendizado de mtodos, tcnicas e ferramentas. Possivelmente o mais importante no processo de modelagem de sistemas de informao o processo de investigao, de observao e de sistematizao das informaes coletadas. Os mtodos que aprendemos servem para, inicialmente, nos auxiliar no entendimento da realidade. Sob este aspecto o aprendizado dos mesmos importante. Mas como ensinar modelagem de sistemas de informao? Ensinar apenas a teoria ou partir para a prtica? Se nos limitarmos ao aspecto meramente terico permanece a deficincia em identificar situaes onde aquele conhecimento pode ser usado. Por outro lado, ensinar modelagem de sistemas de informao, apenas via o uso da prtica, no permite uma formao conceitual adequada. Uma soluo o emprego de estudos de caso. O uso de casos para exercitar a aplicao da teoria no novidade, j feito com sucesso em outros cursos. Para a rea de sistemas de informao este mtodo se parece tambm apropriado. Entretanto apesar desse aspecto, o volume de livros de modelagem sistemas de informao que abordam o aspecto terico infinitamente superior aos livros que sugerem casos para o exerccio da teoria de modelagem de sistemas de informao. Uma das preocupaes com esta parte do livro foi com o processo de integrao entre os casos. Para tal para cada parte do livro procura tratar de um domnio especfico. No obstante, tambm existem casos isolados. Desta forma, esta primeira parte do livro pode ser utilizada empregando-se os casos isoladamente ou, na medida em que os casos so desenvolvidos, pode-se buscar uma integrao conceitual entre os diferentes casos. Alguns casos so inusitados, ressaltando que a modelagem de sistemas de informao no se restringe a determinados ambientes organizacionais, ela pode ser feita em todos os lugares. Os casos so fictcios. As rotinas e os detalhes operacionais foram descritos considerando apenas a minha experincia. Os casos servem como um ponto de partida para a modelagem, podendo o aluno e o professor considerar aspectos e situaes no inicialmente descritas no mesmo. 6

Em alguns casos escrevi um cenrio. Sabemos que um sistema no existe isoladamente, ele existe dentro de um contexto. A descrio destes cenrios importante se o professor usar os casos para a elaborao de projetos de software. Os casos se referem a faculdade de computao recm criada, carinhosamente chamada de Turing Machines. O objetivo modelar os sistemas acadmicos desta instituio. Outra empresa apresentada, a Being Digital. Nesta ltima empresa os casos se dividem em dois grupos. O primeiro grupo diz respeito a ferramentas de auxlio gerncia interna de suas atividades de software. O segundo grupo corresponde solicitao de clientes. Esses sistemas so, em geral, sistemas pessoais de baixa complexidade necessrios a compreenso e ao exerccio da modelagem de sistemas de informao. Na Parte II - Conceitos do livro encontra-se o que chamo de material tradicional de sistemas de informao. Ainda est incompleta, contendo somente os captulos de Tecnologia da Informao e de projetos. Na Parte III Complexidades o livro trata da dificuldade de se modelar sistemas de informao. Esta parte serve tanto para professores quanto alunos. A modelagem de sistemas de informao algumas vezes um processo frustrante. Esta parte procura mostrar a real dificuldade de se modelar estes sistemas fazendo, creio, que frustrao ser torne controlada. Na Parte IV Aplicao Didtica exemplificado uma forma de se aplicar os casos atravs de um processo de software onde tantos os artefatos quanto a equipe so avaliados. A aplicao de conceitos de modelagem, com cursos especficos, de engenharia de requisitos e modelagem UML podem ser acessados em minha pgina: www.camposmf.eti.br Boa leitura e boa modelagem!

Parte I Casos

1. O Ambiente Acadmico.
1.1 Caracterizao do ambiente.
As Faculdades Integradas Turing Machines identificou como estratgico para a o seu posicionamento de mercado a criao de um curso de Cincia da Computao. Aps dois anos de atividades o Curso de Cincia da Computao est desenvolvendo uma srie de projetos que auxiliam no planejamento, no controle e na avaliao do mesmo, na elaborao de eventos acadmicos e no apoio ao laboratrio. Apesar de existirem processos manuais bem definidos, a informatizao se faz necessria, devido ao crescimento no nmero de alunos. Entretanto, faz-se necessrio a automatizao de vrios sistemas inerentes ao curso em si quanto aos que dizem respeito s Faculdades Integradas. A atualizao e modernizao dos sistemas do curso de Cincia da Computao, assim como do das Faculdades, fundamental para o processo de transformao desta em Centro Universitrio.

1.2 O Cadastro Acadmico.

Cenrio Institucional. As Faculdades Integradas Turing Machines necessitam tornar mais gil o processo de oferta de turmas nos diversos cursos que possui. Para tal definiu como prioritrio automatizar seu processo de cadastro de professores, de disciplinas entre outros. Assim, contratou uma empresa especializada em desenvolvimento Java e utilizar todo o aparato tecnolgico desta plataforma. O sistema ser desenvolvido para ser utilizado pelos diversos setores atravs da internet. O final do semestre o prazo limite para a entrega do sistema. Caso. A Direo Acadmica das Faculdades Integradas Turing Machines a responsvel pelo planejamento de ofertas de cursos da instituio. cadastro os professores licenciados e os dispensados. A Secretaria tambm cadastra os novos Cursos criados pela instituio e o respectivo currculo desses cursos. Os professores so classificados em professores de tempo parcial (20h) e professores de tempo integral (40h), ou visitantes. Esta informao proveniente dos cursos e autorizado pela Direo Acadmica. 9 Assim, todo o incio de semestre, a Secretaria das Faculdades providencia o cadastramento dos novos professores e retira do

As Coordenaes dos Cursos informam as disciplinas que sero oferecidas no semestre, junto com os professores que lecionaro nas mesmas, as turmas que sero abertas e os horrios das mesmas. A Direo de Patrimnio informa quais as salas de aula estaro disponveis para as turmas. Sendo que as salas esto espalhadas por trs prdios contidos no campus. Cabe ao Setor de Apoio Docente alocar as salas para cada turma. As disciplinas oferecidas podem ser do ciclo bsico ou do ciclo profissionalizante. Ao final de cada semestre so emitidos os relatrios de professores disponveis e a grade contendo as matrias oferecidas, as turmas, as salas e o horrio.

1.3 O Workshop.
Cenrio Institucional. Aps a reunio com o gerente de projeto o Diretor Acadmico autorizou a construo do referido sistema. Entretanto fez algumas restries. Devido a crise financeira que assola s faculdades, o projeto somente ter o equivalente a R$20.000 de recursos alocados. Devido a necessidade e urgncia do projeto, j que no se imagina nenhuma faculdade sem este sistema, o projeto deve terminar em no mximo 2 meses. Com a proximidade de mudana de Diretoria, tambm no ser permitida a contratao de consultoria externa. O projeto ter de contar com a qualificao interna dos profissionais. Cursos e treinamentos para qualificao tambm no sero possveis. Devido a adoo de software livre pela instituio, o projeto dever contemplar a utilizao deste tipo de software mesmo sabendo que no existe qualificao interna para isso. Caso. Um Professor do curso de Cincia da Computao das Faculdades Integradas Turing Machines, resolveu realizar um Seminrio com a finalidade de ser evento com palestras e mini-cursos, com a inteno a trazer o debate acadmico e profissional para fora da sala de aula. O Seminrio contar com dois tipos de participantes: os alunos (nome, numero de matrcula, CPF, ou identidade, e-mail) da instituio e os convidados (nome, nmero de matrcula, CPF ou identidade, instituio de origem, e-mail). Os preos cobrados para cada tipo de convidado sero diferenciados. Ao se inscrever o participante poder optar pelo ciclo de palestras ou por um ou mais minicursos. O ciclo de palestras possui um preo fixo e os minicursos so cobrados individualmente.

10

Cada palestra e minicurso ser realizada em um auditrio, ou sala, e com uma configurao de recursos apropriada (ex.: nmero da sala, nmero de lugares, infra-estrutura de computao, retroprojetor, flip chart, data-show), previamente alocados pela coordenao do curso As palestras e minicursos sero proferidas por palestrantes que so registrados pela Secretaria da Coordenao do Curso (nome, CPF, instituio de origem, e-mail, minicurrculo) e que podem ser professores da instituio, profissionais de mercado, professores visitantes. Ao final de cada palestra e minicurso registrado a qualidade do evento via um questionrio de avaliao. Deste questionrio produzido um relatrio de qualidade. Ao final do Seminrio, os inscritos e os palestrantes recebero um certificado especificando as atividades realizadas (nome do participante, data, lista de atividades realizadas) e que ser emitido pela Secretaria do Curso. Alguns relatrios de controle estaro disponveis para a coordenao do curso: o de inscritos por minicurso, o de inscritos para o ciclo de palestras e a programao de evento.

1.4 Projetos de Pesquisa

Cenrio Institucional. O coordenador do curso de Cincia da Computao e o um professor orientador submeteram um projeto a uma instituio de Fomento a Pesquisa com vistas a melhorar e apoiar o seu processo de pesquisa dentro da instituio. Neste projeto sero concedidas cinco bolsas de iniciao cientfica, compra de oito mquinas e softwares de apoio. O prazo para a prestao de contas do projeto de um ano. Caso. O coordenador do curso de Cincia da Computao das Faculdades Integradas Turing Machines resolveu automatizar o sistema de acompanhamento de projetos de alunos. Assim sendo, ele necessita de um sistema que cadastre os projetos oferecidos plos diversos professores e os respectivos alunos interessados. A responsabilidade pelo cadastro dos projetos do Coordenador. Cada projeto possui um professor como lder do mesmo. Ao realizar um projeto o aluno ganhar um nmero de horas que so necessrias para a colao de grau. O total necessrio para colao de grau de 300h. Cada projeto emite um certificado de concluso para o aluno e, dependendo do desempenho de cada aluno no projeto, um nmero de horas diferentes pode ser creditada. O Professor, lder do projeto, que faz essa avaliao .

11

Ao final do projeto, os alunos devem apresentar um relatrio do projeto que deve ser registrado pelo sistema. Caber ao Coordenador avaliar a quantidade de horas que o aluno receber, independente das horas registradas no certificado. Ao final de cada semestre o Coordenador do Curso solicita um relatrio contento o total de horas de cada aluno e publica-o na secretaria do curso. Um extrato detalhado, de um aluno especfico, tambm pode ser obtido. Nesse extrato so listados todos os projeto realizados com as respectivas horas, o total de horas e quantas horas ainda faltam para completar.

1.5 Seleo de Monitores de Disciplina.

Cenrio Institucional. O Curso de Cincia da Computao foi recentemente avaliado por uma comisso externa que tinha por objetivo avaliar a qualidade do curso. Uma das principais observaes desta comisso foi a ausncia de um processo de monitoria bem definido no curso. O existente manual pouco transparente e sujeito a particularidades de cada professor. Desta forma, o coordenador do curso resolveu distribuir quiosques ao longo da faculdade para permitir que este processo seja o mais eficaz, seguro e transparente possvel. Para evitar a alocao de novos recursos institucionais, o coordenador realizou projeto de financiamento de melhoria institucional, na ordem de R$120 mil. A princpio, o sistema permitir que 12 disciplinas participem do processo de monitoria, mas este sistema devem ser escalvel para permitir que todas as faculdades da instituio possam utiliz-lo. O sistema deve contratada. Caso. O Coordenador do Curso de Cincia da Computao das Faculdades Integradas Turing Machines resolveu tornar mais transparente o processo de seleo de monitores. Assim, todo incio de semestre, o Coordenador divulga um edital para a seleo dos monitores. No edital so registradas as disciplinas que tero monitores, as datas de incio e de trmino do processo de seleo, o coeficiente de rendimento necessrio para a candidatura, as atividades extracurriculares de extenso necessrias, a data das provas e da entrevista. Quando o edital aprovado pelo Conselho Acadmico do Curso ele divulgado por toda a instituio. O coordenador do curso tambm define a Comisso de Monitoria composta de professores que iro selecionar os diversos monitores. A comisso possui um presidente e um relator. Os alunos se inscrevem no processo seletivo. Ao se inscreverem, os alunos preenchem um questionrio de expectativas e de conhecimentos gerais. 12 estar pronto em 3 meses e uma empresa externa deve ser

Aps a inscrio a comisso emite o relatrio dos inscritos. Em cada etapa do processo de seleo os alunos recebem uma nota: ao realizarem a prova, ao serem avaliados na entrevista e pelas atividades de extenso. De posse das notas a comisso se rene e elabora a lista de aprovados por ordem decrescente da mdia geral das atividades requisitadas. A comisso emite o relatrio de aprovados no processo. Ao longo do processo de monitoria os alunos monitores registram as atividades realizadas e a presena dos alunos em cada uma destas atividades. Alm disso, o monitor escreve um relatrio relatando a experincia vivida. Estes registros so entregues ao professor da disciplina que efetua a aprovao da monitoria e registra horas de extenso para o aluno. Ao final do semestre a Comisso de Monitores avalia os diversos relatrios entregues pelos alunos, e respectivamente aprovados pelos professores, e verifica a necessidade de mudanas no processo. Todas estas anlises ficam registradas em ata. Cenrio de Desenho. O coordenador imagina comprar cinco quiosques que estaro ligados em rede com um servidor central, situado na coordenao do curso. A sala do Conselho Acadmico, assim como a sala da Comisso de Monitoria, possui um computador que estaro tambm ligados em rede. A expectativa de utilizao de software livre tais como linux, MySql e PHP. Estuda-se a possibilidade de se utilizar, ao invs do PHP o Java. O volume de alunos candidatos da ordem de 50, mas se toda a Faculdade entrar no processo este nmero pode saltar para 500. O ponto crtico do projeto reside na primeira semana aps a publicao do edital, quando as inscries so efetuadas.

1.6 Avaliao de Disciplinas.

Cenrio Institucional. As Faculdades Integradas Turing Machines querem ser reconhecidas pala qualidade dos diversos cursos superiores que oferece. Assim, um grupo de trabalho foi constitudo pelo Diretor Geral para definir as regras de avaliao das disciplinas oferecidas pelos cursos. Essas regras foram aprovadas, tambm, pelo Colegiado de Coordenadores e de Diretores. Este sistema deve interagir com o sistema acadmico para obter as matriculas em cada curso e as disciplinas. Caso. O curso de Cincia da Computao das Faculdades Integradas Turing Machines resolveu automatizar o seu processo de avaliao das disciplinas oferecidas. 13

A Direo Geral cadastra, seu critrio, as questes que deseja avaliar, assim como os questionrios que deseja aplicar. As questes so divididas em trs categorias: avaliao do professor; avaliao da disciplina; e avaliao da infra-estrutura utilizada. Alm destas categorias a Direo Geral pode criar novas categorias. Cada pergunta do questionrio de avaliao o aluno possui um roteiro que o orientar. Cada resposta pode ser de vrios tipos: sim/no; por faixa de valores contnuos; por faixa de valores discretos. Assim, ao final de cada semestre, os questionrios so disponibilizados pelos alunos a partir da autorizao da Direo Geral. Cada aluno responde a tantos questionrios quantas forem as disciplinas em que estiver matriculado. O questionrio annimo e respondido sempre ao final do semestre de aula. Ao registrar o questionrio respondido por cada aluno, a Direo geral solicita a emisso do um ranking com dos Professores e das Matrias. O Setor de Apoio Docente de posse dos resultados emite o relatrio de Avaliao Individual e entrega a cada professor; emite o relatrio de Avaliao de Infra-estrutura e entrega a Direo Administrativa e emite o relatrio de avaliao da disciplina e entrega para os coordenadores decurso.

1.7 Acompanhamento de Estgio

Cenrio Institucional. O programa de estgio regulado por lei federal e pelos regimentos internos das Faculdades Integradas Turing Machines. O coordenador do curso solicitou ao professor de projeto final que este sistema fosse desenvolvido por um aluno desta disciplina. O coordenador considera que o sistema pode ser desenvolvido por uma equipe de alunos e melhorado, se necessrio, em um semestre posterior. Caso. O coordenador do curso de Cincia da Computao das Faculdades Integradas Turing Machines resolveu desenvolver um sistema para acompanhamento de estgio de seus alunos, j que essa uma exigncia do curso para a colao de grau. Atualmente o coordenador realiza convnios com diversas empresas. O convnio composto por um Termo de Estgio, assinado entre o coordenador e a empresa e o Termo de Compromisso que ser assinado entre o aluno da faculdade e a empresa. De acordo com a necessidade as empresas enviam suas requisies de estgio ao coordenador do curso, que contm o perfil desejado ao cargo. O coordenador do curso, por sua vez divulga esta necessidade.

14

Os alunos interessados se inscrevem para a posio aberta e o coordenador faz uma pravaliao, indicando apenas trs dos interessados. Por sua vez, a empresa contrata aquele aluno que melhor atender ao perfil e envia um comunicado ao coordenador do curso. Ao final do estgio o aluno deve escrever um relatrio descrevendo as atividades desempenhadas no estgio. Esse relatrio deve ser aprovado pela coordenao e pela empresa contratante. Aps a aprovao, as horas realizadas no estgio so creditadas ao aluno. Esse questionrio considerado na avaliao do crdito das horas para o aluno. O aluno deve fazer um total de 500h horas de estgio. Ao fim do estgio, a empresa, tambm, envia uma avaliao, a partir de um questionrio predeterminado, do desempenho do aluno. Todo final de ms o coordenador emite um relatrio de estgio que traz o histrico de estgio de cada aluno com o total de horas de estgio realizadas.

1.8 Prova On-line.

Cenrio Institucional. O professor que resolveu oferecer este projeto um excelente profissional, porm de pouca capacidade de relacionamento com os alunos. autoritrio e no admite erros. Exige marcao de entrevista formal e faz ata de reunio para registrar os encontros. Considera-se o dono do projeto e no permite a participao de outros professores no projeto. Entretanto para o projeto continuar necessrio que as especificaes do mesmo sejam aprovadas pelo colegiado do curso, que formado por cinco professores do curso e pelo Coordenador do mesmo. Caso. Um Professor do Curso de Cincia da Computao das Faculdades Integradas Turing Machines resolveu oferecer um projeto extraclasse para seus alunos. O projeto consiste em construir uma prova on-line. O projeto considera que: um professor pode elaborar vrias questes com suas respectivas respostas; cada questo classificada em simples, mdia e complexa e est associada a um ou mais itens do programa de uma disciplina de um determinado curso. Para cada questo registrada a resposta correta. Essas questes so armazenadas em um banco de dados. Todas as questes so de mltipla escolha. Quando deseja montar uma prova o professor configura o nmero de questes que deseja e qual o nmero de questes com um determinado grau de complexidade. Por exemplo: uma prova de 15 questes distribudas em seis questes fceis, cinco questes mdias e quatro questes difceis. As questes so buscadas aleatoriamente na base de dados.

15

O professor tambm configura a aplicao da prova. Assim o professor determina a data e a hora inicial da prova assim como a data e a hora final; a turma que far a prova e os respectivos alunos. O professor pode especificar uma ou mais listas de exerccios nos moldes da prova. Estas listas ficam disponveis aos alunos que podem faz-las antes de executar uma aprova. Os alunos por sua vez fazem a prova no perodo determinado. Ao final da prova o aluno sabe a nota que tirou e pode emitir o gabarito da mesma. Antes de se iniciar a prova todos os alunos da turma so cadastrados pelo professor; ao final do tempo de prova so emitidos o gabarito, as estatsticas e as notas dos alunos. O professor, ao final da prova emite o relatrio de Estatsticas de Notas dos Alunos e o relatrio de Estatstica de Notas por Questo. O professor tambm pode emitir uma avaliao das listas realizadas pelos alunos.

1.9 Laboratrio
Cenrio Institucional. As Faculdades Integradas Turing Machines resolveram reformular suas instalaes de laboratrio. Atravs de apoio de uma entidade de fomento as Faculdades receberam R$150 mil para compra de mquinas e R$20 mil para servios de terceiros. Desta forma ficou a cargo da Faculdade de Cincia da Computao o desenvolvimento de um sistema para apoiar os laboratrios. O projeto de desenvolvimento deve dura quatro meses e envolver profissionais de mercado, alunos e professores. Caso. A Faculdade de Computao Turing Machines possui cinco laboratrios de informtica. Os laboratrios esto organizados de acordo com um propsito especfico, por exemplo: o laboratrio de Arquitetura, o de circuitos digitais, de administrao, de uso geral etc. Em cada tipo de laboratrio possui um conjunto de computadores. Cada computador categorizado por um conjunto de monitor, teclados, acessrios (caixas de som, microfone, por exemplo) e unidade principal (composta de cpu, memria, placa de rede etc). Todas as informaes do conjunto do computador so armazenadas para fins de auditoria, manuteno e de inventrio, na planilha de Configurao de Componentes de Computadores. Cada computador possui um conjunto de softwares instalados. Os softwares

instalados/desinstalados em cada computador so devidamente registrados em uma planilha Configurao de Software de Computadores. Ao final de cada dia, o Relatrio de Nmero de Licenas Utilizadas emitido para verificar se existe algum uso indevido de software.

16

Sempre que se compra um software, ou se faz um upgrade o laboratorista registra o software com a nova verso e o nmero de licenas. A manuteno dos computadores feita por uma empresa externa. Ao surgir um defeito o laboratorista de planto abre uma ordem de servio, contendo o nmero do micro defeituoso, a data de abertura da ocorrncia e os sintomas detectados, que encaminhada empresa de manuteno. Quando a empresa atende a ordem de servio, o tcnico emite um laudo e registra as providencias (troca de placas, limpeza etc). Todo final de ms emitido o relatrio de manuteno por micro. Sempre que se compra um computador este, ao chegar, destinado a um laboratrio especfico. Em casos especficos um computador pode ser destinado a se tornar um servidor. Alm destes servios os laboratrios podem ser reservados pelos professores. Para tal o professor liga para o laboratorista que verifica a disponibilidade e providencia a reserva, na data e na hora e nos tempos necessrios.

1.10Cursos Livres.
As Faculdades Integradas Turing Machines resolveram criar uma Sub-coordenao de extenso cujo objetivo servir de complemento s atividades de graduao. Uma das atividades sob a responsabilidade desta Sub-coordenao a de planejar e a de organizar cursos livres para seus alunos e para a comunidade. Em um primeiro momento a Sub-coordenao relaciona os diversos interessados em ministrar cursos a partir do preenchimento de uma proposta que constam do nome do professor, do seu currculo, da ementa do curso, a data de incio, o nmero mnimo de alunos, o nmero mximo de alunos, o valor hora aula do professor e a carga horria do curso. A partir destas propostas as Faculdades elaboram um planejamento de cursos. Para cada curso so abertas uma ou mais turmas em horrios e datas diferentes. Ao se inscrever em uma turma de um determinado curso, os alunos informam o nome, o endereo, o telefone, o e-mail e os outros cursos de interesse. Todo incio de ms so enviados por e-mail a programao dos cursos para os prximos meses para os alunos inscritos. Ao se realizar um curso, os professores lanam s presenas dos alunos. Ao final do curso emitido um certificado para os alunos que completarem 75% das aulas. Os cursos so realizados quando 50% das vagas de uma turma so preenchidas, de outra forma uma outra turma programada para nova data.

17

1.11 Avaliaes e trabalhos.

O Coordenador do curso de Cincia da Computao das Faculdades Integradas Turing Machines resolveu controlar o calendrio de avaliaes. Dessa forma, os Professores devem registrar com uma semana de antecedncia a data para a aplicao de testes e provas. Ao registrar o teste ou a prova o Professor deve informar os tpicos do programa que sero exigidos, as regras da prova (se caneta, com uso de calculadora etc) e o local e hora. Ao registrar trabalhos, o Professor deve informar programa do curso. O Coordenador do curso preenche o calendrio de avaliaes com as datas limites de lanamento de notas para o primeiro e segundo bimestre, do perodo de segunda chamada e da prova final. Todo incio de semana o coordenador emite o calendrio de avaliaes daquela semana. Todo incio de ms o Coordenador emite o relatrio de Avaliaes Mensais por Professor. o tema, o objetivo, os mtodos e os

softwares que devem ser empregados para a elaborao do mesmo alm dos tpicos do

1.12 Sistema Pessoal de Lanamento de Notas.

Cenrio Institucional. A Vice-Reitora das Faculdades Integradas Turing Machines resolveu junto com o colegiado de Diretores automatizar o processo de lanamento de notas. Para tal a Vice-Reitora montou um grupo de trabalho com trs Coordenadores para realizar a tarefa. Entretanto um dos Coordenadores est em viagem e somente poder ser contatado distncia. Uma das caractersticas do sistema que este dever se interconectar com o sistema acadmico. Caso. As Faculdades Integradas Turing Machines, em especial o curso de cincia da computao, resolveu desenvolver um sistema para o auxlio do professor no lanamento de notas. Ao invs da nota ser lanada em uma pauta, esta ser lanada via Internet. Assim o novo sistema teria algumas funcionalidades. O Professor ter de que se conectar com a respectiva matrcula e com uma senha. Ao fazer isso, sero mostradas todas as disciplinas que o Professor leciona naquele perodo (matria e turma). Ao selecionar uma disciplina/turma, o Professor ter a sua disposio a lista de alunos matriculados e o conjunto de notas a serem lanadas (nota um, a nota dois e a prova final). O Professor poder lanar qualquer nota a qualquer momento. Alem de laar as notas o Professor ter algumas funcionalidades extras, tais como: ao clicar em um aluno poder verificar as notas deste em outras disciplinas; poder solicitar as 18

estatsticas da turma (mdia da turma, desvio padro, quantidade percentual de alunos aprovados, reprovados, em prova final); poder simular um conjunto de notas antes de lanar; pode listar as notas lanadas da turma; poder baixar o arquivo de notas para o seu computador.

1.13 Planejamento e Acompanhamento das Disciplinas.

O coordenador do curso de Cincia da Computao das Faculdades Integradas Turing Machines resolveu automatizar o processo de planejamento e de acompanhamento das disciplinas. Quando da criao de uma disciplina registrada a ementa, o objetivo, a carga horria, o programa, o mtodo de avaliao e a metodologia de ensino. O professor de posse deste plano de disciplina elabora o programa da matria que estabelece o contedo programtico de todo o contedo a ser aplicado e suas respectivas datas. O contedo pode ser classificado como palestras convidadas, aulas expositivas, apresentao de trabalhos, aulas de laboratrio, visitas, tema dirigido, provas entre outros Ao longo do curso o professor vai lanando aquilo que foi realmente feito em sala de aula. Quando o que foi programado for diferente do realizado o professor deve lanar tambm uma justificativa para tal fato. O coordenador pode solicitar a qualquer momento o relatrio de disciplina, o relatrio de plano de curso e o relatrio de realizao de curso.

1.14 Biblioteca de Projetos de Software.

Cenrio Institucional. O coordenador do curso de Cincia da Computao das Faculdades Integradas Turing Machines resolveu apoiar um projeto para cadastrar todos os projetos de software desenvolvidos pelos alunos. Para tal solicitou uma bolsa de estgio remunerado para dois alunos do quinto perodo e atribuiu a um professor a responsabilidade de coordenar a equipe para a construo de uma biblioteca de software. Esta biblioteca de projetos de software est baseada em um projeto final desenvolvido por alunos do perodo anterior. Este projeto dos alunos ainda est em uma etapa acadmica, com todas as funcionalidades identificadas e caracterizadas, porm com a implementao de um estgio inicial. Caso. Com vistas ao desenvolvimento e a utilizao de projetos de software, o curso de Cincia da Computao das Faculdades integradas Turing Machines resolveu criar uma Biblioteca que armazene os projetos de software desenvolvidos pelos alunos. 19

Nessa biblioteca o Aluno registrar o software desenvolvido a partir de informaes de quem desenvolveu, o Professor ou Professores que orientaram na construo do mesmo bem como o ano, o perodo de desenvolvimento (um semestre ou segundo semestre) e a verso. Cada software poder ter vrias classificaes de forma que este pode ser bem caracterizado. Esta classificao ser feita pelo professor orientador do projeto. O software registrado ser composto do aplicativo, da sua especificao de arquivos/banco de dados, da documentao de projeto e do manual de usurio e de instalao. A documentao de projeto consiste do plano para a construo da verso ora registrada, do modelo de anlise, do modelo de projeto, assim como a massa de teste utilizada e os resultados obtidos. Alm dessas funcionalidades o Aluno poder disponibilizar notcias sobre as diversas verses liberadas. Usurios que desejarem participar de um determinado projeto podero se inscrever em um cadastro especfico para isto.

1.15 Reserva de Espao e de Recursos.

As Faculdades Integradas Turing Machines possui um setor de apoio docente. Este setor responsvel pelo atendimento das solicitaes de recursos especiais aos professores, como por exemplo: vdeo, data show, reserva de auditrio, televiso, computadores etc. Assim o apoio docente possui uma lista de todos os recursos mveis disponveis (computador, retroprojetor etc) e de todos os recursos imveis (auditrios, salas, laboratrios etc). Quando um novo recurso comprado ou disponibilizado pela Direo Acadmica este atualizado pelo setor. Quando um dos recursos est com defeito ou em manuteno esta informao registrada e o setor de manuteno contatado. Quando um professor solicita um recurso o gerente do setor de apoio docente verifica se para a data e hora requisitada se os recursos j esto alocados ou no. Caso no estejam alocados, o setor de apoio docente faz a reserva anotando o nome do professor e sua matrcula, assim como o motivo da solicitao (aula, palestra, evento). Uma semana antes da reserva solicitada, o setor de apoio docente confirma a reserva dos recursos em contato com os professores. Em caso de solicitao de recursos mveis o funcionrio do setor de apoio docente leva uma guia de recebimento que assinada pelo professor solicitante. Ao final do uso, o professor avalia a qualidade do material enviado. Todo incio de manh o setor de apoio docente verifica quais as reservas do dia e faz a seleo dos recursos necessrios; verifica quais os recursos em manuteno e que esto para ser liberados para uso. 20

1.16 Sala Virtual.

Cenrio. O Coordenador do curso de Cincia da Computao um profissional experimentado e v na internet uma oportunidade de realizao de um ambiente de potencializao do ensino. Para tal convidou trs professores do curso para especificao deste produto. Os trs professores possuem perfis e vises diferentes sobre o projeto. Uma situao certa: a sala virtual ser feita com software livre. Caso. As Faculdades Integradas Turing Machines resolveram criar um sistema para gerenciar as aulas atravs da internet: o projeto Sala Virtual. Assim, cada disciplina estar associada a uma Sala Virtual. Neste ambiente o professor planeja suas aulas ao longo do semestre e a cada aula registra o que foi dado. Quando necessrio o professor pode cadastrar os artigos, as pginas internet e as transparncias de cada aula ministrada. Pela Sala Virtual o professor pode especificar e planejar a entrega dos trabalhos e provas estabelecendo as datas e horas limites de entrega. O professor tem opo de divulgar noticias aos alunos. O professor pode criar frum de discusso. Em determinados dias, previamente programados, o professor pode agendar uma orientao atravs da internet de um espao de discusso com tpicos previamente agendados. O professor, a partir dos alunos inscritos, pode criar grupos de trabalho. Para acessar a Sala Virtual o aluno deve se cadastrar e criar uma senha. O aluno acessa a Sala Virtual e todas as aes realizadas pelo aluno so registradas. Assim o aluno pode selecionar um artigo ou pgina da internet, assim como entregar uma prova ou trabalho. Um professor pode ter quantos ambientes de Sala Virtual ele desejar.

1.17 Acompanhamento de Atividades Complementares.

O Curso de Cincia da Computao das Faculdades Turing Machines possui em sua grade a disciplina de Atividades Complementares. Esta disciplina corresponde as atividades extraclasse necessrias a formao dos discentes e visam a integrao de conhecimentos (atividades Complementares II) e a formao do perfil profissional ( Atividades Complementares I). Assim, todo incio de semestre, os alunos se matriculam em uma dessas disciplinas. As Atividades Complementares I so compostas pelos seguintes tipos de atividades: a presena no ciclo de palestras, presena nas atividades de frum e seminrios, a realizao de cursos e a execuo de atividades profissionais internas ao curso. Desta forma, o aluno matriculado 21

ganha 20h todo semestre quando participa, com 75% de presena, de um pacote de atividades previamente agendadas para o semestre pelo coordenador do curso. Caso o aluno apresente uma lista de cursos pertinentes a sua formao as horas podem ser contabilizadas tambm, no limite de 20h. Quando o aluno possui 60h destas atividades ele fica aprovado. A cada realizao de um evento desta Atividade o professor responsvel registra a presena do aluno. Ao final do semestre o professor contabiliza as presenas e verifica os aprovados; avalia dos cursos realizados pelos alunos e atribui horas e avalia as atividades internas dos alunos e tambm atribui horas. As atividades Complementares II so destinadas a iniciao cientfica, as atividades de estagio e as atividades de extenso. Assim estas atividades possuem como caracterstica principal a orientao de um professor e ao final da atividade o aluno deve escrever um relatrio. O professor orientador faz avaliao do relatrio e atribui um conjunto de horas para o a trabalho. Nesta atividade quando o aluno atinge 60h fica aprovado. Ao final de cada semestre, o professor responsvel pela disciplina recebe dos professores orientadores a lista de horas atribuda a cada aluna e registra estas horas. O coordenador do curso, por sua vez, emite o relatrio analtico de atividades complementares que lista por aluno todas as horas de atividades complementares I e II atribudas naquele semestre e nos anteriores. Emite tambm o relatrio de sinttico de atividades complementares que lista por aluno as horas totais das Atividades I e II. Emite tambm os alunos que naquele semestre concluram tanto as atividades complementares I quanto a II.

1.18 Projeto Pedaggico.

Cenrio Institucional. A Diretora Aacadmica era uma antiga coordenadora de um dos cursos das FITM. Apesar de longa experincia na coordenao de curso no possui experincia na direo. A sua relao com o departamento de informtica difcil, pois ela no consegue entender o informatiqus daqueles profissionais. Recentemente contratou um professor do curso de cincia da computao para auxiliar neste processo de traduo de necessidades. Ao assumir a diretora necessita rever o sistema de projetos pedaggicos que dever ser confivel, seguro e gil e estar pronto no incio do prximo semestre. O sistema dever ser aprovado pelo Conselho Superior de Ensino, Pesquisa e Extenso das faculdades. Caso. A Diretora Acadmica das Faculdades Integradas Turing Machines resolveu que os coordenadores de cada curso deveriam possuir um sistema automatizado de gerncia de projetos pedaggicos. 22

Neste caso os coordenadores de curso cadastrariam a verso do currculo dos cursos assim como as disciplinas com as suas respectivas ementas, carga horria e pr-requisito. O coordenador tambm cadastraria os professores com as respectivas titularidades, a infraestrutura de laboratrio disponvel para o curso e o tcnicos de apoio. As pedagogas, por sua vez, cadastrariam o plano de estudo de cada disciplina contendo o contedo programtico, o mtodo de ensino e as formas de avaliao. As pedagogas tambm cadastrariam a bibliografia do curso e associariam cada livro a cada uma das disciplinas. Os professores de cada disciplina cadastrariam o plano de aula, registrando o que ser aplicado em cada encontro. Seria da responsabilidade dos professores o cadastro de cada programa a ser utilizado pela disciplina como os endereos internet. O coordenador teria a sua disposio o relatrio de Plano Pedaggico do Curso, as pedagogas o relatrio de Contedo Programtico e de Bibliografia disposio o relatrio de Plano de Aula. Este sistema se integraria com o sistema acadmico existente sendo responsvel pela atualizao de dados do mesmo. e os professores teriam a sua

1.19 Vestibular.
Cenrio Institucional. O Diretor Financeiro est deixando a instituio. Ele era um dos principais incentivadores do projeto, alm de um dos principais patrocinadores. O novo diretor ainda no se convenceu da necessidade do novo sistema. Nas prximas semanas far reunio com a equipe de projeto para determinar o futuro dos investimentos. A tecnologia considerada para a elaborao do projeto recente no mercado e existem poucos profissionais capazes de serem contratados. Na instituio no existem profissionais com tal qualificao. Os sistemas nesse domnio de problema ainda so incipientes no existindo uma certeza quanto aos benefcios a serem obtido com o sistema. A gerncia do projeto est a cargo de uma analista de sistemas que foi recentemente alado ao cargo de gerente de projetos. Este analista, em projetos passados, mostrou total conhecimento em tecnologia, projetando e analisando sistema eficazmente. No entanto este o seu primeiro projeto que gerenciar. Caso.

23

As Faculdades Integradas Turing Machines resolveram realizar um sistema para apoiar a realizao do seu processo seletivo. Para isso delegou a funo de organizao e operao a Coordenao do Processo Seletivo. O processo seletivo composto de Vestibular e ENEM (Exame Nacional de Ensino Mdio). Desta forma a Coordenao do Processo Seletivo divulgar na Internet o edital do respectivo processo para os interessados. Esta Coordenao registra os dados do processo do Vestibular e do ENEM, informando para cada processo o nmero de vagas disponveis por curso. O candidato interessado far a inscrio pela Internet onde registrar suas informaes pessoais, escolher um curso cursar e responder a um questionrio scio-econmico. O candidato escolher tambm entre as opes de entrada: Vestibular ou ENEM. Se a opo for por vestibular o candidato far uma prova de seleo em uma data previamente marcada. Ao final da prova a Coordenao do Processo Seletivo registra o gabarito da prova de vestibular e processar as provas. Aps o processamento esta coordenao divulgar os resultados na internet. Para o ENEM, o aluno registrar o resultado de respectivo exame no ato da inscrio e apresentar o documento comprobatrio a Coordenao do Processo Seletivo em data previamente agendada. resultado do ENEM. Ao final do processo seletivo a coordenao do processo seletivo emite os relatrios de estatstica de aprovados, de resultados scio-econmicos e de histrico de ingresso ao longo dos ltimos 5 anos. Em data previamente determinada pelo edital processado o

1.20 Seleo de Artigos para o Workshop.

Cenrio Institucional. O Vice-Reitor acadmico da Turing Machines acredita que a qualidade de ensino se faz com pesquisa e resolveu premiar os melhores trabalhos do workshop. Para agilizao do workshop o Vice-Reitor resolveu automatizar o processo de seleo e premiao de artigos atravs da internet. Assim criou um grupo de trabalho com seis professores de faculdades distintas. O sistema automatizado deve ser utilizado para o prximo evento em outubro do deste ano. A expectativa que se utilize a mais moderna tecnologia disponvel para garantir a segurana da avaliao e dos artigos enviados. Caso. As Faculdades Integradas Turing Machines solicitaram a Being Digital um sistema para a avaliao de artigos para os Workshops que organiza.

24

Assim as Faculdades divulgam as chamadas de trabalhos (artigos e posteres) informando as datas limite para envio dos trabalhos, da aceitao dos trabalhos e de envio das verses finais. Os artigos e psteres so classificados segundo as diversas sesses do workshop. O workshop possui uma comisso de professores (mximo de 20) que avaliaro os trabalhos e psteres enviados. O presidente da mesa informa os total de artigos e psteres que sero aceitos por sesso. Ao enviar os artigo o(s) Autor(es) fazem um cadastro com seus dados de endereo e de e-mail. Aps o cadastro o autor principal envia o artigo no formato especificado indicando a sesso que o artigo/pster estar concorrendo. Os trabalhos sero avaliados segundo os critrios de originalidade, relevncia do tema, embasamento terico, aplicao prtica, apresentao e importncia para o evento. Para cada um dos tpicos ser dada uma nota de zero a quatro. O presidente da comisso indicar 3 professores para a avaliao de cada artigo ou pster. Desta forma o(s) professor(es) avaliador(es) abrir(ao) o(s) artigo(s) e far(o) o registro da nota segundo os critrios estabelecidos. Ao final do processo os artigos so classificados por mdia de todas as notas registradas pelos professores avaliadores. Ao final do processo o presidente da comisso solicita o relatrio de Artigos e Psteres aprovados por sesso e autoriza o envio dos e-mails comunicando o aceite e as alteraes que devem ser feitas ou a recusa do artigo. O presidente da comisso solicita o relatrio de dados estatsticos dos artigos submetidos assim como o relatrio de ranking de classificao dos artigos. Os trs artigos de maior pontuao so enviados a todos da comisso do workshop que os avalia e o de maior pontuao recebe o prmio Turing Machines.

1.21 Elaborao de horrio.

O Coordenador do curso de Cincia da Computao das Faculdades Integradas Turing Machines resolveu automatizar o processo de elaborao do horrio. Assim todo final de semestre o Coordenador solicita aos professores a disponibilidade para o prximo semestre. Cada professor deve informar os dias da semana e os horrios disponveis para alocao (matricula, nome, dias da semana, horrio disponvel, ano, semestre). Quando necessrio o professor pode alterar sua alocao. Os professores tambm informa as disciplinas que est apto a lecionar (cdigo e nome).

25

Ao mesmo tempo o coordenador analisa as ofertas de disciplinas que ocorrero para o prximo semestre e registra todas as disciplinas que sero oferecidas (cdigo da disciplina, nome da disciplina, ano e semestre). A partir das ofertas de disciplinas e de professores o coordenador estabelece os parmetros de alocao de professores e disciplinas (ex.: priorizao de professores e de disciplinas a serem alocadas) e processa a alocao do horrio parcial. Processado o horrio parcial, o coordenador verifica se existem problemas de alocao que no puderam ser resolvidos pelos parmetros de alocao (ex.: professores que ficaram sem carga horria, disciplinas que ficaram sem professores, sobreposio disciplinas com o professor) atravs do relatrio de consistncia de horrio. O coordenador consulta o professor quanto a alocao de novos horrios e de disciplinas disponveis, de forma a fechar o horrio. Em caso positivo o professor volta a informar a sua disponibilidade. Quando o coordenador no consegue encontrar um professor do curso para uma determinada disciplina em um determinado horrio o coordenador contrata um professor substituto para a disciplina no horrio especfico. O coordenador considerando o horrio estvel o disponibiliza para os alunos que podem ento consulta-lo.

1.22 Grupos de trabalho.

O coordenador do curso de Cincia da Computao das Faculdades Integradas Turing Machines resolveu engajar mais seus professores nos processo administrativos e pedaggicos do curso. Para tal o coordenador comeou a organizar grupos de trabalho que deve ser apoiado por um sistema desenvolvido para a Web. Os grupo de trabalho so compostos por no mximo cinco professores e no mnimo trs. Cada grupo de trabalho possui um presidente que responsvel pela execuo das tarefas atribudas ao grupo. O coordenador cria um grupo de trabalho com um propsito especfico, estabelecendo uma misso, descrevendo seu propsito e os resultados que devem ser alcanados. O presidente do grupo de trabalho programa todas as reunies do grupo, estabelecendo uma data e objetivo da reunio. O presidente do grupo, quando do dia da reunio, registra a ata, os presentes e os resultados obtidos. O presidente do grupo tambm adiciona todo o material parcial e final desenvolvido pelo grupo (relatrios, fotos, apresentaes, som, vdeos). 26

Os participantes do grupo tambm podem, a qualquer momento postar qualquer material de interesse para os trabalhos. O presidente do grupo pode, em caso de conflitos, elaborar uma enqute integrantes do grupo votem em determinados assuntos. O presidente do grupo de trabalho pode solicitar ao coordenador a prorrogao do prazo para a entrega dos trabalhos. Esta prorrogao, sua nova data e com a sua justificativa, aprovada e registrada pelo coordenador para este grupo. O resultado final do trabalho deve ser aprovado pela maioria dos participantes em enquete realizada pelo presidente. Os discordantes devem registrar em relatrios os motivos que os levaram para votar contra a aprovao do relatrio final. Todo final de ms o coordenador emite o relatrio de grupos encerrados naquele ms e que grupos encontram-se em operao. O coordenador pode solicitar tambm a emisso do relatrio de reunies do grupo at uma determinada data. para que os

1.23Elaborao de Provas Unificadas.

Cenrio Institucional. Uma das caractersticas deste sistema que ser necessrio tambm possuir uma equipe experiente j que as Faculdades no possuem uma equipe interna para tal. Deve-se ter em mente que estes usurios so usurios experimentados em tecnologia da informao sendo a interface voltada para usurios experientes. O aspecto de segurana tambm deve ser considerado j que a invaso de sistemas por parte de hackers tem sido uma constante nos sistemas das faculdades. Uma das condies de operao do sistema que os professores possuam assinatura digital devidamente registrada. Assim, ao encaminhar uma prova este deve assin-la digitalmente garantindo que a prova enviada realmente sua; o mesmo ocorre com os coordenadores de curso. Caso. As Faculdades Integradas Turing Machines, com o propsito de expandir suas atividades, est abrindo novas unidades em diversos pontos da cidade. Uma das preocupaes decorrentes quanto a qualidade do ensino oferecido nestas unidades. Para tal, uma das aes programadas a da elaborao de um prova unificada por disciplina nas diversas unidades. Para a execuo desta meta cada coordenador de curso elabora e divulga um calendrio com as data limites para a entrega das provas pelos professores. O coordenador de curso divulga tambm a data da reunio geral por disciplina para a definio do formato da prova. O coordenador escolhe dentre os professores da disciplina aquele que ir coordenar o processo de elaborao das provas unificadas. 27

No dia da reunio geral o coordenador registra os professores presentes e elabora a ata da reunio e o formato de prova e os divulga posteriormente para os professores. O coordenador estabelece tambm divulga as regras de elaborao da prova. O professor registra as questes de prova e os respectivos gabaritos em um banco de provas. As provas unificadas devem ser inditas. O professor obedecendo ao calendrio envia as provas e o gabarito para o professor coordenador das provas unificadas. O coordenador registra todos os professores que enviaram as provas e os gabaritos e envia um email para aqueles que no o fizeram. O professor coordenador da prova unificada avalia a prova e a envia para o professor autor. Toda comunicao entre os professores e o professor coordenador registrada. A prova avaliada segundo os critrios de: adeso ao formato e pertinncia das questes. Em caso de faltarem provas, o coordenador obtm do banco de provas uma prova substituta. Ao final da data limite para a entrega, o coordenador do curso emite o Relatrio de Professores que Entregaram a Prova, o Relatrio de Professores que Entregaram a Prova fora do prazo e o Relatrio dos Professores que No Entregaram a Prova.

1.24Aplicao de Provas Unificadas.

Cenrio Institucional. Uma das caractersticas deste sistema que este deve ser desenvolvido utilizando a plataforma JAVA em sua plenitude e deve estar preparado para atender todos os tipos de usurios inerentes ao processo de elaborao de provas unificadas, sejam eles especialistas ou novios em informtica. Os desenvolvedores devem estudar o perfil de cada usurio identificando as tarefas que cada um realiza e as devidas necessidades de informao e perfil de formato de cada uma destas. Deve-se lembrar que estes usurios possuem diversos nveis de habilidades e de competncia quanto ao manuseio de computadores. As FITM tambm esto utilizando como referncia bsica para o arquivamento de dados o banco de dados MySQL, j que esta estabeleceu uma parceria estratgica para a utilizao deste software. Alm desta parceria as FITM esto com uma apoltica de adoo, em todas as suas unidades, de software livre, tanto para servidores quanto para os desktop da instituio. Ser necessrio tambm possuir uma equipe experiente j que as Faculdades no possuem uma equipe interna para tal. Assim a FITM ir contratar uma empresa para prover treinamento aos seus funcionrios alm de contratar consultores experientes. Estes consultores ajudaro na conduo do projeto auxiliando na reduo dos riscos de projeto. Caso As Faculdades Integradas Turing Machines com o propsito de expandir suas atividades est abrindo novas unidades em diversos pontos da cidade. Uma das preocupaes decorrentes 28

quanto a qualidade do ensino oferecido nestas unidades. Para tal, uma das aes programadas a da aplicao de provas unificadas por disciplina, nas diversas unidades. Para a aplicao das provas unificadas o Coordenador acadmico consulta o horrio de cada unidade e identifica a quantidade de turmas e de provas a serem elaboradas. Ao mesmo tempo, o Coordenador lana no calendrio acadmico as datas das aplicaes das provas unificadas por disciplina, turma e unidade. Este calendrio consultado por professores, alunos e funcionrios administrativos. O Coordenador consulta o Banco de Provas Unificadas para o semestre e atribui as provas para cada disciplina/unidade/turma. O Coordenador, ento, verifica a quantidade de alunos em cada disciplina/unidade/turma e emite o pedido de reproduo das respectivas provas para a grfica. Uma vez produzidas pela grfica as provas so entreguem a coordenao que registra o recebimento das provas por disciplina/unidade/turma. As provas so, ento, encaminhadas a cada unidade e recebidas pelos funcionrios do apoio docente que registram o recebimento das provas. O Coordenador pode, quando necessrio, solicitar o Relatrio de Horrio Escolar por Unidade (dia da semana, horrio, disciplina), o Relatrio do Calendrio Escolar (dada e atividade), o Relatrio de Produo Grfica das Provas Unificadas (disciplina/unidade/Turma, quantidade, data da entrega), o Relatrio de Recebimento de Produo (disciplina/unidade/turma, quantidade recebida e data da entrega), Relatrio de Recebimento das Provas Unificadas pela Unidade (disciplina/unidade/turma, data recebimento, funcionrio administrativo). Cenrio de Desenho. O Coordenador possui um computador em sua mesa, assim como a sua secretria que encarregada de emitir os seus relatrios gerenciais. Cada funcionrio administrativo de cada unidade tambm possui um computador para a emisso de relatrios e registros diversos. As FITM possuem um servidor central que realiza todas as atividades computacionais da instituio. Devido a crise que atravessa as FITM apenas 70% das funcionalidades do sistema sero implementadas. Dos cursos que so oferecidos, apenas uma nica disciplina de cada perodo ter prova unificada. A produo das provas unificadas ocorre uma nica vez ao longo do semestre e a sua realizao apenas na segunda prova (A2).

1.25Solicitao de reviso de provas.

Cenrio Institucional. O processo de reviso de provas visa estabelecer um parmetro deve ser seguido em todas as unidades, garantindo que a reviso das provas sejam justas todos os alunos. Um dos 29

aspectos crticos deste sistema quanto a conduo deste processo e do registro de toda a documentao correlata. Uma das caractersticas deste sistema que este deve ser desenvolvido utilizando a plataforma JAVA em sua plenitude e deve estar preparado para atender todos os tipos de usurios inerentes ao processo de elaborao de provas unificadas, sejam eles especialistas ou novios em informtica. Deve-se lembrar que estes usurios possuem diversos nveis de habilidades e de competncia quanto ao manuseio de computadores. As FITM tambm esto utilizando como referncia bsica para o arquivamento de dados o banco de dados MySQL, j que esta estabeleceu uma parceria estratgica para a utilizao deste software. As FITM possuem uma equipe experiente, entretanto no possuem um gerente hbil para a construo deste sistema. Uma das possibilidades e a promoo de um de seus integrantes a gerente de projetos. Apesar da entrada crescente do nmero de alunos na instituio, as FITM possuem um oramento restrito para a construo deste projeto, R$100 mil, alm de ter a necessidade de termina-lo em, no mximo, cinco meses. Caso. Objetivando dar maior transparncia no processo de avaliao acadmica, a Direo Acadmica implantou um processo reviso de provas. Desta forma, o professor sempre que corrigir a prova deve entregar ao apoio docente o conjunto de provas corrigidas que registra o recebimento das mesmas (disciplina, turma, data do recebimento e lista nominal da provas). Aps o registro o apoio docente providencia a digitalizao das mesmas. O aluno que deseja reviso de provas deve fazer um pedido na secretaria da escola (disciplina, turma e tipo de prova). A secretaria encaminha ao apoio docente esta solicitao que providencia uma cpia da prova anexando-a ao processo. O apoio docente comunica ao professor da existncia de pedido de reviso de prova. O professor de posse do processo reduz, mantm ou aumenta o grau atribudo fazendo as devidas justificativas e divulga o seu laudo. O aluno pode recorrer a uma outra instncia, a de conselho de professores, atravs de um novo pedido na secretaria. Neste caso o coordenador seleciona dois professores para avaliar a prova. No processo de avaliao, caso um concorde como laudo do professor da disciplina, a nota mantida. Em caso de discordncia dos dois professores a nota mais baixa, dentre as duas, lanada. Em qualquer um dos casos, os professores devem realizar um laudo da prova revista.

30

A secretaria do curso pode emitir o relatrio de Solicitao de Pedidos de Reviso de Prova. O apoio docente pode emitir o relatrio de Pedidos de Reviso de Provas Concludos e de Estado de Reviso de Prova.

1.26Avaliao de Trabalho de Concluso de Curso.

Cenrio Institucional. O novo Diretor Acadmico est preocupado com as recorrentes reclamaes de notas dos trabalhos de concluso de curso. Para tal definiu um processo para o controle e o acompanhamento destes trabalhos. O Colegiado de professores j aprovou o processo, porm est ainda reticente quanto ao prprio processo. Entretanto acredita que este processo, da forma que est, ajudar na resoluo de vrios conflitos. O prazo para a implementao deste processo o prximo semestre e dever ser feito utilizando softwares no-proprietrios. Caso. As Faculdades Integradas Turing Machines resolveram estabelecer um regulamento de avaliao de trabalhos de concluso de curso de forma a formalizar esta atividade. Um trabalho de concluso de curso feito por um ou mais alunos e possui a superviso de um professor, podendo ter, em alguns casos, um professor orientador. Todo incio de semestre o professor orientador pode aceitar a orientao de novos grupos de trabalho de concluso de curso. Aceitando o professor orientador responsvel pelo cadastramento do grupo e do perfil do projeto que ser desenvolvido (objetivos, descrio sumrio, recursos, cronograma inicial etc.). Ao longo do semestre, o professor realiza, a seu critrio, laudos de acompanhamento a respeito da evoluo do trabalho. Os alunos do grupo podem acessar estes laudos. Um ms antes do final do semestre o professor pode agendar a data de apresentao do trabalho de concluso de curso. Assim que esta data confirmada o Coordenador do curso seleciona 2 professores para comporem a banca. O trabalho de concluso de curso avaliado pelos professores da seguinte forma: a nota da apresentao de cada aluno, a nota do trabalho escrito, a nota do produto gerado (software, aulas, pesquisa). O orientador lana tambm a nota de orientao que individual para cada aluno. Aps a apresentao as notas so computadas e o presidente da banca elabora uma ata de avaliao com as correes determinadas pela banca avaliadora. O grupo possui uma semana para entregar todas as correes feitas, sob pena de perder o projeto. Caso o trabalho seja aprovado o professor orientador atualiza estado do grupo para aprovado. 31

O Coordenador de curso pode a qualquer momento emitir o relatrio de Grupos Aprovados no Semestre, Alunos Aprovados no Semestre e de Laudos Acompanhamento dos Grupos de Trabalho de Concluso de Curso.

1.27Sistema de pagamentos de Contratos

Cenrio Institucional.
As Faculdades Integradas Turing Machines(FITM) resolveram capacitar seu pessoal de informtica (DINFO Diviso de Informtica) para iniciar o desenvolvimento de sistemas baseados em orientao a objetos. Para tal contratou um curso de capacitao. Os sistemas passaro a ser desenvolvidos em Java utilizando-se de Hibernate e Mysql. Alm deste ambiente de produo os sistemas necessitaro de software de apoio dentre eles j esto escolhidos o Jude e o Eclipse. Caso. As Faculdades Integradas Turing Machines necessitam de um sistema que automatize os processos de pagamentos de funcionrios contratados temporariamente. A estrutura das Faculdades composta por vrios Centros e cada Centro composto de vrios Departamentos que por sua vez possuem vrios cursos. Para processar o sistema de pagamentos de contratos as FITM necessitam cadastrar os descontos de IR e de INSS, assim como os cargos e seus respectivos salrios. Cada departamento possui autonomia para registrar seus contratados. Na ocasio o profissional cadastrado necessita informar seu cpf, nome, data do nascimento, banco onde possui conta, identidade, o tempo de vigncia do contrato e o cargo a ser preenchido. O mesmo profissional pode ser contratado em mais de um departamento. Ao final do ms as FITM processam a folha de contratados, consolidando-a por CPF. A partir da folha de pagamento gerado o contra-cheque do ms. A empresa, a qualquer momento pode solicitar o relatrio de contratados e cada departamento, do mesmo modo, pode solicitar o relatrio de contratados pelo departamento. Cenrio de projeto. Devido complexidade geogrfica do campus das FITM apenas dois Centros implantaro este novo sistema. O volume de contratos por Centro da ordem de 20 contratos por ms. Cada Centro ter um computador em sua secretaria para processar os contratos assinados. Estes contratos, quando efetivados, sero transmitidos para a Diviso Geral de Informtica que possui um servidor que processar a folha. O sistema operar atravs a internet.

32

2. A Empresa Jnior.
2.1 Caracterizao do ambiente.
A empresa de consultoria Being Digital resolveu, depois de cinco anos de atuao no mercado, automatizar vrias atividades que considerava importante para a atuao em seu nicho de mercado. Para tanto decidiu automatizar vrias de suas tarefas internas tais como de estimativas, avaliao de produto, especificao de processo, gerenciamento de grupos de trabalho, banco de horas trabalhadas entre outras. Estes sistemas compem um conjunto de softwares para a gerncia interna do trabalho.

2.2 Produtos internos de gerncia.

2.2.1Estimativas.
Cenrio Institucional. O Diretor Executivo da Being Digital o maior patrocinador do sistema. Ele conta tambm com o apoio do Diretor de Projetos. O escopo bem definido e delimitado. A princpio no h resistncia interna ao projeto. Este considerado um projeto estratgico para a empresa. Os gerentes de projetos e especialistas tambm do apoio ao projeto. Caso. A empresa Being Digital resolveu desenvolver um sistema que apoiasse a atividade de estimativas de projetos de software. Desta forma, ao iniciar um projeto de software o gerente de projetos cadastra o projeto (nome, data de incio, cliente, setores envolvidos, objetivo do projeto e restries). A partir do registro do projeto, o gerente de projeto cadastra todos os requisitos funcionais do sistema para a verso do sistema a ser desenvolvido. Para calcular as estimativas do projeto, o gerente de projeto seleciona um conjunto de especialistas para estimar cada requisito do software. As estimativas so feitas em pontos por funo. Para cada requisito so feitas trs estimativas: a otimista, a pessimista e a ideal. Aps uma reunio com todos os especialistas definido os valores finais de cada requisito. A partir destes valores calculada a estimativa ponderada segundo a frmula: estimativa ponderada = (estimativa otimista + estimativa ideal * 4 + estimativa pessimista)/6. Calculada a estimativa ponderada, o gerente de projeto transforma o total de pontos por funo, calculada a partir da soma de todas as estimativas ponderadas de cada requisito, os 33

pontos de funo so transformados em linhas de cdigo, atravs de uma tabela especfica de correlao entre linhas de cdigo e pontos por funo. Com o total de linhas de cdigo estimadas o gerente de projeto utiliza o mtodo COCOMO para estimar o tamanho da equipe e o tempo de desenvolvimento. Ao final deste processo o gerente de projeto emite o relatrio de tamanho do projeto, o relatrio de requisitos e o relatrio de estimativas por especialistas.

2.2.2Avaliao de produto.
Para a avaliao de produtos de software a Being Digital se baseia na ISO9126/NBR13596. Desta forma para cada produto de software avaliado considerando as seguintes caractersticas de qualidade: funcionalidade, manutenibilidade, portabilidade, confiabilidade e usabilidade. O gerente do processo de avaliao registra o software a ser avaliado, os critrios (notas em cada caracterstica) para a aceitao do software e os pesos para cada caracterstica. A empresa escala um Juiz Principal que associa cada item de qualidade a um tipo de viso de qualidade: do desenvolvedor, do gerente e de usurio. O critrio de julgamento final de cada qualidade definido utilizando-se uma escala de 1 a 5. O Juiz pode consultar um manual on-line para obter orientao de como julgar as caracterstica. Para efetivao do julgamento o Juiz Principal escala mais dois Juizes Auxiliares que faro a avaliao dos softwares solicitados. As notas de cada juiz so armazenadas. Ao final da avaliao dos Juzes o Juiz Principal emite o Relatrio Tcnico de Avaliao com as notas e comentrios individuais de todo as caractersticas avaliadas, assim como o Relatrio de Resultado Consolidado com a respectiva aprovao ou no. eficincia,

2.2.3Gerenciamento de Grupos de Trabalho.

A Being Digital est necessitando gerenciar melhor os projetos de atendimento seus clientes. Desta forma ela dividiu seus empregados em grupos de trabalho de dois tipos: grupos de cliente e grupos de apoio. Estes grupos, os projetos e os clientes so criados pelo Diretor Executivo. Os grupos de cliente realizam vrias tarefas do projeto no cliente como, por exemplo: levantamento, anlises, implementao ou manuteno de um sistema. Cada grupo de cliente possui uma equipe bem definida: composta de um lder de equipe, um analista, um programador e uma secretria. Cada grupo de cliente pode ser responsvel por zero, um ou dois clientes. O lder do grupo que o responsvel pelo lanamento das tarefas realizadas pelo mesmo. 34

Os grupos de apoio ajudam os grupos de cliente em seu atendimento aos clientes. Um grupo de apoio atende a no mximo dois grupos de clientes. A composio deste grupo de um lder de apoio, um analista e de dois programadores. o Diretor de projetos que atualiza o estado de um grupo de trabalho. Um gerente de projeto gerencia um, e no mximo, trs grupos. o Diretor de Projetos que determina, para um determinado projeto, quem ser o gerente e os respectivos grupos. Semanalmente o Diretor executivo emite o relatrio de Grupos de Trabalho contendo os perfil das equipes e seus principais clientes. Cabe ao Diretor de Projetos emitir o Relatrio de Tarefas realizado por uma equipe em um determinado projeto.

2.2.4Qualificao profissional.
Cenrio Institucional. O Diretor de Recursos Humanos da Being Digital novo na organizao. Para conhecer melhor seu quadro funcional resolveu desenvolver um currculo eletrnico. O Diretor de Projetos acha a medida ineficaz e no est disposto a alocar pessoal para a construo deste sistema. O Diretor de Marketing v o projeto como uma oportunidade de venda e de comercializao deste produto e quer lana-lo antes do carnaval. O Diretor Financeiro j alocou verba para a execuo do mesmo. Caso. A empresa Being Digital sabe que nos dias de hoje a qualificao profissional de seus funcionrios muito importante. Desta forma resolveu registrar o perfil de profissional de seus empregados e de suas respectivas equipes. A Direo de Recursos Humanos que responsvel pela elaborao do currculo padronizado. Assim todo profissional da empresa ter que registrar os seguintes dados: seus dados pessoais, a formao universitria; certificao e qual tipo; o conhecimento de lnguas, principalmente o portugus, o ingls, o espanhol e o francs; os eventos que cada funcionrio participou como palestrante; os artigos publicados; o tipo de experincia profissional que possui organizado por ano, tipo de atividade (programao, analista de sistemas, analista de negcios, gerente de projetos, auditor de qualidade, testador, outros), a descrio da atividade, a empresa; quais os cursos livres realizados (ano, descrio, ttulo , empresa); se possui os no ps-graduao (Latu Sensu ou Strictu Sensu) indicando o ano em que se formou e a instituio emissora do diploma e a titulao obtida. Os profissionais devem indicar tambm quais as outras atividades esportivas e artsticas de interesse.

35

O profissional deve tambm informar qual a equipe a qual ele pertence no momento. O Diretor de Projetos o responsvel pela abertura das equipes assim como pelo seu encerramento. Ao final de cada semestre o Diretor de Recursos Humanos avalia a qualificao de cada equipe a partir do relatrio de qualificao de cada equipe. Cada item do currculo est associado a uma pontuao definida pelo Diretor de Recursos Humanos de forma a quantificar a formao dos profissionais. Por sua vez o Diretor de Projetos analisa o perfil de cada funcionrio e sua evoluo tcnica ao longo do semestre a partir do relatrio de perfil do funcionrio.

2.2.5Banco de Horas.
A empresa Being Digital possui uma poltica flexvel quanto ao horrio de trabalho de suas equipes, no exigindo horrio rgido de trabalho. Ao chegar o funcionrio registra sua hora de entrada e ao sair a sua hora de sada. Ao longo do dia, ao executar uma determinada tarefa, o funcionrio registra o total de horas dedicadas a atividade. Se ao longo da semana for registrado um total de horas acima das 44h estas horas ficam registradas como crdito. Apenas o gerente de projeto pode autorizar a utilizao dos crditos do funcionrio de sua equipe. Pode autorizar o pagamento de horas extras ou a compensao em um determinado dia ou dias. Todo final de quinzena emitido o relatrio de banco de horas por equipe que lista as horas de trabalho de cada funcionrio assim como seus crditos para o gerente da equipe. Quando o total de horas semanal for inferior a 30h ou superior a 50h emitido quinzenalmente o relatrio de produtividade da equipe.

2.2.6Identificao de requisitos.
A empresa Being Digital resolveu desenvolver um sistema que apoiasse a identificao de seus requisitos de software. Nesse sistema o gerente de projeto registra o projeto (nmero, cliente, data d abertura) e a misso do produto. Aps a anlise inicial do caso em mos o gerente de projeto registra os tipos de levantamento que sero pertinentes ao ambiente (entrevista, observao, JAD, brainstorm, PIECES, outros) justificando a utilizao ou no de cada um destes. O gerente de projeto escolhe tambm o tipo de estratgia que ser executada ao longo do projeto (cascata, espira e prototipao) justificando a sua escolha.

36

Os analistas de negcio registram os requisitos (nmero, descrio, necessidades e benefcios) descrevendo as suas necessidades e seus benefcios. Este verificam tambm quais os requisitos de qualidade (nmero, descrio) sero considerados, sendo estes classificados de acordo com o tipo (ex.: confiabilidade, manutenibilidade, usabilidade) justificando-os. Os analistas de negcio registram os principais atores e seus respectivos perfis (numero, nome, descrio, escolaridade, conhecimento de informtica). Os analistas de riscos registram as restries impostas ao projeto (numero, descrio) classificando quanto ao seu tipo (ex.: oramentria, pessoal, legal etc). Em datas previamente agendadas o gerente de projeto realiza uma inspeo dos itens registrados a partir de uma lista de verificao (numero, item a ser avaliado, o que deve estar registrado, nota de observao) previamente definida. O mesmo feito junto ao Cliente do projeto.

2.2.7Especificao de requisitos.
Cenrio Institucional. A Being Digital atravs de seu diretor de operaes convocou seus principais gerentes de projetos para a construo de um sistema de outros do Prxis e, ainda outros do XP. Caso. A empresa Being Digital necessitando melhorar seu processo de especificao de requisitos resolveu automatizar parcialmente o seu processo de anlise. Assim o gerente de projeto a partir de um projeto j existente autoriza o incio da etapa de anlise. Os analistas de negcio, dando incio ao processo de anlise, registram os casos de uso do sistema (nome, ator, fluxo principal, fluxo alternativo) assim como informaes associadas a estes tais como regras de negcio cobertas identificando atravs de um nmero, descrio textual e quando necessrio uma descrio formal. Os analistas de interface registram para os casos de uso identificados as interfaces (numero, descrio, seus atributos e diagrama de estados). Os analistas de desenho definem a partir de cada caso de uso os requisitos de desempenho associados a cada um deles registrando a freqncia de uso, o volume de dados e o tempo de resposta esperado. Por fim os analistas de dados, a partir da descrio textual dos casos de uso registram as classes, sua especialidade (fronteira, controle e entidade), sua responsabilidade e suas colaboraes. 37 uma especificao de requisitos. Entretanto os gerentes esto divididos quanto ao formato final, pois uns so devotos do processo do RUP,

Em datas previamente agendadas o gerente de projeto realiza uma inspeo dos itens registrados a partir de uma lista de verificao (numero, item a ser avaliado, o que deve estar registrado, nota de observao) previamente definida. O mesmo feito junto ao Cliente do projeto.

2.2.8Gerenciamento de riscos de projeto.

Cenrio Institucional. Depois de alguns fracassos na construo de alguns softwares a Being Digital resolveu apoiar a prtica de gerenciamento de riscos, ou seja, a identificao de algum fato adverso que venha ocorrer impedindo ou complicando a construo de um software. Os custos destes fracassos somas a ordem de R$ 1milho, assim a Being Digital alocou para este projeto R$200 mil reais de forma a evitar que novas surpresas ocorram. Alm disso, alocou seus melhores profissionais para a execuo do mesmo. Entretanto devido as necessidade de se evitar desperdcio o projeto dever ter no mximo dois meses de execuo, quando deve estar pronto para operar. O levantamento do sistema, devido ao seu carter estratgico deve ser feito apenas com o presidente e com os diretores da empresa. Caso. Depois de alguns fracassos na construo de alguns softwares a Being Digital resolveu apoiar a prtica de gerenciamento de riscos, ou seja, a identificao de algum fato adverso que venha ocorrer impedindo ou complicando a construo de um software. Assim o gerente de projeto ao incio de cada projeto ir identificar trs tipos de riscos: relacionados ao projeto, relacionados ao produto que est sendo construdo e os riscos de negcio. Aps a identificao o gerente de projeto com a sua equipe de analistas devem analisar os riscos. Esta anlise descreve para cada risco a probabilidade de ocorrncia do risco, caracterizada como muito baixa (menor que 10%), baixa (entre 10% e 25%), moderada (entre 25% e 50%), alta (entre 50% e 75%) e muito alta (maior que 75%). Os efeitos da incidncia dos riscos so caracterizados como catastrfico, srios, tolerveis ou insignificantes. Esta anlise ocorre vrias vezes ao longo do projeto em reunies especficas agendadas pelo gerente de projeto. Nesta reunio, tambm, o gerente e sua equipe selecionam para monitoramento os 10 riscos mais crticos. Alm da identificao e anlise dos riscos, o gerente de projeto, junto com o usurio patrocinador do projeto, estabelece estratgias classificadas como preventivas ou de minimizao ou de contingncias para cada requisito e que visam gerenciar a ocorrncia do mesmo ou evitar que este acontea. 38

Quando ao longo do projeto um dos riscos acontece de fato, o gerente de projeto registra todas as atividades previstas nas estratgias e registra todos os fatos previstos ou no para o tratamento do mesmo. O gerente de projeto emite a cada reunio gerencial o relatrio de riscos associados ao projeto e suas respectivas estratgias de ao; assim como o relatrio de problemas com os seus respectivos acompanhamentos. Todos os riscos e os acontecimentos de um projeto ficam armazenados em um banco de dados disponveis a todos os projetos da empresa.

2.2.9Verificao/Inspeo de software.
Cenrio Institucional. De forma a manter a qualidade de seus projetos a Being Digital procura seguir com rigor normas, mtodos, tcnicas e processos de software. A verificao/inspeo uma dessas tcnicas que auxiliam na garantia da qualidade e da entrega dos sistemas. Um dos aspectos iniciais para a adoo das tcnicas de verificao e inspeo de projetos foi o treinamento de toda a sua equipe de profissionais que realizaram cursos nesta rea. A partir da criao de uma cultura de verificao e inspeo a Being Digital iniciou um processo de construo de um sistema para garantir a qualidade de seus projetos. Depois de alguns fracassos na construo de alguns softwares a Being Digital resolveu apoiar a prtica de verificao e inspeo, ou seja, a verificao parcial de vrios produtos intermedirios gerados a partir de um processo de construo de software. Os custos da baixa qualidade dos softwares construdos somam ordem de R$ 1milho, assim a Being Digital alocou para este projeto R$250 mil reais de forma a evitar que novas surpresas ocorram. Alm disso, alocou seus melhores profissionais para a execuo do mesmo. Entretanto devido as necessidade de se evitar desperdcio o projeto dever ter no mximo trs meses de execuo, quando deve estar pronto para operar. O levantamento do sistema, devido ao seu carter corporativo ser feito atravs de uma comisso especialmente criada para tal. O sistema em questo deve operar utilizando-se de plataformas livres tais como Linux, ArgoUML, Hibernate, Jboss dentre outros. A poltica institucional est totalmente voltada para a utilizao deste tipo de softwares. Caso. A Being Digital resolveu assegurar a qualidade de seu processo de desenvolvimento de software atravs da utilizao de inspees de cdigo. Para a realizao da inspeo de cdigo o Gerente de projeto em questo escolhe o programador, autor do cdigo, convida dois inspetores de cdigo para fazer a anlise do 39

cdigo, uma analista que atua como relator da inspeo, e um moderador que pode ser o prprio gerente ou outro gerente de projeto. O processo de inspeo ocorre em quatro atividades: planejamento, reunio de inspeo, emisso do laudo de inspeo e acompanhamento. Na etapa de planejamento o moderador especifica o objetivo da inspeo, classifica a importncia da inspeo, seleciona a equipe de inspeo, assim como o componente de software que ser inspecionado, marca uma sala de reunies e identifica os materiais correlatos que devem ser apresentados e especifica o padro ou norma pelo qual a documentao ser avaliada. No dia da reunio o autor do cdigo apresenta o componente de software e os documentos correlatos. Os inspetores avaliam o cdigo e identificam erros. Ao final da reunio a equipe de inspeo elabora um laudo contendo todos os defeitos encontrados no cdigo. Como laudo pronto o gerente de projeto acompanha o retrabalho do programador registrando as melhorias. Estas melhorias ficam associadas ao processo de inspeo em questo. Dependendo da importncia da inspeo o gerente pode convocar outra reunio ou simplesmente dar por encerrado o processo. Cabe ao moderador especificar e atualizar as normas de inspeo, adaptando-as s novas necessidades da empresa. Na atual verso de inspeo seis classes de defeitos so consideradas: defeitos de dados, defeitos de controle, defeitos de entrada e de sada, defeitos de interface, defeitos de gerenciamento de armazenamento e defeitos de gerenciamento de excees. O gerente de projeto pode emitir os relatrios de reunies agendadas, os laudos especficos de cada inspeo e os integrantes da cada reunio. Cenrio de Desenho. A empresa ir dispor de mais R$50 mil reais para o processo de automao deste projeto porm apenas 80% das funcionalidades identificadas inicialmente sero consideradas. Desta forma a arquitetura bsica ter um servidor de aplicao e de banco de dados dedicados alm de um servidor WEB cada um instalado em mquinas distintas.

2.3 Solicitao de Clientes.

2.3.1O pipoqueiro da esquina.
A empresa Being Digital recebeu uma solicitao de sistema inusitada: o pipoqueiro da esquina resolveu automatizar a gerncia de seu carrinho de pipoca. A primeira providncia foi comprar um Palm. Agora ele quer um sistema que rode em seu computador de mo.

40

Em primeiro lugar o pipoqueiro deseja registrar as vendas realizadas. Ele vende dois tipos de pipoca, a doce e a salgada, sendo que cada tipo possui trs tamanhos: pequena, mdia e grande. Cada tipo de pipoca vendido est associado a uma quantidade de insumos necessrios sua produo. Por exemplo, para cada pipoca salgada grande necessrio: 0,001 do valor do botijo de gs, 10g de sal, 80g de milho e 0,1 hora de mo de obra e um saquinho. Assim para cada venda de pipoca o pipoqueiro deduz a respectiva quantidade correspondente do estoque. Todo domingo o pipoqueiro realiza um inventrio de seus insumos (gs, saquinho, milho, nescau, sal, etc). Ao faz-lo, para cada produto utilizado, este anota o valor real do estoque, gerando o relatrio de inventrio. Aps realizar o inventrio o pipoqueiro verifica o valor indicado de estoque. Caso existam diferenas entre valor do estoque e o valor obtido do inventrio estas so anotadas em um relatrio de diferena de inventrio, para cada produto. Para manter a qualidade de seus servios, o pipoqueiro compra apenas produtos e marcas selecionadas. Ao comprar um produto o pipoqueiro anota o preo da mercadoria. Ao registrar o preo dos produtos comprados o pipoqueiro atualiza o preo de custo de cada produto vendido. Aps a atualizao de preos o pipoqueiro entra com a margem de lucro e o valor final de cada produto calculado. Alm de produzir os seus prprios produtos o pipoqueiro revende produtos de terceiros tais como cocadas e ps-de-moleque. Nesses casos o pipoqueiro entra com o preo de custo e com a margem de lucro. O pipoqueiro somente solicita mais destes produtos quando o estoque acaba. Antes de repor esses produtos o pipoqueiro produz o relatrio de quanto tempo o estoque foi vendido (em dias). O pipoqueiro, procurando diversificar sua atuao, tem aceitado convites para participar de festas infantis. Neste caso o pipoqueiro estabelece um preo fixo e registra a data, a hora, o local e o contato. Durante o evento o pipoqueiro registra todas as solicitaes de sacos de pipoca e de produtos de terceiro. Aps o evento o pipoqueiro registra o lucro obtido a partir da receita recebida e do consumo total da festa.

2.3.2O vendedor de sandwich natural.

Um vendedor de sandwich natural resolveu requisitar a empresa Being Digital um sistema. Ele estava cada vez mais impressionado com a tecnologia sem fio e vislumbrava a automao de seu negcio atravs do uso desta. O vendedor possui dois tipos de sandwich natural: o normal e o light. So trs as variedades de sandwich normal e duas light.

41

Todo o final do dia o vendedor verifica as vendas realizadas diariamente por tipo de sandwich no relatrio de Vendas Dirias. Ao final da semana ele consolida as vendas realizadas diariamente, no relatrio de Vendas Semanais. Cada sandwich possui uma composio que precisamente controlada de forma a manter a qualidade do mesmo. Por exemplo, para o sandwich light de ricota necessrio: 100g de ricota, dois pes de forma, 5g de sal etc. Assim, para cada venda de sandwich equivale a reduo das respectivas quantidades do estoque. Assim a cada conjunto de sandwich produzido o equivalente em estoque deduzido da Planilha de Estoque. Quando o estoque est abaixo do nvel determinado pelo vendedor este vai a quitanda da esquina repor o estoque. Para cada produto comprado o vendedor atualiza a Planilha de Estoque. Para manter a qualidade de seus servios, o vendedor compra apenas produtos e marcas selecionadas. Ao registrar o preo dos produtos comprados, o vendedor atualiza o preo de custo de cada produto vendido assim como atualiza as margens de lucro na Planilha de Lucratividade. Ao final do ms o vendedor realiza um inventrio de seu estoque. Ao faz-lo, para cada produto utilizado, este anota o valor real do estoque na Planilha de Inventrio e confere com a Planilha de Estoque. As diferenas so anotadas na Planilha de Estoque, atualizando o estoque. Devido ao sucesso de seus produtos o vendedor de sandwich tem recebido solicitaes de pipoqueiros desejosos em diversificar seus negcios para tal o vendedor registra estas solicitaes na Planilha de Pedidos de Sandwich. Quando a entrega feita esta mesma planilha atualizada. Todo final de semana o vendedor elabora o Relatrio de Pedidos em Aberto e o Relatrio de Pedidos Atendidos.

2.3.3A casa de festas.

A empresa Being Digital vislumbrando o mercado alternativo resolveu atender a um pedido da Casa de Festa Infantil Aquarela. do interesse desta casa de festas utilizar software livre. A Casa possui dois horrios: o da manh e o da tarde. O cliente pode escolher fazer uma festa para 80, 100 ou 120 pessoas. A Casa possui vrios motivos de festa que so escolhido pelo cliente. A casa dispe tambm de vrios tipos de buffet. A Casa tambm oferece servios extras: por exemplo, a casa pode colocar uma mesa de frios que contratado parte. O mesmo ocorre para o servio de bebidas mais sofisticadas para os

42

adultos, que tambm pode ser contratado. A Casa de Festas pode disponibilizar, tambm, a presena de personagens infantis. A Casa possui vrias equipes de animao. O cliente pode solicitar uma equipe especfica para a festa. Cada equipe composta de um animador chefe e cinco auxiliares. Ao fechar um contrato o gerente da casa de festas anota o nome, o endereo, o telefone e o email do cliente. Anota tambm a forma de pagamento. Todas estas informaes so registradas no Ficha de Plano de Festa. Para garantir a festa so cobrados 20% do valor orado no contrato. a partir das informaes da Ficha de Plano de Festa que emitido o Contrato de Festa para o cliente. A casa de festas somente atende a cliente que marcam visita. O cronograma de visitas registrado no Ficha de Atendimento ao Cliente. No dia da festa a recepcionista registra os nomes dos convidados na Planilha de Convidados. Ao final da festa a gerente emite o Relatrio de Balano de Festa que calcula se houve excedente de convidados. Alm do balano final da festa, o cliente preenche uma ficha de avaliao da festa e a entrega para a gerente. Toda Segunda feira a gerente da festa emite o relatrio da programao contratada para a semana. E, todo ltimo dia do ms o gerente solicita o relatrio de taxa de utilizao da casa naquele ms.

2.3.4A festa de casamento.

A empresa Being Digital recebeu uma solicitao de uma equipe de cerimonial, Dias Felizes, que realiza festas de casamento. A equipe de cerimonial registra os diversos tipos de salo de festa com o respectivo preo e facilidades (ex:. estacionamento, espao para dana etc.); registra os floristas e decoradores destas festas (preo cobrado, nome e telefone); os vrios servios de aluguel de carros; assim como os servios de buffet. O cerimonial oferece servios de entrega de convites para a festa. Nesse caso o cerimonial registra o nome, o telefone e o endereo de todos os convidados para a festa e providencia a entrega dos mesmos. O cerimonial oferece, tambm, servios de lista de casamento, atravs de convnios que possui com lojas de departamento e lojas de presentes. Neste caso o casal escolhe trs opes de lojas e a partir delas elabora uma lista de presentes a partir dos produtos comercializados nestas lojas. 43

Quando um casal solicita um oramento de uma festa de casamento o cerimonial elabora uma configurao de casamento atendendo s respectivas necessidades e emite uma proposta de festa de casamento. Aceita a proposta, o cerimonial confirma com seus fornecedores os preos e os servios. A partir da confirmao da proposta pelos fornecedores, o cerimonial elabora o contrato para a festa. Todo incio de ms o cerimonial imprime o relatrio de festa do ms.

2.3.5Economia Domstica.
Cenrio Institucional. A dona Amlia de casa que tem medo de qualquer artefato tecnolgico. Gosta mesmo de anotar tudo em papel. Seu filho, no entanto, tem incentivado ela a entrar na era da informtica e da internet. Ela no est bem segura quanto necessidade de controlar seus gastos em um sistema computadorizado, porm ela est disposta a tentar. Como os gastos esto sempre sob controle ela no admite que gaste em um sistema como este mais do que R$200,00. Caso. A empresa Being Digital recebeu uma solicitao de uma dona de casa ansiosa para controlar os seus gastos domsticos. A dona de casa resolveu cadastrar todos os supermercados em que faz compra de forma a poder comparar os preos dos produtos e comprar naquele que for mais barato, assim como fez um cadastro de todos os produtos que fazem parte de seu acervo de compras. Toda semana, antes de realizar as compras de ms, a dona de casa verifica a necessidade de compra de cada produto no estoque e registra as quantidades necessrias para repor o mesmo. Para garantir o preo mais baixo a dona de casa envia a sua assessora de forno e fogo para pesquisar os preos das mercadorias em dois supermercados escolhidos por ela. A assessora anota os preos de todas as mercadorias solicitadas, entregando a dona de casa a referida lista de preos pesquisados que providencia a atualizao dos mesmos. Com base nos preos pesquisados a dona de casa verifica aquele com o preo total mais baixo e decide fazer as compras de ms neste supermercado. Aps a escolha do supermercado a dona de emite o relatrio de Evoluo dos Preos dos ltimos cinco meses. Neste relatrio, alm dos preos listados por supermercado, so destacados o preo mais baixo, o preo mais alto, a mdia e a necessidade de compra. No supermercado a dona de casa registra os preos de cada produto comprado. Ao final das compras a dona de casa emite o relatrio de Economia Domstica que contm o quanto ela esperava gastar e quanto ela gastou. 44

2.3.6Finanas Domsticas.
Uma dona de casa em vista da atual conjuntura econmica e tecnolgica resolveu ampliar automatizar o seu processo de controle de gastos com a casa. Para tal ela deseja utilzar um sistema desktop que permita a conexo com um palm. A dona de casa classificou todas as despesas e receitas domiciliares em contas especficas atravs de um cdigo e de uma descrio (ex.: 01-salrio da empregada, 02-despesas mdicas, 03-colgio das crianas etc.). Cada conta pode ser de dois tipos: receita e despesa. Assim todo incio de ano a dona de casa planeja todos os gastos ao longo do ano informando ms a ms os valores de cada conta de despesa controlada. A dona de cada tambm informa as receitas planejadas ms a ms para cada conta de receita (ms, cdigo da conta e valor). Todo final de dia, o marido e os filhos prestam conta das despesas e das movimentaes financeiras efetuadas (data, cdigo da conta e valor). O marido informa os gastos reais efetuados assim como as crianas. Cabe ao marido o registro de todos os cheques emitidos e de todas os recibos do carto de crdito. Ao final do ms, ao receber o extrato bancrio e o extrato do carto, cabe tambm ao marido a conciliao dos cheques e recibos (data, cdigo da conta, cdigo do cheque ou do recibo, valor). Semanalmente a dona de casa emite o relatrio de gastos correntes e verifica quais contas esto dentro do limite de gastos. O mesmo relatrio e feito mensalmente, na presena de todos da famlia.

2.3.7Estudante Organizado.
A empresa Being Digital recebeu uma solicitao de um estudante para ajudar no planejamento e controle de seus estudos ao longo do semestre. Este sistema deve ser feito para rodar em um palm. Devido as notas baixas obtidas no ltimo semestre o estudante resolveu automatizar o seu processo de gesto de aprendizado. Assim ao abrir semestre o estudante cadastra todas as disciplinas que ele est matriculado. Cadastra todos os professores que lecionam em cada disciplina e os objetivos especficos de cada uma delas. Para cada disciplina o estudante registra todas as provas, testes e trabalhos programados para a disciplina no semestre. Toda aula o estudante registra os tpicos lecionados pelo professor, o material de apoio distribudo em sala de aula e os sites recomendados para completar o assunto em questo.

45

Alm disso, programa todas as sesses de estudo sendo que para cada sesso estabelece as metas de aprendizado que sero alcanadas a partir dos itens lecionados em sala pelo professor. Com o planejamento estabelecido o estudante registra todas as sesses de estudo indicando se alcanou, superou ou ficou abaixo da a meta programada. O estudante registra todas as notas obtidas assim como a mdia final e o resultado de seu desempenho. Ao final do semestre o aluno faz uma auto avaliao verificando o seu empenho ao longo do semestre a partir do relatrio de Planejado versus Realizado onde verifica se realmente houve dedicao ao longo do semestre. O estudante no incio de cada semana emite o relatrio de Planejamento Mensal de Estudos assim com o de Programao de Provas e Trabalhos. Dois dias antes de cada compromisso de estudo o estudante avisado.

2.3.8Personal Professor.
A empresa de software Being Digital resolveu atender a um pedido de um professor particular. O professor atende a diversos alunos do ensino fundamental, bsico e superior. (data, hora, local e nome do aluno), informando o assunto que deseja estudar. Para todo aluno novo o professor registra seus dados principais (nome, nome pai, noem me, nvel do ensino) assim como as ltimas cinco notas do mesmo. Ao longo do atendimento ao aluno, o professor vai registrando as novas notas do aluno. O professor registra tambm se o aluno ao final de seu ciclo escolar teve aprovao ou no. O professor registra, sempre que desejar, o valor de sua hora aula que diferenciada para os diversos tipos de alunos que atende. O professor, por sua vez, quando atende a um aluno, registra a aula particular com os exerccios aplicados, os exerccios propostos e as atividades desempenhadas. Sempre ao chegar a um atendimento o professor registra o horrio do incio da aula assim como o fim da mesma. Assim que acaba a aula o professor calcula o valor da aula e informa o valor ao aluno procedendo ao registro do pagamento do mesmo. O professor possui a opo de faturamento de seus servios. Assim ao final de cada ms o professor emite o relatrio de faturamento e informa os valores devidos aos seus alunos. Assim, sempre que um aluno deseja marcar uma aula, ele liga para o professor e agenda uma visita

46

Todo incio de semana o professor emite o relatrio de agendamentos para a semana. Ao final do ms o professor emite o relatrio de atendimentos dentro do ms assim como o relatrio de evoluo do aluno.

2.3.9Ambulante de Software Livre.

Cenrio Institucinal. O ambulante de software livre um especialista em tecnologia, mas nunca participou de um processo de desenvolvimento de sistemas. O ambulante conhece bem os diferentes tipos de software e de computadores, sabe oper-los e os mantm em perfeita ordem. Ouviu dizer que Java a linguagem do futuro, por isso espera que ao longo do desenvolvimento possa conhecer um pouco mais desta tecnologia. O ambulante esta impressionado com a tecnologia Palm e deseja que o sistema rode em um destes dispositivos. Caso. A empresa Being Digital recebeu a incumbncia de automatizar um sistema de apoio venda de cds de Software Livre e de servios correlatos de um Ambulante pirata de Software Livre. Toda tarde o vendedor de Software Livre vende vrios tipos de cds de software livre (ferramentas de modelagem, sistemas operacionais, chat, forum, workflow) para clientes avulsos e selecionados. Todas as vendas so registradas. O ambulante possui um catlogo de cds que contm os softwares contidos em cada tipo de cd com a respectiva verso de cada software. Cada nova verso de cd produzida o vendedor registra este cd no catlogo.O ambulante, tambm, possui um catlogo com os principais sites de software livre e a descrio de seus principais produtos e verses. Um cliente pode solicitar um cd com softwares livres especficos e que providenciado pelo vendedor para o dia seguinte. Cada nova solicitao de cliente, o ambulante atualiza o seu catlogo. O ambulante agenda visitas para proceder a instalao e configurao de softwares livres em domiclios. Quando acaba a visita o ambulante/consultor cobra a visita que devidamente registrada. Ao final do dia, o vendedor consulta a seu registro de vendas e de visitas, e apura a receita diria, assim com os cd mais vendidos e as solicitaes de gravao para o dia seguinte.

47

2.3.10Liga dos Blocos Unidos.

Cenrio Institucional. A liga dos blocos unidos composta por uma diretoria que est preocupada com o processo de transparncia de seu processo de apurao de resultados. Um dos requisitos para a garantia desse objetivo a utilizao da internet e de algoritmos de segurana. Caso. A liga dos blocos Unidos realiza todo ano, no Domingo de carnaval, o seu concurso de blocos. A Diretoria da Liga escolhe 10 juizes para avaliar os 12 requisitos estabelecidos para escolher o melhor bloco. Para a seleo dos juzes feita uma lisa com 30 candidatos (nome, endereo, mini-currculo) com notrio saber que so entrevistados e escolhidos 20, critrio da Diretoria. Os juzes escolhidos passam por um seminrio de treinamento e ao final fazem uma prova. Os 10 melhores colocados so os escolhidos ficando os restantes de suplentes. Os quesitos so variveis de ano para ano sendo estabelecidos na reunio geral da Liga que ocorre todo ano. Alm dos quesitos a Liga estabelece as regras dos desfiles, as mtricas de avaliao de cada quesito e as formas de julgamento de cada mtrica. Os blocos filiados a liga, 3 meses antes do carnaval, confirmam a participao no desfile. Durante o desfile os juzes avaliam quesito a quesito para cada bloco. Os populares a partir de uma ficha com os quesitos, as mtricas e os critrios de julgamento fazem tambm sua avaliao. Na quarta-feira de cinzas elaborado o relatrio de notas dos juzes, o relatrio do campeo pela liga, o relatrio de campeo pelo voto popular e os prmios dados pela liga (melhor mestra sala e porta bandeira, melhor maestro de bateria, melhor destaque, melhor diretor de evoluo, melhor carnavalesco).

2.3.11Bloco Cores Unidas do Arco ris.

Cenrio Institucional. A Diretoria do Bloco est muito preocupada com o desempenho do no carnaval. No ltimo ano o bloco quase foi rebaixado. Assim, o carnavalesco foi demitido trs novos foram sugeridos para realizar o carnaval deste ano. O presidente do bloco foi escolhido este ano e pessoa de confiana da Diretoria. Entretanto ainda existe muita dificuldade em como ser feita a inspeo de qualidade das alegorias e dos adereos. Caso. O bloco de rua Cores Unidas do Arco ris, em busca de seu primeiro ttulo resolveu automatizar o seu processo de realizao de carnaval. 48

Assim logo aps o carnaval a Diretoria do bloco se rene para escolher o enredo do prximo ano. O enredo possui uma justificativa e um contexto que definido por esta Diretoria. Aps a escolha do enredo a Diretoria elabora uma lista trplice com o nome e o mini-currculo de carnavalescos que podero ser escolhidos para e execuo do enredo. O presidente do bloco escolhe um carnavalesco desta lista. O carnavalesco escolhido elabora o figurino (nome, desenho e piloto) das 12 alas que compem o bloco, alm do projeto dos carros alegricos (nome, desenho e maquete) e dos passos da coreografia da comisso de frente. Todos esses projetos so aprovados pela diretoria em uma reunio de avaliao que elabora um laudo de aprovao. Cada ala possui um gerente (nome, endereo e telefone) que nomeado pelo presidente. O gerente responsvel pelo cadastro dos participantes de sua ala (nome, endereo e telefone). Em outubro de cada ano ocorre a seleo do samba-enredo. A letra, a msica e os autores so registrados pelo presidente do bloco. Um ms antes do carnaval a diretoria realiza uma inspeo das alegorias e dos adereos alas e nos carros alegrico.

2.3.12Dieta Alimentar.
Um mdico endocrinologista solicitou um sistema que apoiasse o acompanhamento e a gerncia de seus pacientes atravs da dieta alimentar conhecida como a Dieta dos Pontos. Um ponto equivale a mais ou menos metade de uma caloria. Na dieta dos pontos os diversos tipos de alimentos so classificados (Verdura, pes e bolachas, queijos, frutas, temperos, gros etc.). Os itens que compem cada classificao (ex. acelga e agrio para a classificao Verdura) possuem uma quantidade de pontos especficos podendo variar de zero a 500 pontos. de responsabilidade do mdico a identificao e classificao dos alimentos com a sua respectiva quantidade de pontos. As classificaes so identificadas por um cdigo e uma descrio e os itens tambm. O mdico registra a consulta de seus pacientes (data, hora e nome do paciente) quando verifica a evoluo da dieta anotando o peso do mesmo. Quando necessrio o mdico altera a meta de pontos e prescreve nova receita. Quando o paciente novo o medico solicita um exame de sangue, estabelece a meta de pontos e prescreve uma receita. No ato da consulta o mdico emite o relatrio de consumo do paciente ao longo do ms e de evoluo do paciente ao longo dos ltimos trs meses. Um paciente, ao seguir a dieta dos pontos, deve atingir uma meta diria de pontos estabelecidos pelo mdico assim como seguir a prescrio medicinal. Desta forma, ao longo do dia o paciente deve ir registrando tudo aquilo que consome e acompanhando os pontos 49

somados. Este consumo deve ser registrado ao longo do dia atravs da internet (data, hora e itens consumidos). O paciente pode a qualquer momento emitir um relatrio de consumo dirio, semanal ou mensal.

2.3.13Agenda Domstica.
Cenrio Institucional. O sistema a ser desenvolvido corresponde a uma nova diviso de sistemas embarcados que foi criada para atender as novas demandas do setor de telefonia, em especial. O Diretor desta diviso foi recrutado internamente e possui larga experincia nesses tipos de sistemas. Entretanto a equipe interna necessita de treinamento e os prazos para a construo do mesmo de no mximo 3 semanas. Caso. A Being Digital resolveu entrar no mercado de software para telefonia e ganhou uma licitao para o desenvolvimento de uma agenda para ser executada em um telefone celular. A agenda permitir ao cliente o cadastramento de se seus principais contatos contendo o nome da pessoa, os vrios tipos de telefone (com cinco entradas ao todo), o e-mail, e o endereo. A agenda tambm permitir o cadastro de dados profissionais do contato tais como empresa, cargo, e-mail. Alm destas funcionalidades a agenda permitir o cadastro de datas comemorativas tais como aniversrios alm de eventos especficos tais como reunies ou dentistas. A busca das informaes contida na agenda dever ser feita por nome ou pelo cdigo interno do sistema.

2.4 Bibliografia.
A bibliografia listada a seguir serve de orientao para o aprendizado das diversas tcnicas para a prtica de construo e de gerncia de sistemas de software.

Paula Filho, Wilson de Pdua. Engenharia de Software Fundamentos, Mtodos e Padres. LTC 2001, Rio de Janeiro. Este o meu livro preferido. Sempre recomendo aos meus alunos. Possui uma didtica boa e enfatiza tanto o lado prtico quanto o terico. O fio condutor do livro o processo Prxis. 50

Possui um site de apoio que ajuda na confeco dos sistemas. um timo livro para a graduao.

Carvalho, Ariadne M. B. Rizzoni e Chiossi, Thelma C. dos Santos. Introduo Engenharia de Software. Campinas, Sp: Editora Unicamp, 2001. Esse livro uma boa introduo a Engenharia de Software e em especial a Engenharia de Requisitos. Serve de introduo a disciplina de engenharia e a modelagem de sistemas.

Pfleeger, Shari Lawrence, Software Engineering: Theory and Practice. Upper Saddler River, NJ: Prentice Hall,1998. timo livro que une a teoria com a prtica. um livro direcionado para ps-graduao, porm pode servir de literatura complementar para as disciplinas de modelagem de sistemas e de engenharia de software.

Sommerville, Ian. Engenharia de Software. So Paulo: Addison Wesley, 2003. Uma tima referncia terica. um bom livro para a graduao e que serve de leitura complementar quanto a modelagem.

51

Parte II Conceitos

52

1Introduo.
Um aspecto central nos atua sistemas de informao a capacidade deles incorporarem as capacidades das atuais Tecnologias da Informao e da Comunicao. Este captulo analisa o impacto da Tecnologia da Informao (TI) na organizao. Inicialmente so caracterizados as Tecnologias da Informao. A seguir quatro perspectivas de impactos so consideradas: A perspectiva interna, considerando a organizao do departamento de TI; a perspectiva externa, considerando a posicionamento da empresa frente a TI; a perspectiva transversal, dos sistemas de informao e a perspectiva antropolgica, da cultura. Ao final analisado como a TI est oferecendo novas oportunidades para as organizaes e quais so as justificativas para a baixa produtividade no mbito desta tecnologia. As potencialidades da TI esto disponveis a olhos-vistos mas como transform-los em benefcios para a organizao. Uma das respostas atravs de projetos de TI que incorporem essas potencialidades s organizaes. Entretanto esse no uma caminho fcil e vrios aspectos devem ser considerados tais como o gerenciamento de mudanas a definio do escopo do projeto, cliente. comprar ou desenvolver, especificao de requisitos, mtricas para acompanhamento, normas e padres internacionais, estratgias de adoo, participao do

53

2A Tecnologia da Informao e impactos.

2.1 Conceitos.
O que a Tecnologia da Informao (TI)? Quais so as suas origens? Est ela sempre associada os computadores ? organizacionais. Este artigo procura inicialmente uma definio para TI e uma caracterizao do que vem a ser esta tecnologia a partir de seus vrios aparatos. A partir do entendimento do da TI analisado o impacto da TI sob as diversas perspectivas organizacionais. No primeiro momento, como a TI influenciou a estrutura interna do departamento de processamento de dados ao longo destes ltimos 50 anos. Depois, na seo seguinte, analisa como a TI est possibilitando novas formas de operao das empresas sob diversos aspectos: estrutura, processos, gerncia e indivduos. Uma terceira anlise feita quanto aos sistemas de informao, como estes evoluram em funo das novas possibilidades tecnolgicas e por fim como a TI moldou a cultura informtica. Por fim, feita uma reflexo das razes que levam a TI ser um ferramenta estratgica de negcio mas com baixo retorno. A TI influencia o molde das aplicaes e das estruturas

2.2 Tecnologia da Informao: origem e definio.

Em geral, sempre que se considera a expresso Tecnologia da Informao, faz-se logo uma associao aos computadores e s redes de transmisso; entretanto, a definio dessa tecnologia e a identificao da sua origem, dependem da viso de cada autor e da sua respectiva abordagem de anlise. Na realidade dependendo de como se considera o que seja Tecnologia da Informao, pode-se chegar a origens distintas. Yates & Benjamin (1991) fazem justamente isso: ampliando o escopo de estudo, dispem de um perodo maior para anlise desta tecnologia. A fim de se desassociar o conceito de Tecnologia da Informao da idia de computadores, os autores identificam-na por quatro funes bsicas: converso (dispositivos de entrada e de sada), armazenamento, processamento e comunicao. Dentro dessa perspectiva, os autores classificam dois perodos de estudo que so: o perodo histrico entre 1840 e 1950, quando se fez uso do telgrafo, do telefone, das mquinas de Hollerith e dos arquivos de fichrio, e o perodo moderno, que vai de 1960 at os nossos dias, e que faz uso das redes de informao e de computadores em alta escala. A concluso dos autores a de que a origem da Tecnologia da Informao no to recente quanto aparenta ser, pois se se analisar sob a tica de suas funes, esta j existe ha muito 54

tempo. Entretanto a grande diferena, entre o perodo moderno e o perodo histrico, que as funes da Tecnologia da Informao no esto integradas no primeiro momento, apresentado um alto grau de descontinuidade. No perodo moderno as funes de converso, de armazenamento, de processamento e de comunicao esto totalmente integradas via o uso de computadores com grande capacidade de processamento, de armazenamento, uma grande variedade de dispositivos de entrada e sada, e interligados via redes de comunicao. A anlise de Yates & Benjamin encontra lastro no trabalho de Schement(1990) que identifica o surgimento da Sociedade da Informao nos anos 20. Para o autor, esse fato conseqncia da verticalizao das organizaes e do aumento dos nveis hierrquicos dentro destas, que, por sua vez, levaram ao desenvolvimento dos sistemas de gerenciamento e das profisses que lidavam com o tratamento da informao. Esse ambiente organizacional dos anos 20 era apoiado no que Yates & Benjamin designam perodo histrico da Tecnologia da Informao. Entretanto a viso dominante na sociedade a de que a Tecnologia da Informao vem sempre associada ao uso do computador, e portanto, teria sua origem a partir da Segunda Guerra Mundial. Para Massuda (1980), a anlise do uso, e da difuso da Tecnologia da Informao, est dividida em quatro etapas sobrepostas. Na primeira etapa, que vai de 1945 a 1970, a Tecnologia da Informao era utilizada, basicamente, em nveis governamentais, tanto para fins cientficos, quanto para fins militares relacionados a pesquisa espacial e a defesa nacional. Na segunda etapa, que vai de 1955 a 1980, a Tecnologia da Informao passa a ser utilizada na administrao pblica e privada, com o objetivo principal de busca da eficincia nos negcios. Na terceira etapa, de 1970 a 1990, a Tecnologia da Informao comea a ser utilizada em aplicaes na rea de sade e na rea educacional. A quarta e ltima etapa caracterizada pelo uso individual da Tecnologia da Informao, onde objetivo o indivduo em sua auto-realizao e satisfao pessoal. Em relao definio do que seja Tecnologia da Informao, no existe uma que seja aceita por todos, embora, em geral, essas definies costumam vir associadas ao emprego dos computadores. Leavitt & Whisler (1958) foram provavelmente os primeiros a utilizarem a designao de Tecnologia da Informao (e, possivelmente, os primeiros a analisarem os "impactos" do uso desta tecnologia nas organizaes). Nesse artigo, os autores descrevem-na como um conjunto de trs partes relacionadas. A primeira parte composta de tcnicas necessrias para o processamento rpido de grandes quantidades de informao. A segunda parte composta de tcnicas de programao matemtica e de mtodos de pesquisa operacional. A ltima parte consiste em tcnicas que possibilitam a simulao do pensamento humano. 55

Huber(1990), por sua vez, define Tecnologia da Informao, que ele chama de Tecnologias de Informao Avanadas, como dispositivos: (a) que transmitem, manipulam, analisam ou usam informaes; (b) que possuem o computador digital como uma ferramenta complementar ao processamento de informaes e que so necessrias tanto nas tarefas de comunicao quanto nas de apoio deciso dos usurios; (c) que surgiram a partir de 1970 e que ajudam nas tarefas de comunicao e de apoio deciso em um grau maior do que os dispositivos pr-1971. Towett & Rothwell (1986) definem Tecnologia da Informao como a interligao entre as telecomunicaes, de um lado, e os computadores, de outro. Esta parece ser uma viso mais aproximada do que se observa na atualidade. De qualquer maneira, importante notar que definir Tecnologia da Informao uma tarefa rdua e sempre gerar discrdia. Independentemente da origem desta tecnologia, ou de como ela pode ser definida, o fato que hoje ela vital para a sobrevivncia das empresas pois, ao mesmo tempo em que possibilita a criao de novos modelos organizacionais, permite que as organizaes extraiam o mximo de seus prprios benefcios.

2.3 Evoluo da Tecnologia da informao.

Nesta seo sero caracterizados os principais artefatos tecnolgicos que compem a TI. Alguns artefatos sero destacados nesta anlise tais como Bancos de Dados e Internet.

2.3.1Hardware.
Uma das maneiras clssicas de estudar a evoluo do hardware dos computadores atravs das geraes dos seus dispositivos. A primeira gerao de computadores desenvolveu-se no incio dos anos 50. Esta gerao caracterizada pela utilizao de vlvulas. Um dos cones desta gerao foi o ENIAC, considerado o primeiro computador feito pelo homem, que possua mais de 18.000 vlvulas. Os computadores desta poca eram muito limitados em suas funes, apenas clculos muito especficos eram programados nestas mquinas. Alm do tamanho, estas mquinas eram extremamente caras e apenas os rgos militares e grandes empresas podiam arcar com seus custos. A segunda gerao de computadores utilizava a tecnologia dos transistores. Esta tecnologia era muito mais confivel que as vlvulas, que para funcionarem tinham que ser aquecidas e invariavelmente queimavam, necessitando de reposio. Alm de mais confiveis os transistores eram menores, o que resultou na construo de computadores mais compactos. A terceira gerao de computadores trabalhava com um conjunto de transistores que eram montados em uma pequena pastilha de silcio: os circuitos integrados. A grande vantagem nesta poca foi a miniaturizao do transistor e a densidade de transistor por pastilha. 56

A Quarta gerao utilizava tecnologias integrao em larga escala (LSI) e em escala muito larga (VLSI). Isso permitiu o aparecimento dos micro-processadores, onde em uma nica pastilha continha todos os circuitos de uma CPU. Atualmente os computadores possuem milhes de transistores, processam bilhes de informaes por segundo, so plenamente confiveis e possuem uma grande capacidade de armazenamento de dados. Estas geraes possuem como critrio de classificao a tecnologia utilizada para o processamento de informao. Entretanto nos anos 80 um projeto japons de desenvolvimento de computador de quinta gerao estava preocupado mais desenvolvimento de computadores inteligentes, a partir do desenvolvimento de software, e no de hardware. O projeto no alcanou os objetivos esperados mas serviu para aprofundar pesquisas em vrias reas de inteligncia artificial e robtica. Ao se analisar a evoluo dos computadores ao longo deste ltimos 50 anos, sob o ponto de vista de sua arquitetura v-se que houve pouca evoluo. Os conceitos inicialmente estabelecidos por John Von Newman e Alan Turing esto presentes at hoje. A evoluo da tecnologia que propiciou a construo de computadores mais rpidos e confiveis. Hoje temos vrias manifestaes destas mquinas em nosso dia-a-dia, dos palms aos supercomputadores passando pelos micros de mesa.

2.3.2Software.
Os primeiros cientistas da computao programavam os computadores diretamente no hardware da mquina, semelhante aquelas telefonistas do passado que ficavam conectando fios para realizar uma ligao. Este tipo de programao exigia um conhecimento muito especfico da arquitetura do computador. O advento do software possibilitou a programao dos computadores atravs de uma linguagem simblica que se encarregava da comunicao do com o computador em si. Criavase uma interface, uma linguagem de comunicao entre o homem e a mquina. Inicialmente, devido a natureza dos computadores, o capacidade de programao era muito limitada. Hoje em dia pode-se classificar o software em dois tipos: o software para a gerncia de recursos do computador e software para o atendimento a uma necessidade final, aplicativo. O software mais importante de gerenciamento de recursos de um computador o sistema operacional. Este sistema que permite o gerenciamento de todos os dispositivos conectados no computador. Algumas funes do sistema operacional so: interface com o usurio,

57

gerenciamento de recursos (ex.: memria, armazenamento, cpu), gerenciamento de arquivos e gerenciamento de tarefas. Nos dias atuais, com o alto poder de conexo entre os diversos computadores, algumas tarefas especficas so necessrias, tais como o gerenciamento de redes, gerenciamento de transmisso, configurao de protocolos de comunicao etc. Os sistemas operacionais que enfatizam estas caractersticas so chamados de sistemas operacionais de rede. Outro software importante de gerenciamento de recursos o Software de Gerncia de Banco de Dados(SGBD). Armazenar dados sempre foi uma funo importante no processamento de dados. A sesso de Banco de Dados tratar melhor deste assunto. Pelo lado dos aplicativos, pode-se citar os aplicativos gerais tais como um navegador ou em aplicativo para uso especfico, software de vendas de uma empresa. Software , portanto, o meio pelo qual pode-se criar as diversas funes que um computador pode possuir. atravs dele que os sistemas de informao so construdos, que os banco de dados so criados e interfaces concebidas

2.3.3Rede e telecomunicaes.
Pode-se definir telecomunicaes como sendo toda forma de troca de informaes por meio de redes computadorizadas[OBrian, 2003]. Nos dias de hoje praticamente todas as empresas esto de alguma forma conectadas. Pode-se classificar redes de vrias formas. Uma delas pelo seu tamanho ou amplitude. Um Rede Local(LAN) uma rede que atende a um departamento e que envolve algo em torno de 20 computadores. Uma rede metropolitana opera em grande velocidade na distncia suficiente de uma cidade (MAN). E quando opera com pontos geograficamente distantes uns dos outros, redes mundiais (WAN), como por exemplo a Internet. Pode-se classificar as redes de acordo com a sua topologia (sua forma) . Uma rede em anel cada computador se comunica com dois vizinhos at formar uma crculo. Na rede em estrela todo o trfego passa por um computador central. Na topologia de barramento os computadores ser comunicam com todos os outras em linha. Outra classificao para as redes quanto a sua tecnologia. Aqui sero destacados as redes Ethernet e a FDDI. A tecnologia mais difundida a rede Ethernet. uma tecnologia desenvolvida pela Xerox no incio dos anos 70. Esta tecnologia possui as seguintes propriedades: utiliza o mecanismo de comunicao geral (broadcast) a 10Mbs, com entrega no-notificada e pode ser acessada sem a existncia de uma autoridade central.

58

FDDI (fiber distributed data interconnect) uma tecnologia que prove uma melhor banda do que a Ethernet, por utilizar fibra tica. As propriedades da rede FDDI que opera com banda de 100Mbps, baseada em token ring, e possui com capacidade de acomodar falhas no sistema. Tanto as redes FDDI e Ethernet so redes cuja classificao est baseada na especificao do hardware que a faz operar. Em teoria, por possurem especificaes diferentes estas redes no se comunicam entre si. Um micro ligado a uma rede Ethernet somente poderia se comunicar com outro utilizando a mesma tecnologia. Uma maneira de conexo entre redes distintas atravs de roteadores.

2.3.4Banco de dados.
Banco de dados um item a parte do que se pode chamar de software de banco de dados, ou software de gerncia de banco de dados. Devido a importncia do assunto para uma organizao este assunto ser tratado separadamente do item de software. Armazenar dados vital para qualquer organizao. a partir dos dados que se pode tomar decises, entender melhor o mercado, fazer inferncias, conhecer melhor o cliente. Nos dias de hoje tomar decises com rapidez e com confiabilidade crtico. Os dados armazenados so a memria da organizao. Existem vrios dispositivos utilizados para armazenar dados, podemos citar fitas magnticas, discos rgidos e CDs. Os sistemas de gerncia de banco de dados (SGBD) uma evoluo da gerncia de arquivos de dados. Os SGBD propiciaram uma maior segurana e confiabilidade no armazenamento de dados. Os SGBD so na realidade um ambiente contendo uma srie de ferramentas para a manuteno e administrao de dados de forma segura. Entretanto os dados utilizados pela organizao refletem a forma como esta os utiliza. Assim para o emprego de banco de dados necessrio a modelagem de dados que considere as regras de negcio da organizao. Algumas variaes desta tecnologia existem. Quando o banco de dados utilizado para armazenar dados de uma determinada rea estes podem ser considerados banco de dados temticos. Quando os dados so consolidados ao longo dos anos e estruturado de forma a apoiar o processo decisrio no nvel gerencial este pode ser chamado de data warehouse. Data Warehouses so na realidade um grande banco de dados que armazena dados de diversas fontes para futura gerao de informaes. Esses bancos de dados obtm tanto informaes internas da organizao quanto externas. A principal vantagem dessa tecnologia a capacidade de relacionar dados de forma no convencional e criativa. A integrao chave desta tecnologia. 59

Como pode-se observar na figura 3, um Data Warehouse obtm dados de vrias fontes de dados, tanto internas quanto externas e procura consolid-las em um conjunto da bases de dados temticas. Para a obteno de dados em um data warehouse utiliza-se tecnologias de data mining e online transaction processing (OLTP).

2.3.5Internet.
A Internet uma rede virtual que opera em diferentes tipos de redes utilizando para isso apenas um protocolo geral de troca de mensagens chamado TCP/IP. Desta forma a Internet no uma especificao de hardware uma conjunto de protocolos que so instalados nos diversos computadores e que provm uma linguagem nica de comunicao entre os diversos tipos de redes. Deve-se ao uso da Internet a exploso das comunicao entre empresas e entre empresas e consumidores. O comrcio eletrnico um dos reflexos desse estreitamento entre empresas e entre pessoas. Outra caractersticas possibilitada pela Internet a possibilidade de se trabalhar colaborativamente. Pessoa localizadas em pontos distintas de uma organizao ou at mesmo em pases diferentes podem desenvolver projetos em conjunto. A tecnologia Internet pode ser utilizada internamente em uma organizao. Nesse caso quando o ambiente Internet restrito ao ambiente organizacional denomina-se Intranet. Quando utiliza-se a tecnologia Internet para interconectar organizaes que compartilham dados em comum denomina-se Extranet.

2.4 Tecnologia da Informao e Impactos.

Nesta seo sero caracterizadas quais as transformaes possibilitadas pela evoluo, no apenas da tecnologia mas como tambm de sua compreenso, sob as perspectivas interna, externa, transversal e cultural.

2.4.1Perspectiva interna: a administrao da tecnologia da informao.

A estrutura e a administrao da TI nos ltimos 50 anos passou por grandes transformaes que refletem de alguma maneira a cultura atual na rea de TI. Uma pesquisa antiga feita por Nolan [1982] caracteriza vrios estgios de administrao da TI nas organizaes. Devido a antigidade do trabalho de Nolan, ser dado a seguir um enfoque mais atual destes estgios sem procurar descaracterizar cada um deles. Nolan classifica em 6 estgios administrativos: iniciao, contgio, controle, integrao, administrao de dados e maturidade. 60

O estgio de iniciao caracterizado pelo desenvolvimento aplicaes operacionais da organizao, os recursos so centralizados, o planejamento inexistente sendo que os cliente e principais usurios so timidamente envolvidos tecnologia. O estgio de contgio caracterizado pela proliferao de aplicaes na organizao, criada uma estrutura formal para a realizao das funes de processamento de dados, existe um planejamento e um oramento destinado ao centro de processamento de dados, os cliente e usurios esto mais envolvidos com a tecnologia e os sistemas por ela gerados. O estgio de controle, o controle das aplicaes so formalizados e as aplicaes comeam a ser integradas. Surgem os padres para desenvolver sistemas. O estgio de integrao o quarto estgio. nesse estgio que generaliza-se o emprego de base de dados. Os sistemas de apoio a deciso e em tempo real so iniciados. O quinto estgio o de administrao de dados. Nesta ocasio a empresa reconhece a necessidade de administrar seus dados de forma integrada. Assim as aplicaes compartilham uma base de dados corporativa. A integrao dos sistemas via banco de dados. O sexto estgio o de maturidade. Neste estgio a empresa j possui um conhecimento maior do que vem a ser a TI. Os sistemas passam a atender s estratgias da organizao. Os sistemas no visam apenas a operao da empresa mas sim a sua atuao estratgica. O ltimo estgio o do Conhecimento. Assim a informao no o recurso mais importante mas sim o forma de registrar e disseminar conhecimento. Ultimamente, com o advento da Internet, as empresas enfrentam o desafio de oferecer SI/TI globais. Assim essa nova forma de operar redimensiona o tamanho do marcado e da prpria organizao. necessrio, portanto considerar novas estratgias, novos portflios de aplicaes, integrao de plataformas, uma gesto de dados globalizada e um desenvolvimento de sistemas integrado entre os diversos parceiros no nvel global.[OBrien, 2003]. e no conhecem bem o potencial da

2.4.2Perspectiva externa: da organizao e seu meio.

A Tecnologia da Informao tem oferecido s organizaes, ao longo do tempo, novas formas de gerenciamento e de estruturao de seus processos de negcio. Seu uso profcuo est associado a diversos fatores, tais: como a qualificao tcnica para a adoo da tecnologia, o grau de relacionamento com fornecedores e com novos parceiros, mudanas estruturais organizacionais oferecidas pela tecnologia etc. Os fatores so muitos e, em geral, estes tem sido analisados de forma independente e no integrada. Entretanto, no final dos anos 80, em um esforo realizado pelo MIT/Sloan School of Management e representantes de grandes corporaes dos E.U.A., foi criado o Programa de 61

Pesquisa de Gerncia nos Anos 90 que tinha como tarefa principal investigar os impactos das novas Tecnologias da Informao nas Organizaes, cujos resultados encontram-se consolidados em um trabalho editado por Morton (1991). O Programa considerou duas premissas bsicas para realizar o estudo. A primeira premissa diz respeito ao ambiente extremamente turbulento do mundo dos negcios em termos sociais (a partir de novas demandas para o aumento da qualidade do trabalho), polticos (nas alteraes de posturas reguladoras e intervencionistas das economias do ocidente), econmicos (no realinhamento de blocos econmicos mundiais) e tcnicos (fundamentalmente, no uso intensivo da Tecnologia da Informao, entre outras descobertas). A segunda premissa considera a rpida evoluo da Tecnologia da Informao, cujo ritmo de desenvolvimento ir se manter na dcada de 90. Segundo o programa as duas premissas implicam em mudanas potenciais e fundamentais para a sobrevivncia das organizaes, visto que as atuais estruturas e formas organizacionais no suportaro o novo modelo de competio. As concluses do Programa consideram que a Tecnologia da Informao est possibilitando mudanas organizacionais em diversos nveis, tais como: na estratgia, na integrao de funes, nas estruturas, nos procedimentos gerenciais e criando novas necessidades nas habilidades dos indivduos. A influncia da Tecnologia da Informao sobre cada um destes nveis se caracteriza da seguinte forma: Oportunidades Estratgicas: A Tecnologia da Informao apresenta novas oportunidades estratgicas para as organizaes que reavaliam suas misses e operaes. Integrao de Funes: A Tecnologia da Informao est oferecendo a integrao das funes do negcio em todos os nveis (tanto dentro da prpria Organizao quanto entre organizaes) e est causando mudanas nas regras de competio. Estrutura e Gerncia: A aplicao com sucesso da Tecnologia da Informao requer mudanas no gerenciamento e na estrutura organizacional. Habilidades dos Indivduos: A Tecnologia da Informao est possibilitando mudanas fundamentais na maneira em que o trabalho realizado. Portanto, para o Programa, o uso de Tecnologia da Informao no suficiente para obter os benefcios a ela associados; o que fundamental que a Organizao se submeta a um processo de mudana, de forma a fazer uso desses benefcios. Os requisitos precpuos dessa mudana so: clareza dos objetivos do negcio aliados s possibilidades de uso da Tecnologia da Informao e, fundamentalmente, na capacitao dos indivduos no processo de transformao. Para o Programa, o maior desafio para as organizaes o que se segue. 62

Desafio: O maior desafio para a gerncia nos anos 90 ser o de guiar as Organizaes, no sentido de realizar transformaes que so necessrias para se prosperar em um ambiente globalmente competitivo. Segundo o Programa, as organizaes podem ser entendidas como um conjunto de 5 foras: Estratgia, Estrutura, Procedimentos Gerenciais, Indivduos e Tecnologia. Estas foras atuam em equilbrio dinmico (Figura 2-01). As foras dos Indivduos, dos Procedimentos Gerenciais e da Estrutura definem e refletem a cultura de uma Organizao que, por sua vez, central no processo de transformao organizacional. A seguir, sero apresentadas e discutidas as oportunidades de transformao oferecidas pela Tecnologia da Informao, sobre as trs grandes foras que compem a Organizao: Estratgia, Cultura Organizacional e Tecnologia. Estratgia de uso: a Tecnologia da Informao, por si s, pode no prover nenhuma vantagem competitiva; pode ser usada, simplesmente, para a reduo de custos de produo ou administrativos. No entanto, se a Tecnologia da Informao estiver associada e vinculada a objetivos organizacionais, pode ser utilizada para lanar novos produtos e servios, criar novas barreiras de negcio, eliminar as distncias entre parceiros e colaboradores, ou at mesmo redefinir o eixo de negcio. Cultura Organizacional: a Cultura Organizacional, entendida como o somatrio de trs foras (Estrutura, Procedimentos Gerenciais e Indivduos), fundamental no processo de transformao organizacional. As trs foras sero tratadas em conjunto, visto que muito difcil analis-las separadamente, pois cada uma exerce uma forte influncia sobre as outras. Ao nvel da Estrutura, a Tecnologia da Informao permite que se coordene grupos de pessoas distncia, que se mantenha uma memria organizacional permanente (que no dependa das pessoas), que se reduza os nveis hierrquicos, que se integre funes internas e parceiros externos etc. A nvel dos Procedimentos Gerenciais, a Tecnologia da Informao pode oferecer uma redistribuio de poderes, assim como possibilitar novas formas de planejamento e controle. Ao nvel dos Indivduos, a Tecnologia da Informao oferece uma srie de novas ferramentas de trabalho criando um nvel de abstrao maior e favorecendo formas cooperativas de trabalho. Novas qualificaes e habilidades so necessrias nesse novo ambiente. Tecnologia: a Tecnologia da Informao possui atributos que no apenas automatizam ou informatizam. A sua caracterstica mais importante o seu poder de transformao. Sob esse aspecto o sucesso efetivo do uso da Tecnologia da Informao passa pela gerncia da adoo dessa tecnologia e de seu processo de uso junto Organizao. O sucesso, no processo de transformao, exige um equilbrio de mudanas entre a Tecnologia da Informao e a Organizao. 63

2.4.2.1 Estratgia de uso.

At o incio dos anos 80 a Tecnologia da Informao era utilizada apenas na sustentao de atividades burocrticas na Organizao. Essa atitude pode ser explicada por, at ento, esta tecnologia ser extremamente cara e poucas organizaes podiam suportar seus custos. A partir dos anos 80, com a introduo de microcomputadores e do uso intensivo de redes de comunicao, uma nova realidade emergiu, com reflexos na estrutura das organizaes, nas regras de competio, na criao de novas vantagens competitivas e no levantamento de novas barreiras de negcio. Assim, a Tecnologia da Informao se transformou, nos anos 90, em uma arma de competio importante para as organizaes. A estratgia de uso da Tecnologia da Informao pela Organizao pode ser entendida de vrias formas: quanto sua vinculao aos objetivos estratgicos da Organizao; quanto ao apoio s estratgias genricas de atuao no mercado; e quanto na criao de novos produtos ou servios e na transformao do prprio negcio. No que diz respeito vinculao do uso da Tecnologia da Informao estratgia da Organizao, Venkatraman (1991) cita 3 modelos bsicos. No primeiro modelo a Tecnologia da Informao empregada independentemente das necessidades estratgicas da Organizao, ou seja, esta no considera as oportunidades oferecidas pela tecnologia, ao nvel estratgico. Nesse, caso a Organizao utiliza a Tecnologia da Informao, apenas para automatizar seus processos administrativos, o que no lhe confere vantagens competitivas a nvel de mercado. No segundo modelo, a Tecnologia da Informao est vinculada estratgia organizacional, porm, empregada de forma reativa. Neste caso, a infra-estrutura da Tecnologia da Informao utilizada como ferramenta de apoio s estratgia de negcio da Organizao. No terceiro modelo, a Tecnologia da Informao utilizada de forma interdependente em relao estratgia organizacional, isto , qualquer nova possibilidade tecnolgica sinaliza mudanas na estratgia do negcio, e vice-versa, qualquer modificao na estratgia do negcio influencia mudanas apropriadas na infra-estrutura da Tecnologia da Informao da Organizao. Nesse caso a Tecnologia da Informao uma valiosa arma de competio, sendo parte integrante da prpria estratgia do negcio. Sob outro ponto de vista, Porter & Millar (1985) consideram trs estratgias de negcio genricas e avaliam como a Tecnologia da Informao pode apoiar cada uma delas. Na primeira delas, Estratgia de Racionalizao, a Tecnologia da Informao pode ser utilizada na reduo dos custos de produo. As atividades propcias para a reduo de custos so aquelas de carter repetitivo e local, entretanto, novas formas de uso da Tecnologia da Informao permitem a racionalizao de custos em vrios nveis organizacionais.

64

A segunda, Estratgia de Diferenciao, a Tecnologia da Informao ajuda na diferenciao via a customizao da produo, de servios que apoiem o consumidor, de uma melhor imagem, de unicidade de projeto ou, simplesmente, via a incorporao de sistemas de informao a seus produtos. Os autores citam o caso da American Express que pode particularizar seu servio de viagem, oferecendo programas diferenciados para seus clientes. A terceira, Estratgia de Escopo, se caracteriza pela explorao de um mercado especfico (nichos). Nesse caso, a Tecnologia da Informao possibilita a segmentao da produo, permitindo s organizaes atuarem de forma competitiva, localmente, nacionalmente e globalmente. As abordagens acima reforam o fato de que a Tecnologia da Informao pode ser utilizada no apenas como suporte a automao de procedimentos burocrticos na Organizao, mas sim como arma de competio efetiva em um mercado cada vez mais globalizado e competitivo. No entanto, o que se observa na prtica o uso de racionalizao de processos (defensivo) e no na redefinio de novos (agressivo), da Tecnologia da Informao. Possivelmente este fato pode estar associado falta de qualificao dos gerentes e executivos das organizaes para adotarem esta tecnologia, em toda a sua potencialidade.

2.4.2.2 Cultura Organizacional.

Schein (1994) define Cultura Organizacional como "um padro de crenas bsicas, que um determinado grupo inventou, descobriu ou desenvolveu, de forma a ser bem sucedido, frente a problemas de adaptao de origem externa e de integrao interna, que deu resultados e considerado vlido e que pode ser ensinado aos novos membros do grupo como a maneira correta de perceber, pensar e sentir em relao a esses problemas". Como visto anteriormente, a Organizao o maior entrave para o aproveitamento das oportunidades da Tecnologia da Informao. Em geral, pode-se dizer que a Cultura Organizacional quem oferece a maior resistncia a mudanas. Essa constatao apresentada pelo Programa de Pesquisa de Gerncia nos Anos 90 reforada por DeLisi (1990), Liker, Roitman & Roskier (1987) e Adler & Shenhar(1990). Estes autores avaliam que a Cultural Organizacional fundamental no processo de transformao. Muitas organizaes mantm suas estruturas, seus procedimentos gerenciais e as qualificaes dos indivduos inalteradas subutilizando, por conseguinte, sua capacidade na produo de melhores servios e produtos oferecidos via uso da Tecnologia da Informao. A Cultura Organizacional est refletida na forma como a Organizao se estrutura hierarquicamente, como controla seus procedimentos e como qualifica seus funcionrios. Em realidade, esses fatores no podem ser analisados isoladamente, visto que esto interligados. 65

Ao se analisar a cultura organizacional alguns aspectos so importantes, e dizem respeito a centralizao ou no da estrutura organizacional, das novas possibilidades de interconexo com outras empresas e parceiras, do aumento ou diminuio dos nveis hierrquicos e do modelo de gesto dos indivduos. O final dos anos 50 marca o incio da discusso do impacto da Tecnologia da Informao sobre a Cultura Organizacional. Previses conflituosas eram feitas a respeito do uso desta tecnologia e seus respectivos impactos na estrutura organizacional. Leavitt & Whisler (1958) afirmavam que a Tecnologia da Informao alteraria a estrutura organizacional nos seguintes aspectos: Mdia Gerncia: O trabalho da mdia gerncia iria se tornar cada vez mais estruturado, sendo possvel sua programao via computadores. Dessa forma, uma nova diviso do trabalho aconteceria a nvel da gerncia, acentuando, ainda mais, o papel do planejador (alta gerncia) e do executor (mdia gerncia). Dentro dessa perspectiva, a mdia gerncia seria enormemente reduzida dos quadros da Organizao. Centralizao: As grandes corporaes iriam centralizar cada vez mais suas atividades sendo que o trabalho de inovao , de planejamento e de outras funes "criativas" seria incorporados em grande escala pela alta direo. Por outro lado, Burlingame (1961) previa exatamente o contrrio. Para o autor, a Tecnologia da Informao iria possibilitar uma maior descentralizao das organizaes, j que a informao estaria disponvel, onde fosse necessria, para a tomada de deciso, e no substituiria os gerentes, mas, sim, os auxiliaria em seu processo de trabalho. A Tecnologia da Informao possibilita ambas estratgias (centralizao e descentralizao); a escolha depende da cultura da empresa. De qualquer maneira, o fato que novas possibilidades de gerenciamento esto sendo oferecidas pela Tecnologia da Informao. Yates & Benjamin (1991) destacam que a Tecnologia da Informao est provendo novas oportunidades e novas formas de coordenao do negcio. Segundo os autores, essas novas formas de coordenao so viabilizadas pela dramtica reduo do tempo e do espao (via a utilizao de redes de alto desempenho e do grande volume de informaes que se pode transmitir por estas), expanso e transformao do conhecimento armazenado nas organizaes (memria organizacional permanente, via a utilizao de bases de dados e de Sistemas Especialistas) e flexibilidade (via a adaptabilidade da Tecnologia da Informao a um grande nmero de tipos diferentes de aplicaes). Segundo os autores, essas novas possibilidades de coordenao possibilitam s organizaes proverem mudanas estruturais, tanto a nvel interno, quanto a nvel externo. A nvel externo, tais mudanas possibilitam a criao de uma Organizao Virtual, onde existe uma forte interligao entre duas ou mais organizaes como se fossem apenas uma. Tal ligao pode se 66

dar, tanto a nvel do processo de produo, quanto a nvel de projetos. Johnston & Lawernce (1988) definem tal relao como Companherismo-de-Valor-Agregado (VAP - Value Adding Partnership), onde diferentes companhias trabalham juntas, a fim de gerenciar o fluxo de produtos e servios, ao longo de toda a cadeia de produo. A terceirizao, a subcontratao e o emprego da E.D.I (Eletrocnic Data Interchange) so alguns exemplos da inter-relao cada vez maior entre as gil e enxuta. A nvel da estrutura interna, a Organizao pode balancear suas necessidades no desenvolvimento de determinadas funes de negcio (ou repassar para terceiros), atuar em espaos geogrficos distintos e diversificar sua linha de produtos. Esse balanceamento nem sempre foi possvel, pois, no fim do sculo XIX, as organizaes americanas atuavam localmente (geografia limitada), no possuam variedade de produtos (linha de produtos limitada) e estavam concentradas, apenas, no processo de produo (poucas funes do negcio). A verticalizao possibilitou o crescimento do nmero de funes dentro da Organizao, mas com a produo centrada em poucos produtos e concentrada em apenas um (grande) mercado. No incio do sculo XX, a Organizao Multidivisional emergia, nesse caso a Organizao estava estruturada, ou por linha de produo (mltipla linha de produtos), ou geograficamente (variedade geogrfica), e dentro dessa estrutura eram definidas as funes inerentes ao negcio (vrias funes do negcio). A Tecnologia da Informao possibilitou criar novas formas organizacionais de forma a atender, ao mesmo tempo, os aspectos funcionais, os geogrficos e os de produo. O conceito de Unidades de Negcio o que melhor se enquadra nesse modelo. Nessa nova estrutura, a Organizao dividida em unidades que atuam, de forma autnoma, como se fossem uma empresa dentro da prpria empresa. Mas a Tecnologia da Informao no esta alterando as necessidades de habilidades do indivduo, exigindo novas qualificaes no posto de trabalho? A introduo de novas tecnologias e a subseqente automao das atividades cotidianas no trabalho tm gerado discusses a respeito da qualificao necessria dos indivduos. No caso especfico da Tecnologia da Informao, uma nova gama de habilidades tm sido identificadas. Em 1958, James Bright questionava, em seu artigo, se a contnua elevao dos nveis de automao ampliaria as qualificaes dos trabalhadores. Para o autor, quanto maior o grau de automao, mais reduzido seria o contedo do trabalho e menores seriam as necessidades de esforo fsico, esforo mental, experincia, habilidades manuais e de tomada de deciso, apontando para uma tendncia contnua de desqualificao. organizaes. As novas possibilidades de coordenao distncia, permitem que a Organizao se concentre, apenas, em seu prprio negcio, tornando-a mais

67

No entanto, com a utilizao mais intensa da Tecnologia da Informao, uma nova perspectiva emergiu. Para Zuboff(1985), a Tecnologia da Informao possui uma dualidade, pois esta pode ser utilizada, tanto para automatizar, quanto para informatizar rotinas e processos. A grande diferena entre automao e informatizao, segundo Zuboff, que a automatizao utilizada para substituir esforo fsico e habilidades humanas por tecnologia, de forma a desempenhar o mesmo processo, com menos custo, mais controle e menos descontinuidade. Entretanto, atravs da informatizao que a Organizao pode obter uma melhor compreenso do seu processo produtivo, sendo esse ponto sobre o processo, e o principal benefcio da Tecnologia da Informao. O que diferencia a informatizao que, alm de automatizar o processo, informaes so geradas anteriormente. Para Zuboff, essa nova caracterstica informativa exige novas habilidades intelectuais que, so determinantes para se fazer bom proveito dessa tecnologia. Elas correspondem capacidade de pensar abstratamente, de possuir um pensamento indutivo e de ter uma fundamentao terica do processo de trabalho. A habilidade de pensar abstratamente justificada pelo fato de que o trabalho se torna menos manual, uma vez que este mediado pelo computador, tornando os objetos de trabalho cada vez mais remotos, afastando cada vez mais o trabalhador de seu produto final. A habilidade de pensar indutivamente est associada ao fato de que o processo de trabalho tende a ser reduzido em termos qualitativos, necessitando, por parte dos indivduos, um potencial para relacionar variveis e testar hipteses. Por ltimo, a fundamentao terica de processo de trabalho necessria de modo a servir de guia para vasculhar dados, elaborar hipteses e auxiliar no pensamento indutivo. Adler(1986) analisa de modo semelhante o impacto da Tecnologia da Informao nas qualificaes. Para o autor, existe uma tendncia de se pensar que a Tecnologia da Informao leva desqualificao do trabalhador. Entretanto, essa anlise no observa que para cada tarefa transferida do trabalhador para a mquina, uma nova tarefa criada para o trabalhador: a de se fazer uso efetivo das novas possibilidades da mquina. considerando esse ponto de vista que o autor, estudando o processo de automao de uma Organizao bancria, identifica trs caractersticas bsicas de qualificao que emergem, a partir do uso da Tecnologia da Informao: Responsabilidade: nesse caso, a mudana ocorre na transformao da responsabilidade-poresforo, para a responsabilidade-por-resultados. Em geral, o trabalhador tem sido remunerado pelo esforo fsico. A Tecnologia da Informao tem possibilitado a substituio que no estavam disponveis

68

do esforo fsico, pelo esforo mental, acrescentando novas funes ao trabalho e aumentando o grau de responsabilidade no processo de trabalho. Abstrao: assim como argumentado por Zuboff(1985), o uso da Tecnologia da Informao transforma tarefas manuais em tarefas intelectuais exigindo uma nova familiaridade com linguagens mais abstratas. As operaes tendem a se tornar algortmicas e processuais, alm de demandar um conhecimento maior de cunho tcnico da nova ferramenta. As tarefas se tornam mais interligadas e o entendimento de toda a cadeia de produo se faz necessrio redefinindo, dessa forma, os mtodos de treinamento. Os procedimentos passam a estar integrados no sistema, alterando o papel e o perfil dos funcionrios, com grande conhecimento das rotinas dirias da Organizao. Interdependncia: com a adoo da Tecnologia da Informao interligam-se, cada vez mais, as tarefas, exigindo novas habilidades gerenciais, maior relacionamento interpessoal e a possibilidade de se trabalhar em grupos. Estas novas possibilidades criam uma nova dimenso no processo de treinamento dos indivduos. A Tecnologia da Informao tem oferecido s organizaes uma nova realidade, em termos de Organizao do negcio. Entretanto, o papel da mudana, no visto nesta seo, no depende, exclusivamente, da pura e simples introduo da tecnologia. A mudana exige, acima de tudo, transformao da Cultura Organizacional, de forma a aproveitar, de fato, os benefcios trazidos pela Tecnologia da Informao. Entretanto, enganoso pensar que a Tecnologia da Informao no traz nenhuma alterao por si s. As habilidades dos indivduos so diretamente afetadas, em um mundo cada vez mais virtual e interligado.

2.4.2.3 Adoo de Tecnologia.

Este um item extremamente sensvel em pois a partir da adoo da TI que se pode extrair seu. benefcios. Por ser um fator chave no sucesso esse item ser melhor explorado em um captulo parte.

2.4.3Perspectiva transversal: os sistemas de informao.

A tica da anlise feita aqui quanto a evoluo dos sistemas de informao baseados em Tecnologia da Informao (SI/TI) no processo decisrio[OBrien, 2003] [Stair, 2000]. Considera-se que a TI influencia a forma como os sistemas de informao so desenvolvidos. Na dcada de 60, devido as restries de hardware (baixa confiabilidade, baixa capacidade de processamento e de armazenamento, pouca capacidade de interconexo) os sistemas de informao baseados em TI atendiam apenas a uma pequena frao da organizao. Alguns autores chegam a argumentar que existia a crise do hardware que consistia na imposio e na limitao do hardware no desenvolvimento de sistemas maiores. Assim, mesmo que se desejasse criar sistemas organizacionais, no se conseguiria. 69

Nessa poca os sistemas tpicos eram os sistemas de apoio as operaes bsicas da organizao. Os sistemas de contabilidade e de folha de pagamento eram sistemas caractersticos dessa poca. Esses sistemas so classificados em SIO - Sistemas de Apoio a Operaes [Rezende e Abreu, 2000] ou como [Stair,1998]. Estes sistemas do apoio s operaes bsicas da organizao. So sistemas que esto associados as operaes dirias da organizao. Esses sistemas possuem como caractersticas bsicas[Stair,1998]: SOT Sistemas de Apoio a Transaes

Grande quantidade de dados de entrada e de sada. Grande volume de processamento de dados. Grande volume de repetio de operaes. Grande necessidade de armazenamento. Volume de crtica de dados elevado. Atendimento a vrios usurios. Vital para a organizao.
Uma da maiores dificuldades dos SIO que eles se tornaram ilhas dentro das organizaes. Muitas vezes os dados eram replicados em outros sistemas necessitando uma atualizao constante de todas as bases de dados. Essa atualizao nem sempre se fazia de forma imediata, causando inconsistncia de informaes na organizao! Em geral o mesmo dado tinha que ser varias vezes atualizados, em vrios sistemas. Nos anos 70, com o aumento da capacidade de processamento, armazenamento e de transmisso de dados, iniciou-se a disseminao de sistemas ao atendimento da mdia gerncia. Esses sistemas caracterizam-se pelo aumento de dados que auxiliam o planejamento e o controle do processo gerencial. Aparecem os sistemas de informaes gerenciais (SIG). Assim a finalidade de um SIG o de ajudar a organizao a atingir seus objetivos atravs do subsdio de informaes mdia gerncia para que esta possa controlar, organizar e planejar de modo mais eficiente. Um fator diferenciador dos SIO/SIT que as informaes geradas pelos SIG do suporte a tomada de deciso gerencial. Um dos pontos principais de um SIG fornecer informao certa, no momento certo, com segurana pessoa certa. Os SIG e os SIO/SOT resolvem o problema de tomada de decises de forma rotineira, seja para lidar com as operaes do dia a dia , seja para a tomada de deciso gerencial. O uso da TI para apoiar sistemas que dessem apoio a decises no estruturadas resultaram no 70

desenvolvimento do conceito de Sistemas de Apoio Deciso (SAD) ou Sistemas de Suporte Deciso (SSD). Os SAD so um ambiente computacional que auxilia nas diversas etapas do processo decisrio e de soluo de problemas. Esses sistemas possuem como caractersticas principais o acesso a um grande volume de banco de dados internos e externos, fornecem apoio a diversas formataes de sada e possui banco de dados. Nos ltimos anos esto sendo desenvolvidos sistemas de apoio a deciso baseados em grupo (SADG ou SSDG). Este sistemas possibilitam que uma equipe de pessoas passes pelos estgios de tomada de deciso e de soluo de problemas de forma coletiva. Os SAD utilizam informaes consolidadas em Data Warehouse aliados a Data Mining e a tecnologias on-line analitical processing (OLAP). Tecnologias de Sistemas especialistas, Sistemas Baseados em Conhecimento, Banco de dados de modelos so tecnologias associadas aos SAD. Nos anos 90 a preocupao est em atender as decises dos executivos e a integrao geral dos sistemas de informao. Surgem os sistemas de informao de executivos (SIE). Esses sistemas surgem como o desdobramento do emprego dos conceitos dos SAD mas voltados para a alta gerncia. A TI, em sua evoluo, possibilitou a criao de sistemas que imitassem o processo cognitivo de tomadas de deciso do ser humano. O ramo da TI, em particular da computao, que estuda o processo de automao do conhecimento humano a Inteligncia Artificial. Um dos frutos desse ramo so os Sistemas Especialistas (SE), s Sistemas Baseados em Conhecimento (SBC) e as Redes Neurais (RN). Esses sistemas diferem dos SAD pois incorporam o conhecimento de um indivduo ao sistema. Entretanto uma das maiores dificuldades desses sistemas est justamente nos SIO/SIT. Se este sistemas no estiverem integrados, se no apoiarem efetivamente o negcio organizacional, no forem confiveis, no proverem informaes em tempo hbil a seus executivos dificilmente serviro de insumo para SAD. Uma das alternativas para a integrao destes sistemas so os sistemas de Planejamento de Recursos Empresariais(ERP). Este tipo de sistema visa a integrao dos processos organizacionais, ao invs de funes. Uma das caractersticas desses sistemas so o uso de uma base de dados nica. Os sistemas ERP procuram resolver o problema e a complexidade crescentes em se mais sistemas cada vez mais complexos assim como obter informaes mais confiveis dos dados disponveis na empresa. Devido a sua integrao os dados so entrados apenas uma nica vez.

71

2.4.4Perspectiva antropolgica: a Cultural.

O desenvolvimento do profissional de informtica possui caractersticas muito particulares. No incio da era das grandes mquinas, anos 60, o centro de processamento de dados estava totalmente desconectado da organizao. Muito hermtico, de linguagem pouco acessvel e distante, o profissional de informtica vivia um mundo parte. A computao era um conceito pouco difundido, Hardware e Software eram palavras novas e desconhecidas. Programar era uma atividade que poucos conheciam. Havia uma preocupao desproporcional com a tecnologia, o negcio organizacional sempre ficava em segundo plano. De certa forma, o profissional de informtica passou a intermediar o acesso aos dados que eram, antes do computador, de acesso imediato quem interessava. O Centro de Processamento de Dados (CPD) estava praticamente alheio s questes organizacionais. Sob determinado aspecto parecia que a organizao existia para suprir as necessidades deste centro. De qualquer maneira, a tecnologia era de difcil compreenso. Esta baixa compreenso estava associada a novidade desta tecnologia. Os micro computadores, a partir dos anos 80, alteram um pouco esta perspectiva. Como os diversos atores da organizao puderam adquirir seus micros de mesa, j no estavam mais dependentes do CPD para obter informaes. Quebravase o monoplio do acesso do profissional de informtica. A informao voltava a ser obtida pelo seu prprio dono, sem intermedirios. Entretanto essa cultura ainda est encruada nos comportamentos e aes do departamento de TI. Uma forma que as empresas encontraram para resolver este problema foi terceirizando seus Centros de Processamento de Dados. Assim, a terceirizao de servios de informtica no necessariamente responde a questo: a empresa consegue atravs de seu processo de gesto gerir os seus recursos de informtica? Se a empresa ainda no sabe gerir suas informaes no ambiente de TI dificilmente ir conseguir gerir em um ambiente terceirizado. Possivelmente a questo no seja a mera observao e descoberta das novas possibilidades da TI que seja a barreira para obter as oportunidades que ela oferece. A razo pode estar na cultura tecnicista representada pelo chefe de tecnologia da informao e a cultura de negcio dos demais participantes do alto escalo da organizao, conforma apontado por Wang[1994].

2.5 Concluso.
A TI definitivamente algo novo para as organizaes. Apesar de ter apenas 50 anos de existncia ainda um desafio muito grande para as organizaes. Em pesquisa realizada ao longo dos anos 90 constatou-se que apesar de todo o investimento realizado em TI nos anos anteriores pouca produtividade havia sido obtida. 72

Uma das razes levantadas para essa baixa produtividade era que as organizaes no fizeram os ajustes necessrios em suas estruturas organizacionais de forma a aproveitar os novas possibilidades de TI. Necessitavam por tanto repensar suas formas de ao tendo em vista que eles foram construdas em um modelo de TI anterior ao uso do computador. Outra vertente acreditava que o problema ia alm do mero aspecto da estrutura organizacional. O principal problema era cultural. Em realidade o choque cultural que existia, e ainda existe, entre os gestores da TI e os gestores organizacionais, refletidos nos papis dos CIO e CEO. Muitas iniciativas vo ao encontro desta desconexo cultural. Vrios executivos j fazem curso de TI e alguns cursos formam um profissional de informtica no necessariamente tcnico mas com viso organizacional. Sauer e Willcocks[2002], sustentam que necessrio criar uma figura intermediria entre o CIO e o CEO que possibilite a integrao entre a empresa e o seu departamento de TI. Os desafios continuam, e as possibilidades da TI ainda continuam disponveis. As organizaes que conseguirem superar estas diferenas tero melhores chances de vencer.

2.6 Bibliografia.
ADLER, Paul. "New Technologies, New Skills". California Management Review. Vol. 29. No. 1.Fall/1986. Pg. 9-23. ADLER, Paul S., SHENHAR, Aron. "Adapting Your Technological Base: The Organizational Challenge". Sloan Managemente Review. Vol. 32. No 1. Fall/1990. Pg. 25-37. BRIGHT, James R.Does Automation Raise Skill Requirements ?. Harvard Business Review, July-August, Vol. 36. No. 4. 1958. Pg. 85-98. BURLINGAME, John. Information Technology & Descentralization. Harvard Business Review. Vol 39. No 6. November-December/1961. Pg. 121-126. DeLISI, Peter S. "Lessons from The Steel Axe: Culture, Technology and Organizational Change". Sloan Management Review. Vol 32. No 1. Fall/1990. Pg. 83-93. HUBER, George P. "A Theory of The Effects of Advanced Information Technology On Organization Design, Intelligence, and Decision Making". Academy of Management Review. Vol 15. No 1. 1990. Pg. 47-71. JOHNSTON, Russel, LAWRENCE, Paul R."Beyond Vertical Integration: The Rise of The Value-Adding Partnership". Harvard Business Review. Vol 66. No 4. July-August/1988. Pg. 94-101.

73

LEAVITT, Harold J., WHISLER, Thomas. "Management in the 1980s". Harvard Business Review. Vol 36. No 6. November-December/1958. Pg 41-48. MASSUDA Uma nova era de redes de informao global e seu impacto em pases em desenvolvimento. Encontro Sobre a Indstria do Conhecimento e o Processo de Desenvolvimento. OCDE. 1980. MORTON,Michael S. Scott."Introduction". In: The Corporation of The 1990s: Information Technology and Organizational Transformation. Ed. Michael S. Scott Morton. New York University Press. 1991. NOLAN, R. L.(1982) .Managing the crises in data processing. OBRIEN, James A.Sistemas de Informao e as decises gerenciais na era da Internet. Saraiva. 2003. PORTER, Michael, MILLAR, Vitor E. "How Information Technology Gives You Competitive Advantage". Harvard Business Review. Vol. 53. No. 4 July-August/1985. Pg. 149-160. REZENDE, A. R., Abreu, A. F. Tecnologia da Informao aplicada a sistemas de informao empresariais. 2a Edio. Atlas. 2000 SAUER, Chris, WILLCOKS, Leslie. Organizational Architect. Sloan Management Review. 2002. SCHEIN, Edgar H."Coming to a New Awareness of Organizational Culture". Sloan Management Review. Winter. 1984. SCHEMENT, Jorge R."Porat, Bell, and the Information Society Reconsidered: The Growth of Information Work in the Early Twenty Century". Information Processing & Management. Vol. 26, No. 4 pp 449-465. 1990. STAIR, Ralph M. (1998) Princpios de Sistemas de Informao uma abordagem Gerencial. LTC. TOWETT, Paul, ROTHWELL, Margaret. "The Economics of Information Technology". McMillan Press. 1986. VENKATRAMAN, N. "IT-Induced Business Reconfiguration". In: The Corporation of The 1990s: Information Technology and Organizational Transformation. Ed. Michael S. Scott Morton. New York University Press. 1991. WANG, Charles B. Techno Vision. McGraw-Hill. 1994. YATES, Joanne, BENJAMIN, Robert. "The Past And The Present As A Window On The Future". In: The Corporation of The 1990s: Information Technology and Organizational Transformation. Ed. Michael S. Scott Morton. New York University Press. 1991. 74

ZUBOFF, Shoshana. "Automate/Informate: The Two Faces Of The Intelligent Technology". Organizational Dynamics. Vol 14. No. 2. Autumn/1985. Pg 5-18.

75

3Projetos de TI.
3.1 Introduo.
Presenciamos uma era que caracterizada como a Era do Conhecimento. Vivemos em um mundo extremamente conectado. A TI uma das ferramentas chave para organizaes, uma tecnologia revolucionria. A Internet o artefato mais concreto do tipo de mundo que vivemos. Como, ento, gerir o processo de transformao das tecnologias de automao ou convencional para as tecnologias da informao? Como aproveitar as oportunidades criadas pela TI? Uma das respostas esta questo atravs de projetos. Projeto um processo nico, consistindo de um grupo de atividades coordenadas e

controladas com data para incio e trmino, empreendido para o alcance de um objetivo conforme requisitos especficos, incluindo limitaes de tempo, custo e recursos. [NBR ISO 10006]. Este artigo discute alguns pontos que so fundamentais para a gerncia de um projeto de TI. Devido a caractersticas histricas, discutidas no captulo II, os projetos de TI em geral tratam apenas dos aspectos tcnicos da soluo. A participao dos principais atores e beneficirios do projeto de TI , em boa parte dos casos, marginal. Um dos problemas enfrentados pelos principais beneficirios desses sistemas a prpria caractersticas da TI, dentre as quais pode-se citar: Evoluo muito rpida do Hardware: este aspecto refletido na Lei de Moore, uma observao feita em 1965 por Gordon Moore, em que o nmero de transistores por polegada quadrada em um circuito integrado dobra a cada ano e meio. Esta taxa deve se manter para as prximas duas dcadas. Intangibilidade do software: diferente de outras artefatos tecnolgicos o software no pode ser tocado ou sentido. Neste aspecto o software quando construdo sofre com essas caractersticas pois no se pode ver sua evoluo. Novidade: as TI, mais particularmente as TIs associadas ao computador e as telecomunicaes, so extremamente recentes. Considerando que um dos marcos foi o ENIAC no ano de 1945, relativamente muito pouco tempo para amadurecer toda a evoluo e potencialidade desta tecnologia. Dos aspectos acima, o software se apresenta como o mais desafiador visto ele a expresso tecnolgica da alma de qualquer organizao: as suas regras de negcio. Essas caractersticas dificultam a adoo de qualquer projeto de TI. Entretanto alguns pontos, nos dias de hoje, so considerados chaves para qualquer projeto de TI, so eles: 76

Gerenciamento de mudanas, comprar ou desenvolver, requisitos de um projeto de software, ciclos de vida de um projeto de software, ciclo de vida de adoo de pacotes ERP, mtricas de software, normas e padres internacionais, estratgias de adoo e a participao do cliente. Esses assuntos sero tratados a seguir.

3.2 Gerenciamento de Mudanas.

Um dos maiores desafios no uso da Tecnologia da Informao tem sido a sua adoo e o processo de transformao organizacional necessrio. Foi a partir de vrios fracassos, ao longo das ltimas dcadas, que foram desenvolvidos mtodos de transformao que permitissem compreender melhor as necessidades das organizaes, viabilizando a adoo dessa tecnologia de forma efetiva (De Marco, 1989 e Gane 1983). Entretanto, esses novos mtodos estavam baseados em fatores extremamente tcnicos pois no consideravam a gerncia do processo como um todo e nem o meio organizacional no qual o projeto estava inserido. Novas abordagens comeam a considerar fatores no-tcnicos, porm determinantes, para o sucesso da introduo da Tecnologia da Informao nas organizaes. A nfase, nesse caso, se desloca da tecnologia em si, para a gerncia do processo de mudana. Para Benjamin & Levinson (1993), a grande dificuldade na gerncia da Tecnologia da Informao est no fato dessa tecnologia ser capaz de prover mudanas radicais, a nvel do processo de trabalho, prover novas possibilidades de comunicao, tanto intra, quanto entre firmas, e de possibilitar maior agilidade no processo de produo e no suporte aos mtodos de colaborao no trabalho, como visto nas sees anteriores. Tendo em vista tais dificuldades, os autores sugerem oito princpios no tcnicos, porm bsicos, para o auxlio no processo de adoo e gerenciamento de mudanas, via o uso da Tecnologia da Informao: Desenvolvimento de um processo sistemtico de mudanas: para os autores esse processo

serve para dar visibilidade transformao, identificando quais as tarefas sero realizadas e quando. O planejamento da mudana vital ao fornecimento de referncias para discusso da gerncia da transformao. Gerncia do equilbrio entre a Tecnologia e a Organizao: toda mudana leva a Organizao de um estado inicial de relativo equilbrio, para um novo estado de equilbrio. Para os autores, o uso efetivo da Tecnologia da Informao s estar consolidado, quando a tecnologia e a Organizao se transformarem, de forma conjunta e integrada. Determinao da vontade de mudana: todo processo de mudana exige apoio dos indivduos da Organizao. Fundamentalmente, a vontade de mudana est diretamente relacionada satisfao dos requisitos organizacionais.

77

Tamanho do esforo de mudana: as mudanas podem ser meramente pontuais, ou envolver toda a Organizao; sendo assim, o tamanho do esforo de mudana est diretamente relacionado ao escopo de mudana, e quanto maior o esforo, benefcios. O papel do patrocinador: em toda grande mudana fundamental o papel do patrocinador, cuja funo a de prover recursos financeiros e outros recursos chaves ao projeto, advogar em prol desses recursos, influenciar grupos de usurios e servir de consultor para a Organizao, na determinao dos recursos desejados. Comprometimento do usurio: a anlise do comprometimento do usurio fundamental pois serve para verificar se a Organizao pode desenvolver as mudanas esperadas, identificar as mudanas crticas, perceber resistncias em potencial e desenvolver um estratgia de mudana adequada. Prottipo: o desenvolvimento de prottipos, modelos simplificados dos sistemas de informao, pode possibilitar a revelao de resistncias, assim como pode ajudar a quebrlas. Os prottipos tambm so importantes na validao, ajustes e feedback, dos requerimentos necessrios mudana. Revises: as revises no processo de gerenciamento so fundamentais no redirecionamento do projeto, via eliminao de resistncias, e na determinao de aes futuras de forma a garantir a completeza da mudana. Uma srie de outros autores, Kellner(1991), Tully(1991) e McKersie & Walton (1991), consideram que o sucesso de adoo e de uso da Tecnologia da Informao depende, cada vez mais, de fatores no tcnicos, que valorizem o processo de transformao organizacional; de uma forma ou de outra, mencionam os fatores acima analisados por Benjamim & Levinson. Outro fator importante est no engajamento dos indivduos envolvidos com a mudanas. Dessa forma, a introduo da Tecnologia da Informao deve considerar o envolvimento dos principais usurios afetados pela mudana, a discusso do novo processo de trabalho trazido pela introduo da nova tecnologia, treinamento, segurana no emprego (no que se refere a substituio da mo-de-obra pela tecnologia) e no estabelecimento de novas formas de monitoramento e de avaliao do trabalho. Neste caso, o papel da liderana de um indivduo, ou de um grupo, fundamental no processo de cooperao entre os envolvidos pela mudana, e pelo sucesso na adoo e no uso da tecnologia. O processo de adoo e gerncia da transformao exige que a Organizao redefina seu processo de trabalho antecipadamente, ou ao longo do processo de mudana. Mudanas aps a introduo de sistemas de informao, baseados em Tecnologia da Informao, sofrem, em maiores so os riscos e

78

geral, resistncias dos indivduos envolvidos, dificultando o aproveitamento dos benefcios da tecnologia, apesar, desta ltima forma de introduo, ser a mais usual.

3.3 Comprar ou desenvolver.

Uma das questes que mais afligem as empresas quanto a compra de um pacote ou o desenvolvimento interno de uma aplicao. H uma 20 ou 30 anos atrs essa no seria uma questo sria pois quase tudo deveria ser produzido internamente. Hoje com o amadurecimento da rea existem pacotes para quase todos os gostos. Entretanto quando se trata de software trata-se de regras de negcio da organizao e os pacotes nem sempre implementas as regras de negcio praticados. Assim algumas regras devem ser seguidas antes de se decidir pela compra ou pelo desenvolvimento de software [Pressman, 2001]:

Descreva os requisitos funcionais e no funcionas do software. Estime o curso interno para desenvolver o projeto. Selecione trs ou quatro aplicaes que melhor se adeqe s especificaes. Selecione componentes de software que melhor lhe assistiro na construo de software. Desenvolva uma matriz comparativa. Analise questes de suporte ao produto. Consulte a opinio de outros usurios que utilizam o pacote.

3.4 Requisitos de um projeto de software.

Requisitos de um projeto de TI/software sempre complicado. Em primeiro lugar pela questo cultural de no se saber o que fazer com computadores. De certa forma o cliente no consegue observar as potencialidades inerentes de um projeto de TI. Em segundo lugar os projetos de TI lidam sempre com regras de negcios da organizao, que dependendo da cultura e do segmento de mercado em que a organizao esteja inserida, pode ser extremamente voltil. Em terceiro lugar software sempre lida com o intangvel. comum modelar modelos mentais do negcio, concepes e percepes dos diversos atores envolvidos. No raro estas concepes so em geral conflitantes e incompletas. Assim comum o que ocorre na figura 1. Assim um dos principais problemas enfrentados no incio de qualquer projeto est na obteno dos requisitos que faro parte do escopo do projeto. Uma segunda dificuldade

79

quanto a representao desses requisitos e por fim a gerncia desses requisitos ao longo de todo o projeto. Um dos tem mais importantes dos requisitos de um projeto de TI/Software sobre qual o escopo se deseja trabalhar. A definio do escopo fundamental pois a partir dela que um estudo de viabilidade feito, que recursos so definidos, prazos so especificados e custos so determinados. Qualquer alterao no escopo do projeto implica na reavaliao de todos essas variveis. A determinao do escopo implica na definio de todas os requisitos funcionais que estaro presentes no sistema de informao futuro assim como todas os respectivos requisitos funcionais etc). Para se obter os requisitos utiliza-se de vrias tcnicas dentre as quais pode-se citar: correlatas que estaro ausentes. na determinao do escopo que so determinadas tambm os requisitos no funcionais (desempenho, armazenamento, tempo

Entrevista. Observao. Questionrio. JAD.

Quanto a representao, atualmente utilizam-se modelos que procuram representar tanto aspectos estticos, os dados necessrios ao problema, quanto aspectos dinmicos, as funes que operam sobre os dados, dos sistemas de informao. Existem vrias formas de se especificar requisitos[Sommerville, 2003]:

Linguagem natural estruturada: utiliza-se de formulrios padro. Linguagem de descrio de projeto: utilizao de linguagens de programao com recursos
mais apuados.

Notaes grficas: por exemplo a notao de casos de uso. Especificaes matemticas (formais): atravs de utilizao de lgicas de primeira ordem.

3.5 Ciclos de Vida de um projeto de TI/Software

Desenvolver software nos anos 60 era considerado uma arte. Apenas no final desta referida dcada, depois de vrios fracassos em projetos de sistemas de informao baseados em computador, que se cunhou a expresso Crise do Software. E porque no a Crise do Hardware. A crise do software dizia respeito a incapacidade humana de escrever um volume 80

enorme de linhas de cdigo de forma correta, confivel e infalvel. Era necessria o desenvolvimento de novos mtodos, tcnicas e ferramentas que pudessem garantir ou apoiar estas caractersticas. Custo, prazo e qualidade eram sempre questionreis nesses tempos. A crise do hardware no existia visto que o hardware no era uma limitao ao desenvolvimento de sistemas j que sua potencialidade crescia exponencialmente e seu curso reduzia-se na mesma proporo. Os projetos de software deveriam deixar de ser uma arte para terem mais o perfil de

engenharia. Assim uma das primeira providncias nesse sentido foi a determinao de uma ciclo de vida para a construo de software: nascia o ciclo de vida em cascata. Neste ciclo de vida eram identificados etapas bem determinadas na construo de software. Software se tornara uma linha de produo! O ciclo de vida em cascata possua algumas caractersticas:

Etapas bem definidas. Somente se passava para a prxima etapa quando terminava a anterior. Os requisitos do projeto eram bem definidos e conhecidos por todos.

Essas caractersticas logo se tornaram incompatveis com a evoluo e a complexidade dos sistemas e da tecnologia. Novas abordagem gerenciais surgiram que consideravam a prototipao descartvel (apenas para se obter e validar requisitos do usurio), a prototipao evolutiva (com um conjunto de requisitos sendo implementados em uma verso inicial e os outros implementados nas verses subsequentes). O ciclo de vida em espiral foi um marco neste modelos de ciclo de vida de software quando reconheceu a necessidade de evoluir avaliando sempre os riscos de um projeto. No ciclo de vida em espiral sempre se retorna ao comeo mas sempre com uma perspectiva diferente. O ciclo de via em espiral inspirou vrios outros modelos. Atualmente reconhece-se que um projeto de software deve considerar tanto o aspectos da construo quanto o aspecto da gerncia, sendo que em cada etapa de gerncia podem acontecer diversos ciclos de construo. Nos ltimos anos vrios modelos prontos de processos sugiram. Por exemplo o modelo da Rational, RUP Rational Unified Process, tem sido muito utilizado. O modelo do XP, extreme programming, outro que est sendo utilizados por equipes menores e para sistemas mais leves. Algumas empresas tm utilizado este modelo para o desenvolvimento de sistemas WEB.

81

No Brasil existe um processo definido pela UFMG e que pode ser aplicado ao desenvolvimento de sistemas acadmicos[Pdua, 2003]. Nos ltimos anos vrias tm sido as abordagens para a definio de processos para o desenvolvimento para a WEB.

3.6 Ciclos de vida de adoo de projetos ERP.

Os sistemas de ERP so considerados uma soluo para o problema de obteno de qualidade da informao. Assim vria empresas tm assumido o nus e o bnus da adoo e uso desses sistemas. Considera-se 3 estratgias para a adoo de sistemas ERP: a Big-Bang, Small-Bang e a em Fases. A estratgia Big-Bang considera a entrada de operao de todos os mdulos do sistema simultaneamente em toda a organizao. A estratgia small-bang corresponde a entra da de todas os mdulos do sistemas para determinadas unidades da organizao. A estratgia em Fases corresponde a entrada de mdulos especficos do pacote ERP ao longo do tempo. A estratgia Big-Bang possui as fases: deciso e seleo, implementao, estabilizao e utilizao. A estratgia Small-bang e Fases possui as mesmas fases apenas com a repetio contnua das fase de implementao, estabilizao e utilizao.

3.7 Mtricas de Projetos.

No se pode saber se um sistema grande ou pequeno se no se consegue medi-lo. No se pode dizer que um sistema possui qualidade se no sabe o limite de aceitao. Na rea de software essa uma questo complexa. Uma das formas mais comuns de medio de sistemas de informao baseados em software atravs da contagem de linhas de cdigo. Mas essa no parece ser uma abordagem til para aqueles que esto na gerencia do projeto pois as linhas de cdigo de um sistema so influenciadas pela tipo de linguagem de programao utilizada. Uma outra alternativa contagem de linhas de cdigo e atravs da contagem de funcionalidades do sistema. Um dos maiores representantes deste tipo de contagem a medio de pontos por funo. O IFPUG [www.ifpug.org] o rgo internacional responsvel pela regulamentao desta mtrica. funcionalidades: A medio de pontos por funo considera cinco

Entradas de dados. Sadas de dados. Consultas (entrada com sada).

82

 Nmero de Arquivos lgicos. Nmero de Interfaces externas.

A medio em pontos por funo possibilita saber o tamanho de um projeto, saber o tamanho da mudana de requisitos e at se mais apropriado configurar um pacote ou desenvolv-lo. No Brasil a comunidade IFPUG est organizada e possui diversos eventos que so apoiados por ela[www.bfpug.com.br].

3.8 Normas e padres internacionais para a gerncia de projeto.

Devido a complexidade dos projetos de TI a comunidade internacional tem feito um enorme esforo na tentativa de padronizao dessa atividade. Existem atualmente dois grandes modelos de nortmatizao: o de origem europeu, a ISO [www.iso.org] e o de origem a americana, IEEE [www.ieee.org] e SEI [www.cmu-sei.org]. Estas organismos normalizam e fundamentam o conhecimento a respeito de vrios assuntos. No caso da IS0 existem padres para vrias reas do conhecimento, no caso da IEEE e SEI mais direcionados a engenharia. Quando se considera projeto e em especial projeto de TI/software, pode-se caracterizar as seguintes perspectivas: a do produto, a do processo e a do gerenciamento. Do ponto de vista das normas ISO existem duas normas que tratam de software como produto: a 9126, de produto de software e a 12119, que trata de pacote de software. Estas duas normas especificam atributos de qualidade que devem ser identificados em um software. Do ponto de vista de processos para o desenvolvimento de software a ISO possui a norma 12207 que lista todas as atividades de um processo de software e possui tambm a 15504 que trata da avaliao de processo de software. A 12207 uma norma de referncia, sendo que cada projeto de software deve ser configurado de acordo. A norma 15504 trata da tendncia iniciada na ltima dcada de tratar o processo de software com algo a ser devidamente gerenciado e avaliado. Por sua vez a 10006 trata do gerenciamento de projetos de software. A SEI tm tido um papel importante nos ltimos anos. Tm partido deste instituto

possivelmente os maiores avanos no que diz respeito a gerncia de projetos de software. O modelo desenvolvido pelo SEI, o modelo de maturidade de software causou grande impacto em toda a indstria. Hoje vrias verses deste modelo foram especificadas. O foco do modelo d SEI esta na melhoria contnua do processo de desenvolvimento.

83

Um dos aspectos a se considerar em qualquer projeto de TI quanto ao tipo de estratgia ir se adotar para absorver as mudanas. Guida e Tasso, 1994 analisam cinco estratgias gerais, para adoo de Sistemas Especialistas e que podem ser aplicadas a TI de forma geral. A Estratgia Ingnua: procura introduzir a tecnologia sem muitos compromissos via determinada aplicao. A Estratgia Vital: baseia-se na seleo de uma aplicao especfica, alocando recursos para a sua construo. A aplicao escolhida deve ser um sucesso para a Organizao, de forma a ser convincente quanto ao emprego da tecnologia. A Estratgia Planejada: caracterizada por quatro itens: iniciativa da alta gerncia; centralizao do desenvolvimento, em uma equipe especializada; anlise estratgica de oportunidades de negcio; treinamento disciplinado e disseminado. A Estratgia Passo-a-Passo: procura, antes de tudo criar uma cultura e conscincia na Organizao, quanto ao uso da tecnologia. Essa conscincia criada, a partir de explicaes de como a tecnologia pode auxiliar na estratgia geral da corporao. A estratgia est baseada, em apoio contnuo iniciativa de uso da tecnologia e pela nfase em obteno de resultados mensurveis. A Estratgia Passo-a-Passo est sedimentada na gradualidade da difuso da tecnologia. A Estratgia Espontnea: baseada no campeo de projeto. A Organizao comea a experimentar a tecnologia, graas a um de seus funcionrios que desenvolve um projeto, no apoiado pela Organizao, que se torna um sucesso e que, finalmente, consegue apoio organizacional de forma a criar uma equipe ou departamento nessa rea. Estas estratgias devem ser devidamente analisadas pois a adoo pode ficar limitada a um nico departamento ao invs de se difundir por toda a organizao. a

compra de hardware e software e o alistamento de voluntrios que procuram desenvolver uma

3.9 Participao do cliente.

A participao do cliente em projetos de software tem sido muito pouco considerada. Em geral a nfase tem recado, desde a propalada crise do software, nas questes tcnicas destes tipos de projeto: criam-se novas tcnicas de modelem, novas formas de representao de requisitos, novas ferramentas CASE mas pouca ateno tem sido dada a fatores no tcnicos deste projetos. Em particular em qual deve ser a participao dos principais atores e consumidores das informaes ao longo deste processo. So raros os casos em que um cliente entende como um processo de desenvolvimento de software acontece, quais so suas etapas, quais os produtos de cada etapa, qual a efetiva participao ao longo deste processo entre outras. 84

Dados os assuntos tratados nestes relatrios pode-se comentar que:

Projetos vo ao encontro de mudanas.

Todo projeto de TI visa a mudana. Se existe um projeto em andamento porque necessrio cortar custos, melhorar procedimentos, apoiar uma estratgia etc, ou seja existe alguma insatisfao atual com determinada rotina ou procedimento ou forma de atuao da organizao. Assim a participao dos principais atores de um sistemas de informao importante nas diversas etapas de um projeto, pois o novo modelo a ser criado ir interferir diretamente na forma com que este profissional trabalha.

Riscos.
Todo projeto, qualquer se seja, possui riscos. Projetos de TI em particular so muito propensos a falhas, devido a razes diversas: maturidade tecnolgica, pouca participao dos principais envolvidos, volatilidade tecnolgica entre outros. Reconhecer que esses riscos existem e trat-lo adequadamente imprescindvel.

Validao.
Validao uma atividade que exige grande envolvimento do usurio. nessa hora que muitas caractersticas do projeto podem se levantadas. Deve-se estar atento que quanto mais se caminha ao longo da espiral do processo de construo/adoo de projeto mais caro fica abort-lo ou modifica-lo. Os principais atores devem ter mecanismos de validao e inspeo sistemticos ao longo do projeto como forma de garantir que o projeto ir atender os objetivos propostos.

Apoio da alta gerncia..

Todo projeto, como visto acima, vem ao encontro de transformaes. Em uma organizao a transformao sistemtica somente acontece quando existe apoio da alta direo. Projetos locais, iniciativas pessoais ficam, em geral, limitados nessas iniciativas.

3.10 Concluso.
A tecnologia da Informao oferece uma srie de oportunidades que so capazes de revolucionar e de criar os negcios e as organizaes que hoje se conhece. Entretanto, para se obter os reais benefcios desta tecnologia necessrio um processo de adoo que passa pela execuo de projetos de TI. Muitas empresas hoje j reconhecem o papel dos projetos na obteno de mudanas. A disciplina de projeto deixou de ser secundria e passou a ser considerada essencial. Entidades, 85

como o PMI Project Management Institute, congregam profissionais que discutem sistematicamente o tema. Em particular, os projetos de TI parecem ser o elo fraco na obteno dos benefcios da TI. Um dos aspectos mais neglicenciados neste processo a participao dos principais atores ao longo destes projetos. A discusso est em geral cercada de fatores tcnicos que alija e impede que os principais clientes e donos das informaes participem efetivamente deste processo importante de transformao.

3.11 Bibliografia.
BENJAMIN, Robert, LEVINSON, Eliot. "A Framework For Managing IT-Enable Change". Sloan Management Review Vol. No. Summer/1993. Pg. 23-33. DeMARCO, Tom."Anlise Estruturada e Especificao de Sistemas". Editora Campus. 1989. GUIDA, G., TASSO, C.Design and Development of Knowledge Based Systems - For Life Cicle to Methodology. Willey Professional Computing. 1994. KELLNER, Marc. "Non-Technical Issues in Software Engineering". IEEE. 1991. McKERSIE, Robert, WALTON, Richard E. "Organizational Change". In: The Corporation of The 1990s: Information Technology and Organizational Transformation. Ed. Michael S. Scott Morton. New York University Press. 1991. NBR ISSO 10006. Gesto da Qialidade Diretrizes para a qualidade no gerenciamento de projetos. ABNT. Pressman, Roger S. "Software Engineering a pratictioners approach". Fith Edition. 2001. MCGrawHill. Sommerville, Ian. Engenharia de Software. Sexta edio. 2003. Addison Wesley. TULLY, Colin. "A Failure of Management Nerve and Vision". IEEE. 1991.

86

4 A Engenharia de Requisitos.
4.1 Introduo.
Realizar projetos de Tecnologia da Informao uma tarefa recorrente em empresas que desejam estar atualizadas com o atual momento historio. Entretanto, so trs os pontos chaves de qualquer projeto de TI:

O entendimento dos requisitos dos usurios, o que chamo do entendimento do objeto

Sistema de Informao.

O entendimento das caractersticas tecnolgicas de TI em decorrncia do objeto Sistemas

de Informao, em particular dos requisitos de software e

Do processo de transformao do objeto Sistema de Informao para o objeto Software.

No captulo de complexidades ser abordado melhor este tema. No momento, sero apenas indicadas algumas consideraes a respeito dos tpicos que devem ser observados para lidar com a complexidade desses dois objetos e de sua transformao sob o ponto de vista dos requisitos.

4.2 Caracterizao.
O processo de engenharia de requisitos chave em projetos de software j que se no se consegue entender o que se quer possivelmente aquilo que se constri estar errado. A importncia da etapa de conhecimento dos requisitos em um projeto de software diferente de um processo de engenharia tradicional, visto que esta ltima se ocupou, ao longo da histria do homem, com a construo de objetos visveis. O software traz novas necessidades e nuances de desenvolvimento: enquanto que na engenharia tradicional a montagem da linha de produo proporcionalmente mais cara que concepo do produto na engenharia de software a concepo do produto mais cara do que a montagem de uma linha de produo; na engenharia tradicional v-se o objeto ao logo se sua construo mas na engenharia a de software esta caracterstica no to evidente. Desta forma o entendimento dos requisitos na construo de um sistema de

informao/software crucial. Assim a etapa de engenharia de requisitos uma das mais importantes quando se desenha construir software. Em geral a engenharia de requisitos considera trs etapas:

Identificao. Especificao.
87

 Validao.
A etapa de identificao procura registrar quais os conceitos chaves iniciais do sistema de informao em questo. Entre estes conceitos procura-se responder algumas perguntas tais como: qual a misso do sistema? Quais os principais atores que necessitam e trocam informao com o sistema? Quais as funcionalidades principais do sistema? Quais dos dados que so manipulados? Quais os principais mecanismos de troca de informao? Qual o escopo do sistema? Entretanto, esta etapa uma da mais difceis j que as respostas a estas perguntas so obtidas atravs de um processo de levantamento de dados que envolvem relaes sociais entre os diversos participantes atravs de vrias tcnicas especficas para tal propsito. Ironicamente estas tcnicas no so enfatizadas em cursos de graduao de informtica. Dentre as tcnicas pode-se citar: entrevista, brainstorm, JAD e PIECES. Estas tcnicas sero tratadas em uma seo especfica. O resultado final desta etapa um documento basicamente estruturado respondendo as questes acima. A etapa de especificao procura detalhar os requisitos identificados na etapa anterior detalhando-os atravs de vrios modelos especficos. Os modelos de especificao so, em geral, caracterizados sob dois paradigmas: o estruturado e o orientado a objetos. Alguns exemplos de modelos desta etapa so os diagramas da UML, listas de eventos, diagramas de fluxos de dados. A etapa de validao certifica que os modelos especificados pela equipe de tecnologia da informao so efetivamente aqueles que so esperados pelos principais clientes e usurios do sistema de informao. Alguns exemplos de tcnicas de validao so revises gerenciais, inspees, revises tcnicas dentre outras.

4.2.1Etapa de Identificao.
Esta etapa consiste em identificar quais os requisitos que sero necessrios para a construo de um sistema de informao baseado em software. A princpio o gerente ou analista est preocupado com alguns elementos, conforme indicados anteriormente, tais como a misso do sistema, as funcionalidades do sistema, o prprio escopo do sistema, entre outros. A dificuldade maior est no processo de identificao destes elementos. Para tal algumas tcnicas de identificao de requisitos so necessrias. Estas tcnicas devem ser utilizadas conforme a situao em que se encontra o contexto ou o cenrio do sistema. Cenrios conturbados exigem tcnicas apropriadas.

88

A seguir sero descritas as seguintes tcnicas: entrevista, brainstorm, JAD e PIECES. O texto que se segue est baseado em [Carvalho e Chiossi, 2001], [Xexo, 2006], [Raghavan, Zelesnik e Ford, 1994].

4.2.1.1 Entrevistas.
Entrevistas podem ser entendidas com tcnicas em que um investigado especfico, no caso de um sistema de informao um gerente de projeto ou analista, est frente a um usurio e lhe formulam perguntas com o propsito de obteno de dados que interessam para uma determinada investigao ou problema. A entrevista possui algumas vantagens tais como: possibilita a obteno de dados diretos daqueles atores que so importantes para o sistema; permite obter informao detalhas daquilo que se quer investigar; os dados obtidos podem ser quantificados e classificados. Entretanto as entrevistas possuem algumas desvantagens tais como a falte de interesse do entrevistados em fornecer informaes; o no entendimento dos conceitos apresentados pelo entrevistador; a obteno de respostas inconsistentes. Vrios tipos de entrevistas so possveis. Elas podem variar no modelo de estruturao. Entrevistas informais no h estruturao daquilo que se quer saber, o objetivo bsico a coleta de dados de forma exploratria. A entrevista focalizada permite ao usurio falar abertamente sobre um determinado assunto, entretanto esta enfoca um tema bem especfico. Este tipo de entrevista utilizado em situaes experimentais com o objetivo de analisar uma determinada experincia vivida ou um determinado processo de deciso. A entrevista por pautas estabelecida atravs de pontos de interesse em que o investigador vai explorando ao longo do processo. Por fim, a entrevista estruturada se desenvolve a partir de uma relao predeterminadas de perguntas que materializado atravs de um questionrio. Este tipo de entrevista possibilita o tratamento quantitativo dos dados. O processo de conduo de uma entrevista considera a preparao do roteiro da entrevista, do estabelecimento do contato inicial, da formulao das perguntas (a entrevista em si), do registro das respostas e da concluso da entrevista. No um tipo de entrevista melhor que outro. Todos so apropriados, dependendo do contexo, tais como: estabelecer um contato inicial, detalhar determinado aspecto do sistema, avaliar a qualidade de um servio etc.

4.2.1.2 Brainstorm.
Em uma traduo livre Brainstorm significa uma chuva de idias. Princpio bsico desta tcnica fazer com que os participantes falem sem medo de serem censurados ou reprimidos. A tcnica de Brainstorm recomendada para grupos de quatro a dez pessoas que sejam relevantes para sesso. 89

Fazem parte da sesso alm dos usurios relevantes, o lder da sesso e o relator. O lder da sesso tem por misso colocar o problema que ser discutido e conduzir a sesso garantindo que:

Os participantes fiques confortveis em expressar suas idias. Que as idias menos convencionais tenham espao para apreciao. Que o nmero de idias seja suficientemente grande. Que as idias possam ser agrupadas em novos conceitos ou idias.

O relator tem por misso o registro das idias. Uma sesso de brainstorm possui duas fases: a de gerao de idias e a de consolidao. Na fase de gerao de idias o lder coloca o problema e conduz a reunio em busca de idias para a resoluo do problema. Esta fase se encerra quando o lder da sesso fica satisfeito com a quantidade e qualidade das idias geradas. Caso a sesso fique cansativa o lder pode marcar uma nova sesso. A segunda fase a de consolidao das idias. Nesta etapa o grupo organiza as idias geradas de forma a ser bem utilizada. nesta fase que a avaliao das idias ocorre e so organizadas. As idias so sistematizadas e priorizadas.

4.2.1.3 JAD.
A tcnica de JAD que promove a cooperao do entendimento dos requisitos. August[1993] descreve com detalhes esta tcnica que foi desenvolvida pela IBM em 1977. Esta tcnica possibilita a criao de uma viso coletiva e compartilhada dos requisitos. baseados em quatro princpios bsicos:

O JAD est

Dinmica de grupo. Utilizao de recursos visuais. Processo organizado e sistematizado de conduo. Documentao padronizada.

O JAD pode ser utilizado para a definio de requisitos de software seja para a construo ou para a compra; para a determinao dos requisitos para a modificao de pacotes de software; para melhorias evolutivas de software entre outras. As fases de um processo j se caracterizam por: 90

Fase de adaptao: necessria a customizao da tcnica para a necessidade em questo. Esta fase consiste em organizao da equipe de JAD, preparao do material e adaptao das etapas para a atividade em questo.

Fase de reunies: consistem em encontros sistematizados do grupo de JAD para a definio dos requisitos do problema.

Fase de finalizao: consiste em relatar organizadamente a sesso de reunies em seu formato final.

Alguns papis so caractersticos em uma sesso JAD: do lder da sesso, do analista, do patrocinador, do usurio, do analista de tecnologia e especialistas em uma rea de aplicao.

4.2.1.4 Arcabouos(Frameworks).
As tcnicas de entrevistas, JAD e Brainstorm lidam com os aspectos de identificao dos requisitos sem, no entanto, uma formatao para a expresso desses. Em geral pode-se usar a prpria linguagem natural para reapresentar os requisitos, entretanto sabe-se das dificuldades inerentes do uso da linguagem natural com respeito a ambigidade e preciso, entre outras. Por outro lado o uso de linguagens formal acarreta problemas de validao com os usurios. Uma alternativa estas opes a utilizao de arcabouos para minimizao destes problemas. Um dos arcabouos para a especificao dos requisitos o PIECES. O PIECES uma sigla para seis caractersticas de requisito que um requisito pode possuir, so elas: desempenho (performance), informao e dados, economia, controle, eficincia e servios. Cada uma destas categorias pode ser utilizada pelo entrevistador ou analista para explorar os requisitos. Assim tem-se:

Desempenho: associado a produtividade ou ao tempo de resposta. Informao e dados: corresponde ao tipo de dados que deve ser manipulado pelo sistema para que este possa fornecer a informao til ao usurio.

Economia: diz respeito a questes relacionadas ao custo necessrio tanto para a prestao de um determinado nvel de servio ou para suportar demanda em uma determinada hora de pico.

Controle: corresponde a funcionalidade necessria para manter o sistema operando dentro de padres previsveis. Estas funes atuam sobre as funcionalidades dos sistemas. Questes dizem respeito tambm a quais usurios possuem direito de acesso a determinadas funcionalidades.

91

Eficincia: caracterizada como o volume de perda dos recursos necessrios para a execuo do sistema. Em particular a eficincia est caracterizada como redundncias de processos ou de algoritmos mal projetados.

Servios: neste quesito podem ser identificados quais as funcionalidades do sistema assim como as interfaces necessrias para a comunicao do sistema com seus usurios, assim como outros sistemas.

Outras formas de arcabouos podem ser encontradas tais como em Durn et all[1999].

4.2.2Etapa de Especificao.
A especificao de um requisito deve possuir alguns atributos de qualidade, tais como [Pfleeger, 1998]:

Correto: est descrito sem erros que provoquem ambigidade na interpretao. Consistente: no existem outros requisitos conflitantes ou ambguo. Completa: o requisito est completo ser os seus estados, entradas, produtos e restries so descritos pelos requisitos de alguma forma.

Realstico: diz respeito as reais necessidades do usurio com relao aos objetivos que se quer alcanar.

Necessrio: no existem requisitos suprfluos ou desnecessrios que no ajudaro ao usurio atingir seu objetivo.

Verificvel: possvel escrever funes de teste que demonstrem que os requisitos foram alcanados.

Rastrevel: as funes do sistema podem ser mapeadas para os requisitos que representam.

As tcnicas de especificao de requisitos podem ser classificadas de vrias formas [Naddeo, 2002]. Para fins didticos, as tcnicas aqui apresentadas sero classificadas em externas aos sistemas de informao considerado e as internas. Sendo as internas classificadas entre aquelas votadas para a orientao a objetos e a de paradigmas estruturados. As tcnicas externas dizer respeito a modelagem do contexto do sistemas de informao sendo utilizadas para caracterizar o negcio, sua estruturas, seus principais personagens e processos. Xexo[2006] apresenta vrias tcnicas para a modelagem do negcio. Destaca-se nesta etapa o diagrama de atividade da UML para a modelagem de processo. Estas tcnicas esto voltadas para discusso e a validao com o usurio. 92

J as tcnicas internas ao sistema de informao so necessrias para o desenvolvimento do software, logo atende aos gerentes de tecnologia da informao, arquitetos de software e programadores. Sob esta tica dois paradigmas se consolidam: o orientado a objetos e o estruturado. Dentro destas dois paradigmas as tcnicas podem ser classificadas em tcnicas que lidam com modelos estticos e as tcnicas que lidam com modelos dinmicos. O modelo estruturado tendo como pice a dcada de 70 e 80 possui como caracterstica principal a separao conceitual de processos e dados. Assim todas as tcnicas derivadas deste paradigma procuram tratar de forma inter-relacionadas tanto os dados quanto as funcionalidades. As tcnicas representantes deste paradigma so os Diagramas de Fluxo de Dada, utilizados na etapa de anlise dos requisitos, os Diagramas Estruturados, utilizados na etapa de projeto, e os Diagramas Entidade e Relacionamento, utilizados na etapa de anlise. J o paradigma orientado a objetos foi concebido nos anos 60, mas apenas maturou nos anos 90 com o advento das linguagens desktop e depois da utilizao ubqua do Java. Em se tratando de modelos de desenvolvimento de sistemas a maior representante deste modelo hoje a UML com seus diagramas que tratam da modelagem das vrias facetas do software.

4.3 Atributos da Engenharia de Requisitos.

Como visto anteriormente a Engenharia de Requisitos fundamental para a compreenso e posterior detalhamento do sistema. A lista de atributos abaixo reflete a complexidade do assunto e orienta possveis aspectos de investigao deste assunto.

a. Tcnicas de Levantamento.
Existem vrias tcnicas de levantamento de requisitos: brainstorm, JAD, entrevistas, observao, PIECES entre outras. Utilize-as de acordo com as caractersticas associadas a cada uma delas e levando-se em considerao a complexidade do caso e do ambiente institucional.

b. Ciclo de vida.
Ciclo de vida pode ser considerado como uma estratgia de ao de processos. Por exemplo, utilizar cascata quando os requisitos forem bem entendidos por todos. Assim, empregue um ciclo de vida de acordo com o ambiente institucional vigente.

c. Processos
Os processos definem as atividades e as etapas necessrias para se construir um software, ou melhor, dizendo, para transformar o objeto Sistemas de Informao em objeto software. Existem dois paradigmas de processos: os processos pesados, tais como RUP, e os processos geis tais como XP. Dependendo de sua estratgia de cilco de vida configure ou escola um que se adapte a esta. 93

d. Regras de negcio.
Regras de negcio no so requisitos dos sistemas. Os requisitos do sistema definem a fronteira do objeto Sistema de Informao. Uma regra de negcio define uma ao, um conceito ou um clculo que valem para todos os sistemas dentro de um determinado domnio.

e. Objetos de um sistema de informao.

Ao observar um sistema de informao deve-se levar em conta os elementos que o constituem: atores, aes, dados, tempo e restries.

f. Misso do sistema.
Identificar a misso do sistema fundamental para validar as aes e os requisitos, j que estes devem ser devidamente justificveis para completar a misso proposta. Sem a identificao da misso no h como verificar a aplicabilidades das aes e dos requisitos.

g. Limites dos sistemas.

Toda definio do escopo do sistema parte do princpio daquilo que o sistema deve fazer. Entretanto isto nem sempre traz clareza quanto aos contornos exatos do sistema. Para delimitar a fronteira com maior preciso necessrio dizer quais os requisitos no sero considerados.

h. Os eventos dos sistemas.

O advento da orientao a objetos fez com que as tcnicas da modelagem essencial fossem descartadas como um todo. Entretanto a teoria de eventos serve de ponto de partida tanto para sistemas sob a tica do paradigma funcional quanto da tica do paradigma orientado a objetos e uma tima abordagem para se encontrar requisitos.

i. Priorizao dos requisitos.

Todo projeto sofre com a falta de recursos, sejam eles humanos, financeiros e tecnolgicos. Assim, necessrio priorizar os requisitos, de forma a entregar um conjunto possvel e essencial de funcionalidades necessrias e imediatas.

j. Requisitos de persistncia de dados.

Em um sistema de informao necessrio que os dados relevantes necessrios a tomada de deciso estejam presentes. Desta forma necessria a identificao e a caracterizao dos mesmos.

k. As restries ou requisitos no funcionais.

Os requisitos no funcionais podem ser entendidos como restries para a operao do sistema. Eles so importantes, pois afetam, em geral, vrios requisitos. Identifica-los e cataloga-los ajuda no entendimento de como o sistema vai operar.

l. Temporalidade dos requisitos.

Os requisitos no so estticos no tempo. Eles possuem uma dinmica e por vezes dependem um dos outros. Saber quando os requisitos acometessem no tempo determina como o software ser projetado. 94

m.Justificativa e benefcios dos requisitos.

Para se possuir clareza dos requisitos identificados, cabe caracterizar as razes e os resultados decorrentes daqueles requisitos.

n. A estimativa a partir dos requisitos.

Um dos fatores importantes da identificao dos requisitos quanto ao processo de elaborao de estimativas. As estimativas ajudam a estabelecer custos, prazos e recursos necessrios a construo do projeto. O processo de elaborao de estimativas ajuda na visibilidade do projeto.

o. Os atores.
Saber que so os atores que interagem com o sistema ajuda a delimitar as fronteiras do sistema

p. O perfil dos atores.

Alm de saber que so os atores necessrio saber o perfil de cada um. Este detalhamento necessrio para a conduo de entrevistas e reunies de levantamento de requisitos assim como para a identificao de fatores de usabilidade.

q. Especificao das aes.

A identificao das aes apenas um passo inicial para a caracterizao do objeto sistema de informao. Para a transformao em objeto software necessrio uma especificao contnua e cada vez mais detalhada destas aes. A utilizao de cenrios como a na especificao de casos de uso um bom passo para a definio das destas.

r. Prottipos.
A elaborao de prottipos uma boa tcnica para a identificao de requisitos assim como para a validao dos mesmos. Os prottipos permitem aos atores a visualizao, materializao, de suas aes em software.

s. Outros sistemas.
Um sistema de informao interage com Atores que podem ser pessoas desempenhando um determinado papel como tambm outros sistemas de informao. A identificao destes ltimos ajuda na caracterizao do sistema de informao em questo.

t. Mltiplas vises.
Devido a natureza dos diversos elementos que compem um sistema de informao necessrio visualizar estes elementos dos diversos ngulos de forma a verificar a consistncia dos requisitos e do projeto como um todo. Exemplo: ngulo do processo, dos atores, dos dados, das funes etc.

u. Representaes grficas.
Devido a natureza dos sistemas de informaes necessrio criar modelos grficos de forma que evidenciem e revelem a natureza e o inter-relacionamento entre os requisitos. 95

v. Ferramentas automatizadas.
Devido a complexidade de identificao e de especificao dos requisitos de um sistema de informao necessrio que se utilize ferramentas automatizadas de controle de verso e de rastreabilidade de requisitos.

w. Validao dos requisitos.

O processo de identificao e de especificao de requisitos necessita ser validado com o cliente com o intuito de se verificar se estes requisitos que esto sendo percebidos pelos profissionais de informtica so aqueles necessrios s reais necessidades dos usurios.

x. Rastreabilidade
O processo de transformao do objeto Sistema de Informao para o objeto software necessita de um conjunto de atividades que tem por objetivo ir transformado gradativamente o requisito percebido pelo usurio para um requisito implementado em um software. Assim, necessrio este processo de transformao seja acompanhado de forma a se prover futuras manutenes ou evolues nestes objetos.

y. Riscos de projetos.
Todos projeto possui riscos que devem ser identificados e acompanhados ao longo de todo o projeto de transformao. O acompanhamento dos riscos, em particular dos riscos inerentes aos requisitos no-funcionais, vital para a sobrevivncia do projeto e para a entrega segura do objeto software.

z. Construo e descoberta.
O processo de identificao de requisitos em geral concebido como um problema de descoberta, isto implica dizer que os requisitos j esto l basta apenas revela-los. Esta abordagem nem sempre a correta. A identificao de requisitos em geral um processo de construes contnua onde o usurio modela suas necessidade em tempo de projeto, tornando muito mais difcil a elaborao de projetos de TI.

4.4 Bibliografia.
A. Durn, B. Bernrdez, A. Ruiz, and M. Toro. A Requirements Elicitation Approach Based in Templates and Patterns. In WER'99 Proceedings, Buenos Aires, 1999. http://citeseer.ist.psu.edu/651772.html August, Judy H. JAD Joint Application Design. Makron Books do Brasil Editora. 1993. Carvalho, Ariadne M. B. Rizzoni; Chiossi, Thelma C. dos Santos. Introduo a Engenharia de Software. Campinas. SP: Editora da Unicamp, 2001. Srie Ttulos em Engenharia de Software.

96

Naddeo Dias Lopes, Paulo Srgio. Uma Taxionomia na rea de Engenharia de Requisitos. Dissertao de Mestrado. 2002. Pfeeger, Shari L. Software Engineering: theory and practice. Prentice Hall. 1998. Raghavan, Sridhar; Zelesnik, Gregory; Ford, Gary. Lectures Notes os Requirements elicitation. Software Engineering Institute. 1994.CMU/SEI-94-EM-10. Xexo, Geraldo B. Modelagem de Sistemas de Informao: Anlise Essencial e Moderna Aplicada. Disponvel em http://ge.cos.ufrj.br.

97

Parte III Complexidades

98

1 Introduo.
Modelar sistemas de informao no uma tarefa fcil. Talvez a primeira pergunta que emerge : por que modelar sistemas de informao. A principal resposta que atualmente informao pea chave em qualquer processo decisrio logo conhecer o modo como esta informao obtida e caraterizada relevante. Outra importncia do processo de modelagem de sistemas de informao a necessidade de transformar esta modelagem em software. Mas por que necessariamente software? Por que atualmente esta tecnologia que permite disponibilizar o sistema de informao original em internet, banco de dados, redes, agentes, sistemas especialistas entre outros e que por sua vez possibilita que a informao esteja disponvel, acessvel, compartilhada, segura, distribuda e acurada. Desta forma temos um processo de transformao que vai da modelagem do sistema de informao a construo de software. Apesar desta transformao ser um grande problema, em boa medida vrios obstculos j foram superados. Entretanto entender como estes dois objetos de trabalho se caracterizam pode ajudar ainda mais neste processo de transformao. Os tpicos abaixo caracterizam estes dois tipos de objetos.

2 Do objeto sistema de informao.

2.1 Introduo.
Apesar de todo o avano no tratamento automao da informao, o entendimento e a modelagem do objeto sistema de informao, continua sendo de muita complexidade. Nesta seo ser tratada da caracterizao deste objeto. A anlise ser feita do seguinte modo: na seo seguinte sero definidas as caractersticas gerais deste objeto e na seo trs as caractersticas particulares.

2.2 Caractersticas gerais.

Um sistema de informao definido como um conjunto organizado de pessoas, hardware, software, redes de comunicao e recursos de dados que coleta, transforma e dissemina informaes em uma organizao [OBrien, 2003]. Esta definio, assim como outras semelhantes, enfatizam os recursos pelos quais o sistemas de informao se manifestam. Se procurssemos os atributos especficos destes sistemas possivelmente encontraramos os seguintes:

Abstrato.

99

Um sistema de informao, em realidade, no est vinculado ao um determinado dispositivo em si. Os dispositivos apenas fazem com que este seja mais gil, confivel e disponvel. Desta forma um sistema de informao est vinculado ao processo decisrio de um indivduo, logo o sistema de informao algo abstrato que somente til na mente do indivduo que o utiliza.

Dinmico.
O objeto sistema de informao depende essencialmente de quem o utiliza. Pessoas e setores distintos podem inferir ou utilizar sistemas de informao distintos mesmo tendo como base um sistema nico. A troca de profissionais, em uma mesma posio, pode acarretar na diminuio consideradas. ou valorizao de determinadas caractersticas do sistema. Assim o objeto sistema de informao se molda na medida que novas necessidades so identificadas ou

composto de dados, aes e informao.

O processo de tomada de deciso envolve a coleta de dados confiveis para que, com esse conjunto de dados correlacionados e significados se possa obter informaes suficientes para a tomada de deciso. Por conseguinte, um sistema de informao deve possuir mecanismos registro de dados e possuir um conjunto de aes significativas que levem a transformao destes dados em informao.

Escopo indefinido.
O escopo de um sistema de informao sempre indefinido. Teoricamente um sistema um conjunto de partes ou de elementos inter-relacionados que atendem a um objetivo especfico. Um sistema composto de subsistemas. Assim temos uma infindvel emaranhado de sistemas e subsistemas entrelaados. Desta forma qualquer escopo definido um escopo arbitrrio, para efeitos prticos.

Voltil.
A natureza de um sistema de informao reside no em seus componentes, mas na percepo de quem toma deciso. Logo este objeto se molda na medida da necessidade de quem o obeserva.

2.3 Caractersticas particulares.

Assim, sendo este objeto possuidor destes atributos, quais os elementos necessrios para se observar e modelar este objeto. Se o objeto abstrato deve-se procura por conceitos do mundo real. Mas estes conceitos podem ser relativos a quem est tomando decises e no ser efetivamente um conceito absoluto. Logo, o primeiro elemento a se observar so os atores que interagem com o sistema. Mas como identificar os atores se o escopo do sistema por 100

definio indefinido? Esta com certeza uma deciso arbitrria baseada em um conjunto de fatores tais como tempo para caracterizao do sistema, recursos envolvidos etc. Os atores buscam no sistema algo que lhes apiem a tomada de deciso. Esta tomada de deciso est baseada em suas necessidades especficas que so atendidas a partir na significao dos dados existentes no sistema de informao. Assim deve-se observar quais dados so necessrios para serem mantidos pelo sistema de forma que estes dados ganhem significado (informao) quando devidamente empacotados para suprir uma necessidade de um ator. Para obter estes dados um ator necessita de uma interface que possibilite recuperar

apropriadamente a informao de que necessita. Esta interface necessita ser identificada e caracterizada. Para especific-la com propriedade necessrio conhecer devidamente o Ator, seu perfil de uso, suas habilidade e capacidade junto ao sistema. Mas os dados por si s so entidades em repouso eles necessitam, para serem empacotados, processados, que possam geram novos dados e informaes necessrias a tomada de deciso. Logo, junto com os dados deve-se olhar tambm para as aes que so feitas sobre estes dados. Entretanto a tomada de deciso feita ao longo do tempo. Por exemplo, para um aluno se matricular em uma disciplina outras decises devem ter sido necessrias e precedidas ao ato de realizar a matrcula. Portanto necessrio analisar a temporalidade das decises. A localidade outro fator que deve ser analisado. Desta forma caracterizar o espao de ao do sistema possibilita identificar recursos e disponibilidades de informao. Por fim a as decises so tomadas levando em considerao restries de desempenho e ambientais. Restries podem ser entendidas com requisitos no funcionais. Em geral as restries podem ser classificadas em trs tipos: restries de caracterizao do objeto sistema de informao, restrio de desenvolvimento e restrio de operao do software. As restries de caracterizao so decorrentes de regras e procedimento que devem ser seguidos pela equipe de desenvolvimento. Podem tambm estar relacionados a tipos usurios que devem ser entrevistados ou no, ou a tcnicas que devem ser utilizadas para tal. As restries de desenvolvimento dizem respeito a prazos que devero ser compridos, a custos totais de devero ser considerados, ao formato de equipe que ser utilizado entre outros. As restries de operao dizem respeito a como o software ser operado. Alguns exemplos de requisitos restries so: eficincia, manutenibilidade, portabilidade, segurana, usabilidade etc. Estes requisitos devem ser identificados, pois eles influenciaro o desenho do software. 101

Restries

T em po

Estmulo Evento Dados e Aes

Ator

Resposta Sistema de Informao

Espao

Figura PIII-1 Ilustrao dos componentes de um sistema de informao.

Um aspecto final destas caractersticas especficas o modelo de interao dos Atores com o objeto sistema de informao. Um dos modelos que permitem caracterizar com propriedade estes sistemas o modelo de eventos. Este modelo se caracteriza pelo tratamento dos sistemas como o objeto de respostas planejadas. Desta forma, conhecendo os eventos podemos saber qual o seu comportamento e as suas respectivas respostas.

2.4 Da manifestao dos sistemas de informao.

Ao caracterizar como atributos intrnsecos do sistema de informao os atores, estmulos, dados, aes, tempo, espao e restries deixa-se parte relatrio, telas de entrada de dados, fichas etc. Em realidade vimos que o sistema de informao ocorre do ponto de vista de interao entre um determinado ator com objetos portadores de algum dado. Analisando sob este enfoque os objetos em si, isoladamente, no constituem um sistema de informao. O que isto quer dizer? Isto implica que olhar estes objetos identificar uma situao que no possa ver real do ponto de vista da tomada de deciso. Pode ser que aquele relatrio no seja mais til. Desta forma importante sempre estar olhando as necessidades de informao dos atores. Estes objetos so apenas uma manifestao do sistema de informao e no o sistema de informao em si. O sistema de informao em si ocorre quando da interao produtiva entre o ator e o sistema de informao.

102

Se deixssemos um relatrio deitado sobre uma mesa durante 20 dias nenhuma deciso seria tomada, logo isto no seria um sistema de informao. Olhar a manifestao de um sistema de informao importante do ponto de vista inicial da caracterizao do mesmo. Certa vez um grupo de alunos foi modelar um sistema de biblioteca. Ao apresentar o modelo, que era parcialmente automatizado, os alunos descreveram a caixa onde eram registrados os emprstimos e as devolues. A caixa era apenas a forma de manifestao do sistema, o foco deveria ser as funcionalidades inerentes tais como emprestar, devolver etc.

2.5 Bibliografia.
Maffeo, Bruno. Engenharia de Software e especificao de Sistemas. Editora Campus. 1992. Pompilho, S. Anlise essencial Guia prtico de Anlise de Sistemas. Editora Cincia Moderna. 2002. Ruble, David A. Practical Analysis and Design for client/server and GUI systems. Yourdon Press Computer Series. 1997. Xexo, Geraldo B. Modelagem de Sistemas de Informao. Disponvel em http://ge.cos.ufrj.

103

3 Do objeto Software.
3.1 Da caracterizao.
Em geral software conhecido como um conjunto de cdigos associados que implementam uma funo especfica. Mas esta uma definio limitada do que vem a ser software. Quando se conceitua software no se esta apenas lidando com as linhas de cdigo em si. Junto com o software se tem um conjunto de dados associados, que auxiliam na execuo das instrues e uma documentao que explica a operao e na manuteno do software. Mas manual software? , pois ajuda no entendimento do mesmo. Por esse ngulo poder-se-ia caracterizar como software atividades. Por que, ento, esta dificuldade de se caracterizar software? Esta dificuldade inerente a natureza do software que est associado ao nosso processo de tomada de deciso. Assim software em sua essncia um conjunto de instrues que so executadas em um computador e seus dados associados, como tambm todo seu entorno que auxilia ao ser humano entender, operar, explorar ao mximo este objeto para a melhoria de sua tomada de deciso. o treinamento, o manual do usurio entre outras aes e

3.2 Da sua histria.

A histria a do software na realidade uma histria recente. Pode ser categorizado como tendo incio no final dos anos 40, quando da criao dos primeiros computadores. Comercialmente a histria do mercado de software pode ser caracterizado como tendo incio depois de a Justia dos E.U.A determinou que a IBM vendesse o software e o hardware separadamente. Para se ter uma idia do quanto o software um objeto de trabalho recente temos os seguintes marcos:

Criao das primeiras linguagens de alto nvel nos anos 60 (COBOL e FORTRAN). Criao das primeiras linguagens para microcomputadores nos anos 80 (BASIC). Uso extensivo da orientao a objetos com VB e DELPHI (anos 90). Criao da linguagem Java em 1995. Adoo da internet comercial (programao dinmica, 1998).
Estes so apenas alguns exemplos que ilustram o quo pouco tempo lidamos com este objeto.

104

3.3 Do seu processo de produo.

O software possui um processo de produo diferente do processo industrial. No processo industrial tradicional , de objetos concretos (ex.: carros, sapatos, bicicletas) a concepo do produto custa menos do que a construo de uma linha de produo e a produo em si destes produtos. No caso de software o processo de produo diferenciado. A linha de produo e a produo de software em si so relativamente algo triviais, comparado com outros tipos de indstria. Entretanto a concepo do software algo custoso e demorado, vide a dificuldade crescente dos novos lanamentos de software por parte de grandes empresas no mercado. Neste aspecto a necessidade de se estabelecer mtodos tcnicas e ferramentas especficas para lidar com esta complexidade se faz necessrio. Dado a natureza do software e de sua diferena entre outros tipos de indstria o processo de produo de software necessita de uma nfase considervel no processo de descoberta do problema. Em realidade este processo considerado chave em toda a produo do software. Devido a maleabilidade do software, a construo deste deve ser feito em ciclo pequenos evitando que a demora na construo do mesmo implique no envelhecimento das necessidades anteriormente estabelecidos e identificadas no objeto sistemas de informao.

3.4 Da sua natureza

Uma das razes para a diferena do processo de criao e de produo de software tem a ver com a sua prpria natureza. Software um objeto intrinsecamente tecnolgico e mental. necessrio alinhar e modelar todos os aspectos conceituais de modo formal, o que exige grandes habilidades de entendimento do problema, de representao e de especificao. O que mais se aproxima com esta lgica de trabalho a matemtica, mas a linguagem matemtica no consegue ser uma linguagem popular de forma a prover um ferramental para a realizao de tal tarefa. Outra caracterstica do software sua maleabilidade. Isto , o software capaz de ser alterado e modificado criando solues alternativas, onde antes no era requerido. Desta forma o software necessita de uma abordagem no exclusivamente de criao, mas de alterao.

105

4 Benefcios da Abordagem Essencial.

4.1 Eventos e Anlise Essencial
A tcnica de identificao de eventos foi inicialmente concebida para a identificao de funcionalidades de um sistema de informao. Entretanto, a teoria desenvolvida por esta tcnica pode ser bem aplicada para a identificao de requisitos de uma forma geral. Por exemplo, pode-se utilizar eventos para a identificao de casos de uso, onde cada evento identificado poder ser mapeado em um caso de uso. A vantagem de utilizao de eventos est justamente na concepo terica de tratar sistemas como sistemas de respostas planejadas que respondem a eventos bem determinados. Este tipo de aproximao auxilia e fornece uma concepo de ao que facilita o entendimento dos requisitos do sistema. A abordagem por eventos possibilita identificar os requisitos do sistema sob a tica dos usurios. O propsito do modelo de eventos o de identificar o comportamento do sistema. O modelo de eventos constitudo de termos dos quais os usurios podem entender. Esta abordagem, conforme visto anteriormente, pode ser incorporada ao processo de entendimento do que a se caraterizar um sistema de informao. Outra vantagem desta abordagem que a anlise inicial baseada em eventos possibilita a identificao de vrias caractersticas importantes dos sistemas tais como: a identificao dos principais usurios, as aes/funes do sistema, as interfaces de comunicao indicativos conceituais para o diagrama de classes ou de dados. Outros benefcios da modelagem por eventos o de possibilitar a especificao das interfaces e seu processo de navegao e auxlio no desenho do sistema a partir de sua localizao geogrfica de sua ocorrncia. dos atores com o sistema e

4.2 Sistemas de respostas planejados.

J sabemos o que identificar quando se trata de sistemas de informao, mas como coletar todos estes elementos de forma integrada. De que outra forma procuraramos por dados, aes, atores, temporalidade, espao e restries aleatoriamente. Para tratar estes conceitos de forma integrada necessrio entender o sistema de informao como algo que reage a determinadas aes de seus atores, ou seja, como um sistema de respostas planejadas.

106

Um sistema de respostas planejadas um sistema cujas aes dos atores pode ser mapeada e cujas respostas para estas aes so sempre as mesmas. Assim ao clicar sobre o um cone de um aplicativo obter-se- a mesma resposta repetidamente. Nem todos os sistemas so sistemas de respostas planejadas: o ser humano no um sistema de resposta planejada, pois se voc perguntar o nome de uma mesma pessoa vrias vezes, com certeza voc obter respostas bem distintas. Os sistemas de informao podem ser interpretados como sistemas de respostas planejadas. Assim, se desejarmos modelar estes sistemas, devemos identificar quais os eventos que foraro o objeto sistema de informao a fornecer uma resposta. Desta forma, os eventos sempre acontecem no meio externo ao sistema. O Sistema de informao, de alguma forma, detecta que o evento aconteceu, realiza uma ao e responde.

Estmulo Evento Dados e Aes

Ator

Resposta Sistema de Informao

Figura PIII - 2 modelo de eventos

Pela perspectiva dos eventos, ento, podemos tratar os elementos de um sistema de informao de forma integrada.

4.3 Eventos.
Para caracterizar um sistema de informao, procurando pelo seus elementos bsicos, utilizamos a anlise de eventos para modelar o comportamento do sistema com relao as aes provocadas pelos atores. Os eventos so caracterizados segundo a sintaxe sujeito+verbo+objeto. Esta sintaxe especifica que Algum realiza alguma ao sobre um determinado objeto. Algumas caractersticas dos eventos so[Ruble,1997]:

O evento ocorre em um determinado momento . 107

O evento ocorre no ambiente, no no interior do sistema. O sistema deve ser capaz de identificar que o evento ocorreu. O sistema, ao identificar a ocorrncia do evento, deve fazer alguma ao sobre este fato.

A tabela PIII-1 mostra uma lista de eventos. Uma tabela de eventos mais detalhada pode ser especificada. Assim, podemos construir uma tabela que caracterize com mais detalhe a lista de eventos, tal como a da tabela PIII -2 - Tabela de eventos.
Nmero 1 2 3 Evento Aluno faz matricula Professor lana nota Secretaria cadastra turmas

Tabela PIII-1 Tabela simplificada de eventos.

Nmero 1 2 3 4 5 6 7

Evento Faculdade autoriza registro de chamada de workshop Presidente da mesa registra o tota l de trabalhos aceitos por sesso Autor faz cadastro Autor envia trabalho Professor avaliador registra notas Presidente da Comisso registra avaliadores por trabalho Presidente da Comisso emite relatrio de trabalhos aprovados por sesso

PIII-1a exemplo de lista de eventos baseado no caso Workshop.

Nm. 1

Ator Aluno

Estmulo Formulrio preenchimento matricula

ao de Fazer de matricula

Dados/Conceito Matricula

resposta Matricula realizada

Professor

Tela de lanamento de Lanar nota nota

Notas Alunos Disciplina

Nota lanada.

Secretaria

Tela de cadastro de Cadastrar turmas turmas

Turmas

Turma cadastrada

Tabela PIII-2 Tabela de eventos para a tabela PIII-1 108

Analisando cada um dos itens da tabela temos:

Nmero: um nmero seqencial para a identificao do evento. Pode ser qualquer outra identificao pertinente.

Ator: o nome do ator do evento. Estmulo: o que identifica que o evento aconteceu. O estmulo que dispara as aes internas no sistema e faz com que estas aes manipulem dados e provoquem respostas ao usurio. Sem o estmulo os eventos aconteceriam sem que o sistema soubesse que este ocorreu.

Dados ou conceitos: o conceito manuseado pelo sistema de forma a fornecer uma resposta adequada. relacionamento. Estes conceitos no devem ser tratados como atributos. Estes conceitos serviro de apoio a modelagem dos diagramas de classe ou de entidades e

Resposta: a resposta, sempre em caso afirmativo do evento.

Outros elementos podem ser adicionados a esta tabela. O primeiro deles quanto a sua natureza. Assim temos os eventos provocados por atores tais como pessoas, departamentos ou outros sistemas e os eventos provocados pelo tempo. Outra foma de classificar os eventos e nos apropriarmos da formas de classificao de

requisitos como um todo. Uma destas formas, descrita em Wazlawick,[2004], a de classificar os requisitos como requisitos de transao/processos de negcio, cadastro/conceitos e consultas. Os requisitos de transao correspondem aos requisitos necessrios a operacionalizao o efetiva de um determinado sistema. Por exemplo, um sistema acadmico irrelevantes sem um sistema de matrcula. Os requisitos de cadastro/conceito correspondem aos requisitos que lidam diretamente com a manuteno o dos principais conceitos do sistema. Por exemplo, os requisitos de manuteno do cadastro de professores e de alunos em um sistema acadmico. Por sua vez os requisitos de consulta correspondem aos requisitos que obtm informaes do sistema para efeito de tomada de deciso do usurio. Por exemplo um requisito de emisso de pauta de aula. Em um sistema acadmico.

4.4 Priorizao dos eventos.

Sabemos que dos eventos identificados alguns so mais importantes que outros. Porm, de que forma podemos classific-los para prioriz-los ao logo do processo de desenvolvimento. Pdua[2000] sugere a classificao dos requisitos em trs categorias: essencial, desejvel e opcional. 109

Esta classificao est associada a contribuio do requisitos frente aos objetivos. Desta forma se requisito estiver for imprescindvel para o alcance do objetivo do sistema este dever ser classificado como essencial. Se for importante mas no imprescindvel este dever ser classificado como desejvel. Se o requisito poder ser descartado sem maiores prejuzos ou apenas uma facilidade especfica este deve ser classificado como opcional. Em geral esta classificao deve ser apoiada pelo usurio e no ser arbitrariamente definida pelo gerente de projeto de sistemas.

4.5 Da classificao dos eventos.

A lista de eventos na forma listada na tabela PIII-1 j se suficiente para identificar o comportamento do sistema. Entretanto, necessrio saber como o objeto sistema de informao se comporta ao longo do tempo, j que as atividades desempenhadas pelos atores esto normalmente associadas ao tempo. Por exemplo, o evento Aluno faz matrcula somente pode acontecer se os eventos Coordenao acadmica cadastra curso, coordenao Acadmica cadastra disciplina e Diretoria de Recursos Humanos registra professor. Somente aps estes ltimos eventos acontecerem o evento Aluno faz matrcula pode acontecer. Os eventos so sempre tratados como externos ao sistema. Assim de forma geral pode-se classificar os eventos em eventos externos-no temporais e eventos externos-temporais. Neste ltimo caso trata-se o tempo como se fosse um ator que determina inicia um evento.[Ruble, 1997] Os eventos externos-no temporais acorrem a partir de um ator sem o conhecimento de quando o evento ir acontecer. Quando o evento pode acontecer a qualquer momento tem-se um evento inesperado, por exemplo o evento Cliente compra pipoca. Este evento pode acontecer com tambm pode no acontecer, ou pode acontecer vrias vezes ao dia. Do ponto de vista do sistema este no precisa ter a capacidade de prever quando este evento acontecer mas deve estar pronto para trat-lo quando este ocorrer. Quando se sabe que um evento pode acontecer em um determinado momento,seja o tempo absoluto ou tempo relativo no, tem-se os eventos esperados. Os eventos esperados so descritos segundo a conveno tempo de+fazer alguma coisa/algo. Os eventos esperados so conhecidos como eventos temporais. Quando existe um tempo bem definido para uma ao acontecer, por exemplo toda segunda feira pela manh, tem-se o evento temporal absoluto. Por exemplo, toda segunda-feira tempo de emitir o relatrio de pedidos abertos.

110

Entretanto, quando um evento est vinculado a outro evento atravs do tempo, tem-se o evento temporal relativo. Por exemplo Professor lana nota de A1 . Este evento s poder acontecer ser j tiver acontecido o evento de abertura de lanamento de nota.

4.6 Da temporalidade dos eventos.

A anlise da classificao temporal dos eventos auxilia na elaborao da tabela de temporalidade dos eventos. A anlise de temporalidade dos eventos permite identificar a precedncia das aes de um sistema . Uma forma de visualizar a temporalidade dos eventos atravs de uma matriz de precedncia de eventos como mostra a tabela 2. Evento\Evento precedente 1 2 3 4 5 X X Tabela PIII-3 matriz de precedncia de eventos Para a tabela 2 considere os seguintes eventos: 1. Professor lana nota de A1. X X 1 2 3 4 5

2. Professor lana nota de A2. 3. Professor lana nota de VS. 4. Aluno consulta nota de A1. 5. Ao final do semestre, professor solicita emisso do relatrio de aprovados.

Desta forma verifica-se a dependncia entre os eventos. Por exemplo, o evento 1 no depende de nenhum outro evento pois um evento inesperado. O evento 2 depende do evento 1, um evento relativo. Uma boa literatura sobre a classificao de eventos pode ser encontrada em Xexo[2004], Pompilho[2000] , Maffeo[1992] e Ruble[1997].

4.7 Validando os eventos.

Devido a natureza abstrata e voltil dos sistemas de informao a validao dos requisitos destes sistemas no um processo 100% seguro ou cientfico. Existem entretanto mecanismos que possibilitam verificar se um determinado evento est dentro do escopo do objeto sendo considerado.

111

Existem duas maneiras de se validar os eventos: a validao interna e a externa. A validao interna diz respeito a misso e seus eventos e a externa em relao as regras de negcio e os eventos. Na validao interna duas anlises so feitas: a de consistncia e a de completeza. A de consistncia verificao emprica de que todos os eventos apiam a misso, por exemplo, o evento professor elabora questo de prova um evento que apia a misso Sistema informatizado para a elaborao de provas on line. Entretanto o evento professor elabora lista de exerccios no est diretamente apoiando a misso. Neste caso o evento parece ser um evento no essencial ao sistema. Para avaliar a completeza necessrio verificar ser a Misso realizada por todos os eventos listados, ou seja, verifica-se se para a realizao da misso no falta nenhum evento.

Misso Consistncia: todos sos eventos apiam a misso. Evento

Figura PIII 3 : validando o escopo dos eventos.

Completeza: a misso realizada com todos os eventos listados.

A validao externa diz respeito a validao entre as regras de negcio e os eventos. Verifica-se se os eventos identificados esto de acordo com as regras de negcio previamente identificadas ou se estes violam algumas destas regras.

4.8 Utilizando eventos para descobrir processos, classes e subsistemas.

Uma das razes para se utilizar eventos a possibilidade de se identificar uma srie de artefatos teis tanto para aqueles que seguem com a especificao tradicional estruturada quanto para outros desejosos em seguir a especificao orientados a objetos. Dentre os artefatos que podem ser identificados so:

processos e funes: verificando a coluna de aes, da tabela de eventos, obtm-se a lista

de todas as aes pertinentes do sistema. Organizando-as de forma seqencial pode-se obter uma seqncia de processos. Por exemplo, se organizssemos os eventos da tabela 2 na seqncia de tempo poderamos identificar um processo de organizacional. A organizao temporal ficaria desta forma: 112

o o o o o

Professor lana nota de A1.(primeiro evento) Aluno consulta nota de A1.(segundo evento) Professor lana nota de A2.(terceiro evento) Professor lana nota de VS.(quarto evento) Ao final do semestre, professor solicita emisso do relatrio de aprovados. (quinto evento).

Esta seqncia denota um processo de lanamento de nota ao longo do semestre.

Classes de sistemas: verificando a coluna de dados/conceito do evento, obtm-se uma

aproximao inicial das classes do sistema. Esta no uma lista definitiva. Existem vrias tcnicas de identificao de classes do sistema e estas devem ser utilizadas em conjunto para validao de consistncia. Observando-se a tabela PIII 2 obtm-se as classes candidatas matricula, nota, disciplina e turma.

Subsistemas: a classificao dos eventos pelos atores auxilia na identificao de grupos

de eventos por usurios, possibilitando a visualizao de subsistemas. Considere a lista de eventos do estudo de caso Laboratrio. 1. Laboratorista cadastra computador Ator Ao Dados Interface Tipo-evento Hardware, Cadastrar Tela de cadastro de Laboratorista software, Cadastro computador computador computador 2. Laboratorista associa computador em laboratrio Ator Ao Dados Interface Tipo-evento Associar Tela de associao Computador, Laboratorista computador a entre computador e Transao laboratrio laboratrio laboratrio 3. Laboratorista cadastra compra e atualizaes de software Ator Ao Dados Interface Tipo-evento Cadastrar compra e Tela de cadastro / Laboratorista atualizao de Software atualizao de Cadastro software software 4. Laboratorista abre ordem de servio Ator Ao Dados Interface Tipo-evento Abrir ordem de Computador, Tela de abertura de Laboratorista Cadastro servio Ordem de servio ordem de servio 5. Laboratorista cadastra providncias tomadas para consertar computador Ator Ao Dados Interface Tipo-evento Laboratorista Cadastrar Computador, Tela de edio de Transao providncias Ordem de servio ordem de servio tomadas para 113

consertar computador 6. Professor reserva laboratrio Ator Ao

Dados Interface Tipo-evento Laboratrio, Data Tela de reserva de Professor Reservar laboratrio Transao e hora laboratrio 7. Laboratorista solicita ao sistema emisso de relatrios Ator Ao Dados Interface Tipo-evento Computador, Solicitar emisso de Hardware, Laboratorista Tela de Relatrios Transao relatrios software, Ordem de servio

Tabela III- 4 Tabela de eventos do estudo de caso Laboratrio [Silva, Rabello, Caetano e Simes,2007]
Organizando-se lista acima, por atores obtm-se as funcionalidades por grupo de atores.

1. Laboratorista cadastra computador Ator Ao Dados Interface Tipo-evento Hardware, Cadastrar Tela de cadastro de Laboratorista software, Cadastro computador computador computador 2. Laboratorista associa computador em laboratrio Ator Ao Dados Interface Tipo-evento Associar Tela de associao Computador, Laboratorista computador a entre computador e Transao laboratrio laboratrio laboratrio 3. Laboratorista cadastra compra e atualizaes de software Ator Ao Dados Interface Tipo-evento Cadastrar compra e Tela de cadastro / Laboratorista atualizao de Software atualizao de Cadastro software software 4. Laboratorista abre ordem de servio Ator Ao Dados Interface Tipo-evento Abrir ordem de Computador, Tela de abertura de Laboratorista Cadastro servio Ordem de servio ordem de servio 5. Laboratorista cadastra providncias tomadas para consertar computador Ator Ao Dados Interface Tipo-evento Cadastrar providncias Computador, Tela de edio de Laboratorista tomadas para Transao Ordem de servio ordem de servio consertar computador 7. Laboratorista solicita ao sistema emisso de relatrios Ator Ao Dados Interface Tipo-evento 114

Laboratorista

Computador, Solicitar emisso de Hardware, Tela de Relatrios relatrios software, Ordem de servio

Transao

Tabela PIII 5 Tabela de eventos do laboratorista

6. Professor reserva laboratrio Ator Ao Professor

Dados Interface Tipo-evento Laboratrio, Data Tela de reserva de Reservar laboratrio Transao e hora laboratrio

Tabela PIII 6 Tabela de eventos do Professor Usurios: a lista de eventos possibilita a identificao de usurios do sistema podendo-se
com esta informao obter o perfil destes usurios para o desenvolvimento de interfaces de sistemas adequadas. Duas tabelas podem ser descria a primeira de descrio geral e a segunda de identificao do perfil do usurio. Outros modelos de perfis podem ser especificados. A Tabela PIII- 7 ilustra a descrio de atores e a PIII 8 descreve o perfil dos mesmos. Nm. Ator Descrio Profissional de planto responsvel pela execuo de atividades relacionadas ao funcionamento do laboratrio. Professores da faculdade que eventualmente precisam reservar laboratrios para ministrar suas aulas.

1 2

laboratorista Professor

Tabela III- 7 Tabela de descrio de atores do estudo de caso Laboratrio [Silva, Rabello, Caetano e Simes,2007]
Nm Freqncia de Uso Diria Semanal Nvel de Instruo Proficincia em informtica

1 2

Nvel mdio Nvel superior

Mdio Mdio

Tabela III- 8 Tabela de perfil dos atores do estudo de caso Laboratrio [Silva, Rabello, Caetano e Simes,2007]

Aes: as aes pode ser descritas brevemente, sendo um ponto de partida para a
definio mais completa dos eventos. 115

Nm

Ao

Descrio Professor solicita ao sistema "reserva de laboratrio" e fornece como entrada as seguintes informaes: laboratrio a ser reservado, dia e hora da reserve e tempo total de utilizao.

Reservar laboratrio

Solicita ao sistema Laboratorista solicita ao sistema emisso de relatrios tais emisso de como: "configurao de componentes de computadores", relatrios "nmero de licenas utilizadas", "manuteno de micro".

Tabela III- 9 Tabela de descrio das aes do estudo de caso Laboratrio [Silva, Rabello, Caetano e Simes,2007]

Descrio inicial das interfaces: os eventos podem ser utilizados para a descrio inicial
das interfaces. Nm. Interface Descrio Sumria Formulrio para cadastramento de novo hardware contendo os campos: grupo do hardware (combobox - monitor, teclado, mouse, novo unidade principal), tipo (disco, placa de expanso, memria, unidade tica, placa me), fabricante e especificaes (capacidade, velocidade de acesso, interface). Formulrio para associar cada hardware do cadastrado a um computador contendo os campos: numero do computador e lista do hardware.

Tela de Cadastro hardware

de

Tela de associao hardware a um computador

Formulrio para associar computador a um Tela de associao do laboratrio contendo os campos: numero do computador a um laboratrio computador, nome do laboratrio.

Tabela III- 10 Tabela de descrio das interfaces do estudo de caso Laboratrio [Silva, Rabello, Caetano e Simes,2007] Casos de uso: a lista de eventos um comeo para a identificao dos casos de uso do
sistema. Este tpico ser descrito em maiores detalhes em sesso especfica.

4.9 Bibliografia.
Pompilho, S. Anlise essencial Guia prtico de Anlise de Sistemas. Editora Cincia Moderna. 2002. Ruble, David A. Practical Analysis and Design for client/server and GUI systems. Yourdon Press Computer Series. 1997. 116

Silva, Alan Gonalves; Rabello, Henrique Rodrigues; Caetano. Marcelo; Simes, Ricardo Simes. Trabalho de Projeto de Sistemas II. UERJ. 2007. Xexo, Geraldo B. Modelagem de Sistemas de Informao. Disponvel em

http://ge.cos.ufrj.br

117

Parte IV Aplicao Didtica

118

1 Da Modelagem de Sistemas de Informao.

1.1 Introduo.
Construir sistemas de informao, baseados em tecnologia da informao, confiveis e com qualidade uma tarefa tratada nas disciplinas de Engenharia de Software. No uma atividade considerada fcil, j que os problemas com esses tipos de sistemas no esto relacionados apenas com o funcionamento intrnseco destes sistemas, mas tambm em como estes sistemas so construdos [Pressman, 2002]. Um dos aspectos relevantes na de construo o processo de modelagem desses sistemas, sendo este ato crucial para o entendimento do problema e o encaminhamento de uma soluo. Entretanto, o ato de modelar subentende o conhecimento do objeto que se est modelando. No conhecer o objeto de modelagem implica em no represent-lo adequadamente e utilizar inapropriadamente ferramentas e mtodos possivelmente ineficazes na sua construo, ocasionado perda de qualidade, insatisfao e custos elevados. Este trabalho discute a natureza do objeto sistema de informao de forma a mostrar, atravs da discusso do nosso objeto de estudo, a complexidade deste objeto tanto para e anlise quanto para o encaminhamento de uma soluo em tecnologia da informao.

1.2 Do contexto.
Desde o final dos anos 60 assiste-se a sucessivas ondas no processo de modelagem de sistemas de informao. A primeira onda com os modelos estruturados e com todas as suas variaes[DeMArco, 1989; Yourdon, 1990; Gane e Sarson, 1996], nos anos 90 com os modelos orientados a objetos e a respectiva unificao em torno da UML[Larman, 1997; Rumbaugh, 1994] e nesse incio de sculo com a proliferao dos modelos para descrio de sistema baseados em agentes. Sem mencionar os diversos modelos para sistemas especialistas e sistemas multimdia que tangenciaram as ondas de modelagem. Entretanto, apesar de todo esse desenvolvimento, a comunidade ainda ressente o problema do ato de modelar sistemas de informao. Este pode ser um problema de prtica: as pessoas no esto habituadas a modelar ou no a consideram importante; ou de formao: no possuem a educao formal adequada para empreender tal empreitada ou simplesmente no acreditam nas vantagens que a modelagem pode oferecer. Possivelmente os maiores problemas no ato de modelar dizem respeito a: como criar descries de software precisas, como acompanhar as mudanas de requisitos e rastre-las ao software e aos produtos intermedirios? Como determinar o escopo de um sistema de 119

informao? Como garantir que o modelo seja entendido por todos? Como representar estrutura e dinamicidade de forma integrada e consistente? Essas so apenas algumas perguntas que ainda no foram adequadamente respondidas. Este tpico no ir tentar responde-las, mas ir tentar lanar um novo olhar sobre as dificuldades destas tarefas. Ao que tudo indica a comunidade continua a desenvolver modelos, apresentando diversas solues, sem, entretanto, entender, possivelmente, a natureza do problema. De certo modo melhoramos em muitos aspectos do entendimento do nosso objeto de trabalho, mas falhamos, ainda, sistematicamente em muitos casos. considerando estas dificuldades que o entendimento dos principais conceitos que so pertinentes ao tema, como modelagem, sistemas e informao, devem ser tratados em sua natureza. Ao realizar uma srie de exerccios de modelagem vrias dificuldades emergem revelando a real complexidade do assunto. Esta experincia possibilita aos profissionais a compreenso e da dimenso do problema e uma compreenso maior da soluo a ser dada. Nesse aspecto, este tpico vai contra a tendncia de apresentao de novos modelos de construo de sistema de informao, e procura, ao invs disto, entender a natureza deste objeto. Assim, ao se conhecer este objeto, talvez seja possvel melhorar aspectos de aprendizagem e da prpria construo destes sistemas. As sesses abaixo refletem esta abordagem que creio serem teis para aqueles que lecionam e praticam a modelagem de sistemas de informao.

1.3 A abordagem de modelagem corrente.

O atual enfoque na modelagem de sistemas de informao, em geral, seguem as seguintes regras :

O objeto e o modelo: as disciplinas enfatizam a modelagem do objeto em questo e no as

dificuldades de modelagem do objeto em si. Assim, se esquece que, antecede ao modelo o objeto que desejamos representar, e esse objeto no bem entendido pelos profissionais.

nfase na engenharia e nas linguagens de representao e no concepo: a construo de

sistemas toma como base o modelo de engenharia pautado em um sistema modelado, a referncia bsica, e a sua derivao bsica para software. A nfase na modelagem se reflete na atual tendncia a notao UML, este um dos aspectos decorrentes do item anterior.

120

 Modelagem uniforme: o sistema entendido como algo que pode ser representado de
forma uniforme e bem definido, basta aplicar as tcnicas de modelagem para representar o sistema em sua totalidade. O sistema est l basta representa-lo.

Escopo: A definio do escopo vista como algo que pode ser bem delimitado e
caracterizado, ou seja, conhece-se todos os limites do sistema.

As prticas de elicitao e requisitos so pouco exercitadas: pratica-se, em geral, a

representao dos requisitos atravs da utilizao de uma notao. Entretanto a identificao dos objetos do sistema to importante quanto a representao do mesmo.

Essas regras no auxiliam na formao de um bom profissional, j que ao chegar no mercado este ter grande dificuldade em ver o sistema, este ficar perdido e suspeitar que os mtodos ensinados servem apenas para documentao. Assim, os conceitos exemplificados a seguir, procuram antes de se mais nada treinar o olhar para a identificao do objeto que se deseja modelar.

1.4 Modelagem.
Segundo o dicionrio da AOL modelar significa: fazer o modelo ou molde de uma pea; denunciar ou insinuar as formas; formar de acordo com um modelo. Para [Rumbaugh, 2000] um modelo uma simplificao da realidade de forma a entender aquilo que estamos modelando j que aquilo que modelamos complexo, pois, de alguma forma, no podemos compreende-lo por inteiro. Entretanto alguns problemas emergem quando do ato de modelar. Em primeiro lugar o ato de modelar sugere que tenhamos um objeto de referncia ao qual olhamos ou pensamos sobre. Quando lidamos com conhecimento sempre temos um objeto de estudo. Por exemplo: Cincia da Computao tem como objetos algoritmos e mquinas, Psicologia, tem como objeto a mente humana, Sociologia, tem como objeto as relaes humanas etc. Entretanto ao modelarmos um objeto vrios fatores influenciam no ato de modelar (faa a prtica abaixo), tais com a natureza do objeto (abstrato ou concreto), a simplificao imposta pelo modelo, a habilidade de quem modela, o tempo que se tem para modelar, os recursos financeiros disponveis, a perspectiva em que se olha o objeto e como podemos validar o modelo, conforme explicado abaixo: Problema: diferentes pessoas modelam diferentemente o mesmo objeto. Prtica: coloque um objeto qualquer na frente dos participantes, pode ser uma cadeira. Solicite que os participantes desenhem o objeto sua frente e que o faam em 3 minutos, por exemplo. Ao final deste tempo solicite que os alunos apresentem uns aos outros o resultado de sues modelos. Resultado: O resultado desta prtica sabido. Cada um dos participantes ir desenhar uma carteira diferente. Mas isso a princpio contraditrio visto que todos que participam 121

da prtica vem o mesmo objeto! Por qual motivo existe esta perda entre o ato de ver e o ato de desenhar? Por quais motivos pessoas diferentes representam objetos diferentes?

Prtica 1 Modelagem de um objeto concreto Objeto: todo o processo de modelagem ocorre sempre a partir do foco em um objeto.
Modela-se sempre olhando para um determinado objeto, neste caso um objeto concreto. Este com certeza um conceito central no ato de modelar. Desta forma o objeto deve ser bem caracterizado e bem definido.

Modelo e realidade: o ato de modelar um ato de descrio do objeto, no se pretende que

seja o prprio objeto. Modela-se para criar um modelo de como o objeto se comporta ou , pois manuseando o modelo pode-se por sua vez prever o comportamento ou a estrutura do objeto real. Outra funo do modelo este pode ser manipulado distncia do objeto, pode-se enviar o modelo para outras pessoas sem a necessidade de enviar o objeto.

Habilidade: cada um dos participantes possui habilidades distintas de desenhar.

Possivelmente algum fez um curso de desenho ou possui habilidade nata. Assim ao olhar um objeto, o participante de maior habilidade, sabe por onde comear e por onde terminar na descrio do objeto.

Tempo: com certeza o tempo um fator limitante. Quanto menor o tempo mais
habilidades so postas prova. Entretanto, se ao invs de 3 minutos os participantes tivessem 3 meses eles poderiam entrar em um curso de desenho e com certeza aprenderiam a desenhar o objeto.

Recursos financeiros: caso um dos participantes no soubesse desenhar poderia solicitar a

outro que desenhasse para ele, contrataria os seus servios.

Validao: Neste processo de modelagem podemos perceber quando o modelo no

representa o objeto em questo. Apenas olhando para o objeto real e olhando de volta para o nosso modelo verificamos que existe uma diferena. Existe um processo de reflexo daquilo que vemos e aquilo que desenhamos. Isso nos permite ajustar o nosso desenho e melhorar o nosso modelo.

Dinmica: o objeto encontra-se parado, fcil representa-lo, a princpio. Perspectiva: possivelmente os participantes poderiam ter desenhado diferentemente pois
possuam perspectivas diferentes do objeto. Se juntssemos todos os desenhos poderamos ver um modelo mais completo do objeto modelado. Assim o ato de modelar necessita do estabelecimento de vrios ngulos de forma a se conhecer ou representar adequadamente o objeto considerado. 122

Entretanto quando desejamos trabalhar na modelagem de objetos abstratos novas dificuldades emergem: Problema: diferentes pessoas modelam de forma totalmente diferentemente o mesmo objeto abstrato. Prtica: retire o objeto que estava em evidncia na modelagem anterior, a carteira. Solicite que os participantes modelem o objeto invisvel, uma cadeira, que est em evidncia. Resultados: nesta segunda prtica verifica-se a dificuldade da modelagem. Cada participante desenha a carteira que v, que acha que est ali. Afinal, qual a carteira est em evidncia. Seria uma carteira confortvel ou desconfortvel, azul ou branca, alta ou baixa, com rodinha ou sem rodinhas?

Prtica 2 Modelagem de um objeto astrato

Vemos que desenhar objetos que vemos j uma tarefa difcil, quando no o vemos torna-se ainda mais difcil, pois os fatores que afetam a modelagem ficam mais complexos, conforme explicado abaixo:

Objeto: neste caso temos um objeto diferente do primeiro problema, temos um objeto
abstrato. Assim fixar uma referncia um ato incerto e incompleto.

Modelo e Realidade: como criar um modelo se a realidade ao qual se refere o objeto no

pode ser visto, apenas percebida?

Habilidades: somos treinados a perceber o real a nossa volta e acostumados a trabalhar

com fatos concretos. De forma geral, nossa maior abstrao se encontra na matemtica cujos objetos so diferentes dos objetos que estamos preocupados.

Escopo: onde comea e termina o objeto. Quando vemos o objeto sabemos exatamente o
limite do mesmo, quando no o vemos como determinar estes limites? Uma forma de reduzir este problema acordando quais caractersticas so inerentes ao objeto, no caso a carteira. Mesmo assim, ao modelarmos verificaramos que cada participante desenharia objetos diferentes.

Dinmica: o objeto est em movimento ou parado? Se o objeto estiver parado podemos

desenh-lo de uma forma, se estiver em movimento temos que empregar outras tcnicas de modelagem.

Validao: este processo fica comprometido, pois como no temos a referncia do objeto
no podemos, a princpio, valid-lo. Modelar objetos abstratos torna-se ento de enorme complexidade.

123

Assim ao se modelar objetos vimos a dificuldade que executar esta tarefa. Entretanto ao se modelar um objeto abstrato uma nova questo se estabelece: o objeto existe ou est sendo criado em tempo de modelagem? Problema: quando modelamos objetos abstratos estamos descobrindo ou construindo o objeto em questo? Prtica: tendo como referncia o Prtica 2, aps algumas rodadas de desenho da cadeira e com todos concordando quanto ao modelo desenhado pergunte aos participantes se a cadeira em questo j estava l, ou seja se foi descoberta, ou foi construda. Assim, ela realmente existia ou foi criada? Resultado: se esta j existia ento o ato de modelar meramente um ato absoluto de desvendar o sistema que est l. De outra forma, se for um ato de construo o ato de modelar extremamente criativo e voltil. Assim duas perspectivas emergem quando modelamos objetos abstratos:

Da descoberta: nessa perspectiva considera-se que o objeto abstrato est presente cabendo
apenas ao desenhista descobrir os limites do objeto e suas propriedades. Enfim cabe ao desenhista apenas desvendar os limites do objeto ao executar a modelagem. Neste caso, o objeto est l, meramente uma questo de tempo descobri-lo.

Da construo: nesta caso o objeto abstrato talvez no exista de fato. Neste caso este ser
construdo na medida em que se fale sobre ele. Neste ltimo caso a modelagem de um objeto abstrato se torna extremamente tempo voltil pois basta que um dos participantes veja uma nova propriedade do objeto para o objeto alterar sua composio. Logo, ao analisar o processo de modelagem descritas acima pode-se concluir que:

Processo de modelagem extremamente complexo e complicado. Nem tudo aquilo que

vemos refletido em nossos modelos. Sempre existe uma perda entre o objeto que observamos e o objeto que modelamos. Esta perda pode ser minimizada quando treinamento apropriado for aplicado.

Processo de modelagem de um objeto concreto j desafiador. Entretanto quando o objeto

um objeto abstrato esta complexidade aumenta enormemente, fazendo com que o ato de modelar seja realmente complexo e desafiador.

i. A modelagem de objetos abstratos pode ser tratada como um problema de descoberta ou como um problema de construo.

1.5 Sistemas.
No nosso caso ao modelarmos estamos preocupados com um tipo particular de objeto: sistemas de informao. Para entend-lo, ento, devemos caracterizar o que vem a ser um sistema.

124

Um sistema pode ser definido como um conjunto de partes que interagem umas com as outras de forma a atingir um determinado objetivo; um sistema pode ser constitudo de subsistemas que tambm so sistemas; e podem interagir com outros sistemas. Afinal tudo pode ser um sistema. Se o desejamos modelar o objeto sistema de informao, como ento caracteriza-lo. Problema: tendo como referencia os conceitos de sistema como delimit-lo? Como descrev-lo? Como identificar as suas partes sem incorrer na perda de foco? Prtica: ao olhar uma maa caindo de uma rvore, quantos sistemas podemos enumerar? Resultado: a definio trivial de sistema aquela que diz que sistema um conjunto de partes integradas que procuram ou possuem um objetivo em comum. Seno vejamos:

Um sistema um conjunto de subsistemas sendo que cada subsistema tambm um

sistema: considero esta caracterstica como de complexidade vertical de um sistema j que caminhando para os sistema de nvel mais geral ou mais particular sempre encontramos outros sistemas.

Um sistema interage com um ou mais sistemas: esta caracterstica pode ser classificada
como de complexidade horizontal j que os sistema interagem com outros sistemas impedindo a determinao de fronteiras bem definidas.

E finalmente uma das partes de um sistema pode pertencer a outros sistemas ao mesmo
tempo: classifico esta caracterstica de complexidade transversal j que ao olhar um nico ponto podemos estar assistido a execuo de vrios sistema ao mesmo tempo dependendo apenas do interesse e do ponto de vista do observador. Olhando toda essa complexidade uma pergunta se faz: onde se inicia o sistema e onde termina o sistema? Ser que o sistema se iniciou quando da queda a maa? Ser que se iniciou quando a rvore foi plantada? Quando o vento bateu mais forte? Quando lidamos com sistemas e em particular com sistemas de informao. Essa caracterizao, quando estabelecida, meramente arbitrria e classificatria j que todo sistema aberto possui complexidade ilimitada. Se a nossa preocupao com o aspecto de modelagem, e em particular com a modelagem de sistemas de informao, como devemos proceder para olhar este objeto se este no pode ser caracterizado em sua plenitude devido a sua multiplicidade de formas e perspectivas?

1.6 Dado e Informao.

No estamos interessados em modelagem de sistemas simplesmente, mas de um tipo particular de sistemas: sistemas de informao. Assim, o que vem a ser informao. Em geral defini-se informao em termos de fatos e de dados. Esta definio assume que informao

125

pode ser obtida atravs de correlao de dados. Esta definio elimina o papel do observador na obteno do dado, assume-se que a dado e informao so intrnsecas dos objetos. Problema: dado e informao so caractersticas dos objetos que o portam ou esto associados aos atores que manuseiam estes objetos? Prtica: acabou de sair um livro sobre UML2.0. Voc compra trs exemplares: uma para a sua me que trabalha dando aula de ingls e nunca ouviu falar de UML, uma para o seu tio que faz parte do grupo que definiu a verso e outro para um colega que deseja ansiosamente aprender UML para conseguir uma vaga como analista em um grande empresa de informtica. Assim sendo, qual o valor do livro para cada um dos presenteado? Resultado: percebe-se a definio tradicional de dados e informao no aplica quando se considera o ator e sua relao com seus objetos. Se considerarmos que um livro de UML 2.0 possui vrias informaes e dados importantes ento o objeto livro portador desses dados e informaes, independente de qualquer outro fator. Se, por outro lado, consideramos o livro como apenas um portador de uma mensagem que se transforma em dado ou informao, a partir do momento que interage com seus atores, verificamos que dado e informao no so caractersticas do objeto, mas sim, se comportam como tal, na medida que interagem com seus atores. Desta forma este livro no trar nenhum dado ou informao para a sua me, ser apenas um dado para o seu tipo, mas conter muita informao para seu amigo. Se apoiarmos esta ltima abordagem, verificamos que os objetos que nos cercam possuem apenas uma mensagem, o valor desta mensagem definido pela interao dos diversos atores com seus respectivos objetos. Somente a partir desta interao que podemos caracterizar dados e informao. Desta forma os conceitos de dados e informao esto associados s necessidades pessoais de cada um dos atores na relao com seus objetos. Assim se quisermos agradar algum com um presente que carregue muita informao devemos saber qual a necessidade desta pessoa e com quais objetos esta pessoa lida. Logo se quisermos modelar sistema de informao temos mais um complicador j que o nosso objeto de modelagem um sistema de informao e ao modelarmos devemos nos ater s necessidades dos atores e dos diversos objetos que interagem com estes.

1.7 A modelagem de sistemas de informao

O que vem ser a modelagem de sistema de informao. Neste caso a Modelagem de Sistema de Informao visa criar um modelo representativo de um Sistema de Informao, sendo o Sistema de Informao o objeto de modelagem.

126

O que vem a ser um sistema de informao. Dados os conceitos apresentados acima um sistema de informao um conjunto de objetos e atores de interagem de forma que esta interao seja portadora de valor necessrio para que estes atores tomem deciso. Assim o objeto Sistema de Informao pode ser assim caracterizado:

Abstrato: o sistema de informao acontece na interao dos atores com os seus objetos e
a informao apenas se realiza quando esta mensagem satisfaz uma necessidade mental deste ator.

Dinmico: este item est associado ao item anterior adicionando-se ao fato que a ao e
entre os objetos definem novas mensagem que podem representar novas informaes quando a interao com os atores.

Dados e informao: os objetos compostos deste sistema no carregam o atributo dado e

informao. Apenas pela inter-relao entre os diversos atores com estes objetos que determinam o valor da mensagem. Assim o mesmo objeto pode ser valorado diferentemente para cada ator.

Escopo indefinido: pela prpria definio de sistema adicionado ao fato de ser um sistema
abstrato onde os limites do escopo so intangveis.

Voltil: as necessidades de informao dos diversos atores mudam a cada instante. Novos
objetos de mensagem so trazidos para a tomada de deciso, antigos objetos so descartados ou revalorados. Assim mudam-se as necessidades de informao, muda-se a valorizao dos objetos do sistema, altera-se o sistema. Assim o objeto de modelagem se apresenta como objeto complexo e de difcil caracterizao. Os erros e as dificuldades normalmente atribudas, em particular caracterizados na engenharia de requisitos, refletem a natureza deste objeto.

1.8 Concluso.
Ao se identificar a dificuldade de se modelar sistemas de informao temos que estabelecer algumas regras metodolgicas para melhor representa-lo:

O modelo de um sistema de informao construdo em tempo de modelagem, esteja

preparado para mudar.

As fronteiras de um sistema de informao so estabelecidas de forma artificial j devido a

natureza desse objeto seus limites no existem.

O modelo sempre uma viso parcial e incompleta do objeto sistema de informao,

muda-se um ator e altera-se, por conseguinte a viso sobre os mesmos objetos e por sua vez a necessidades. 127

 Deve tambm estar preocupada com a velocidade e a volatilidade desta representao j

que as percepes dos diversos atores se modificam ao longo do tempo.

Trabalhe sempre com vrias perspectivas, pois difcil integrar a viso de deferentes
atores.

Observe os artefatos que manifestam manuseio de informao no por eles mesmos, mas
pelas necessidades que os diversos atores possui em relao a eles. Os resultados prticos desse processo tem sido:

Adequao realidade: ganho no processo de confiana do praticante no ato de modelar

fazendo-o perceber que a modelagem nunca est completa que ele sempre ser evolutiva e que a cada novo usurio ir perceber uma realidade diferente que implicar em uma redefinio do objeto sob pesquisa.

Gabarito: percebe-se o objeto sistema de informao no como algo fixo, mas dinmico e
mutante, sujeito a diversas perspectivas ao mesmo tempo.

Notao: ao se praticar uma tcnica de modelagem, procura-se mostrar no a tcnica por

si, mas qual o ganho de representao e de entendimento que se obtm a partir do objeto. Assim deve-se modelar os objetos a partir de vrias perspectivas complementares que descrevem algum comportamento ou estrutura dos objetos atravs de perspectivas diferenciadas.

Valorizao da notao: ao mostrar a dificuldade em esse modelar um objeto concreto e,

de forma mais incisiva, a dos objetos abstratos, valoriza-se a necessidade de modelar com preciso o objeto sistema de informao.

Este trabalho procurou tratar da complexidade de se construir sistema de informao. Ao mostrar a complexidade de se modelar sistemas de informao, analisando-se a natureza do prprio objeto de modelagem, abre-se um novo leque de possibilidades para o tratamento deste problema e da aplicao de mtodos de representao.

1.9 Bibliografia.
DeMarco, Tom, Anlise Estruturada e Especificao de Sistemas, Campus, 1989. Gane, Chris / Sarson, Trish, Anlise Estruturada de Sistemas, LTC, 1996 Larman, Craig, Applying UML and Patterns: an introduction to object oriented and design, 1997. Pressman, Roger, Engenharia de Software, McGraw-Hill, 2002. 128

Rumbaugh, James, Modelagem e Projetos Baseados em Objetos, Campus, 1994. Rumbaugh, James, UML Guia do Usurio, Campus, 2000. Yourdon, Edward, Anlise Estruturada Moderna, Campus, 1990.

129

2 Uso de um processo.

Uma das formas de aplicar este livro de casos atravs de um processo de software. Este modelo baseado em Larman uma forma de exercitar o conceito de processos alm de possibilitar a aplicao dos diversos diagramas de modelagem. Este modelo pode ser aplicado em um bimestre utilizando-se quatro ou cinco interaes. As avaliaes podem ser complexas com descrito no modelo ou simplificada, avaliando-se os resultados apenas no final.

2.1 Exemplo,
2.1.1O processo/Pasta de desenvolvimento.
Disciplina Prtica Artefato de Concepo Elaborao Incio Construo Modelagem Modelagem Modelo do Negcio gil. Domnio Reunio de requisitos Requisitos

Reunio de Modelos de Incio. requisitos. Caso de Uso. Viso. Proposta Incio inicial de especifica o de software. Especifica o Suplementa r Incio

Reviso

Reviso

Reviso

Projeto

Modelagem Modelo gil. Projeto

de

Incio

Reviso

Documento de Arquitetura de software

Inicio

Reviso

Reviso

Modelo de Incio Prottipo

Reviso

Reviso

2.1.2Artefatos.
Tipo-evento:consulta, cadastro, transao. Tipo-rnf: levantamento, construo, operao. 130

Subtipo-rnf: usabilidade, confiabilidade, manutenibilidade, portabilidade.

Artefato: Proposta Inicial de Especificao de Software. 1. O objetivo do sistema.

2. A lista de funes/eventos (nmero e nome). 3. A tabela de eventos (nmero, evento, ator, ao, dados, interface, tipo-evento). 4. A descrio dos atores (nmero, ator, definio). 5. Descrio inicial das aes (nmero, ao, descrio sumria).

6. Descrio inicial das interfaces (nmero, interface, descrio sumria).

Artefato: Especificao Suplementar: 7. Requisitos no funcionais (nmero, descrio, tipo-rnf, subtipo-rnf).

8. Regras de negcio. (nmero e descrio).

Artefato: Modelo de Casos de Uso. 9. Elabore o diagrama de Casos de Uso apenas para os requisitos de transao. 10. Especifique dois Casos de Uso, identificados no item 10, segundo o padro do Larman. 11. Especificao dos atores (nmero, freqncia de uso, nvel de instruo, proficincia em informtica). 12. Diagrama de Seqncia Simplificado.

Artefato: Modelo de Domnio. 13. Especifique o Diagrama de Classe de Domnio. 14. Identifique a responsabilidade das classes (nmero, classe e responsabilidades).

Artefato: Modelo Projeto. 15. Diagrama de Seqncia Completo para os dois casos de uso especificados. 16. Identificao dos padres utilizados (nmero, descrio/justificativa). 131

Artefato: Documento de Arquitetura de Software. 17. Viso Lgica. a. Motivao.

b. Camadas de software (diagrama de pacotes). 18. Viso Implantao. a. Motivao.

b. Diagrama de implantao (ns). 19. Viso de dados. a. Motivao.

b. Modelo de banco de dados. c. Mapeamento objeto relacional.

20. Viso dos casos de uso. a. Motivao.

b. Descrio justificada dos casos de uso mais importantes. 21. Viso do desenvolvedor. a. Motivao.

b. Especificao de ferramentas e ambientes utilizados.

Artefato: Modelo de Prottipo. 22. Especificao das telas (referentes aos casos de uso especificados). a. Lay-out das telas.

b. Especificao do diagrama de estados da tela.

2.1.3Avaliao. Notas por entrega na interao (uma nota para o grupo, total de trs notas). Nota dos pares gerente-equipe, tendo o gerente 28 pontos para distribuio para uma
equipe de 4(ao final do projeto). 132

 Notas por perfil de profissional ao longo das interaes (uma nota ao final). Prova de qualificao

2.1.4Perfil da equipe.
Escolher um perfil para um ou mais integrantes do grupo:

Gerente de projetos: responsvel pela conduo geral do projeto. Analista de negcios: responsvel pelos artefatos proposta inicial de software,
especificao suplementar e modelo de casos de uso.

Desenvolvedores de aplicativos: responsvel pelo modelo de prottipo, modelo de domnio

e modelo de projeto.

Arquitetos de software: responsvel pelo documento de arquitetura de software.

133