U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2001/02 D EP. I NFORMÁTICA DESENVOLVIMENTO DE...

UNIVERSIDADE DO MINHO

ESCOLA DE ENGENHARIA 2001/02 DEP. INFORMÁTICA

DESENVOLVIMENTO DE DESENVOLVIMENTO DE SISTEMAS EMBEBIDOS SISTEMAS EMBEBIDOS

(MESTRADO EM INFORMÁTICA) (MESTRADO EM INFORMÁTICA)

- SESSÃO 3: Projecto de Software -- SESSÃO 3: Projecto de Software -

JOÃO MIGUEL FERNANDESJOÃO MIGUEL FERNANDESEmail: [email protected]: [email protected]

URL: http://www.di.uminho.pt/~miguelURL: http://www.di.uminho.pt/~miguel

© 2

001

UM

/EE

/DI/

JMF

2

SumárioSumário

1. Enquadramento1. Enquadramento

2. Mitologia do Software2. Mitologia do Software

3. Qualidade no Software3. Qualidade no Software

4. Gestão de Projectos4. Gestão de Projectos

© 2

001

UM

/EE

/DI/

JMF

3

1. Enquadramento 1. Enquadramento (1/2)(1/2)

Objectivos deste móduloObjectivos deste módulo– Apresentar os mitos mais comuns associados ao Apresentar os mitos mais comuns associados ao

software.software.– Identificar os aspectos mais importantes que o Identificar os aspectos mais importantes que o

software deve ter, para se conseguir um produto de software deve ter, para se conseguir um produto de qualidade.qualidade.

– Discutir alguns problemas associados à gestão de Discutir alguns problemas associados à gestão de projectos.projectos.

Audiência alvoAudiência alvo– licenciados (com ou sem formação na área das TSI) licenciados (com ou sem formação na área das TSI)

com responsabilidades e experiência comprovada com responsabilidades e experiência comprovada (desejável!) na análise, concepção e implementação (desejável!) na análise, concepção e implementação de sistemas baseados em softwarede sistemas baseados em software

© 2

001

UM

/EE

/DI/

JMF

4

1. Enquadramento 1. Enquadramento (2/2)(2/2)

Bibliografia recomendadaBibliografia recomendada– Brooks F.P. (1995). “Brooks F.P. (1995). “The Mythical Man-MonthThe Mythical Man-Month”. ”.

Addison Wesley. Addison Wesley. ISBN 0-201-83595-9ISBN 0-201-83595-9..

– Ghezzi C., Jazayeri M., Mandrioli D. (1991). Ghezzi C., Jazayeri M., Mandrioli D. (1991). ““Fundamentals of Software EngineeringFundamentals of Software Engineering”. Prentice-”. Prentice-Hall. Hall. ISBN 0-13-818204-3ISBN 0-13-818204-3..

– Pressman R.S. (1997). “Pressman R.S. (1997). “Software Engineering: A Software Engineering: A Practitioner's ApproachPractitioner's Approach”. McGraw-Hill, 4th ed. ”. McGraw-Hill, 4th ed. ISBN 0-07-ISBN 0-07-

052182-4052182-4..

© 2

001

UM

/EE

/DI/

JMF

5

Mitologia do softwareMitologia do software– Muitas das causas subjacentes às incorrecções de software Muitas das causas subjacentes às incorrecções de software

decorrem da existência de uma mitologia sobre o software decorrem da existência de uma mitologia sobre o software que foi sendo “desenvolvida” ao longo das décadas e que foi sendo “desenvolvida” ao longo das décadas e desde o surgimento do primeiro programa de computador.desde o surgimento do primeiro programa de computador.

Mitos do gestor de projectoMitos do gestor de projecto– Os gestores de projectos de software, tal como os gestores Os gestores de projectos de software, tal como os gestores

de outras áreas, estão sujeitos a pressões para manterem de outras áreas, estão sujeitos a pressões para manterem os orçamentos sob controlo, para evitarem que os prazos os orçamentos sob controlo, para evitarem que os prazos deslizem e para aumentarem os índices de qualidade, deslizem e para aumentarem os índices de qualidade, provocando a construção mental de vários mitos que lhes provocando a construção mental de vários mitos que lhes aliviam aparentemente a pressão, nem que seja aliviam aparentemente a pressão, nem que seja temporariamente.temporariamente.

2. Mitologia do Software 2. Mitologia do Software (1/15)(1/15)

© 2

001

UM

/EE

/DI/

JMF

6

Mito #1 do gestor de projectoMito #1 do gestor de projecto– ““Já descobri um livro com todos as normas e regras para Já descobri um livro com todos as normas e regras para

construir software. Acho que isto é o necessário e o construir software. Acho que isto é o necessário e o suficiente para que a minha equipa desenvolva suficiente para que a minha equipa desenvolva correctamente software.”correctamente software.”

RealidadeRealidade– O tal livro pode até, eventualmente, existir mas será O tal livro pode até, eventualmente, existir mas será

efectivamente utilizado?efectivamente utilizado?– Estão os projectistas de software conscientes da sua Estão os projectistas de software conscientes da sua

existência? ou só o gestor de projecto conhece o livro?existência? ou só o gestor de projecto conhece o livro?– O seu conteúdo reflecte as práticas mais recentes de O seu conteúdo reflecte as práticas mais recentes de

engenharia de software? é o seu conteúdo completo?engenharia de software? é o seu conteúdo completo?– Na grande maior parte das vezes a resposta a estas Na grande maior parte das vezes a resposta a estas

questões é “NÃO!”questões é “NÃO!”


© 2

001

UM

/EE

/DI/

JMF

7

Mito #2 do gestor de projectoMito #2 do gestor de projecto– ““A minha equipa possui uma ferramenta poderosíssima A minha equipa possui uma ferramenta poderosíssima

para desenvolver software. É que eu gastei uma fortuna para desenvolver software. É que eu gastei uma fortuna com os computadores que lhes comprei recentemente”.com os computadores que lhes comprei recentemente”.

RealidadeRealidade– É preciso muito mais do que o último modelo de É preciso muito mais do que o último modelo de

computador para realizar um desenvolvimento de computador para realizar um desenvolvimento de software com elevados índices de qualidade.software com elevados índices de qualidade.

– As ferramentas de CASE são muito mais importantes do As ferramentas de CASE são muito mais importantes do que o hardware para atingir uma boa qualidade e que o hardware para atingir uma boa qualidade e produtividade.produtividade.

– Apesar disto, a maior parte das equipas de Apesar disto, a maior parte das equipas de desenvolvimento não utiliza nenhuma ferramenta de desenvolvimento não utiliza nenhuma ferramenta de CASE.CASE.


