Blog

UNIP INTERATIVA Projeto Integrado Multidisciplinar Cursos Superiores de Tecnologia PIM VIII UNIP Rio de Janeiro pólo Centro 2010 PIM UNIP Rio de 2 Resumo 4 Swipe nentp O objetivo deste trabalho é fazer uma demonstração prática do quadro de estudos e conteúdo das matérias: Gerenciamento de projetos de TI, Empreendorismo e Qualidade de software. Usaremos como objeto de estudos uma empresa “fictícia” Paulista chamada Software Developer cujo afim é o desenvolvimento de aplicativos da área financeira abrangindo os setores de: Sistema de Consórcio, Sistema Financeiro e Sistema e Empréstimos.

Após vários problemas, oriundos diretamente da área de produção ou relatados por clientes, terem sido catalogados pela Software Developer uma abrangente ação corretiva deverá ser implantada. -lal Studia Projeto de software em suas Figura 2. 4 – camadas . Gráfico RUP do Ciclo de vida de um Figura 1. 5 Software — — Figura 2. 5 – Estratégia de testes . – Gráfico de custo X Figura 2. 5 Tempo Figura 3. 5 – Release e Integração Figura 4. 5 Integração . Sumário Introdução Capítulo 1 — As Falhas 1. – Enumeração das falhas „ 2. – Análise das falhas — Capitulo 2 – Requisitos do projeto 2. 1 — Descrição básica do 20F 14 3. 2 – Aplicando as soluções 3. 3- EAP do projeto . Capítulo 4 — Concideraçõeas gerais Capitulo 5- As falhas . 5. 1 – Aplicando as melhorias — — 5. 2 – Desenvolvimento da Unidade — 5. 3 — Teste da Unidade 5. 4 – Teste de Integração — . 5. 5 – Teste de Sistema Capitulo 6 – Escopo , Custo e Tempo 6. 1 – Escopo 6. 2 Custo 6. 3 – Tempo — 6. 3. 1 – User Stories 6. . 2 – Planejamento 6. 3. 3 – Priorização 6. 3. 4 – Stand up Meeting . 6. 3. 5 – Pair programming . 3. 6 – Collective Code ownership Conclusão Referencias 30F 14 Referencias Bibliográficas . Atualmente tempo e dinheiro são dois bens os quais as empresas não abrem mão. Por outro lado uma dura rivalidade entre negócios do mesmo ramo trazem uma grande necessidade de aprendizado, evolução e melhorias constantes principalmente quando o produto vendido precisa ter uma conectividade direta com a qualidade.

Um software de qualidade é muito importante para empresas que disponibilizam serviços essenciais (Bancos, Empresas de crédito, empresas de câmbio e outras). Tanto os desenvolvedores quanto os clientes devem ter em mente que a qualidade de um software deve estar em conformidade com especificações e padrões de desenvolvimento, há necessidades explícitas e objetivos propostos por aquelas pessoas que produzem software, garantindo que, tanto o produto do software quanto um bom processo de desenvolvimento, atinjam níveis de qualidade mantendo sempre as necessidades dos usuários.

Para a produção de um software de qualidade é preciso ter processos voltados para esse propósito atuando desde o inicio de sua construção até a sua entrega. A conformidade com normalizações como a IS09000 são fatores importantes nesses processos principalmente para garantir a mesma consistência em qualquer software produzido. Indo além ainda existe o aprimoramento que deve ser meta já que as melhorias contínuas trazem benefícios e economias tanto nos produtos como nos próprios processos usados durante sua criação.

Palavras-chave: Qualidade, Melhorias, Normalização Capítulo 1 — As falhas AGE 4 4 afetam diretamente o suporte operacional aos clientes como também afetam o suporte administrativo já que seus produtos ão estão alinhados com as convenções internacionais de produtividade e segurança como a adequação a lei SOX e as convenções ISSO e CMMI. Após estudo de caso, enloco de forma “shadow workinã’ inúmeras falhas nos processos do cliente “Software Developer” foram levantadas.

Através de gráficos de situação algumas estratégias serão apontadas como forma de solucionar as falhas e também a geração de processos de melhorias continuas. A atual estrutura possui sérias dificuldades para geração, classificação e solução dos problemas relatados nas ligações dos clientes. Falta consistência nos chamados abertos pelo mesmo problema, mas por pessoas diferentes. As novas releases apresentam falhas quando implantadas no ambiente de produção dos clientes.

Suas operações ficam impactadas por horas. Os clientes reclamam que não possuem um suporte adequado e nem um retorno satisfatório com as causas dos problemas. Os sistemas vendidos apresentam deficiências para prover várias necessidades aos clientes que precisam seguir a lei Sarbanes-oxley. As áreas mais afetadas pela atual “crise” de processos são: Operações • Desenvolvimento e Release de softwares ?? Gestão de TI 2. — Análise das falhas Através do gráfico de Ishigawa, como descrito na figura 1 . 1, traçado um perfil dos problemas operacionais da empresa sera Software Developer. 4 negocios. Criar uma base de dados concistente de todos os problemas novos e já conhecido com o propósito de melhorias constantes e progrecivas. Garantir todos os requestos e procedimentos para novas instalações e reduzir retrabalho e custos desnecessários. 2. – Objetivo do projeto A criação do Service Desk busca gerar um ambiênte de segurança e qualidade no atendimento e no gerenciamento de roblemas relatados pelos clientes e também visa abrir um novo canal de contato, parceiria e novos negócio frente a antigos e novos clientes. 2. 3 – Requisitos Funcionais desejaveis (priorizados) O Service Desk deverá apresentar requisitos mínimos desejaveis para o início de suas funçoes: > Um banco de dados concistente e atualizado > Uma ferramenta CRM estável > Operadores Treinados Uma escala operacional autosuficiênte > Rápida inteiração entre o call management e o fault management 2. – Requisitos de Qualidade iniciais e principais O Service Desk na função de SPOC (Single point of Contact) deve er requisitos de qualidade bastante visiveis aos clientes tais como: > Atendimento no terceiro toque > “Greetings” curtos e objetivos Rapidez na abertura do 6 4 percebidos. pela visão Interna de Outras Áreas — Qualquer mudança Inspira preoculpação por parte dos que estão diratamente envolvidos o que pode trazer certos desconfortos no início, mas ao longo da maturidade do projeto suas qualidades logo serão percebibas pelos integrantes das áreas envolvidas.

