usina - cin.ufpe.brcin.ufpe.br/~aa2/abc/documentos/rfp-sla.doc · web vieweste documento tem como...

ABC

Projeto Alocação PLUS++

Resposta à RFP e SLA

Histórico de revisõesVersão(XX.YY)

Data(DD/MMM/YYYY)

Autor Descrição Localização

0.1 20/04/2004 Alexandre Alvaro

Primeiro draft do

documento

Resposta a RFP e SLA Página 2 de 19

ÍndiceÍNDICE DE TABELAS..................................................................................51. RESPOSTA DA RFP...........................................................................6

1.1. OBJETIVO DA RESPOSTA A RFP.............................................................................61.2. SOLUÇÃO REQUISITADA PELO CLIENTE.....................................................................61.3. CLASSE DE PROBLEMA X ALGORITMOS INDICADOS.....................................................6

1.3.1. Caracterização do Problema....................................................................61.3.2 Trabalhos Relacionados...........................................................................71.3.3 Conclusão................................................................................................8

2. PROPOSTA.....................................................................................102.1 VISÃO GERAL DO SISTEMA A SER REUSADO............................................................102.2 FUNCIONALIDADES............................................................................................10

2.2.1 Manter cadastro de professores/alunos.................................................102.2.2 Manter cadastro de disciplinas..............................................................102.2.3 Manter cadastro de recurso físico.........................................................102.2.4 Realizar alocação..................................................................................102.2.5 Alterar/Cancelar alocação.....................................................................102.2.6 Solicitar sugestão de alocação..............................................................112.2.7 Consultar alocação................................................................................11

2.3 PROPOSTA DE SOLUÇÃO.....................................................................................112.3.1 Escopo Negativo....................................................................................112.3.2 Ferramentas..........................................................................................112.3.3 Prazo e Esforço......................................................................................112.3.4 Cronograma..........................................................................................122.3.5 Propriedade e Licença...........................................................................12

2.4 ABC – A FÁBRICA DE SOFTWARE........................................................................122.4.1 Perfis que compõem a Fábrica ABC.......................................................122.4.2 Perfis.....................................................................................................132.4.3 Papéis....................................................................................................132.4.4 Organograma da Fábrica ABC...............................................................132.4.5 Home Page do Projeto...........................................................................132.4.6 Metodologia...........................................................................................132.4.7 Métricas.................................................................................................132.4.8 Riscos....................................................................................................142.4.9 Diferenciais Fábrica de Software III.......................................................14

3. SLA...............................................................................................153.1 CLÁUSULAS GERAIS...............................................................................................15

3.1.1 Propósito e objetivos...............................................................................153.1.2 Partes do acordo...................................................................................153.1.3 Duração e Validade...............................................................................153.1.4 Aplicação do Acordo..............................................................................153.1.5 Alteração do Acordo..............................................................................153.1.6 Serviços e Nível dos Serviços................................................................16

3.1.6.1 Atendimento e Comunicação......................................................................163.1.7 Entregas................................................................................................163.1.8 Processo e Métricas...............................................................................173.1.9 Requisitos e Escopo...............................................................................173.1.10 Novas requisições..............................................................................17

3.2 CLÁUSULAS ESPECÍFICAS....................................................................................173.2.2 Pontos de Contato entre o cliente e o Fornecedor.................................17

9. REFERÊNCIAS.....................................................................................18Resposta a RFP e SLA Página 3 de 19

Índice de Tabelas Tabela 1. Cronograma de Atividades.........................................................................12


1.Resposta da RFP

2.1.Objetivo da Resposta a RFPEste documento tem como objetivo apresentar o atendimento da fábrica de

software ABC sobre o projeto desenvolvido pela Fábrica III, demonstrando a solução proposta pela Fábrica ABC bem como sua estrutura, processos, ferramentas, esforço, cronograma, e demais informações necessárias. Além de determinar o diferencial competitivo da fábrica para o desenvolvimento do projeto Alocação PLUS++.

2.2. Solução requisitada pelo clienteSistema de alocação de recursos que pressupõe o uso de técnicas de job-shop