© 2

001

UM

/EE

/DI/

JMF

8

Mito #3 do gestor de projectoMito #3 do gestor de projecto– ““Se eu vir que o desenvolvimento do software começa a Se eu vir que o desenvolvimento do software começa a

atrasar-se em relação ao previsto, eu contrato, a meio do atrasar-se em relação ao previsto, eu contrato, a meio do projecto, mais uma pessoa para integrar a equipa de projecto, mais uma pessoa para integrar a equipa de desenvolvimento”.desenvolvimento”.

RealidadeRealidade– O desenvolvimento de software não é estritamente O desenvolvimento de software não é estritamente

mecanicista, tal como uma linha de montagem de mecanicista, tal como uma linha de montagem de automóveis.automóveis.

– Adicionar pessoas a um projecto de software atrasado Adicionar pessoas a um projecto de software atrasado provoca ainda mais atrasos.provoca ainda mais atrasos.

– Juntar pessoas novas à equipa exige que as outras percam Juntar pessoas novas à equipa exige que as outras percam tempo a passar informação às recém chegadas.tempo a passar informação às recém chegadas.

– É possível, no entanto, acrescentar pessoas, com É possível, no entanto, acrescentar pessoas, com resultados positivos, desde essa tarefa seja realizada de resultados positivos, desde essa tarefa seja realizada de forma planeada.forma planeada.


© 2

001

UM

/EE

/DI/

JMF

9

Mitos do clienteMitos do cliente– Um cliente que solicita o desenvolvimento de um Um cliente que solicita o desenvolvimento de um

determinado programa de software pode serdeterminado programa de software pode ser o colega da mesa do lado,o colega da mesa do lado, uma outra equipa técnica (como o departamento de venda), uma outra equipa técnica (como o departamento de venda), uma outra empresa que firmou um contrato de aquisição de uma outra empresa que firmou um contrato de aquisição de

um novo produto de software.um novo produto de software.

– Em muitas circunstâncias, o cliente acredita na mitologia Em muitas circunstâncias, o cliente acredita na mitologia do software, porque os gestores de projectos de software do software, porque os gestores de projectos de software e mesmo os elementos da equipa de desenvolvimento não e mesmo os elementos da equipa de desenvolvimento não se preocupam em esclarecer os clientes.se preocupam em esclarecer os clientes.

– Os mitos levam o cliente a criar falsas expectativas e, em Os mitos levam o cliente a criar falsas expectativas e, em última instância, podem levar à insatisfação para com o última instância, podem levar à insatisfação para com o fornecedor do produto de software encomendado.fornecedor do produto de software encomendado.


© 2

001

UM

/EE

/DI/

JMF

10

Mito #1 do clienteMito #1 do cliente– ““Uma descrição genérica daquilo que eu pretendo é Uma descrição genérica daquilo que eu pretendo é

mais do que suficiente para que o meu fornecedor mais do que suficiente para que o meu fornecedor comece a bater umas linhas de código. Posso sempre comece a bater umas linhas de código. Posso sempre completar a minha ideia mais tarde”.completar a minha ideia mais tarde”.

RealidadeRealidade– Um incorrecto levantamento de requisitos é a principal Um incorrecto levantamento de requisitos é a principal

causa da má qualidade do software.causa da má qualidade do software.– É crucial uma descrição formal e detalhada da É crucial uma descrição formal e detalhada da

informação a manipular, das funcionalidades a informação a manipular, das funcionalidades a disponibilizar, do desempenho a atingir, das constrições disponibilizar, do desempenho a atingir, das constrições impostas, das interfaces, ...impostas, das interfaces, ...

– Só após um diálogo conscientemente executado com o Só após um diálogo conscientemente executado com o cliente, todos estes requisitos podem ser levantados.cliente, todos estes requisitos podem ser levantados.


© 2

001

UM

/EE

/DI/

JMF

11

Mito #1 do clienteMito #1 do cliente


© 2

001

UM

/EE

/DI/

JMF

12

Mito #2 do clienteMito #2 do cliente– ““Os requisitos do produto que encomendei vão mudar Os requisitos do produto que encomendei vão mudar

ao longo do seu desenvolvimento, mas isso não ao longo do seu desenvolvimento, mas isso não constitui um problema, porque o produto que constitui um problema, porque o produto que contratualizei é software e, como tal, é altamente contratualizei é software e, como tal, é altamente flexível”.flexível”.

RealidadeRealidade– É verdade que os requisitos se alteram com o tempo, É verdade que os requisitos se alteram com o tempo,

no entanto o impacto das mudanças varia com o no entanto o impacto das mudanças varia com o instante do tempo em que são introduzidas.instante do tempo em que são introduzidas.

– À medida que o tempo de desenvolvimento aumenta, À medida que o tempo de desenvolvimento aumenta, o impacto das alterações de requisitos no custo do o impacto das alterações de requisitos no custo do produto final aumenta exponencialmente.produto final aumenta exponencialmente.


© 2

001

UM

/EE

/DI/

JMF

13



© 2

001

UM

/EE

/DI/

JMF

14



© 2

001

UM

/EE

/DI/

JMF

15

Mitos da equipa de desenvolvimentoMitos da equipa de desenvolvimento– A mitologia do software tem sido um legado das várias A mitologia do software tem sido um legado das várias

gerações de programadores de software que têm construído gerações de programadores de software que têm construído uma cultura, nem sempre, condizente com a realidade.uma cultura, nem sempre, condizente com a realidade.

– No início da informática, a programação era considerada No início da informática, a programação era considerada uma arte e, como tal, devia ser executada por habilidosos uma arte e, como tal, devia ser executada por habilidosos com veia , sem regras, nem técnicas bem definidas, mas sim com veia , sem regras, nem técnicas bem definidas, mas sim ao sabor do vento dos apetites de quem bate código em ao sabor do vento dos apetites de quem bate código em cada momento.cada momento.

– Esta atitude é o principal inimigo da engenharia de software Esta atitude é o principal inimigo da engenharia de software e de qualidade do software.e de qualidade do software.

– Os velhos hábitos ainda se mantém e têm sido muito difíceis Os velhos hábitos ainda se mantém e têm sido muito difíceis de combater.de combater.

– Compete às gerações mais novas, com formação formal em Compete às gerações mais novas, com formação formal em engenharia de software, contrariar a prática ainda corrente.engenharia de software, contrariar a prática ainda corrente.


© 2

001

UM

/EE

/DI/

JMF

16

