Resposta requisio formal de proposta (RFP) do IEC

1. Objetivo
Esse documento tem como objetivo apresentar o entendimento da Fbrica II sobre a demanda
do IEC, documentada na sua RFP, assim como de propor uma soluo para ela, expondo os
processos, ferramentas e diferenciais da Fbrica II no atendimento dessa demanda.
2. Proposta Apresentada pela IEC
Na RFP emitida pelo IEC, o solicitante sugere a implantao de um cadastro de ex-alunos para
manter armazenados os dados dos ex-alunos e fazer posteriores avaliaes estatsticas sobre a mdia
salarial dos ex-alunos e sobre quais empresas esses ex-alunos foram absorvidos, qual ttulo da
dissertao, qual rea, qual orientador e demais campos de contato.
A proposta de soluo dever contemplar aspectos tcnicos, de qualidade, de processo de
desenvolvimento, de arquitetura privilegiando ambientes free e de argumentao cientfica para
as tcnicas e os fundamentos utilizados. Tambm, a proposta dever vir acompanhada de um SLA
(Service Level Agreement) que contemple todo o processo de desenvolvimento at a entrega dos
produtos.
3. Proposta Sugerida pela The Factory
A soluo proposta, para o problema exposto pela IEC, seria desenvolver um sistema que
servir para manuteno dos seus ex-alunos, permitindo a atualizao distribuda dos dados do
mesmo, bem como sua recuperao.
4. Proposta de Soluo da Fbrica II - Requisitos do sistema
4.1 Usurios
Os usurios do sistema sero funcionrios autorizados da instituio responsveis por
administrar a manuteno dos ex-alunos e da turma a que esses pertencem, o prprio ex-aluno
que poder alterar seus dados e enviar e-mail para os ex-alunos da(s) sua(s) turma(s) e um
usurio qualquer que ter apenas a opo de consultar alguns dados de determinado ex-aluno.
Nome
Funcionrio
Autorizado

Descrio
Funcionrio com poder de
administrador do sistema,
autorizado a gerenciar a
manuteno dos ex-alunos

Ex-Aluno

Alterar ex-aluno

Usurio Comum

Realiza consultas no sistema

Responsabilidades
Incluir/alterar/remover ex-alunos;
Incluir/alterar/remover turma;
Enviar e-mail para qualquer turma ou exaluno;
Consultar dados de ex-alunos.
Alterar alguns dados do prprio ex-aluno
como: endereo, empresa atual, faixa
salarial.
Pesquisar sobre alguns dados do ex-aluno.

4.2 Viso Geral do Sistema

O sistema prover uma interface web para manter um cadastro com as seguintes funes:
Manuteno e Consulta do ex-Aluno, Envio de e-mail para ex-alunos e Manuteno de Turma.
A operao de Manuteno se divide em Incluso, Alterao e Excluso.
As operaes de incluso e excluso devero ser realizadas exclusivamente pela
administrao do sistema. A alterao de turma tambm ser uma funcionalidade de uso
exclusivo da administrao do sistema.
As consultas podem ser feitas por qualquer usurio da Internet com base em filtros de
consulta, baseados em nome, cpf, consulta por turma, grau de formao, ano, curso,
especializao e ttulo (por palavras-chave).

O envio de e-mails a ex-alunos ser feito a partir de filtros baseados em nome ou cpf, ou
consulta por turma, grau de formao, ano, curso, especializao e ttulo.
O relatrio da situao financeira dos ex-alunos conter informaes grficas sobre a faixa
salarial dos ex-alunos por curso.
O produto desenvolvido independente e totalmente auto contido no necessitando, dessa
forma, de outros sistemas para o seu funcionamento.
Tambm sero realizadas uma previso de espao em disco utilizado e previso de
escalabilidade para prximos anos. Esta previso constar do relatrio de concluso do projeto.
4.3 Funcionalidades
As principais funcionalidades do sistema so detalhadas no documento CADEX-VENDACasoDeUso.doc e CADEX-VENDA-DocumentoRequisitos.doc .
4.4 Sistemas Relacionados
O sistema CADEX um sistema independente. Ele no interage com outros sistemas, mas
pode trocar informaes, caso necessrio, a partir do banco de dados, desde que o banco seja
compartilhado entre tais sistemas.
Por ser um sistema web, possui apenas dependncia com softwares de infra-estrutura. Em
virtude disso, necessria a presena de um servidor web capaz de suportar Servlets e JSP.
5. Ferramentas Utilizadas

JBuilder (implementao)
Microsoft Visio (modelagem)
CVS (controle de verses)
Bugtrack do CdigoLivre (reportar bugs)
Project (gerenciador de cronograma)
Word (documentao)
Oracle (armazenamento de dados)
ICQ (compartilhamento de conhecimento)

