Blog

FACULDADE DE TECNOLOGIA DE SÃO PAULO QUESTIONÁRIO PRODUTIVIDADE SÃO PAULO 2012 FACULDADE DE TECNOLOGIA DE SAO PAULO 1) O que é produtividade e como se obtém a produtividade? Swipe to page I 0 do de produtivo; atividade econômica em função de tempo, rea, capital, pessoal e outros fatores de produção. 3 Fecundidade, fertilidade. Na verdade, a produtividade é uma maneira de se medir o desempenho de um processo, é a razão entre as saídas de um processo com as suas entradas, ou seja, a capacidade de um processo (e também tarefa ou sistema) de produzir algo em função dos “ingredientes” que foram fornecidos.

A produtividade é obtida através da análise de indicadores envolvidos nos processos envolvidos, onde temos como fórmula geral: Produtividade = Produto Recurso o nível de produtividade através de alguns indicadores, tais como: – Ilnhas de códgo por funcionário hora (loc/h) – linhas de código fonte por funcionário por hora, excluindo-se as linhas de comentário (sloc/h) – horas por Ponto de Função (h/PF), onde a Análise de Pontos de Função (APF) mede o tamanho funcional do software, subsídios para o cálculo da produtividade do processo de desenvolvimento com base na funcionalidade ou utilidade dos programas.

Esta avaliação é realizada sob o ponto de vista do usuário que avalia o tamanho e a complexidade de um software. Nesta contagem são considerados os seguintes itens da aplicação (software): Arquivos Lógicos Internos, Arquivos de Interface Externa, Entradas Externas, Consultas Externas e Saídas Externas. Cada item deste define um peso que no final determina a quantidade de pontos de função da aplicação, para o desenvolvimento de um novo sistema ou os pontos necessários para se realizar uma manutenção em um sistema já existente.

Os pontos calculados servem para se chegar as horas totais do projeto. ) Quais as metodologias no desenvolvimento de software? Algumas das metodologias de desenvolvimento de software tradicionais (não ágeis) são: – A Metodologia “Codifica-corrige” Esta abordagem não pode ser chamada de metodologia no sentido real da palavra, mas é interessante mencioná-la, pois muitos desenvolvimentos ainda continuam utilizando esta abordagem. “Codifica-Corrige” nada mais é do que o conceito de “apenas faça funcionar”.

Inicialmente, o cliente pode fornecer uma especificação do que as isto não ser funcionar”. Inicialmente, o cliente pode fornecer uma especificação do que ele precisa, mas isto não será nada ubstancial. Esta especificação pode ser obtida através de algumas anotações, email, ou de qualquer outra fonte não muito consistente. Esta abordagem se apóia nos conhecimentos da equipe para tentar preencher as lacunas. O desenvolvimento então se inicia com ciclos rápidos de codificação seguidos por correção.

De tempos em tempos, o desenvolvedor apresenta uma nova versão (ou release) da aplicação para o cliente para obter feedback e então continua o desenvolvimento. A figura abaixo demonstra como os desenvolvedores gastam a maior parte de seu tempo codificando e efetuando correções: Metodologia A metodologia “Codifica-Corrige” possui diversos efeitos colaterais negativos: A qualidade do produto é baixa. O sistema frequentemente se transforma num código bagunçado, com falta de adaptabilidade, reuso e interoperabilidade. Os sistemas são dlfíceis de serem mantidos e aprimorados.

Os sistemas frequentemente tornam-se complicados e com baixa escalabilidade. – A Metodologia de Desenvolvimento em Cascata A metodologia de desenvolvimento em cascata foi desenvolvida pela marinha norte-americana nos anos 60 para permitir o desenvolvimento de softwares militares complexos. No modelo m cascata, o projeto segue uma série passos ordenados. Ao final de cada fase, a equipe de projeto finaliza uma revisão. O desenvolvimento não continua até que o cliente esteja satisfeito com os resultados. A figura abaixo ilustra o funcionamento desta metodologia.

Metodologa de Desenvolvimento em Cascata Se for necessário efetuar alguma modificação, voltar os passos de desenvolvimento do projeto é complicado. A metodologia em cascata é extremamente formal, como seria normal de se esperar de uma metodologia cujas raízes encontram-se no militares. Pode-se afirmar que a metodologia em cascata é baseada em ocumentos e com certeza possui uma enorme quantidade de “entregáveis” e saídas que nada mais são do que documentos. Outra característica deste modelo é o alto valor dado ao planejamento.