problem e time scheduling e se destina a alocar salas (aula, auditórios, quadras de esporte, piscina, laboratórios), professores, alunos, disciplinas e horários, dinamicamente e por período pré-determinado com intervalo mínimo de 1 hora. Isso nas esferas: cursos especiais de curta duração, graduação, especialização, mestrado e doutorado. Assim questões como: onde se encontra determinado aluno em determinada hora é facilmente obtida.

Esta solução foi proposta pela Fábrica de Software III e, agora, a Fábrica ABC terá como objetivo, entender o domínio do problema e averiguar as possibilidades de reutilização de artefatos (documentos, modelos, unidades de testes, código) buscando definir um processo efetivo de desenvolvimento baseado em reuso. A primeira possibilidade de reuso encontrada, levantada por um membro que participou do desenvolvimento da Fábrica III e está presente nesta fábrica também, é o algoritmo genético utilizado anteriormente. Com isso, segue uma breve apresentação do problema encontrado e algoritmos indicados para sua solução.

2.3.Classe de Problema x Algoritmos Indicados1.1.1. Caracterização do Problema

Na RFP emitida, o solicitante sugere que sejam utilizadas técnicas de job-shop problem [Jain, 1998] para alocar salas (aula, auditórios, quadras de esporte, piscina, laboratórios), professores, alunos, disciplinas e horários, dinamicamente e por período pré-determinado com intervalo mínimo de 1 hora. Isso nas esferas: cursos especiais de curta duração, graduação, especialização, mestrado e doutorado. Desta forma, questões como: onde se encontra determinado aluno em determinada hora seriam facilmente obtidas. Entretanto, após a realização de um levantamento bibliográfico e da análise do problema, a Fábrica ABC propõe que sejam utilizadas técnicas de resolução de timetabling problem [Schaerf, 1995] para solucionar esse problema, tendo em vista que o mesmo pode ser diretamente modelado, de forma metafórica, por variações do timetabling problem. Abstrações maiores seriam necessárias para se modelar o problema em um job-shop problem.

O problema de construção de um horário acadêmico é conhecido na literatura de forma geral como timetabling. Este problema depende do tipo do sistema educacional utilizado. Desta forma, não existe um modelo universal que possa ser aplicado sempre. Terra [Terra, 2001] considera os seguintes problemas como problemas de timetabling: (a) course timetabling, onde não existe um currículo fixo e os estudantes podem compor seu programa com disciplinas obrigatórias e eletivas. Nestes problemas, as disciplinas são atribuídas aos possíveis horários na semana, considerando-se as escolhas dos estudantes; (b) class-teacher problem, no qual o


escalonamento se baseia em grupos de disciplinas fixas para cada turma e a atribuição de professores a cada disciplina é feita previamente. (c) escalonamento de estudantes; (d) escalonamento de professores; (e) escalonamento de salas de aula, onde horários das aulas e espaço físico são considerados simultaneamente durante a confecção do horário escolar; (f) escalonamento de exames; (g) escalonamento de projetos.

A solução para o problema deve possibilitar que, dado um conjunto de aulas, um conjunto de professores, um conjunto de intervalos de tempo e um conjunto de salas de aula, as aulas sejam organizadas no tempo em uma tabela de alocação, de modo que nenhuma aula e nenhum professor sejam requeridos em dois lugares ao mesmo tempo e que todos os requerimentos adicionais, como espaço físico, por exemplo, sejam satisfeitos. A tabela de alocação deve ser gerada de forma a maximizar ou minimizar uma função de avaliação a ser definida. Essa função pode, por exemplo, maximizar o grau de satisfação dos professores por determinados horários ou minimizar o número de lacunas entre os horários alocados nas diversas salas. Esse problema é conhecido na literatura como class-teacher problem - CTP. Pode-se mostrar que o CTP é do tipo NP-Completo e que não admite solução em tempo polinomial [Schaerf, 1995]. Assim sendo, faz-se necessário a utilização de algum procedimento heurístico para se computar uma solução satisfatória para o CTP, em um intervalo de tempo aceitável.

1.3.2 Trabalhos RelacionadosDiversos trabalhos na literatura têm abordado o problema do timetabling.