Mito #1 da equipa de desenvolvimentoMito #1 da equipa de desenvolvimento– ““Depois do código estar todo batido e a funcionar, a nossa Depois do código estar todo batido e a funcionar, a nossa

tarefa está concluída”.tarefa está concluída”. RealidadeRealidade

– Quanto mais cedo, no fluxo de projecto, se começa a bater Quanto mais cedo, no fluxo de projecto, se começa a bater código, mais difícil vai ser pôr o programa a funcionar.código, mais difícil vai ser pôr o programa a funcionar.

– Dados da indústria de produção de software nos E.U.A. Dados da indústria de produção de software nos E.U.A. indicam que entre 50% a 70% do esforço total despendido indicam que entre 50% a 70% do esforço total despendido no desenvolvimento de um novo produto de software no desenvolvimento de um novo produto de software corresponde ao suporte técnico ao cliente após a entrega corresponde ao suporte técnico ao cliente após a entrega da primeira versão, para eliminar erros e falhas que a da primeira versão, para eliminar erros e falhas que a equipa de desenvolvimento não foi capaz de detectar equipa de desenvolvimento não foi capaz de detectar internamente.internamente.


© 2

001

UM

/EE

/DI/

JMF

17

Mito #2 da equipa de desenvolvimentoMito #2 da equipa de desenvolvimento– ““Não é possível realizar testes de qualidade antes de Não é possível realizar testes de qualidade antes de

finalizar completamente a implementação da finalizar completamente a implementação da totalidade do código do programa de software”.totalidade do código do programa de software”.

RealidadeRealidade– Um dos mais eficazes métodos de controlo de Um dos mais eficazes métodos de controlo de

qualidade no software e que podem ser aplicados qualidade no software e que podem ser aplicados desde o início do projecto correspondem à revisão desde o início do projecto correspondem à revisão técnica formal do código.técnica formal do código.

– A execução de uma fase de teste em paralelo com a A execução de uma fase de teste em paralelo com a de desenvolvimento é uma das recomendações de desenvolvimento é uma das recomendações básicas para controlar desde o seu início o básicas para controlar desde o seu início o desenvolvimento de software.desenvolvimento de software.


© 2

001

UM

/EE

/DI/

JMF

18

Mito #3 da equipa de desenvolvimentoMito #3 da equipa de desenvolvimento– ““O único O único deliverable deliverable de um projecto de software é o de um projecto de software é o

programa de software, propriamente dito, a funcionar”.programa de software, propriamente dito, a funcionar”. RealidadeRealidade

– Um programa de software a funcionar constitui somente Um programa de software a funcionar constitui somente um dos um dos deliverables deliverables do projecto.do projecto.

– A documentação do software e do próprio projecto A documentação do software e do próprio projecto constitui uma base sólida para assegurar o sucesso no constitui uma base sólida para assegurar o sucesso no desenvolvimento de projectos de software, bem como desenvolvimento de projectos de software, bem como um precioso auxílio para as tarefas de manutenção que um precioso auxílio para as tarefas de manutenção que se apresentem no futuro.se apresentem no futuro.


© 2

001

UM

/EE

/DI/

JMF

19

ConclusõesConclusões

– Muitos profissionais de software acabam por reconhecer Muitos profissionais de software acabam por reconhecer a falaciosidade destes mitos.a falaciosidade destes mitos.

– Infelizmente as práticas correntes continuam a querer Infelizmente as práticas correntes continuam a querer fazer com que os mitos sejam reais, mesmo quando a fazer com que os mitos sejam reais, mesmo quando a realidade mostra, de uma forma clara e evidente, aos realidade mostra, de uma forma clara e evidente, aos gestores de projecto e às equipas de desenvolvimento, gestores de projecto e às equipas de desenvolvimento, que o caminho a percorrer tem que ser, inevitavelmente, que o caminho a percorrer tem que ser, inevitavelmente, outro; ou seja, a negação dos mitos.outro; ou seja, a negação dos mitos.

– O reconhecimento da realidade do software é o primeiro O reconhecimento da realidade do software é o primeiro passo em direcção a uma correcta formulação de passo em direcção a uma correcta formulação de métodos e técnicas efectivamente pragmáticos para o métodos e técnicas efectivamente pragmáticos para o desenvolvimento, com sucesso, de software.desenvolvimento, com sucesso, de software.


© 2

001

UM

/EE

/DI/

JMF

20

3. Qualidade no Software 3. Qualidade no Software (1/18)(1/18)

- factores críticos -- factores críticos -

PessoasPessoas– qualificação profissionalqualificação profissional– estabilidade da equipa de desenvolvimentoestabilidade da equipa de desenvolvimento

TecnologiaTecnologia– métodos e metodologias utilizadosmétodos e metodologias utilizados– ambientes e linguagens de programaçãoambientes e linguagens de programação

Capacidade de gestãoCapacidade de gestão– gestão dos recursos humanosgestão dos recursos humanos– gestão dos projectos (actividades de desenvolvimento)gestão dos projectos (actividades de desenvolvimento)

© 2

001

UM

/EE

/DI/

JMF

21


- aspectos de qualidade -- aspectos de qualidade -

CorrecçãoCorrecção

– Um programa de software diz-se Um programa de software diz-se correctocorrecto se se comportar de se se comportar de acordo com a especificação das funcionalidades que ele deve acordo com a especificação das funcionalidades que ele deve disponibilizar.disponibilizar.

– Esta definição assume que a especificação se encontra Esta definição assume que a especificação se encontra disponível e que é possível determinar, sem ambiguidades, disponível e que é possível determinar, sem ambiguidades, se o programa cumpre, ou não, a especificação.se o programa cumpre, ou não, a especificação.

– A correcção é uma propriedade matemática que estabelece A correcção é uma propriedade matemática que estabelece uma equivalência entre o software e a sua, suposta, uma equivalência entre o software e a sua, suposta, especificação.especificação.

– É suposto a especificação ser um modelo daquilo que o É suposto a especificação ser um modelo daquilo que o cliente pretende do software, embora possa não ser cliente pretende do software, embora possa não ser exactamente aquilo que o cliente pretende.exactamente aquilo que o cliente pretende.

– O software, na melhor das hipóteses, cumpre o que está O software, na melhor das hipóteses, cumpre o que está especificado e nunca aquilo que se pretendia que tivesse especificado e nunca aquilo que se pretendia que tivesse sido especificado.sido especificado.

© 2

001

UM

/EE

/DI/

JMF

22



Correcção: o modelo do sistema Correcção: o modelo do sistema

© 2

001

UM

