terça-feira, 26 de fevereiro de 2008

Mesmo sabendo o que precisa ser feito no projeto, é realmente necessário criar um Termo de Abertura?

A. Um termo de abertura sempre deve ser criado, por mais simples que seja.

B. Um termo de abertura é opcional, pois em pequenas organizações o nível de informalidade é elevado não possibilitando a elaboração de muitos documentos.

C. Um termo de abertura é necessário se a equipe do projeto for maior do que 40 pessoas.

D. Um termo de abertura só é necessário se você ainda não sabe o que é um projeto.

Como conduzir um Kickoff Meeting

O que é:
Encontro entre os integrantes do projeto com o objetivo do motivar a equipe e criar interesse pelo produto do projeto, esclarecendo a todos os objetivos do projeto. Outro aspecto importante é deixar claro o apoio executivo na organização em relação ao projeto.

O kickoff meeting deve ser planejado com cuidado, pois coloca o projeto no rumo certo para seu sucesso. Os participantes entenderão o quê estão fazendo e, mais importante, o por quê estão fazendo o trabalho do projeto. É interessante identificar as origens de um projeto, seu valor para a organização e que necessidades da mesma serão atendidas com o projeto.

O que não é:
  • Oportunidade para adquirir estimativas de tempo para atividades do projeto e atribuir responsáveis a essas atividades, afinal, todos os membros do projeto estarão participando...
Como conduzir um kickoff meeting?
(adaptado de PMI, Community Post, acesso em 26 de fevereiro de 2008)
  1. Inicie com uma breve apresentação dos executivos envolvidos no projeto. Peça a uma dessas pessoas que descreva o projeto, e mostre como o projeto se enquadra na estratégia de negócios da organização e especifique como seu produto agregará valor à organização.
  2. Peça ao patrocinador do projeto para falar sobre a necessidade de negócio que o motivou a financiar esse projeto e sobre como isso pode ser valioso para a organização e seus clientes. Peça que ele explique o fator mais importante a ser considerado: se o Tempo (velocidade para o mercado), Custo (restrições no orçamento), ou Qualidade (Satisfação dos clientes). É importante que ele reforce porque o projeto é crucial. Em seguida, o patrocinador apresenta o gerente de projetos.
  3. O gerente de porjeots deve apresentar as principais partes interessadas no projeto (stakeholders), que devem incluir clientes internos e/ou externos, colaboradores-chave de outros departamentos da organização, principais contatos dos fornecedores (ou terceiros), membros de entidades regulatórias (se for o caso) e a equipe de gerenciamento do projeto. Cada participante de explicar sua ligação com o projeto e o papel que deverá desempenhar para seu sucesso.
  4. Permita que todos os presentes façam perguntas para esclarecer qualquer informação que não tenha sido compreendida. As melhores pessoas para responder a essas perguntas estão reunidas nesse encontro.
  5. Em seguida, o gerente do projeto fala brevemente (com o auxílio de imagens ou gráficos) sobre o escopo do projeto e seus riscos (ambos identificados apenas em seu nível mais genérico) e sobre as premissas e restrições do projeto. Você apresenta o plano de comunicações para os relatórios semanais primários para a equipe, fornecedores, gerentes sêniores e patrocinadores e os planos de atualização e gerenciamento de mudanças no projeto.
  6. Dê oportunidade para um curta discussão sobre a apresentação do gerente de projetos e agradeça a todos por sua presença e preciosa contribuição para o projeto no final do encontro.

Sou o responsável por um kickoff meeting. O que é mais útil incluir neste encontro para que o projeto seja bem sucedido?

A. O kickoff meeting não é tão importante assim; é melhor dedicar tempo para o trabalho no projeto o mais rápido possível, deixado o kickoff meeting de lado.

B. Solicitar aos membros da equipe que tragam suas estimativas para as atividades e programação de férias.

C. Garantir a qualidade do cofee-break e divulgar isso, para que as pessoas se sintam motivadas a comparecer.

D. Não trabalhar no cronograma do projeto, mas manter o foco na comunicação e nos objetivos do projeto.

quarta-feira, 13 de fevereiro de 2008

Therac-25

Os acidentes do Therac-25 são os acidentes mais sérios relacionados a falha em computadores.

Aceleradores lineares são dispositivos que aceleram elétrons a fim de criar feixes de luz que podem destruir tumores com um mínimo impacto do tecido saudável local. Estes dispositivos eram normalmente mecânicos em sua totalidade até o início da década de 70.