Gröbner [Gröbner, 2002] apresenta uma abordagem para generalizar todos os problemas de timetabling, descrevendo a estrutura básica deste problema. Gröbner propõe uma linguagem genérica que pode ser utilizada para descrever problemas de timetabling e suas restrições. Nessa abordagem, uma descrição concreta do problema pode ser traduzida para a linguagem de programação Java e combinada com algoritmos padronizados.

Caldera [Caldeira, 1997] discute a implementação de dois algoritmos genéticos [Holland, 1975] utilizados para resolver o problema de class-teacher problem timetabling para pequenas escolas, fazendo uma comparação entre os resultados obtidos pelas duas abordagens propostas.

Em sua tese de doutorado, Fang [Fang, 1994] investiga a utilização de algoritmos genéticos para resolver um grupo de problemas de timetabling. Nesse trabalho é proposto um framework para a utilização de algoritmos genéticos para a resolução de problemas de timetabling no contexto de instituições de ensino. Esse framework possui como pontos de flexibilização: a declaração das restrições específicas do problema, utilização de uma função para avaliação das soluções, também específica para o problema e a utilização de um algoritmo genético que é independente do problema considerado. Fang mostra que os algoritmos genéticos são bastante efetivos e úteis para a resolução de problemas de timetabling e que, quando comparados com os resultados obtidos manualmente, os resultados obtidos por esses algoritmos são mais bem avaliados.

Fernandes [Fernandes, 2002] classifica as restrições para o class-teacher timetabling problem em restrições fortes e fracas. Violações às restrições fortes (como, por exemplo, a alocação de um professor em duas salas diferentes em um mesmo horário) resultam em uma tabela de alocação inválida. Violações às restrições fracas resultam em tabelas válidas, porém afetam a qualidade da solução (por exemplo, a preferência dos professores por determinados horários). Fernandes


descreve um método para a resolução do class-teacher timetabling problem baseado em algoritmos evolucionários. O algoritmo proposto foi testado utilizando-se uma universidade real com 109 professores, 37 salas de aula, 1131 intervalos de tempo de uma hora cada e 472 aulas. O algoritmo proposto conseguiu resolver a alocação sem violar as restrições fortes em 30% das execuções. Fernandes compara o algoritmo proposto com outro algoritmo evolucionário que não conseguiu resolver o problema sem violar as restrições fortes em nenhuma das execuções.

Souza [Souza, 2001] propõe uma técnica de busca local [Aarts, 1997] denominada Intraclasses-Interclasses, que é introduzida em um algoritmo GRASP [Feo, 1995] para o class-teacher timetabling problem. Essa abordagem foi comparada um algoritmo GRASP convencional para o class-teacher timetabling problem. Souza mostra que a nova abordagem produziu um resultado com uma avaliação 5% melhor do que o resultado da abordagem GRASP em aproximadamente 2,5 % do tempo consumido pela mesma (aproximadamente 5 seg). No teste realizado foi considerada uma escola pública brasileira.

Abramson [Abramson, 1992] apresenta um algoritmo genético paralelo para o timetabling problem. Nesse trabalho é feita uma comparação com os algoritmos genéticos convencionais. Nos experimentos realizados, Abramson considerou instâncias do class-teacher timetabling problem com até trezentas tuplas <professor, disciplina, sala>, trinta slots de tempo e máquinas com 1, 2, 5, 10 e 15 processadores. Abramson conclui que a abordagem paralela pode ser até 9.3 vezes mais rápida que a abordagem seqüencial, para as instâncias do problema consideradas.

Ribeiro [Ribeiro, 2001] apresenta um algoritmo genético construtivo para o class-teacher timetabling problem. Nos experimentos realizados, Ribeiro considerou quatro casos de teste reais, de instituições de ensino brasileiras.

1.3.3 ConclusãoDevido à dificuldade de generalização do class-teacher timetabling problem, não

existe uma biblioteca de instâncias de teste bem conhecida. Esse fato dificulta uma comparação de performance e da qualidade das soluções obtidas pelas várias abordagens que se propõem a resolver esse problema. Entretanto, os resultados obtidos pelos diversos trabalhos disponíveis na literatura tratando desse tema revelam que a alocação automática de professores, salas de aula e disciplinas em horários pré-determinados é passível de realização. Alguns trabalhos mostram que, quando comparadas com as alocações feitas manualmente em instituições de ensino reais, as alocações obtidas pelos algoritmos para resolução do class-teacher timetabling problem são mais bem avaliadas, utilizando-se alguma função de avaliação.