/EE

/DI/

JMF

23



FiabilidadeFiabilidade

– A A fiabilidadefiabilidade de um programa depende do seu de um programa depende do seu comportamento estatístico; ou seja, a probabilidade de o comportamento estatístico; ou seja, a probabilidade de o programa funcionar tal como esperado durante um programa funcionar tal como esperado durante um intervalo de tempo bem definido.intervalo de tempo bem definido.

– A correcção constitui um aspecto de qualidade em termos A correcção constitui um aspecto de qualidade em termos absoluto, i.e., qualquer desvio relativamente à absoluto, i.e., qualquer desvio relativamente à especificação torna a execução incorrecta, especificação torna a execução incorrecta, independentemente de quão inofensivo ou fatal possa ser independentemente de quão inofensivo ou fatal possa ser o desvio.o desvio.

– A fiabilidade é, contrariamente, um aspecto de qualidade A fiabilidade é, contrariamente, um aspecto de qualidade em termos relativos, i.e., se a consequência de uma em termos relativos, i.e., se a consequência de uma incorrecção de software não for grave, o programa incorrecção de software não for grave, o programa incorrecto manter-se-á fiável.incorrecto manter-se-á fiável.

© 2

001

UM

/EE

/DI/

JMF

24



Fiabilidade: falhas no hardwareFiabilidade: falhas no hardware

© 2

001

UM

/EE

/DI/

JMF

25



Fiabilidade: falhas no softwareFiabilidade: falhas no software

© 2

001

UM

/EE

/DI/

JMF

26



RobustezRobustez

– Um programa diz-se Um programa diz-se robustorobusto se se comportar se se comportar “razoavelmente”, mesmo em circunstâncias que não foram “razoavelmente”, mesmo em circunstâncias que não foram previstas aquando da sua especificação.previstas aquando da sua especificação.

– A robustez é, obviamente, um aspecto de qualidade muito A robustez é, obviamente, um aspecto de qualidade muito difícil de definir, caso contrário seria possível especificar o difícil de definir, caso contrário seria possível especificar o que se entende por um programa comportar-se que se entende por um programa comportar-se “razoavelmente”.“razoavelmente”.

– A inclusão de um determinado requisito numa A inclusão de um determinado requisito numa especificação leva um programa a ser classificado especificação leva um programa a ser classificado relativamente à sua correcção, enquanto que a remoção relativamente à sua correcção, enquanto que a remoção do mesmo requisito da especificação leva o mesmo do mesmo requisito da especificação leva o mesmo programa a ser classificado relativamente à sua robustez, programa a ser classificado relativamente à sua robustez, pelo que a robustez e a correcção são dois aspectos de pelo que a robustez e a correcção são dois aspectos de qualidade fortemente relacionados.qualidade fortemente relacionados.

© 2

001

UM

/EE

/DI/

JMF

27



DesempenhoDesempenho

– Em engenharia de software, tal como em outras áreas de Em engenharia de software, tal como em outras áreas de engenharia, o desempenho é interpretado como sendo engenharia, o desempenho é interpretado como sendo eficiênciaeficiência..

– Diz-se que um programa de software é eficiente se utilizar Diz-se que um programa de software é eficiente se utilizar os recursos computacionais de uma forma racional os recursos computacionais de uma forma racional (económica)(económica)

– O desempenho (eficiência) de um software pode afectar:O desempenho (eficiência) de um software pode afectar: a sua usabilidade, se criar um ambiente pouco rentável e a sua usabilidade, se criar um ambiente pouco rentável e

desconfortável ao seu utilizadordesconfortável ao seu utilizador a escalabilidade, se colocar em causa a sua utilização em a escalabilidade, se colocar em causa a sua utilização em

circunstâncias de escala superiorcircunstâncias de escala superior

– A avaliação do desempenho pode ser realizada:A avaliação do desempenho pode ser realizada: medindo a complexidade dos algoritmos;medindo a complexidade dos algoritmos; analisando modelos do software;analisando modelos do software; simulando o comportamento do software.simulando o comportamento do software.

© 2

001

UM

/EE

/DI/

JMF

28



Facilidade de utilizaçãoFacilidade de utilização– Um software é fácil de utilizar se os seus utilizadores Um software é fácil de utilizar se os seus utilizadores

(clientes) humanos assim o considerarem.(clientes) humanos assim o considerarem.– A facilidade de utilização é entendida de diferentes modos A facilidade de utilização é entendida de diferentes modos

conforme seja um recém utilizador a efectuar a avaliação, conforme seja um recém utilizador a efectuar a avaliação, ou um utilizador já experiente com o programa em causa.ou um utilizador já experiente com o programa em causa.

– A interface gráfica, bem como a sua coerência constituem, A interface gráfica, bem como a sua coerência constituem, frequentemente, os componentes mais importantes da frequentemente, os componentes mais importantes da avaliação da facilidade de utilização.avaliação da facilidade de utilização.

– A correcção e o desempenho também afectam a facilidade A correcção e o desempenho também afectam a facilidade de utilização.de utilização.

– Os outros factores adicionais relevantes para a facilidade Os outros factores adicionais relevantes para a facilidade de utilização do software são tipicamente de natureza de utilização do software são tipicamente de natureza humana: gostos, estados de espírito, classes de humana: gostos, estados de espírito, classes de utilizadores, etc.utilizadores, etc.

© 2

001

UM

/EE

/DI/

JMF

29



Facilidade de verificaçãoFacilidade de verificação– Um software é Um software é verificávelverificável se as suas propriedades se as suas propriedades

forem facilmente verificáveis.forem facilmente verificáveis.– A correcção e o desempenho são duas propriedades A correcção e o desempenho são duas propriedades

que se pretende sempre que sejam verificáveis.que se pretende sempre que sejam verificáveis.– A modularização do software, o recurso a práticas A modularização do software, o recurso a práticas

disciplinadas na escrita de programas, bem como a disciplinadas na escrita de programas, bem como a utilização de uma linguagem de programação utilização de uma linguagem de programação adequada contribuem para a verificabilidade do adequada contribuem para a verificabilidade do software.software.

– Apesar da verificabilidade do software reflectir Apesar da verificabilidade do software reflectir propriedades internas, em certas circunstâncias, pode propriedades internas, em certas circunstâncias, pode ser utilizada para inferir da qualidade externa do ser utilizada para inferir da qualidade externa do programa (ex. o programa (ex. o kernelkernel de de life-critical solutionslife-critical solutions).).

© 2

001

UM

/EE

/DI/

JMF

30