O Therac-25, máquina criada pela empresa AECL (Atomic Energy of Canada Limited) para produzir radiação a ser utilizada no tratamento Radioterápico, foi desenvolvida utilizando uma tecnologia diferente da usada nas máquinas anteriores, o que fez que a máquina fosse mais compacta, versátil, e deveria também ser mais fácil de usar.

Os predecessores do Therac-25 foram o Therac-6 (que produzia raio-x apenas) e Therac-20 (que produzia feixes de elétrons e raio-x). A Família Therac-20 era controlada por um PDP-11 (a máquina não é do tipo stand-alone); o projeto possui o controle através de travas mecânicas. Já no Therac-25 as funções de segurança foram colocadas no software.

Apesar desse investimento em Software, o projeto do Therac-25 teve partes inter-relacionadas e reutilizadas do Software das máquinas antigas. Porém os testes realizados aparentemente não tiveram uma grande preocupação com o Software.
A máquina trabalhava com dois tipos de tratamento:

  • A radioterapia de feixe de Elétrons direto, que aplicava desde doses fracas 5 MeV (milhões de elétrons-volts) até doses elevadas de 25 MeV, durante um curto período de tempo;
  • Terapia com Raios X, que usava o feixe de 25 MeV passando por uma chapa que o convertia em Raios X.
Os acidentes aconteciam quando o feixe de alta intensidade era ativado sem o target ter sido rotacionado para seu lugar. O software da máquina não detectava que isto havia acontecido e não podia detectar que o paciente estava recebendo uma dose letal de radiação, ou evitar que isso ocorresse. O feixe de alta intensidade atingindo diretamente os pacientes causava a sensação de um forte choque elétrico e a ocorrência de queimadura.

Entre as principais causas dos acidentes investigados pelos pesquisadores, têm-se :
  • Ausência de procedimentos de análise, projeto e verificação (teste);
  • Ausência de gerenciamento de projeto e planejamento de manutenção;
  • Negligência no projeto de interface;
  • Tratamento falho de comunicação com hardware (race condition);
  • A documentação começou a ser feita quando os acidentes foram reportados;
  • Apenas hardware foi testado inicialmente;
  • Após os acidentes, hardware e software foram testados em separado e sem nenhum planejamento a cada modificação. Apenas a modificação do software foi considerada.
  • O software do THERAC-25 era similar ao do seu predecessor, o THERAC-20. Esse software tinha erros que podiam se manifestar em certas circunstâncias. Porém, no THERAC-25, o software também foi projetado para assumir maior responsabilidade pela segurança e alguns mecanismos de proteção por hardware, usados no THERAC-20, foram removidos do novo projeto. Como resultado, em determinadas situações em que o THERAC-20 queimaria alguns fusíveis, o THERAC-25 irradiou, fatalmente, alguns pacientes;
  • O software considerava que os sensores sempre funcionavam corretamente, e não havia como verificar isto;
  • O sistema de controle não operava sincronizado com a interface usada pelo operador da máquina, e caso o operador mudasse a configuração da máquina muito rapidamente, o sistema não atribuia os valores digitados para os controles (o que levava a aplicação das doses letais). Não suportava intruções concorrentes;
  • Overflows* podiam fazer o software não executar procedimentos de segurança;
  • O dispositivo responsável por sincronizar o hardware é removido, mas o software não possui sincronismo e o software falha na tarefa de manter invariantes essenciais: o feixe de elétrons ou o feixe mais forte de radiação e a chapa se interferem na geração de raios X;

As overdoses ocorreram entre 1985 e 1987, a máquina estava em funcionamento desde 1983.

Serão citados alguns acidentes:

No primeiro, a AECL foi notificada e respondeu que nenhum problema poderia ter ocorrido. A paciente, apesar de ter desenvolvido uma vermelhidão e inchaço em volta da área do tratamento, continuou a ser submetida ao tratamento com o Therac-25, a reação foi tida como normal, conseqüente do tratamento, ou de sua doença.

Outro acidente ocorreu quando a máquina se desligou após mostrar a mensagem “H-tilt”, a mensagem de “no dose” e “Treatment pause” ao operador ativá-la. Após isso o operador tentou reativá-la, mais 5 vezes, após o operador da máquina chamou um técnico que não encontrou problemas na máquina.