No que diz respeito ao tempo de execução do algoritmo, não foi encontrado na literatura um trabalho que relacione diretamente o tempo de execução do algoritmo com o tamanho do problema e o poder computacional de máquinas com apenas um processador. Dessa forma, não é possível se fazer previsões do tempo necessário para se computar uma tabela de alocação para uma instituição de ensino de grande porte. Entretanto, alguns trabalhos mostram que, para instituições de ensino de pequeno porte, tabelas de alocação puderam ser obtidas em até 5 segundos, utilizando-se um computador cuja configuração pode ser facilmente encontrada no mercado. Outros trabalhos mostram que, para instituições de ensino de maior porte, a utilização de algoritmos paralelos podem reduzir em até 9.3 vezes o tempo de execução de um algoritmo seqüencial.


Contudo, o algoritmo adotado pela Fábrica III foi o class-teacher timetabling problem, o qual será reutilizado neste “novo sistema”.


2. Proposta

2.1 Visão Geral do SistemaO sistema Alocação PLUS++ tem o intuito de permitir a alocação de recursos

presentes nas unidades de ensino e pesquisas sobre essas alocações. Os recursos considerados são recursos humanos (professor e aluno), recursos físicos (salas de aula, auditórios, laboratórios, etc) e disciplinas.

Para realizar a alocação, serão informados alguns recursos e o sistema deverá fornecer uma sugestão de alocação, baseada em algum critério. Por exemplo, o critério pode ser evitar a ociosidade das salas. Ao invés de alocar uma sala de 13:00 às 15:00 e de 16:00 às 18:00, é preferível alocá-las de 13:00 às 15:00 e de 15:00 às 17:00.

O sistema evitará sugestões que gerem conflito de horários. Não será possível, por exemplo, um mesmo professor ministrando aulas de disciplinas diferentes no mesmo horário, salas serem alocadas para eventos diferentes no mesmo instante, nem um mesmo aluno ser cadastrado em disciplinas que ocorram no mesmo horário.Os recursos de pesquisa permitirão que os usuários possuam consultar as alocações já realizadas e, a partir disso, obtenham informações que possam ser úteis para avaliar as sugestões de alocação geradas pelo sistema.

2.2 FuncionalidadesAs principais funcionalidades do sistema são detalhadas a seguir como casos de

uso. Para cada caso de uso, é apresentada uma breve descrição.

2.2.1 Manter cadastro de professores/alunosO usuário deve realizar operações típicas para manutenção do cadastro de

professores/alunos vinculados a unidade de ensino.

2.2.2 Manter cadastro de disciplinasO usuário deve realizar operações típicas para manutenção do cadastro de

disciplinas oferecidas na unidade de ensino.

2.2.3 Manter cadastro de recurso físicoO usuário deve realizar operações típicas para manutenção do cadastro de

recursos físicos (aula, auditório, laboratório, ...) disponíveis na unidade de ensino.

2.2.4 Realizar alocaçãoO usuário deve proceder a alocação das variáveis disciplina, professor, recurso

físico e horário, a partir de um mapa de alocação.

2.2.5 Alterar/Cancelar alocaçãoUma vez feita a alocação, o usuário poderá cancelar ou alterar a mesma, a partir

do mapa de alocações.


2.2.6 Solicitar sugestão de alocaçãoO usuário solicita sugestão de alocação e o sistema apresenta a melhor proposta

de alocação encontrada, que pode ser aceita ou rejeitada pelo usuário.

2.2.7 Consultar alocaçãoO usuário deve realizar consultas às alocações já existentes.

2.3 Proposta de SoluçãoO sistema descrito logo acima foi construído pela Fabrica III na disciplina de

Engenharia de Software da UFPE no ano que 2003. Visando reconstruir o sistema orientado a componentes, nossa fábrica terá como objetivo a reutilização de artefatos previamente construídos, como documentação, modelos, código, etc. Com isso, aumenta-se a qualidade e produtividade da empresa, diminuindo o tempo de desenvolvimento do mesmo sistema.