Facilidade de manutençãoFacilidade de manutenção– O termo O termo manutenção manutenção de software é utilizado em relação às de software é utilizado em relação às

modificações introduzidas num software após a sua 1ª modificações introduzidas num software após a sua 1ª versão.versão.

– Originalmente, o termo manutenção era utilizado para Originalmente, o termo manutenção era utilizado para designar as actividades de correcção de erros (designar as actividades de correcção de erros (debugdebug).).

– Actualmente é mais correcto aplicá-lo para referir a melhoria Actualmente é mais correcto aplicá-lo para referir a melhoria e evolução do software de forma a dotá-lo com e evolução do software de forma a dotá-lo com funcionalidades não previstas inicialmente.funcionalidades não previstas inicialmente.

– A expressão mais correcta e adequada deveria ser A expressão mais correcta e adequada deveria ser evoluçãoevolução do software e não manutenção.do software e não manutenção.

– As actividades de manutenção podem ser, genericamente, As actividades de manutenção podem ser, genericamente, divididas em:divididas em:

correctivas (remoção de erros detectados no software);correctivas (remoção de erros detectados no software); adaptativas (adaptação do software às mudanças do ambiente);adaptativas (adaptação do software às mudanças do ambiente); preditivas (optimização de funcionalidades prevendo mudanças).preditivas (optimização de funcionalidades prevendo mudanças).

© 2

001

UM

/EE

/DI/

JMF

31



Facilidade de manutenção: Facilidade de manutenção: debuggingdebugging

© 2

001

UM

/EE

/DI/

JMF

32



Facilidade de reparaçãoFacilidade de reparação– Um software é Um software é reparávelreparável se permitir que a correcção de se permitir que a correcção de

defeitos possa ser executada recorrendo a uma quantidade defeitos possa ser executada recorrendo a uma quantidade finita de trabalho (esforço técnico humano).finita de trabalho (esforço técnico humano).

– Um produto de software é muito mais facilmente analisável e Um produto de software é muito mais facilmente analisável e reparável se for construído de uma forma modular, do que se reparável se for construído de uma forma modular, do que se for desenhado segundo uma abordagem monolítica for desenhado segundo uma abordagem monolítica (“tijolaço”).(“tijolaço”).

– O mero aumento do número de módulos (modularização) O mero aumento do número de módulos (modularização) presente no programa não resolve o problema da facilidade presente no programa não resolve o problema da facilidade de reparação, se não se tiver em conta o nível de coesão e de de reparação, se não se tiver em conta o nível de coesão e de acoplamento existente entre os módulos.acoplamento existente entre os módulos.

– A facilidade de reparação também pode ser controlada com A facilidade de reparação também pode ser controlada com uma adequada escolha da linguagem de programação a uma adequada escolha da linguagem de programação a utilizar (em utilizar (em assemblyassembly é mais difícil reparar erros de software). é mais difícil reparar erros de software).

– A reparabilidade do software afecta a sua fiabilidade.A reparabilidade do software afecta a sua fiabilidade.

© 2

001

UM

/EE

/DI/

JMF

33



Facilidade de evoluçãoFacilidade de evolução– Os produtos de software são modificados ao longo do tempo, Os produtos de software são modificados ao longo do tempo,

quer para introduzir novas funcionalidades, quer para alterar quer para introduzir novas funcionalidades, quer para alterar algumas já existentes.algumas já existentes.

– A maleabilidade do software estimula a evolução do software A maleabilidade do software estimula a evolução do software de uma forma pouco cuidadade uma forma pouco cuidada

– Não existem estudos sérios e aprofundados antes das Não existem estudos sérios e aprofundados antes das alterações introduzidas para indagar da efectiva alterações introduzidas para indagar da efectiva possibilidade e viabilidade técnica de tal operação de possibilidade e viabilidade técnica de tal operação de evolução sem afectar drasticamente os índices de fiabilidade evolução sem afectar drasticamente os índices de fiabilidade e desempenho para o produto.e desempenho para o produto.

– As operações de evolução, após efectuadas, também não são, As operações de evolução, após efectuadas, também não são, tipicamente, acompanhadas da documentação respectiva, o tipicamente, acompanhadas da documentação respectiva, o que leva a que um produto de software seja cada vez mais que leva a que um produto de software seja cada vez mais difícil de evoluir à medida que sobre ele são realizadas difícil de evoluir à medida que sobre ele são realizadas operações de evolução operações de evolução ad-hocad-hoc e não documentadas. e não documentadas.

© 2

001

UM

/EE

/DI/

JMF

34



ReutilizaçãoReutilização

– A reutilização está relacionada com a facilidade de evolução.A reutilização está relacionada com a facilidade de evolução.– Na evolução de um produto, este é modificado para dar Na evolução de um produto, este é modificado para dar

origem a uma nova versão do mesmo produto.origem a uma nova versão do mesmo produto.– Na reutilização de um produto, este é utilizado, com a Na reutilização de um produto, este é utilizado, com a

introdução de algumas alterações, para dar origem a um introdução de algumas alterações, para dar origem a um outro produto distinto do primeiro.outro produto distinto do primeiro.

– Em ambas as situações, a facilidade de evolução é Em ambas as situações, a facilidade de evolução é determinante para o sucesso das alterações introduzidas.determinante para o sucesso das alterações introduzidas.

– Tipicamente, a reutilização é aplicada a componentes do Tipicamente, a reutilização é aplicada a componentes do software e não tanto ao programa de software como um todo.software e não tanto ao programa de software como um todo.

– A facilidade de reutilização diminui drasticamente, se o A facilidade de reutilização diminui drasticamente, se o desenvolvimento do software não for pensado de raiz com desenvolvimento do software não for pensado de raiz com essa intenção, recorrendo, por exemplo, a módulos e essa intenção, recorrendo, por exemplo, a módulos e componentes.componentes.

© 2

001

UM

/EE

/DI/

JMF

35



PortabilidadePortabilidade

– Um programa de software é considerado Um programa de software é considerado portávelportável se for se for possível correr em diferentes ambientes, quer se trate possível correr em diferentes ambientes, quer se trate de plataformas de hardware diferenciadas de plataformas de hardware diferenciadas (processadores, barramentos), quer se trate de (processadores, barramentos), quer se trate de plataformas de software distintas (sistemas operativos, plataformas de software distintas (sistemas operativos, protocolos de comunicações).protocolos de comunicações).