6. Investimentos
O projeto ir necessitar, para sua execuo, de uma equipe composta por 8 pessoas durante 5
semanas. Vale ressaltar que a alocao mdia das pessoas de 8 horas por semana.
7. Prazo
O prazo de entrega da soluo contado a partir da data de validao desta proposta, com
previso de trmino para 01/09/2003.
8. Propriedade e Licena
O Contratante ter direito de uso ao sistema desenvolvido bem como s fontes do mesmo, que
sero publicados como software livre, pois o sistema utilizar ferramentas, padres, templates,
guias, mtodos e tcnicas free. O banco de dados com as informaes da Contratante, entretanto,
de sua propriedade, podendo a Contratante utiliz-lo livremente.
O CLIENTE no ter nenhuma licena ou direitos a estes ativos, exceto se especificado e
estabelecido nesta Proposta.
9. Organizao da Fbrica II
Os seguintes perfis compem a Fbrica II:
Gerente de Projetos

Gerente Comercial
Analista de Negcios
Engenheiro de Qualidade
Engenheiro de Software
Arquiteto de Software
Designer

Para um maior detalhamento das atividades, responsabilidades e conhecimentos de cada perfil,

esto no documento CADEX-VENDA-PropostaTecnica.doc.
10. Metodologias Utilizadas
10.1 Qualidade do Produto e do Software

A Qualidade de Pacotes de Software segundo ISO 12119 foi publicada em 1994 e trata da
avaliao de pacotes de software. Um pacote de software est em conformidade com essa
Norma Internacional se ele cumpre com todos os requisitos de qualidade relacionados
Descrio do Produto, Documentao do Usurio, Programas e Dados.
Como forma de garantia da qualidade do processo, sugerimos a adoo do PSP. O PSP
(Personal Software Process) prove um mtodo de trabalho que ensina um processo de software
aos engenheiros, e o ponto de partida fazer com que o engenheiro se envolva em seu prprio
processo. O PSP baseado nas mesmas prticas industriais encontradas no CMM da SEI, s
que em uma escala menor para o uso individual. A idia principal do PSP criar mdulos ou
pequenos programas com alta qualidade.
Os objetivos principais do PSP so:
Melhorar as estimativas
Melhorar o planejamento e o acompanhamento de cronogramas
Proteger contra o excesso de compromissos
Criar um comprometimento pessoal para a qualidade
10.2 Gerncia de Projeto

O processo de gerncia de projetos parte integrante do processo de desenvolvimento de

software, mas se distingue por ser um fluxo que permeia todos os demais, desde o incio ao fim
do projeto, com o objetivo de atender aos requisitos de escopo, prazo, qualidade e custo do
mesmo.
O PMBOK (Project Management Book of Knowledge) considera 9 reas de conhecimento
na gerncia de projetos: Integrao, Escopo, Tempo, Custo, Qualidade, Recursos Humanos,
Comunicaes, Riscos e Aquisies. Estas reas de conhecimento descrevem os conhecimentos
e prticas em gerncia de projetos em termos dos processos que as compem. Estes processos
podem ser organizados em cinco grupos, cada um deles contendo um ou mais processos.
10.3 Arquitetura de Software

Arquitetura de software da fabrica The Factory. A arquitetura ser baseada de acordo com a
plataforma de desenvolvimento e do produto a ser desenvolvido pela fabrica de software.
Independente da plataforma a ser escolhido algum aspecto da arquitetura deve ser considerado.
Cada camada dever prover funes especificas do sistema, a forma de comunicao entre
elas dever ser sempre no sentido Interface -> Comunicao -> Negocio -> Dados.
10.4 Modelo do Banco de Dados

Essa aplicao ser livre de plataforma e poder rodar em qualquer tipo de banco de dados
relacional, pois as operaes utilizadas no sistema usaro SQL padro.

10.5 Descrio do Ambiente de Configurao

A estrutura fsica de desenvolvimento ser distribuda, onde cada membro da fbrica poder
trabalhar em um lugar diferente, porm todos os itens de configurao devero ser mantidos em
um repositrio central onde ser feito o controle de verses e mudanas.
Utilizando ferramentas como Cdigo Livre 7 um servio gratuito em portugus para
desenvolvedores de software que oferece fcil acesso a CVS, listas, controle de bugs, quadro de
mensagens/frums, gerenciador de tarefas, hospedagem, arquivamento permanente de arquivos,
backups completos e administrao totalmente baseada na WEB.
11. Fases X Artefatos
A tabela abaixo lista os artefatos gerados por fase da metodologia
Fase
Comercial

Planejamento e
Gerenciamento

Testes e
Validao

Artefatos

Disponibilizao no Site

Documento de Requisitos

28/07/03

Cronograma Proposta

29/07/03

Resposta a RFP

01/08/03

Estimativa de Esforo

29/07/03

Estimativa de Custos

29/07/03

Proposta Tcnica

30/07/03

Proposta Comercial

31/07/03

Contrato de Software

01/08/03

Ata de reunio

04/08/03, 11/08/03,
18/08/03, 25/08/03

Plano do Projeto

04/08/03

Cronograma Projeto

06/08/03

Relatrio de Riscos Identificados

06/08/03

Planilha de Reportagem de Tempo

29/08/03

Planilha de Acompanhamento de Custos

11/08/03, 25/08/03