Segue uma apresentação de escopo negativo, ferramentas, prazo e esforço, e, propriedade e licença.

2.3.1 Escopo NegativoA Fábrica ABC se compromete a desenvolver todas as funcionalidades acima

citadas, entretanto, não fazem parte do escopo desta proposta serviços como: Suporte técnico: a Fábrica III se compromete a entregar o sistema no prazo

acordado com o cliente e encerra suas obrigações. Manutenção evolutiva: a Fábrica III não irá realizar manutenção para

evoluir o sistema com novas funcionalidades. Caso seja do interesse do cliente, uma nova proposta pode ser feita após a entrega do sistema.

2.3.2 FerramentasSegue as ferramentas que serão utilizadas durante o processo de

desenvolvimento do projeto Alocação PLUS++.

Jbuilder, Eclipse (implementação) Rational Rose [Rose], Poseidon UML [Poseidon], MVCASE [Mvcase] (modelagem) CVS [Cvs] (controle de versões), se possível Word (documentação) PostgreSQL (armazenamento de dados) Apache (Tomcat)

2.3.3 Prazo e EsforçoUtilizando o processo de estimativas por WBS, consultando os membros da

equipe identificamos que o período para o desenvolvimento do sistema vai do dia 26 de abril de 2004 até o dia 24 de maio de 2004, duas semanas a menos do proposto pela construção inicial do sistema pela Fábrica III. O sistema será desenvolvido por uma equipe de dez pessoas, onde cada uma contará com dedicação de 8 horas semanais durante quatro semanas, contabilizando um total de 320 horas esforço.

2.3.4 CronogramaO cronograma abaixo só tem validade a partir do momento que o cliente aceitar

esse documento incluindo riscos e as condições de níveis de serviço. Estimamos que o aceite seja realizado no dia 28 de abril de 2004.


Tabela 1. Cronograma de Atividades

Atividades Abril Maio27

28

29

31

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

01. Estudo do Domínio02. Atividades de Reengenharia03. Atividades de Engenharia do Domínio04. Engenharia de Componentes05. Engenharia de Aplicação05. Levantamento das Métricas Colhidas06.Elaboração da documentação e apresentação do Projeto07.Apresentação do Projeto

2.3.5 Propriedade e LicençaPara a implantação desta solução, a Fábrica de Software ABC utilizará

ferramentas, padrões, templates, guias, métodos e técnicas pertencentes ao processo de software corporativo, cujos direitos, título e interesse (incluindo propriedade e direitos autorais) são retidos à prestadora do serviço. O CLIENTE não terá nenhuma licença ou direitos a estes ativos, exceto se especificado e estabelecido nesta Proposta.

2.4 ABC – A Fábrica de Software2.4.1 Perfis que compõem a Fábrica ABC

Os seguintes perfis compõem a Fábrica III: Gerente de Projetos Engenheiro de Domínio Reengenharia Engenheiro de Componentes Engenheiro de Aplicação

Para um maior detalhamento das atividades, responsabilidades e conhecimentos de cada perfil, consultar o Plano de Definição Fábrica, que está disponível na home page da Fábrica ABC [Home Page].

2.4.2 PerfisSomando a experiência de todos os integrantes, a ABC possui experiência em várias áreas de conhecimento da computação como pode ser visto no Plano de Definição da Fábrica [Home Page].


2.4.3 PapéisOs papéis da ABC estão definidos no Plano de Definição da Fábrica [Home Page].

2.4.4 Organograma da Fábrica ABCOs perfis listados acima se relacionam da seguinte forma na hierarquia da Fábrica ABC, conforme mostra a Figura 1.

2.4.5 Home Page do ProjetoO projeto Alocação Plus++ está hospedado em [Home Page], onde o cliente poderá acompanhar todo o andamento do processo e recuperar os itens de entrega, tendo ótima visibilidade sobre as atividades do projeto.

2.4.6 MetodologiaA fábrica possui toda sua metodologia definida na Home Page, localizado em [Home Page].

2.4.7 MétricasAlgumas métricas serão usadas para medir o processo do projeto Simulare:

Reuse Level: A quantidade de linhas de código reusadas em conformidade com a quantidade de linhas de código do sistema.