O forte planejamento inicial reduz a necessidade de planejamento continuo conforme o andamento do projeto. A Metodologia em Cascata funciona bem quando os requisitos do usuário são rígidos e podem ser conhecidos com antecedência. O sistema de navegação do ônibus espacial, por exemplo, pode ser um bom candidato para esta metodologia. Contudo, o foco em documentos para descrever o que os clientes e usuários ecessitam pode levar a problemas. Muito frequentemente aparecem problemas de comunicação que resultam num software de baixa qualidade.

Os documentos produzidos pelo processo de desenvolvimento podem ser perfeitos, mas o produto real pode ser defeituoso ou inutilizável De uma forma ou de outra, muitas das metodologias de desenvolvimento são variações da metodologia de Desenvolvimento em Cascata – apenas diferenciando-se uma das outras em relação à velocidade, tipos de entregáveis e flexibilidade. A metodologia de Desenvolvimento em Cascata pode funcionar bem em ambientes rígidos em em ambientes rígidos e fortemente controlados, como por exemplo, os militares, mas possui sérios inconvenientes no cenário comercial.

Existem casos onde o contratante do desenvolvimento do software se beneficia pela auditoria imposta pelos métodos do Desenvolvimento em Cascata. Estes casos incluem projetos que possuem componentes de alto risco, tais como projetos para a área médica ou de segurança pública. – A Metodologia de Prototipagem Evolutiva A metodologia de Prototipagem Evolutiva é uma abordagem que visualiza o desenvolvimento de concepções do sistema conforme o andamento do projeto. Esta metodologia baseia-se na utilização de prototipagem visual ou modelos do sistema final.

Estes modelos podem ser simples desenhos, imagens gráficas e até cópias completas em HTML do sistema esperado. Com esta abordagem visual, o cliente tem uma certeza maior do resultado final. A figura abaixo ilustra esta metodologia. Metodologia de Prototipagem Evolutiva O desenvolvimento real nao inicia até que o protótipo final seja aceito. Esta metodologia é até certo ponto bastante flexível a respeito de mudanças de requisitos; contudo, ela ainda necessidade de muito controle.

Um ponto negativo desta etodologia é que o planejamento efetivo pode ser difícil e os projetos podem ser reduzidos a um ciclo Codifica-Corrige depois que o desenvolvimento é iniciado. O aspecto de planejamento pode tornar-se um desafio, pois a equipe não tem certeza sobre quanto tempo levará o trabalho. Isto ocorre, em partes, porque o mode Isto ocorre, em partes, porque o modelo é baseado em interfaces, e não se preocupa tanto com as interdependências mais baixo nlVel entre os componentes.

Os clientes têm uma idéia de como eles querem utilizar o seu novo sistema e utilizam o protótipo como referência. O valor do protótipo, orém, nao deve ser superestimado, pois, apesar de tudo, ele não é um software funcional. Existem riscos associados com o planejamento devido à natureza interativa do desenvolvimento, mas eles são atenuados de certa forma através da prototipagem e ciclos de “releases” (ou versões) menores. Após o início do desenvolvimento, o gerente de projeto ou líder técnico deve assegurar que os desenvolvedores não utilizem a metodologia “Codifica-Corrige”.

Com uma abordagem fortemente baseada na modelagem de interfaces, a modelagem no nível de componentes pode acabar “caindo pelos lados” quando o cliente á o “tiro de largada”. A reversão para a metodologia “Codifica Corrige” é talvez mais um reflexo de mau gerenciamento do que uma fraqueza herdada da prototipagem. Se os desenvolvedores acabarem caindo na metodologia “Codifica-corrige”, o resultado será que a qualidade será difícil de manter. A Metodologia de Entregas por Estágios Esta metodologia é outra abordagem modificada da metodologia de Desenvolvimento em Cascata.

Existe um fluxo definido do inicio ao fim e as aceitações ocorrem a cada estágio. A diferença principal é que os requisitos de negócio do cliente são quebrados m grandes componentes, e estes componentes são entregues ao cliente negócio do cliente são quebrados em grandes componentes, e estes componentes são entregues ao cliente em estágios discretos. A figura abaixo demonstra esta metodologia. Metodologia de Entregas Estagiadas A utilização da metodologia de Entregas por Estágios, onde a ênfase é dada a conjuntos de temas ou funcionalidades, permite que os requisitos mais importantes sejam desenvolvidos primeiro.