– Com a proliferação de diferentes sistemas operativos Com a proliferação de diferentes sistemas operativos (windows98, windowsNT, windowsCE, linux, unix, palmOS (windows98, windowsNT, windowsCE, linux, unix, palmOS ...) e suportes à computação (PCs, workstations, PDAs, ...) e suportes à computação (PCs, workstations, PDAs, telemóveis ...) a portabilidade é um aspecto cada vez telemóveis ...) a portabilidade é um aspecto cada vez mais premente na engenharia de software.mais premente na engenharia de software.

© 2

001

UM

/EE

/DI/

JMF

36



InteroperabilidadeInteroperabilidade– A interoperabilidade refere-se à capacidade de um A interoperabilidade refere-se à capacidade de um

programa de software coexistir e cooperar com outro.programa de software coexistir e cooperar com outro.– A interoperabilidade beneficia da normalização das A interoperabilidade beneficia da normalização das

interfacesinterfaces– A utilização de tecnologias abertas (A utilização de tecnologias abertas (open technologiesopen technologies) )

possibilita a montagem de soluções de software possibilita a montagem de soluções de software complexas, à custa da integração de diversos programas complexas, à custa da integração de diversos programas implementados independentemente uns dos outros que, implementados independentemente uns dos outros que, depois de interligados, colaboram entre eles na execução depois de interligados, colaboram entre eles na execução cooperativa de tarefas elaboradas e que não estão ao cooperativa de tarefas elaboradas e que não estão ao alcance de qualquer um dos programas isoladamente.alcance de qualquer um dos programas isoladamente.

© 2

001

UM

/EE

/DI/

JMF

37



ConclusõesConclusões

– A enumeração dos aspectos de qualidade no A enumeração dos aspectos de qualidade no desenvolvimento de software é um acto relevante, mas desenvolvimento de software é um acto relevante, mas poder-se-á tornar inconsequente se não existir forma de poder-se-á tornar inconsequente se não existir forma de desambiguar (tornar objectivo) a percepção que deles se desambiguar (tornar objectivo) a percepção que deles se tem.tem.

– Uma das formas de tornar objectiva a interpretação dos Uma das formas de tornar objectiva a interpretação dos aspectos de qualidade em situações concretas consiste na aspectos de qualidade em situações concretas consiste na medição (quantificação) de índices de qualidade.medição (quantificação) de índices de qualidade.

– A definição de métricas para índices de qualidade no A definição de métricas para índices de qualidade no software não estão, contudo, livres de polémica, uma vez software não estão, contudo, livres de polémica, uma vez que se para a fiabilidade e o desempenho a quantificação que se para a fiabilidade e o desempenho a quantificação é relativamente pacífica, já para a facilidade de utilização, é relativamente pacífica, já para a facilidade de utilização, ou para a facilidade de evolução, por exemplo, a ou para a facilidade de evolução, por exemplo, a quantificação é uma tarefa de muito difícil resolução ou quantificação é uma tarefa de muito difícil resolução ou consenso.consenso.

© 2

001

UM

/EE

/DI/

JMF

38

4. Gestão de Projectos 4. Gestão de Projectos (1/13)(1/13)

Atrasos nos projectosAtrasos nos projectos– Os atrasos são o maior problema para a maioria dos Os atrasos são o maior problema para a maioria dos

projectos de software.projectos de software.– As causas para tal realidade são essencialmente as As causas para tal realidade são essencialmente as

seguintes:seguintes: Técnicas de estimação da duração do projecto pouco Técnicas de estimação da duração do projecto pouco

evoluídasevoluídas.. Atitude optimista perante o projecto.Atitude optimista perante o projecto. Assunção que “homens x tempo” mede o esforço do Assunção que “homens x tempo” mede o esforço do

projecto.projecto. Progresso do projecto fracamente monitorizado.Progresso do projecto fracamente monitorizado. Introdução de mais recursos humanos, quando se percebe Introdução de mais recursos humanos, quando se percebe

que o projecto está atrasado.que o projecto está atrasado.

– Esta última causa, em vez de acelerar a conclusão do Esta última causa, em vez de acelerar a conclusão do projecto de software, ainda o atrasa mais.projecto de software, ainda o atrasa mais.

© 2

001

UM

/EE

/DI/

JMF

39


Optimismo típicoOptimismo típico– Todos os programadores são, por natureza, optimistas.Todos os programadores são, por natureza, optimistas.

““Desta vez, vai tudo correr bem”.Desta vez, vai tudo correr bem”. ““Encontrei o último bug”.Encontrei o último bug”. ““O compilador não está bom. O programa não tem erros”.O compilador não está bom. O programa não tem erros”.

– O 1º erro de gestão é considerar que cada tarefa vai O 1º erro de gestão é considerar que cada tarefa vai durar aquilo que está previsto de início.durar aquilo que está previsto de início.

– Uma tarefa tem uma dada probabilidade de correr Uma tarefa tem uma dada probabilidade de correr como previsto.como previsto.

– Um projecto é composto por diversas tarefas, Um projecto é composto por diversas tarefas, encadeadas, pelo que é muito baixa a probabilidade de encadeadas, pelo que é muito baixa a probabilidade de tudo ocorrer sem atrasos.tudo ocorrer sem atrasos.

© 2

001

UM

/EE

/DI/

JMF

40


Homens x MesesHomens x Meses– O O custocusto dum projecto pode medir-se por “homens x meses”. dum projecto pode medir-se por “homens x meses”.– Porém, tal indicador não deve usar-se para medir o esforço Porém, tal indicador não deve usar-se para medir o esforço

(ou progresso) dum projecto.(ou progresso) dum projecto.– O 2º erro de gestão é considerar que o esforço dum projecto O 2º erro de gestão é considerar que o esforço dum projecto

se mede por esse produto.se mede por esse produto.

0

1

2

3

4

5

6

7

8

9

10

1 2 3 4 5 6 7 8 9

Homens

Me

se

s

– Adoptar a métrica “homem x mês” Adoptar a métrica “homem x mês” significa que colocar mais recursos significa que colocar mais recursos humanos reduz o tempo de projecto.humanos reduz o tempo de projecto.

– Os homens e os meses são inter-Os homens e os meses são inter-mutáveis apenas quando uma tarefa mutáveis apenas quando uma tarefa pode ser dividida, sem a necessidade pode ser dividida, sem a necessidade de comunicação entre os de comunicação entre os trabalhadores.trabalhadores.

– Ex: apanhar laranjas.Ex: apanhar laranjas.

© 2

001

UM

/EE

/DI/

JMF

41


Homens x MesesHomens x Meses– Quando uma tarefa não pode ser Quando uma tarefa não pode ser