Produtividade: Baseado no tamanho do sistema relacionado ao grau de esforço expendido durante o desenvolvimento (Engenharia de Domínio, Reengenharia, Desenvolvimento Baseado em Componentes)

2.4.8 RiscosAlguns riscos previstos pela Fabrica ABC são listados abaixo. Instabilidade do meio de comunicação principal, o e-mail do CIN. A equipe ainda não possui um conhecimento difundido de quais

métodos/técnicas adotar para realizar a Reengenharia e Engenharia de Domínio. Por isso, nesse projeto piloto serão definidos quais técnicas/métodos serão utilizados.


Gerente de Projetos

Engenheiro de DomínioReengenhariaEngenheiro de ComponentesEngenheiro de Aplicação

Figura 0. Organograma

2.4.9 Diferenciais Fábrica de Software III

A Fábrica de Software ABC possui metodologia baseada no KobrA [Kobra, 2000], processo de desenvolvimento de software, e tem como principal diferencial o foco em reuso de software. Algumas das técnicas adotadas são apresentadas a seguir:

Reengenharia: Concentra-se na reconstrução de sistemas utilizando artefatos de software previamente construídos, resultando num aumento de qualidade, produtividade e redução do tempo de entrega, tornando-se muito atrativo para a produção de software.

Engenharia de Domínio (ED): A ED tem sido, ultimamente, uma das abordagens mais utilizadas para promover o desenvolvimento baseado em reuso [Griss, 1998]. Isso envolve a identificação e desenvolvimento de artefatos reusáveis numa aplicação ou domínio.

Engenharia de Componentes: tem como benefícios a agilidade no processo de desenvolvimento de software e conseqüentemente na entrega da solução [D’Souza, 1999] [Frakes, 1995].

Engenharia de Aplicações: Nesta fase, espera-se que o desenvolvimento da aplicação seja facilitado, uma vez construídos todos os componentes reutilizáveis. Com isso, espera-se que nessa fase, sejam construídos apenas “colas” para interconectar os componentes e gerar a aplicação.


3. SLA

3.1 Cláusulas GeraisSegue a descrição das principais cláusulas relativas a SLA.

3.1.1 Propósito e objetivosO objetivo desse termo é estabelecer regras para garantir a qualidade dos serviços prestados pela fábrica à Universidade Federal de Pernambuco, as responsabilidades e as garantias asseguradas por ambas às partes envolvidas durante o período de contratação conforme resposta da RPF para desenvolvimento do sistema Alocação PLUS++.

3.1.2 Partes do acordoOs envolvidos nesse acordo são: o fornecedor, a fábrica de software ABC doravante denominada CONTRATADA, e, o cliente, a Universidade Federal de Pernambuco denominado CONTRATANTE. Fica ao encargo dos dois realizar sub-contratações, parcerias ou colaboradores de forma que sejam respeitados os itens desse termo.

3.1.3 Duração e ValidadeA validade dos termos aqui expostos terá duração da prestação dos serviços referentes ao projeto do sistema de alocação de recurso cujos prazos e atividades foram definidos na estimativa de esforço (seção 2.3.3) e no cronograma (seção 2.3.4).

3.1.4 Aplicação do AcordoAs partes envolvidas se comprometem por meio desse instrumento a cumprir todos itens descritos pela SLA no período definido em 3.1.3 de maneira que cada parte terá que desempenhar seu papel de acordo com a metodologia (seção 2.4.6), e se auto-disciplinar para cumprir as condições aqui delimitadas, sendo responsabilizada pelas conseqüências que suas ações possam ocasionar, sendo esse termo o instrumento de regulagem para garantir os direitos e deveres de ambas as partes em caso de disputa ou impasse com relação aos mesmos.

A cada um dos envolvidos é de inteira responsabilidade o cumprimento do acordo, não podendo as responsabilidades de cumprimento dos itens ser transferida para sub-contratados, parceiros ou colaboradores externos.

3.1.5 Alteração do AcordoO presente acordo pode ser alterado com o consentimento do CONTRATANTE e do CONTRATADO para realização de mudanças nos prazos e atividades descritos no cronograma. Quando houver mudança, deverá ser gerada uma nova versão desse documento e aprovada por ambas as partes através de e-mail. O e-mail será considerado a documentação comprobatória para quaisquer alterações.

