Engenharia de software Pressman CAP 3

30.3 Faça uma pesquisa (verifique no site da SEI) e determine a distribuição da maturidade de processo para organizações de software nos estados unidos e no mundo todo.

https://processoeletronico.gov.br/projects/sei/

SÓ ENCONTREI NO SITE DA SEI ESTE ARTIGO DE 1991 ,

MAS NEM SEI SE É RELEVANTE =[

As indústrias de software americanas e japonesas são bastante diferentes na estrutura e nos produtos. Segundo Humphrey et. al(1991), a partir de um estudo comparativo dos processos de maturidade do software americano e japonês, estes países apresentam as seguintes semelhanças:

- Com apenas pequenas diferenças de terminologia, o modelo de maturidade de software e o Questionário SEI parecem aplicar-se igualmente bem para grupos de software em ambos países.

- Com poucas exceções, o nível de prática de software em ambos países é muito baixo. Este não é apenas um problema para as organizações envolvidas, mas também é uma questão de importância nacional: a má gestão continuada de recursos de software vai retardar seriamente a aplicação de tecnologias computacionais potencialmente benéficas em ambos os países.

- Algumas organizações de ambos os países alcançaram níveis muito elevados de processo de maturidade. Isto demonstra que as melhorias na maturidade são eficazes em ambos os países e que ambos têm a capacidade técnica e de gestão para trabalhar neste nível.

Ainda baseado neste estudo de 1991, para a indústria de software japonesa, algumas conclusões adicionais foram:

- A suspeita de alta capacidade de alguns dos grupos de núcleo de software (fábricas de software) nas empresas líderes na área da computação é uma força nacional. Com base no estudo, verificou-se que esta força não era transferida para o resto da indústria de software.

- O grande ramo da indústria de software japonesa que desenvolve softwares personalizados parecia estar mal gerido e apoiado. Sem processo focado e qualidade de gestão dos recursos, a indústria inteira provavelmente permanecerá no nível 1 por um futuro indefinido.

- Devido a limitação em engenharia de software e currículos em ciência da computação nas Universidades japonesas, eles não são susceptíveis de resolver a necessidade de a mão de obra com a escassez com novos licenciados.

- O fraco estado da prática software japonês era de preocupação nacional. O Ministério do Comércio e Indústria Internacional (MITI) declarou em 1990 que o software de computador é de importância nacional.

- O uso difundido de software prepackaged é provavelmente o único palpite para responder os problemas de recursos de software e de maturidade processo do Japão.

Algumas conclusões deste estudo para a indústria de software os EUA foram:

- A visão de que a indústria de software japonesa está à frente dos EUA não tem fundamento.

- Na área de sistemas de software, a pequena elite de grupos de programação nos principais fabricantes de computadores japoneses pareciam estar em pé de igualdade e possivelmente até mesmo à frente das melhores práticas dos Estados Unidos.

- Na área de produtos de pacotes de software, os EUA têm uma clara liderança em todo o mundo, mas estas empresas ignoravam o mercado japonês. Se história serve de guia, os japoneses vão estabelecer um mercado interno forte e usá-lo como um trampolim para alcançar o domínio mundial.

HUMPHEY, W.S., KITSON, D.H., GALE, J. A Comparison of U.S. and Japanese Software Process Maturity. 1991. CMU/SEI-91-TR-027. Disponível em http://resources.sei.cmu.edu/asset_files/TechnicalReport/1991_005_001_15971.pdf acesso em 12 de maio de 2015.

30.4 Você trabalha para uma pequena organização de software - apenas 11 pessoas estão envolvidas no desenvolvimento do software. A SPI é adequada a sua empresa? Explique sua resposta.

Sim, pois hoje as organizações de pequeno porte, estão utilizando os padrões e praticadas que foram primeiramente adotadas pelas grandes empresas. Nesse contexto vale apresentar algumas deficiências na adoção destes padrões, sendo a organização, por terem um número limitado de profissionais, os gerentes – engenheiros, podem sobrecarregar a equipe o que possibilita atrasado até que todos os envolvidos venham a deter todo o conhecimento para a efetividade do processo, mas como é apresentado a equipe precisa quando como se acertar proporcionará uma grande eficiência, e com isso agregar valor ao desenvolvimento e por fim a rentabilidade para a organização.

30.7 Como é aplicado o gerenciamento de risco no contexto da SPI?

É aplicado de forma que visa encontrar os prováveis risco no desenvolvimento de um software. Sendo que a organização deve administrar o risco em três pontos, o primeiro antes de iniciar o roteiro da SPI; durante a execução das atividades de SPI; e por fim durante a atividade de avalização - quando há uma ocorrência. A partir dos levantamentos de cada risco encontrado, é possível produzir um tabela que apresente o impacto que o risco oferece a organização, e ainda avaliasse o impacto para determinar em qual categoria ele se enquadra, sendo as categoria de desempenho, suporte, custo ou cronograma.