Com a descrição destes acidentes pode-se observar que houve falha no projeto de Software, que deveria ter sido realizado com mais cuidado, já que foi escolhido utilizar o Software para realizar os controles de segurança. No caso de optar por reuso do sistema anterior, deveriam ser realizados testes mais cuidadosos. Não houve preocupação com a usabilidade do sistema, como podemos observar pelas mensagens de erro passadas do sistema, além das mensagens supracitadas, outras mensagens de erro, como “MALFUNCTION 1 ... 64” eram demonstradas ao usuário, sem que nem ao menos no manual, houvesse maiores explicações sobre elas. Falhas do lado dos operadores e médicos também ocorreram, por desconsiderar as reclamações dos pacientes e continuar com o tratamento. A AECL deveria ter levado em consideração os contatos feitos pelos médicos e hospitais dos pacientes acidentados, realizando novos testes no Therac-25, assim que o primeiro acidente ocorreu.

Em 1987, após o 6º acidente, a FDA declara que o Therac-25 não está de acordo com a lei dos Estados Unidos da América e pede que a AECL avise seus clientes que o aparelho não deve ser utilizado para tratamento de rotina.

Histórico dos Acidentes

Kenneston Regional Oncology Center (1985)

  • Paciente em tratamento de CA de mama recebe overdose
  • Máquina estava operando há 6 meses; após uma investigação superficial, técnicos concluíram que não havia risco de overdose.
  • Paciente desenvolveu uma queimadura profunda na área do tratamento. Tratamento persistiu e o paciente continuou a sentir dores cada vez maiores, perdendo o movimento em um dos braços
  • No total foram 15 os acidentes reportados em diferentes locais, antes que a máquina fosse
    tirada de operação.
  • Todos os acidentes envolveram morte ou deixaram seqüelas para o resto da vida
  • Inabilidade dos órgãos de fiscalização em detectar e reconhecer a ocorrência dos acidentes.
  • Negligência da empresa durante o projeto e análise de segurança do software de controle.
  • Falta de um planejamento de manutenção: a medida que acidentes eram reportados, correções foram feitas, mas deram origem a outros acidentes.

Conclusões

  • Dispositivos mecânicos de segurança foram eliminados (procedimento relativamente comum, tendo em vista a redução de custos). Colocar demasiada confiança em software é errado. Produtos não podem ser desenvolvidos de forma que uma simples falha de software possa causar uma catástrofe. Dispositivosmecânicos de segurança adicionais devem ser mantidos.
  • A análise de segurança do dispositivo não levou em conta o software desenvolvido.
  • Tendência a acreditar que a causa do acidente havia sido determinada sem uma evidência adequada e sem examinar todos os fatores que contribuíram para o mesmo.
  • Assumir que corrigir um erro em particular iria prevenir futuros acidentes. Sempre existe
    um outro erro...
  • Acidentes em sistemas complexos devem ser vistos do ponto de vista do processo de
    engenharia empregado e não pelo uso de software. Será que algum dia poderemos
    desenvolver software com zero erro?
Características de desenvolvimento do software
  • Ausência de procedimentos de análise, projeto e verificação (teste).
  • Ausência de gerenciamento de projeto e planejamento de manutenção
  • Negligência no projeto de interface
  • Tratamento falho de comunicação com hardware (race condition)
  • Documentação começou a ser feita quando os acidentes foram reportados
  • Apenas hardware foi testado inicialmente. Após os acidentes, hardware e software foram testados em separado e sem nenhum planejamento a cada modificação.
  • Reusabilidade não garante que o novo produto vai funcionar a contento e pode levar a projetos de baixa qualidade e potencialmente perigosos.
  • Cursos de programação e experiência em programação não garantem a produção de software de qualidade
  • Apesar de que o uso de boa prática de engenharia de software não se pode prevenir todos os erros, mas é possível eliminar grande parte deles. É portanto um requisito mínimo.

Referências:

LEVESON, Nancy. “An Investigation of the Therac-25 Accidents”, University of Washington e Clark S. Turner, University of California, Irvine, IEEE Computer, Vol. 26, No. 7, July 1993, pp. 18-41

http://sunnyday.mit.edu/therac-25.html

http://en.wikipedia.org/wiki/Therac_25

http://pt.wikipedia.org/wiki/Therac-25

http://www.cs.washington.edu/people/faculty/leveson.html

http://www.cin.ufpe.br/~if668/Aulas/ICC%20-%20sistemas%20e%20complexidade.pdf#search=%22TIMELINE%20DO%20THERAC%20%22

http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html