dividida, devido a dependências dividida, devido a dependências temporais, o uso de mais homens temporais, o uso de mais homens não afecta o progresso do projecto.não afecta o progresso do projecto.

– Ex: o nascimento dum bebé demora 9 Ex: o nascimento dum bebé demora 9 meses, qualquer que seja o número meses, qualquer que seja o número de mães considerado.de mães considerado.

– Algumas tarefas em software Algumas tarefas em software apresentam esta característica, apresentam esta característica, devido à natureza sequencial do devido à natureza sequencial do debuggingdebugging..

– Em tarefas que podem ser divididas Em tarefas que podem ser divididas mas que requerem comunicação, mas que requerem comunicação, este esforço deve ser contemplado.este esforço deve ser contemplado.

0

1

2

3

4

5

6

7

8

9

10

1 2 3 4 5 6 7 8 9

Homens

Me

se

s

0

1

2

3

4

5

6

7

8

9

10

1 2 3 4 5 6 7 8 9

Homens

Me

se

s

© 2

001

UM

/EE

/DI/

JMF

42


Homens x MesesHomens x Meses– O esforço de comunicação provém de 2 actividades: O esforço de comunicação provém de 2 actividades:

formação e intercomunicação.formação e intercomunicação.– Cada trabalhador deve receber formação na tecnologia, Cada trabalhador deve receber formação na tecnologia,

nos objectivos, na estratégia global e no plano do projecto.nos objectivos, na estratégia global e no plano do projecto.

– A formação não pode ser dividida, A formação não pode ser dividida, pelo que o esforço é proporcional ao pelo que o esforço é proporcional ao número de trabalhadores.número de trabalhadores.

– A intercomunicação é mais A intercomunicação é mais penalizante.penalizante.

– O esforço de intercomunicação para O esforço de intercomunicação para n trabalhadores é dado por n(n-1)/2.n trabalhadores é dado por n(n-1)/2.

– Este esforço pode ser superior ao Este esforço pode ser superior ao ganho que a divisão da tarefa ganho que a divisão da tarefa proporcionou.proporcionou.

– Os projectos de software seguem Os projectos de software seguem este modelo.este modelo.

0

2

4

6

8

10

12

1 2 3 4 5 6 7 8 9

Homens

Me

se

s

© 2

001

UM

/EE

/DI/

JMF

43


TesteTeste– A fase de teste é aquela em que há mais restrições de A fase de teste é aquela em que há mais restrições de

sequencialidade.sequencialidade.– Assim, o tempo para o teste depende do número e Assim, o tempo para o teste depende do número e

natureza dos erros encontrados.natureza dos erros encontrados.– Teoricamente, este número devia ser zero! Mas a Teoricamente, este número devia ser zero! Mas a

prática diz-nos que, onde o homem intervém, há erros.prática diz-nos que, onde o homem intervém, há erros.– Devido ao optimismo, o número estimado de erros é Devido ao optimismo, o número estimado de erros é

normalmente muito menor que aquele que ocorre.normalmente muito menor que aquele que ocorre.– Por este motivo, a fase de teste é, habitualmente, Por este motivo, a fase de teste é, habitualmente,

aquela que é mais mal calendarizada. aquela que é mais mal calendarizada.

© 2

001

UM

/EE

/DI/

JMF

44


TesteTeste– Uma regra (informal) a seguir para a calendarização dum Uma regra (informal) a seguir para a calendarização dum

projecto de software de grande complexidade é:projecto de software de grande complexidade é: 1/3 para análise e concepção.1/3 para análise e concepção. 1/6 para implementação (codificação).1/6 para implementação (codificação). 1/4 para teste de componentes e do sistema em fases iniciais.1/4 para teste de componentes e do sistema em fases iniciais. 1/4 teste de integração (todos os componentes).1/4 teste de integração (todos os componentes).

– Esta calendarização difere das convencionais no seguinte:Esta calendarização difere das convencionais no seguinte: A parte devotada à análise e à concepção é maior que o A parte devotada à análise e à concepção é maior que o

habitual.habitual. A fase de teste corresponde a metade do tempo.A fase de teste corresponde a metade do tempo. Metade do tempo de teste é reservado para teste do sistema Metade do tempo de teste é reservado para teste do sistema

completo, o que também é maior que o habitual.completo, o que também é maior que o habitual. A fase mais fácil de estimar (codificação) corresponde apenas A fase mais fácil de estimar (codificação) corresponde apenas

a 1/6 do tempo.a 1/6 do tempo.

© 2

001

UM

/EE

/DI/

JMF

45


TesteTeste– É normal atribuir-se menos tempo para o teste que É normal atribuir-se menos tempo para o teste que

aquele que vai ser de facto necessário.aquele que vai ser de facto necessário.– Não atribuir o tempo suficiente para a fase de teste é Não atribuir o tempo suficiente para a fase de teste é

particularmente perigoso.particularmente perigoso.– Uma vez que os atrasos se vão acumulando, as fases Uma vez que os atrasos se vão acumulando, as fases

finais são aquelas que sofrem as consequências desses finais são aquelas que sofrem as consequências desses atrasos.atrasos.

– Desta forma, aumenta a pressão sobre a fase de teste:Desta forma, aumenta a pressão sobre a fase de teste: Alternativa 1Alternativa 1: fazer menos testes (decisão que não garante : fazer menos testes (decisão que não garante

a qualidade do produto).a qualidade do produto). Alternativa 2Alternativa 2: aumentar o tempo de projecto (decisão que : aumentar o tempo de projecto (decisão que

implica maiores custos e descontentamento do cliente).implica maiores custos e descontentamento do cliente).

– É, pois, extremamente importante atribuir originalmente É, pois, extremamente importante atribuir originalmente o tempo necessário e suficiente para a fase de teste.o tempo necessário e suficiente para a fase de teste.

© 2

001

UM

/EE

/DI/

JMF

46


EstimativasEstimativas– É típico, em software, aceitar a urgência do cliente, como o É típico, em software, aceitar a urgência do cliente, como o

tempo necessário para desenvolver um produto.tempo necessário para desenvolver um produto.– Acontece o mesmo noutras áreas? Alguém pede uma Acontece o mesmo noutras áreas? Alguém pede uma

vivenda pronta em 2 meses? Ou uma omeleta em 1 minuto?vivenda pronta em 2 meses? Ou uma omeleta em 1 minuto?– Se a omeleta não está pronta passado esse tempo, o cliente Se a omeleta não está pronta passado esse tempo, o cliente

tem 2 hipóteses: ou come-a crua ou espera até ela ficar tem 2 hipóteses: ou come-a crua ou espera até ela ficar pronta.pronta.