Relatrio de Concluso de Projeto

01/09/03

Tamanho Final em Pontos de Casos de

Uso

29/08/03

Descrio de Testes de Aceitao

06/08/03

Cdigo de Testes de Unidade

26/08/03

Registro de Erros

28/08/03

12. S.L.A. - Acordo de nvel de servio [Naomi Karten]

A The Factory se compromete a prestar servios de Desenvolvimento de Software para o
IEC, no sentido de desenvolver uma soluo para manter informaes sobre os ex-alunos desta
instituio. Maiores informaes sobre a proposta de soluo podem ser encontradas no documento
CADEX-VENDA-PropostaTecnica.doc e CADEX-VENDA-PropostaComercial.doc.
Na concluso do projeto ser feito um balano das multas e descontos devidos s
penalidades aplicadas para gerar o custo final do projeto, no podendo o custo final ultrapassar uma
variao de 30% no valor estimado do projeto, salvo custos gerados por solicitaes de mudanas.
Os itens seguintes itens ficam acordados para eventuais cobranas.
13.1. Dos prazos
De acordo com a proposta tcnica, a fbrica se compromete a entregar diversos artefatos ao
cliente (inclusive o projeto final). O cliente dever rejeit-los em at 48hs contadas a partir do
recebimento. Aps este prazo os artefatos sero considerados aceitos. No caso de rejeio e
descumprimento do prazo, o cliente ter um nus de 0.5% por dia de atraso no valor do projeto mais
o custo de retrabalho (se existir). Caso o atraso seja da fbrica, o cliente receber um desconto de
igual valor. Artefatos entregues antes do prazo, gradualmente cancelam os descontos provenientes
de atrasos em outros artefatos na medida de um dia de adiantamento para um dia de atraso.
Este mesmo encargo vlido para qualquer artefato com prazo de entrega estabelecida para
qualquer uma das partes, ou seja, as penalidades aplicam-se tambm aos prazos estabelecidos para
solicitaes feitas ao cliente e que dependam do mesmo.
13.2. Das reunies com o cliente
Qualquer uma das partes pode solicitar reunies durante o desenvolvimento do projeto. O
cliente deve ter agilidade na resposta a emails que solicitem tais reunies, ser cobrada uma multa
de 1% sobre o valor do projeto por dia, caso a resposta ultrapasse o prazo de 48hs. Ambos tm que
concordar sobre o horrio e local dessa reunio. O no comparecimento de qualquer das partes fica
sujeito penalidade de 1% sobre o valor do projeto por descumprimento de compromisso para a
parte ausente.
O cliente dever dispor de pelo menos uma hora semanal a ser utilizada quando necessrio para
realizao de esclarecimentos sobre o projeto e seu andamento.
13.3. Da Qualidade
A The Factory garante a qualidade do produto e produz um relatrio de mtricas ao final do
projeto. A no aderncia ao processo de qualidade definido pela fbrica implica no desconto de 5%
sobre o valor do projeto. A The Factory garante entregar o produto com no mximo 3 bugs a cada
1000 linhas de cdigo, sendo este o principal indicador de qualidade.
Fica estabelecido o desconto de 0.5% sobre o valor do projeto por cada 30% de bugs a mais
que o especificado.
13.4. Das Mudanas
As solicitaes de mudana (escopo, SLA, etc) s sero consideradas se enviadas por email
para o gerente de projeto e devem ser bem descritas e justificadas.
A The Factory tem 48hs para responder por email com uma proposta de possvel soluo de
atendimento ao cliente, contendo as modificaes necessrias em cronogramas e encargos
juntamente com sua justificativa.
Os encargos referentes a estudos de viabilidade so pagos pelo cliente na forma de uma
multa de 1% do valor do projeto por solicitao de mudana.

13. Referncias
1. Progressive implementation of distributed Java applications. Paulo Borba, Saulo Arajo,
Hednilson
Bezerra,
Marconi
Lima,
and
Srgio
Soares.
http://www.cin.ufpe.br/~phmb/papers/pim-edo99.ps
2. Gibeon Soares and Paulo Borba. The Web Handlers pattern. In First Latin American
Conference on Pattern Languages of Programming, Rio de Janeiro, Brazil, 3th-5th October
2001.
3. http://wwwedit.inf.ufsc.br:2000/users/r/ronaldo/bdpos/3-modelos.pdf
4. Kan, Stephen H., Metrics and Models in Software Quality Engineering Crtes, Mario
Lcio; Chiossi, Thelma C. Dos Santos. Modelos de Qualidade de Software.
5. PMI,PMBOK Project Management Book of Knowledge; http://www.pmi.org (apenas
para membros), acessado em 12/5/2003.
6. CVS, Concurrent Versions System, http://www.cvshome.org, acessado em 15 de Maio de
2003.
7. Univates Centro Universitrio, Cdigo Livre, http://codigolivre.org.br/, acessado em 15
de Maio de 2003
8. http://www.nkarten.com/handbook.pdf
9. The Factory, http://www.factprocess.codigolivre.org.br