Capítulo 3 – Implantando as Soluçoes 1. — Os Problemas 2. – Aplicando as soluções A implementação de um serviço de Service Desk é o item nicial dentro dos processos de melhorias e melhores práticas. um contato objetivo e profissional feito com o cliente nao é só uma tática Importante, mas é primordial para dar uma ordem aos demais acontecimentos derivados desse atendimento. O Service Desk desenvolverá um único ponto de contato com o cliente assim como mediará alguns processos internos como visto na figura 1. Dentre os problemas relacionados e analisados na Software Developer os problemas com o atendimento ao cliente, gerenciamento das chamadas e o gerenciamento das falhas são os problemas mais notórios já que o manuseio o gerenciamento desses itens não fazem parte do afim da empresa. Mas é conhe anizacáo e um bom Na linha de tempo um dos pontos muito importantes é o que tange ao treinamento dos agentes que estarão envolvidos no dia a dia do Service Desk.

Será importante definir durante a avaliação de requisitos e avaliação de custos alguns itens outros itens como o tipo de mão de obra a ser empregada no atendimento. Questões como: serão os atendentes técnicos ou não e essa é uma visão importante já que ela vai ajudar a delinear os custos de operação. 3. 3 — EAP do projeto O processo para a criação do Service Desk será dividido da seguinte forma: Infra-estrutura – Contratação (se necessário) – Treinamento e Operação.

Usando uma ferramenta EAP (Estrutura Analítica do Projeto) descrevemos na figura 3. 3 a estrutura básica do projeto do Service Desk. Após vencidas todas as etapas que precedem o lançamento do projeto para plena operabilidade incluindo os testes finais, já será possível iniciar as operações Capítulo 4 – Concideraçõeas gerais A empresa Software Developer é desenvolvedora de softwares (Fábrica de Software), mas possui sérios problemas em sua strutura de TI, tanto no que tange a infra-estrutura de TI quanto na área de desenvolvimento e governança.

A engenharia de software envolve o gerenciamento de três elementos como descrito na figura 2. 1 A criação de software, assim como outros produtos, também passa por uma cadeia de passos e processos até seu desenvolvimento final e aceitação do cliente. O aprendizado e o aprimoramento desses processos é o que constitui a maturidade da fábrica.

A maturidade de uma fábrica de software é o que vai ditar seu posicionamento no mercado uma vez que experiência e confiabilidade são requeri is para todos aqueles 0F fábrica de software que apresenta sérios problemas em sua estrutura de desenvolvimento. Uma análise demonstra que nenhum processo é reconhecidamente empregado quer seja na gestão TI quer seja na própria árvore de desenvolvimento de aplicativos.

Um processo de melhorias contínuas deverá ser implementado para possibilitar que a empresa se enquadre em moldes de qualidade sustentáveis e esteja ápta a desenvolver e entregar seus produtos dentro dos padrões Internacionais. Capitulo 5 — As falhas As novas releases apresentam falhas quando Implantadas Sarbanes-Oxley. 5. 1 – Aplicando as melhorias Um software tem um periodo de vida que vai desde o seu início passando por todos os estágios até o seu release (Entrega). Na figura 1. está um gráfico do RUP do ciclo de vida de um Software Existem quatro atividades básicas inerentes ao ciclo de criação e vida de um software: Especificação do Software Desenvolvimento do Software Validação do Software Evolução do Software Durante o ciclo de criação de um software cada passo seguido corretamente é importante para garantir que o software tenha os requisitos chaves a oferecer ue são: requisitos devem convergir para mecanismos que venham assibilitar o monitoramento das etapas de criação e assim além de garantir a qualidade na entrega também incluir-los em moldes de segurança internacionais assim como o SOX.

Assim sendo uma normativa de particionamento do projeto em unidades menores e o teste constante de cada unidade individualmente e depois testes dessa inidade no conjunto garantirá a qualidade final como visto na figura 2. 5 5. 2 — Desenvolvimento da Unidade Esta é a fase de criação da primeira unidade caso seja um software novo ou de mais uma unidade caso seja o desenvolvimento de uma nova release ou versão 5. 3 – -reste da unidade

Tem por objetivo testar a menor unidade do projeto (um componente de software que não pode ser subdividido), procurando identificar erros de lógica e de implementação em cada módulo separadamente. 5. 4 — Teste de Integração Visa descobrir erros associados às Interfaces entre os módulos quando esses são integrados para formar a estrutura do produto de software. – Ascendente (bottom-up) – Descendente (Top-down) – Sanduíche (camada do meio, bottom e up) – Big-bang (integra de uma só vez todos os módulos) Inclui diversos tipos de testes realizados na seguinte ordem: – Teste funcional 0 DF 14