O sistema SIGNUS permite a integração entre as operadoras de telefonia no que diz respeito à Roaming, verificação de valores por limite de crédito e fraudes. Tem como foco principal auditar a troca de CDRs (registro de uma chamada de telefone) entre as operadoras, avaliando nesse aspecto o desempenho de cada uma, e gerindo as contestações entre as mesmas e o controle do cumprimento dos procedimentos operacionais definidos pela associação. A troca desses registros de chamadas é feita por um sistema aplicativo também desenvolvido pela EAS.
 
 
 
Normalmente nos projetos em parceria com a HP, é ela quem monta e aprova junto com o cliente o Plano de Projeto, sendo que parte dele é feito junto com a EAS, principalmente o que diz respeito ao WBS e cronograma de desenvolvimento. Nesse plano são definidos os principais papéis, stakeholder e o plano de comunicação.
Após o Plano de Projeto aprovado, para o desenvolvimento do aplicativo, levantamos as necessidades do usuário e as regras e os requisitos de negócios, através de várias técnicas (JAD, protótipos, cenários, etc.) e montamos a primeira lista de requisitos e das regras de negócio, utilizando um artefato que chamamos de Documento de Visão de Negócio, que nos dá uma noção do negócio, dos problemas atuais e do que o cliente espera e precisa receber.
Uma vez aprovada pela HP (ou cliente HP) esse artefato, é solicitado que o cliente defina uma prioridade desses requisitos, sendo criada uma baseline para rastreabilidade e controle das mudanças que esses requisitos podem sofrer.
Após isso, a Gerência de Risco faz um monitoramento nos riscos levantados inicialmente e se necessário gera uma nova versão desse plano, a Gerência de Qualidade e Teste, verifica a consistência desses requisitos de negócio, com relação à forma e a possíveis faltas de clareza e ambigüidades e monta o plano de teste definindo já alguns cenários, sem fugir da Estratégia do Teste definida no início do projeto.
Desenvolvemos então outro artefato de especificação funcional em forma de Casos de Uso que dão uma idéia de como o sistema irá funcionar. Novamente esse artefato e auditado em vários aspectos, como se todos os requisitos de negócio tem um ou mais casos de uso para satisfazê-lo e se um caso de uso está atendendo algum requisito de negócio, e novamente solicitamos a HP/Cliente a aprovação desse documento. Feito isso é criada mais uma baseline e a versão 1.0 do artefato é entregue.
Os riscos também são revistos e atualizados de forma a minimizar os riscos negativos e maximizar os riscos positivos. Com relação a isso podemos destacar que os riscos de maior impacto para o projeto são priorizados (como por exemplo, um risco de tecnologia). Se o volume de risco for alto, atacamos os 20% mais graves, sem esquecermos os riscos que são característicos e identificados numa determinada fase da metodologia do ciclo de vida.
Os riscos são todos classificados e cada um recebe uma determinada estratégia que resumidamente pode ser: Prevenção, Mitigação, Transferência, Contingência ou Aceitação. Conforme o plano de monitoramento definido no Plano de Risco são feitas as reuniões de monitoramento e criado os milestones utilizado para o relatório de registro de monitoramento do risco.
Com relação ao Plano de Gerenciamento das Comunicações, definimos a necessidade de informações de cada envolvido no projeto, como essa informação será levada até ele e em que nível. Na maioria dos projetos com a HP, o Líder Técnico e o Gerente de Projeto sempre recebem cópia de qualquer e-mail que diga respeito a algum assunto do Projeto. Internamente, criamos um e-mail genérico com o nome do projeto, que o distribui para toda a equipe da EAS envolvida no projeto. Normalmente os artefatos gerados são entregues para o Líder Técnico e/ou Gerente de Projeto da HP, que se encarrega da distribuição dos mesmos para os clientes. Em alguns projetos ainda, a HP utiliza um site externo para colocação dos artefatos gerados.
O processo de distribuição de informações garante assim, que todos os envolvidos no projeto recebem a tempo e hora a informação a eles destinada. A EAS sempre aloca em todos os projetos um gerente de projeto junto a HP, com o papel de coordenar e funcionar como o principal interlocutor com o gerente de projeto HP.
Nas fases de Elaboração e Construção desenvolvemos a arquitetura da aplicação, as especificações técnicas e modelo de classes, além de quando necessários outros artefatos da linguagem UML 2.0, e os programas fontes. Esta fase se divide nas disciplinas de Análise e Design, Arquitetura, Construção e Testes.
A EAS tem ultimamente desenvolvido aplicativos na linguagem JAVA e PL-SQL da Oracle para HP, sendo os fontes entregues e homologados no final do projeto.
Nesta fase a equipe de Qualidade e Teste faz novas validações e verificações através de inspeções e revisões formais, além de preparar e aplicar os casos de testes conforme o aplicativo é construído. Dependendo do projeto a HP pode ou não dar o aceite nos casos de testes criados.
Esses mesmos casos de testes que foram baseados nos cenários de testes definidos ainda na fase de requisitos, e aderente a Estratégia de Testes, são à base do ATP (Plano de Testes de Aceitação). As características e subcaracteristicas da ISO 9126 são a base para a definição de onde a EAS deverá focar a maior força de testes.
Após o aceite e implantação do sistema junto ao cliente, a EAS cria uma baseline das fontes do aplicativo e os entrega para HP.
Durante todo o projeto a Gerência de Mudança estará agindo para garantir que qualquer alteração durante o mesmo seja tratada e validada no que diz respeito a principalmente possíveis impactos. Para que uma mudança seja efetuada, faz-se necessário que um artefato de solicitação de mudança seja preenchido por um stakeholders, onde o mesmo indicará o motivo (não-conformidade, melhoria, legislação).
O Gerente de Projeto HP uma vez concordando com a solicitação de mudança a encaminha para EAS que faz a análise do impacto (custo e prazo) para o projeto para atender a solicitação e a devolve para o Gerente de Projeto HP que uma vez aprovando-a, o insere no cronograma do projeto.
Dependendo da necessidade e urgência do projeto para HP, algumas atividades e artefatos podem deixar de ser desenvolvidos ou alguns planos podem estar embutidos no próprio Plano de Projeto, como às vezes ocorre com o Plano de Comunicações.
 
 
Estamos em processo de avaliação mpsBR-Nível F (equivalente a certificação CMMI-Nível 2).
 
 
A EAS no ultimo dia 29 entrou num grupo de interesse sobre BPM realizado na Firjan. Os processos da fábrica de software estão todos sendo remodelados com a nomenclatura de Bussiness Process (BPMN). Além disso uma equipe interna está voltada para tecnologias que implementem os conceitos.