– O cozinheiro tem outra alternativa que é aumentar o lume. O cozinheiro tem outra alternativa que é aumentar o lume. O resultado é usualmente uma omeleta que tem de ir para o O resultado é usualmente uma omeleta que tem de ir para o lixo.lixo.

– Em software, as estimativas fazem-se com pouco rigor, pois Em software, as estimativas fazem-se com pouco rigor, pois raramente se colectam dados de outros projectos.raramente se colectam dados de outros projectos.

– É necessário recolher dados de produtividade, de ocorrência É necessário recolher dados de produtividade, de ocorrência de erros, de temporizações, para poder criar uma base de de erros, de temporizações, para poder criar uma base de dados sobre os projectos, para uso em futuras estimações.dados sobre os projectos, para uso em futuras estimações.

© 2

001

UM

/EE

/DI/

JMF

47


Atacar os atrasosAtacar os atrasos– A reacção típica dum gestor dum projecto de software, A reacção típica dum gestor dum projecto de software,

quando este se atrasa, é recrutar mais recursos humanos.quando este se atrasa, é recrutar mais recursos humanos.– Essa decisão pode ser ou não benéfica.Essa decisão pode ser ou não benéfica.– Suponha-se uma tarefa estimada em 12 h.m, prevista Suponha-se uma tarefa estimada em 12 h.m, prevista

para ser executada por 3h durante 4m. Existem ainda 4 para ser executada por 3h durante 4m. Existem ainda 4 milestonesmilestones, ao fim de cada mês., ao fim de cada mês.

0

0,5

1

1,5

2

2,5

3

3,5

1 2 3 4

MesesH

om

en

s

– Suponha-se que a 1ª Suponha-se que a 1ª milestonemilestone, só acontece ao fim , só acontece ao fim de 2 meses.de 2 meses.

– Que alternativas deve Que alternativas deve considerar o gestor?considerar o gestor?

© 2

001

UM

/EE

/DI/

JMF

48


Atacar os atrasosAtacar os atrasos– A 1ª hipótese é assumir que a A 1ª hipótese é assumir que a

tarefa vai fazer-se a tempo e que tarefa vai fazer-se a tempo e que só a 1ª sub-tarefa foi mal só a 1ª sub-tarefa foi mal planeada.planeada.

– Assim, ainda restam 9 h.m (3 sub-Assim, ainda restam 9 h.m (3 sub-tarefas de 3h.m cada) e 2 meses.tarefas de 3h.m cada) e 2 meses.

– São pois necessários 4São pois necessários 4½ homens. ½ homens. Como só temos 3, há que contratar Como só temos 3, há que contratar 2 novos colaboradores.2 novos colaboradores.

– A 2ª hipótese é assumir que a A 2ª hipótese é assumir que a tarefa vai fazer-se a tempo e que tarefa vai fazer-se a tempo e que todas as sub-tarefas foram mal todas as sub-tarefas foram mal estimadas.estimadas.

– Assim, ainda restam 18 h.m (3 sub-Assim, ainda restam 18 h.m (3 sub-tarefas de 6h.m cada) e 2 meses.tarefas de 6h.m cada) e 2 meses.

– São precisos 9São precisos 9 homens. Como homens. Como temos 3, há que contratar mais 6.temos 3, há que contratar mais 6.

0

0,5

1

1,5

2

2,5

3

3,5

1 2 3 4 5

Meses

Ho

me

ns

0

0,5

1

1,5

2

2,5

3

3,5

1 2 3 4 5 6 7 8

Meses

Ho

me

ns

© 2

001

UM

/EE

/DI/

JMF

49


Atacar os atrasosAtacar os atrasos– O pressuposto de que a tarefa se pode ainda fazer em O pressuposto de que a tarefa se pode ainda fazer em

4 meses tem efeitos desastrosos.4 meses tem efeitos desastrosos.– Consideremos a 1ª hipótese.Consideremos a 1ª hipótese.– Os Os 2 novos colaboradores, por muito competentes que 2 novos colaboradores, por muito competentes que

sejam, tem de ser informados e treinados por um sejam, tem de ser informados e treinados por um elemento da equipa.elemento da equipa.

– Se a formação demorar 1 mês, 3 h.m foram usados Se a formação demorar 1 mês, 3 h.m foram usados para trabalho inicialmente não considerado.para trabalho inicialmente não considerado.

– Além disso, a tarefa que inicialmente estava dividida Além disso, a tarefa que inicialmente estava dividida por 3 homens, terá agora que ser distribuída por 5por 3 homens, terá agora que ser distribuída por 5

– Isto implica que algum trabalho já feito seja perdido e Isto implica que algum trabalho já feito seja perdido e que o teste e a integração serão mais longosque o teste e a integração serão mais longos..

© 2

001

UM

/EE

/DI/

JMF

50


Atacar os atrasosAtacar os atrasos– Portanto, no final do 3º mês, são necessários mais que 7 Portanto, no final do 3º mês, são necessários mais que 7

h.m de esforço e temos 5 homens e um mêsh.m de esforço e temos 5 homens e um mês.. 7h.m = 12 (total) - 3 (tf A) - 2 (tf B, realizada por 2h no 3º mês)7h.m = 12 (total) - 3 (tf A) - 2 (tf B, realizada por 2h no 3º mês)

– Conseguir a tarefa feita em 4 meses, requer então não 2 Conseguir a tarefa feita em 4 meses, requer então não 2 mas sim 4 novos colaboradores, no fim do 2º mês.mas sim 4 novos colaboradores, no fim do 2º mês.

– Passou-se dum projecto com 3 homens para um outro com Passou-se dum projecto com 3 homens para um outro com 7.7.

– Este processo de adicionar mais pessoas, pode repetir-se se Este processo de adicionar mais pessoas, pode repetir-se se no final do 3º mês, os prazos forem outra vez no final do 3º mês, os prazos forem outra vez ultrapassados.ultrapassados.

– Sem dúvida que seria preferível manter a equipa com 3 Sem dúvida que seria preferível manter a equipa com 3 homens e assumir o atraso.homens e assumir o atraso.

– Podemos então enunciar a lei de Brooks:Podemos então enunciar a lei de Brooks:““Adding manpower to a late software project makes it Adding manpower to a late software project makes it laterlater”.”.

U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2001/02 D EP. I NFORMÁTICA DESENVOLVIMENTO DE...

Documents

Transcript of U NIVERSIDADE DO M INHO E SCOLA DE E NGENHARIA 2001/02 D EP. I NFORMÁTICA DESENVOLVIMENTO DE...