O contratante terá 72 horas após o início desse acordo (encaminhado dia 19 de abril de 2004) para solicitar mudanças na dessa proposta, e mais 24 horas para chegar numa nova versão junto ao CONTRATADO. Após esse período inicial as mudanças só poderão ocorrer no intervalo entre o fim de uma iteração e início da nova iteração.


3.1.6 Serviços e Nível dos ServiçosPara cada serviço descrito nesta seção existe uma definição de cumprimento e descumprimento de cada uma das partes, que acarreta respectivamente em bonificações e penalidades descritas de forma particular para cada serviço.

3.1.6.1 Atendimento e ComunicaçãoO CONTRATADO deverá estar sempre disponível através de e-mail para contato com o cliente para esclarecimentos e informações, o cliente também tem as mesmas obrigações de estar sempre disponível para por e-mail para o CONTRATADO. Ambas as partes devem responder os e-mails dentro do período de 24 horas a partir da data de recebimento.

O não comparecimento do CONTRATANTE às reuniões agendadas será considerado um descumprimento. Se o cliente não responder os e-mails de enviados pelo CONTRATADO no período de 48 horas, relativos a: esclarecimento de um requisito, priorização e re-priorização de requisito o CONTRATADO poderá tomar por si próprio as decisões de quais requisitos serão entregues, e penalidades relativas às escolhas dos requisitos não poderão ser aplicadas.

Todas as informações contidas em e-mails serão consideradas de caráter oficial, o e-mail pode ser usado para levantar e especificar requisitos, priorizar e re-priorizar requisitos, e quaisquer alterações no escopo e andamento do projeto, desde que obedeçam a regras definidas no item 3.1.5.

3.1.7 EntregasO cumprimento dos prazos de entrega (descritos em 2.3.4) por parte do CONTRATADO pode ser usado como critério para redução de outras penalidades.