O cliente obtém um sistema funcional de forma mais rápida. Esta metodologia requer um planejamento cuidadoso e não é muito propício a alterações. Os desenvolvedores precisam entender todas as interdependências entre os componentes e funções que devem ser considerados no planejamento dos estágios. Os riscos são reduzidos para equipes que utilizam entregas por estágios, pois as mesmas são efetuadas em blocos menores, porém, elas ainda devem ser controladas e monitoradas. A Metodologia RUP A metodologia Rup (Rational Unified process) é um processo que fornece uma metodologia disciplinada de desenvolvimento utilizando um conjunto de ferramentas, modelos e entregáveis. A RUP se diferencia das demais metodologias por ser proprietária de uma empresa, no caso a IBM Rational. A metodologia padronizada pode ser atrativa para grandes organizações que necessitem de uma linguagem comum e ferramentas padronizadas para toda a organização. A metodologia RUP utiliza UML (Unified Modeling Language) para comunicar os requisitos, arquiteturas e modelagens.

A UML foi originalmente criada pela Rational Software (adquirida pela IBM) é atualmente é mantida pelo OMG (Object Management Group http://www. omg (adquirida pela IBM) é atualmente é mantida pelo OMG (Object Management Group – http://www. omg. org/). Metodologa RUP A metodologia RUP é outra metodologia de desenvolvimento nterativo com foco na redução dos riscos do projeto. Ela agrega um valor real à organização que necessita manter padrões tanto para as comunicações externas quanto para a comunicação com a equipe de desenvolvimento.

Algumas características “negativas” desta metodologia são o aumento dos requisitos de documentação, a necessidade dos clientes possuírem algum entendimento de UML e ao fato de estar amarrada a software proprietário da IBM Rational. ágeis são: Programação extrema Do inglês eXtreme Programming, ou simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e ue irão desenvolver software com requisitos vagos e em constante mudança. para Isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software.

Os cinco valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback, coragem e respeito. A partir desses valores, possui como princípios básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade. Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco explícito em escopo. para isso, ecomenda-se a priorização de funcionalidades que representem maior valor possível para o negócio. Desta forma, caso seja necessário a diminuição de escopo, as funciona possível para o negócio.

Desta forma, caso seja necessário a diminuição de escopo, as funcionalidades menos valiosas serão adiadas ou canceladas. A XP incentiva o controle da qualidade como variável do projeto, pois o pequeno ganho de curto prazo na produtividade, ao diminuir qualidade, não é compensado por perdas (ou até impedimentos) a médio e longo prazo. – Scrum É um processo de desenvolvimento iterativo e incremental para erenciamento de projetos e desenvolvimento ágil de software. Apesar de a palavra não ser um acrônimo, algumas empresas que implementam o processo a soletram com letras maiúsculas como SCRIJM.

Isto pode ser devido aos primeiros artigos de Ken Schwaber, que capitalizava SCRIJM no título. Scrum não é um processo prescribente, ou seja, ele nao descreve o que fazer em cada situação. Ele é usado para trabalhos complexos nos quais é impossível predizer tudo o que irá ocorrer. Apesar de Scrum ter sido destinado para gerenciamento de projetos de software, ele pode ser utilizado em equipes de anutenção de software ou como uma abordagem geral de gerenciamento de projetos/programas. 4) Quais métodos de produtividade sua empresa utiliza?

Eu trabalho em uma empresa que presta serviços na área de gestão documental. Dessa forma, para algumas funções no setor produtivo são analisados indicadores de produtividade, entre eles posso destacar os seguintes: – Escaneador: ou digitalizador de documentos, é analisado a quantidade de documentos di italizados por hora para cada É necessário avaliar o um dos colaboradores e e cada um dos colaboradores e equipamentos. É necessaria avaliar equipamento utilizado, pois eles possuem especificações diferentes de velocidade. Digitador: para esse colaborador é analisado a quantidade de caracteres digitador por hora, mas é necessário avaliar a complexidade do documento a ser digitado, os campos de indexação e seus tipos (Alfanumérico, Numérico, Data, etc. ) – Preparador: para esse colaborador é avaliado a quantidade de caixas do tamanho padrão Box que ele consegue organizar por hora. Da mesma forma, alguns fatores devem ser considerados, como complexidade dos documentos, organização prévia, etc. De uma forma geral, as métricas de produtividade em minha mpresa baseiam-se em mão de obra, portanto, a análise é feita pela produtividade hora/homem.

Mas, mesmo em casos mais simples, existem outros fatores a serem considerados na análise para se obter informações reais. BIBLIOGRAFIA WIKIPÉDIA. Métrica de software. Disponível em: . Acesso em: 12 de fev. 2012. WIKIPÉDIA. scrum. Disponível em: . Acesso em: 12 de fev. 2012. WIKIPÉDIA. Programação extrema. Disponível em: . Acesso em: 12 MICHAELIS. Produtividade. Disponível em: . Acesso em: 12 de fev. 2012. ANDREY GOMES. Metodolo ias de desenvolvimento de software. Disponível em: PAGF 10