You are on page 1of 9

Curso de Mestrado em Cincia da Computao

Universidade Federal do Mato Grosso do Sul Disciplina de Engenharia de Software


Prof. Dr. Marcelo A. S.Turine

Alunos: Eduardo F. Damasceno Rosenilda Marques da Silva Jos Barbosa D. Junior Simone Rodgheri Este resumo se refere aos artigos de Bary Boehms e de Jhon S. Reel, ambos da revista IEEE e correlatas ao livro texto adotado de Roger S. Pressman ,Software Engeneering 5 edio, o qual retratam fatores crticos para o projeto de software

I. GERNCIA DE PROJETO
SEGUNDO [PRES92]A
PRIMEIRA CAMADA DO GERNCIA DE PROJETO, A DE ENGENHARIA DE ASSIM CHAMADA EM VEZ DE

PROCESSO

SOFTWARE, UMA CAMADA,

ETAPA OU ATIVIDADE, PORQUE ELA ABRANGE TODO O PROCESSO DE DESENVOLVIMENTO, DO COMEO AO FIM.

Para se conduzir um projeto de software bem sucedido, devemos ter as atividades que envolvem medio, estimativa, anlise de risco, programao de atividades, monitorao e controle. Mtrica A medio possibilita que os profissionais da gerncia de projetos entendam melhor o processo de engenharia de software, e o produto que ela ir produzir. A produtividade e a qualidade podem ser definidas atravs das medidas(mtricas) que podem ser diretas ou indiretas. Por exemplo medidas do resultado do desenvolvimento de software como uma funo do esforo aplicado a medida da adequao ao uso do resultado que produzido. Entre as medidas diretas do produto incluem as linhas de cdigo (LOC) produzidas velocidades de execuo, tamanho de memria defeitos registrados ao longo de certo espao de tempo como exemplo pode-se citar: ou defeito) Mtricas orientadas ao tamanho (medidas de pessoa/ms

Mtricas Orientadas funo (mede o domnio da informao, avaliao subjetiva da complexidade do problema)

Curso de Mestrado em Cincia da Computao


Universidade Federal do Mato Grosso do Sul Disciplina de Engenharia de Software
Prof. Dr. Marcelo A. S.Turine

As medidas indiretas do produto incluem funcionalidade, qualidade, complexidade, eficincia confiabilidade, manutenibilidade, como exemplo pode-se citar: Medida de qualidade de software (onde so tomadas as decises para correo manuteno, integridade e usabilidade). Segundo [PRES92] O software medido por cinco razes : - Indicar a qualidade do produto; - Avaliar a produtividade das pessoas que produzem o produto; - Avaliar os benefcios (avaliando-se qualidade/produtividade) derivados de mtodos e ferramentas de softwares; - Para se ter base para estimativa; - Ajudar a justificar os pedidos de novas ferramentas ou treinamentos adicionais Estimativa uma da fases fundamentais do gerenciamento de projeto de software, o planejamento, onde so executadas estimativas de esforos humanos, durao cronolgica do projeto, custo. Existem algumas tcnicas de estimativas por exemplo: A BYL (Before you leap) DECPLA

Anlise dos riscos Os ricos que podem fazer com que em projeto no se desenvolva como planejado. A anlise dos riscos inicia-se pela identificao e seguida pela projeo e avaliao, estas atividades definem cada risco, sua probabilidade de ocorrncia e seu impacto projetado.

II. PROGRAMAO DE ATIVIDADES OU CRONOGRAMA


A determinao do cronograma de um projeto de software se assemelha ao desenvolvimento de um produto multitarefa, portanto pode ser usado ferramentas e tcnicas destes para determinao de um cronograma de software, tais como PERT (Program Evolution and Review Techique) e COM (Critical Path Method). Tanto o PERT quanto CPM so ferramentas quantitativas, que permitam ao planejador de software, determinar o caminho crtico ( a cadeia de tarefas que determina a durao do projeto), estabelecer as estimativas de tempo mais provveis para tarefas individuais a o aplicar modelos estatsticos, calcular limite de tempo que definam uma janela de tempo para uma tarefa em particular.

Curso de Mestrado em Cincia da Computao


Universidade Federal do Mato Grosso do Sul Disciplina de Engenharia de Software
Prof. Dr. Marcelo A. S.Turine

Monitorao ou controle - Plano de Projeto de Software um documento relativamente breve que se destina a um pblico diverso. Ele deve comunicar o escopo e os recursos a administrao, ao pessoal tcnico e ao cliente do software; ele deve definir os riscos sugerir tcnicas para evit-los; deve definir custos e prazos para as revises administrativas; oferecer uma abordagem global ao desenvolvimento do software para todas as pessoas envolvidas no projeto.

Segundo John S Reel (trident data system) em artigo para IEEE


As caractersticas do desenvolvimento de software implica em uma complicada administrao. O problema bsico da computao o domnio da complexidade. A mistura de assuntos volteis na administrao contribui muito para um grande ndice de fracassos nos projetos de desenvolvimento de software, elementos como a pesquisa analtica na anlise, o designo das metodologias, projetos de administrao e qualidade de software, so aliados tecnolgicos importantes. Existem cinco fatores que so essncias para determinar se um projeto de software prospero: 12345Comear com o p direito; Manter o Impulso; Progresso de Rastro; Tomar decises inteligentes; Instituir a Ps anlise;

Existem 10 sinais que um projeto tende a falhar: 12345678910Os gerentes de projetos no entendem as necessidades do usurio; O mbito do projeto no bem definido; As mudanas so administradas de maneira pobre; As mudanas da tecnologia escolhida; Mudanas da necessidade empresarial; Prazos finais so irreais; Os usurios so resistentes; O Patrocnio esta perdido; A Falta de pessoas com habilidades apropriadas no projeto; Os Gerentes ignoram as melhores prticas e lies apreendidas;

O primeiro objetivo a se adquirir em um projeto fora ter um bom comeo colocar todo mundo no mesmo Clima de desenvolvimento com as mesmas expectativas, havendo um comprometimento e dilogo de ambas as partes, para fixao de objetivos e expectativas realistas. As pessoas, equipes tem de estar motivadas e comprometidas com o projeto. Deve-se tomar alguns cuidados para montar o equipe certo, tais como:

Curso de Mestrado em Cincia da Computao


Universidade Federal do Mato Grosso do Sul Disciplina de Engenharia de Software
Prof. Dr. Marcelo A. S.Turine

Pessoas comprometidas; Bom relacionamento; Personalidades compatveis; Hbitos de trabalho em conjunto;

Para melhorar a administrao do equipe pode ser necessrio separ-los em grupos de trabalhos com horas diferentes, devido as diferentes personalidades existentes no mesmo. H tambm a necessidade de envolvimento com o cliente, pois isso aumenta as chances de se desenvolver um produto que atenda as suas exigncias. necessrio tambm motivar o equipe, dar a eles o que eles precisam, seja com o ambiente o pessoalmente, para que eles possam enfocar no trabalho e esquecer do resto do Mundo. Manter a motivao e muito importante, isto pode ser feito atravs de uma boa estrutura, com investimentos constantes em equipamentos, salrios, gratificaes, etc; porm essas decises no devem ser tomadas sozinhas tem que haver o envolvimento da equipe inteiro nessas decises, para que sejam realmente as adequadas. Manter o Impulso O Clima muito importante, pois ajuda a manter sempre um bom ambiente de desenvolvimento, para que isso ocorra necessrio manter a atrao das pessoas monitorando a qualidade com a expectativa de excelncia e administrando mais o produto do que as pessoas. Atrito Necessrio que o Gerente do projeto esteja sempre atualizado sobre tudo que esta acontecendo no ambiente de desenvolvimento, usando um bode expiatrio, que a qualquer sinal de atrito o avise, para que o mesmo possa ter tempo hbil para resolver o problema ou substituir a pessoa a tempo. Qualidade Devem ser estabelecidos procedimentos de controle, verificao e revises do padro de qualidade, antes de qualquer tipo de desenvolvimento, para que se for necessrio algumas pequenas mudanas, essas no venha causar uma avalanche. Administrao A base da Administrao administrar mais o produto do que as pessoas, pois as pessoa sabem o que devem fazer, necessrio apenas monitor-las e enfoc-las em produzir um produto de qualidade, pois afinal de contas o produto que voc esta vendendo.

Curso de Mestrado em Cincia da Computao


Universidade Federal do Mato Grosso do Sul Disciplina de Engenharia de Software
Prof. Dr. Marcelo A. S.Turine

Progresso de Rastro O desenvolvimento de software diferente de uma construo comum, pois no possvel ver tudo e tocar nos pequenos pedaos que esto sendo montados, colados, pregados, durante a construo, pois o software se inicia com um Modelo conceitual e resulta em uma aplicao, portanto fica difcil definir tambm quanto tempo determinado mdulo do sistema vai demorar. Ento em relao ao horrio temos que saber como esta o progresso, para isso existem metodologias que ajudam a localizar o progresso, utilizando-as como uma pessoa (integrante do equipe) de alto nvel e seguindo isto como base. Tomar decises Inteligentes Decises inteligentes separam os lderes de projeto do sucesso ou fracasso. Por exemplo: se voc precisar de bibliotecas de comunicao para um determinado protocolo, busque as que esto no mercado, j prontas e testadas, no tente fazer as suas prprias, isto leva tempo e far com que no mximo voc receba um elogio e no pior caso o fracasso do projeto. No escolha uma tecnologia sem antes fazer uma anlise tcnica da mesma. A Ps- Anlise um processo institucionalizado por algumas companhias para apreender com os enganos, ou seja entender o que aconteceu de bom ou de ruim durante um projeto, se voc no fizer isto est sentenciado a repetir o mesmo erro. A Ps-Anlise o ajudar a desenvolver melhor seus horrios, a definir um perfil no s do seu equipe mas da sua companhia de desenvolvimento. O livro de Neal Whitten, Administrando Desenvolvimento de Projetos de software, oferece seis passos para executar a Ps-Anlise: Declarar o intento: anunciar que a reviso ser seguida e definir os tpicos do procedimentos; Selecionar os participantes: escolher os participantes principais de cada grupo; Preparar a Reviso: juntar os dados aps o termino do projeto; Conduzir a reviso: alguns dias de reunio so suficientes para ver a reviso e preparar as listas do que saio certo e errado; Apresentar s resultados: os participantes apresentam os resultados para que o desenvolvimento ande junto com a liderana executiva; Adotar as Recomendaes: a companhia deve implementar as recomendaes nos seus projetos.

Curso de Mestrado em Cincia da Computao


Universidade Federal do Mato Grosso do Sul Disciplina de Engenharia de Software
Prof. Dr. Marcelo A. S.Turine

III. SEGUNDO O ARTIGO DE BHOEMS


O processo de desenvolvimento do software corresponde ao conjunto de fase interligadas (requisitos do sistema, requisitos do software, projeto preliminar, projeto detalhado, codificao, unidades de teste, teste de aceitao de software, teste de aceitao de sistema, que sofrem uma constante anlise pelas companhias desenvolvedores, organizaes governamentais, grupos de padronizao, para atingir todas as necessidades do projeto de software. Infelizmente o modelo em cascata, se tornou to elaborado que as pessoas passaram a achar que ele no esclarecia as situaes do projeto. Por exemplo: uma consistente e abrangente especificao dos requisitos de software esbarra em problemas: 1. Prottipo; 2. Um bom plano: Investigao detalhada; 3. Solues inflexveis: Dificultam otimizaes futuras; 4. Risco Elevado na concluso do software: modelo incremental; 5. Falta de declarao do Objetivo inicial: em relao a atualizaes futuras; As dificuldades com os modelos de desenvolvimento tem deixado os desenvolvedores frente a algumas difceis alternativas, como: 1. 2. 3. 4. 5. 6. 7. Gerenciar Riscos; Gerenciar a Reutilizao; Gerenciar Heranas; Gerenciar a Demonstrao; Gerenciar os custos do projeto; Gerenciar os Prazos; Gerenciar as atualizaes;

Muitos modelos de desenvolvimento dificultam ainda mais o processo, do que deveriam ajudar, porm as empresas acreditam que valem mais utiliz-los mesmo com falhas do que no utiliz-los. Vrias verses do Modelo Espiral no se encaixavam, as pessoas envolvidas entravam em contradio em trs pontos crticos: 1. 2. 3. Objetivo do Ciclo de Vida (LCO) Arquitetura do Ciclo de Vida (LCA) Capacidade Operacional Inicial (IOC)

Curso de Mestrado em Cincia da Computao


Universidade Federal do Mato Grosso do Sul Disciplina de Engenharia de Software
Prof. Dr. Marcelo A. S.Turine

LCO Objetivo de Ciclo de Vida Determinao dos reais objetivos para o sistema disposto nas seguintes fases: 1. Determinar o maior objetivo do sistema: quais decises devem ser tomadas; 2. Uma viso do trabalho: representar os objetivos nas melhores formas de representao como prototipao, DFDS, DE, Lay-out de telas e outras representaes relevantes; 3. Requisitos do sistema : Registrar os detalhes dos requisitos do sistema; 4. Arquitetura do Sistema e do Software: Que define claramente se a arquitetura escolhida suporta as necessidades do sistema. Sendo assim voc pode cancelar, reestruturar ou prosseguir com o projeto. 5. O Plano de ciclo de vida: Outro ponto crtico para identificar o(s) modelo(s) de processo que se pode usar (inclusive os hbridos), visando a satisfazer as necessidades do sistema: O plano deve ser simples, porm dever conter as seguintes fases: Os objetivos: Porque est sendo usado? Os Pontos Principais e Prazos: Quem Poder executar as Funes e quando? As responsabilidades: Quem se responsabiliza pelas funes? A Metodologia utilizada: Quem far o controle e o gerenciamento ? Os Recursos : Quais so os Recursos para desenvolver um Projeto? 6. Verificar a Viabilidade do Projeto: simular, analisar, testar, e outras tcnicas para verificar a estabilidade do sistema, concluir se este um sistema bom ou no. O LCA Arquitetura de Ciclo de Vida Define a arquitetura do sistema e do software, isso consiste em definir os componentes, os conectores e as configuraes (Combinaes entre componentes e conectores) e as restries dos mesmos. Outras caractersticas principais so: Especificao de um software comercial de pacote; Especificao dos nveis de qualidade: Tempo de Resposta; Segurana; Confiabilidade; Que so pontos significativos para o gerenciamento da arquitetura.

Curso de Mestrado em Cincia da Computao


Universidade Federal do Mato Grosso do Sul Disciplina de Engenharia de Software
Prof. Dr. Marcelo A. S.Turine

- Identificar a evoluo da arquitetura para reduzir as chances dela ficar obsoleta. As coisas mais importantes para os investidores alcanarem so: - Viabilidade Razovel (consistncia e integridade conceitual de outros elementos de modelo); - Os investidores tem consentimento de que o LCA compatvel com os objetivos do sistema; - O Plano vai tentar cobrir o maior nmero de riscos do sistema; Se o sistema passar por estas fases sem identificar os principais riscos, provavelmente este projeto ir ao desastre. As Semelhanas e Diferenas entre o LCO e o LCA O foco do LCA e do LCA est em especificaes de requisitos que antecipem e acomodem as evolues do sistema. As especificaes so dirigidas ao risco e no perfeio. Para diminuir o risco da interface de usurio e melhorar interao com o usurio recomendado a utilizao de prottipos. Os modelos possuem pontos principais e falhas, podemos descartas as falhas e aproveitar os pontos principais. IOC - Capacidade Operacional Inicial Caso o projeto no for bem feito, este pode acarretar na insatisfao do cliente. A preparao do software inclui o uso operacional, as licenas, a converso dos dados, a documentao, os direitos e o reuso do software, necessitando de um teste operacional apropriado. Local apropriado: Preparao dos materiais, instalaes e equipamentos; O usurio, operador, e o responsvel pela manuteno devem ser treinados para as operaes de uso e manuteno; O IOC tambm dirigido pelo risco. Voc pode utilizar a combinao dos 3 marcos, para criar verses aperfeioadas do sistema, ou esforos de engenharia. Conseguindo definir os custos e o cronograma. Para evitar problemas como apresentando nos modelos anteriores, um projeto de software necessita de um misto de flexibilidade e disciplina. O gerenciamento contido no LCO, LCA e IOC, agrupados para resolver situaes de softwares especficos e ainda sobra princpios (idias) suficientes para aplicar em muitos projetos de software, porque estes do nfase no comprometimento de investidores para compartilhar os objetivos do sistema.

Curso de Mestrado em Cincia da Computao


Universidade Federal do Mato Grosso do Sul Disciplina de Engenharia de Software
Prof. Dr. Marcelo A. S.Turine

Eles podem prover uma colaborao de atividades na sua organizao para realizao de um software bem sucedido para ajudar pessoas e organizaes a serem mais competitivas.

You might also like