O limite para as entregas será às 24hs do dia combinado, conforme o cronograma. No Home Page do projeto (http://www.cin.ufpe.br/~aa2/Fabrica), o CONTRATANTE terá acesso aos artefatos documentais e programas relacionados.

Se o CONTRATADO entregar os artefatos e produtos X dias antes do prazo do cronograma, o mesmo será bonificado com o acréscimo de X dias em S, onde S é o saldo de dias.

Se o CONTRATADO entregar depois das 24hs do dia acordado, será subtraído Y de S, onde Y é a quantidade de dias de atraso na entrega excluindo-se às 24hs. Quando o atraso for ocasionado por um risco documentado em 2.4.8, o CONTRATADO não será penalizado, e o cronograma de entregas deve ser renegociado.

Caso S seja positivo ao fim do projeto, o CONTRATANTE ganhará um acréscimo de S x 0.2 pontos no conceito da disciplina, caso contrário, o CONTRATADO será penalizado com S x 2 horas de trabalho que irá oferecer para o CONTRATANTE utilizar na realização de trabalhos de correções e manutenção dos produtos e artefatos entregues.

O CONTRATADO poderá requerer ao CONTRATANTE o adiamento do prazo de entrega de artefatos desde de que isto seja feito até 48 horas antes do prazo de entrega resultando em uma bonificação a ser acordada no banco de horas do CONTRATANTE.


3.1.8 Processo e MétricasO CONTRATANTE e o CONTRATADO utilizarão o processo descrito em 1.4.6, que contempla reajustes a cada iteração. As métricas descritas na seção 1.4.7 só poderão ser modificadas conforme 3.1.5.

3.1.9 Requisitos e EscopoO serviço que o CONTRATADO irá fornecer terá esforço e prazo fixos (conforme visto na seção 2.3.3), a variação se dará nos requisitos e escopo do sistema. A cada release, serão negociados quais requisitos estarão contemplados, para que sejam respeitados os prazos dentro do esforço planejado.

3.1.10 Novas requisiçõesAté a fase de Elaboração, serão aceitas novos requisitos por parte do CONTRATANTE para que possam ser especificados e analisados. A partir da construção, quando a maior parte dos requisitos estiver estabelecida entre o CONTRATANTE e o CONTRATADO, novas requisições vão implicar em alterações do cronograma e esforço que devem ser renegociados e implementados somente mediante re-priorizações dos requisitos preexistentes, podendo até mesmo haver eliminação de um dos requisitos incluídos anteriormente.

3.2 Cláusulas Específicas3.2.2 Pontos de Contato entre o cliente e o FornecedorO cliente será representado por Eduardo Santana de Almeida, contatado através do e-mail, [email protected], e o fornecedor terá pontos de contato fixos: gerente de projetos; e ponto de contato variável : um ou mais dos integrantes do grupo responsável pela área que o cliente deseja interagir. Todos os e-mails enviados pelo cliente devem ser copiados para os pontos de contato fixos.


4. Referências

[Jain, 1998] Jain, A., Meeran, S. A state-of-the-art review of job-shop scheduling techniques. Technical report, University of Dundee, Dundee, 1998.

[Schaerf, 1995] Schaerf, A., A survey of automated timetabling. Report, CWI, Amsterdam, 1995.

[Terra, 2001] Terra, I., Uma Solução para a Confecção do Horário Acadêmico. Dissertação de Mestrado. Universidade Federal de Minas Gerais, 2001.

[Gröbner, 2002] Gröbner, M., Wilke P. A General View on Timetabling Problems. 4th International Conference on the Practice and Theory of Automated Timetabling, 2002,

[Caldeira, 1997] Caldeira, P., Agostinho, R. School Timetabling Using Genetic Search, Practice and Theory of Automated Timetabling, Toronto, 1997.

[Holland, 1975] Holland J. Adaptation in Natural and Artificial Systems. University of Michigan Press, 1975.

[Fang, 1994] Fang, H. Genetic Algorithms in Tametabling Problems. PhD Thesis, University of Edinburgh, 1994.

[Fernandes, 2002] Fernandes, C., Caldeira, J. Infected Genes Evolutionary Algorithm for School Timetabling. WSES, 2002.

[Souza, 2001] Souza, F., Ochi, S., Maculan, N. A GRASP-Tabu Search Algorithm to solve a School Timetabling Problem. Metaheuristics International Conference - MIC, July 2001

[Aarts, 1997] Aarts, E., Lenstra K. Local Search in Combinatorial Optimization. Wiley, 1997.

[Feo, 1995] Feo, T., Resende, M. Greedy randomized adaptive search procedures. Journal of Global Optimization, 1995.

[Abramson, 1992] Abramson, D., Abela, J. A Parallel Genetic Algorithm for Solving the School Timetabling Problem. 15 Australian Computer Science Conference, 1992.

[Ribeiro, 2001] Ribeiro, G., Lorena, L. A Constructive Evolutionary Approach to School Timetabling. EvoCOP2001 - First European Workshop on Evolutionary Computation in Combinatorial Optimization, 2001

[Rose] www.ibm.com/software/rational[Poseidon] www.gentleware.com[Mvcase] http ://www. recope . dc .ufscar. br / mvcase [Cvs] http ://www. cvshome . org [Kobra, 2000] Atkinson, C., et. al. Component-Based Software Engineering:The

KobrA Approach, In 3rd International Workshop on Component-based Software Engineering: Reflection on Practice, in conjunction with the 22th International Conference on Software Engineering (ICSE). Limerick, Ireland, 2000.

[Griss, 1998] Griss, M.; Favaro, J.; D’Alessandro, M. Integrating Feature Modeling with RSEB. 5th International Conference on Software Reuse (ICSR), IEEE, Victoria, Canada, June, 1998.

[D’Souza, 1999] D’Souza, D., F., Wills, C., A. Objects, Components, and Frameworks with UML – The Catalysis Approach. Addison-Wesley, 1999.


http://www.cvshome.org/





http://www.recope.dc.ufscar.br/mvcase/









[Frakes, 1995] Frakes, W., B., Fox, C., J. Sixteen Question about Software Reuse. Communications of the ACM. June 1995.

[Home Page] http://www.cin.ufpe.br/~aa2/ABC


usina - cin.ufpe.brcin.ufpe.br/~aa2/abc/documentos/rfp-sla.doc · web vieweste documento tem como...

Documents