Semana 03 - Aula 02

Prévia do material em texto

Exercício para aula de 12/03:
Realizar uma pesquisa textual sobre os seguintes temas:
Crise de Software
Mitos/Verdades sobre o desenvolvimento de Software
Crise do software
Origem: Wikipédia, a enciclopédia livre.
A crise do software foi um termo utilizado nos anos 1970, quando a engenharia de software era praticamente inexistente. O termo 
expressava as dificuldades dodesenvolvimento de software frente ao rápido crescimento da demanda por software, da 
complexidade dos problemas a serem resolvidos e da inexistência de técnicas estabelecidas para o desenvolvimento de sistemas 
que funcionassem adequadamente ou pudessem ser validados.
A noção da crise do software emergiu no final dos anos 60. Uma das primeiras e mais conhecidas referências ao termo foi feita 
por Edsger Dijkstra, na apresentação feita em 1972 na Association for Computing Machinery Prêmio Turing, intitulada "The Humble 
Programmer" (EWD340), publicada no periódico en:Communications of the ACM. O artigo pode ser encontrado em Edsger Dijkstra: 
The Humble Programmer (PDF, 473Kb)
Projetos estourando o orçamento;•
Projetos estourando o prazo;•
Software de baixa qualidade;•
Software muitas vezes não atingiam os requisitos;•
Projetos ingerenciaveis e o código difícil de manter.•
As causas da crise do software estão ligadas a complexidade do processo de software e a relativa imaturidade da engenharia de
software como profissão. A crise se manifesta de varias formas:
A maior parte dos projetos continuam com estes problemas ainda na atualidade, assim pode se dizer que a crise continua vigente 
ainda na atualidade[carece de fontes?].
Análise Econômica de Sistemas de Informações;•
O uso de melhores técnicas, métodos e ferramentas;•
Interesse do governo em treinamentos e educação.[carece de fontes?];•
A mudança de paradigma sobre o que é desenvolver software e como deveria ser feito.•
As soluções para a crise de software
Obtida de "http://pt.wikipedia.org/w/index.php?title=Crise_do_software&oldid=36337656"
De <http://pt.wikipedia.org/w/index.php?title=Crise_do_software&printable=yes> 
A engenharia de software ainda é uma disciplina relativamente nova. A noção de ‘engenharia de software’ surgiu pela 
primeira vez em 1968 em uma conferência organizada para discutir a chamada ‘crise do software’. Essa crise resultava 
diretamente da introdução (naquela época) do poderoso hardware de computador de terceira geração. Sua capacidade 
tornava viáveis aplicações de computador até então inimagináveis. O software resultante era bem maior e mais complexo que 
os sistemas de software precedentes. 
A experiência inicial de construção desses sistemas mostrou que uma abordagem informal do desenvolvimento de software 
não era o bastante. Projetos importantes sofriam atrasos às vezes de alguns anos. por apresentarem custos muito maiores do 
que os inicialmente previstos eles não eram confiáveis eram de difícil manutenção e tinham desempenho inferior. O 
desenvolvimento de software estava em crise. Os custos de hardware caíam enquanto os de software subiam rapidamente. 
Novas técnicas e novos métodos eram necessários para controlar a complexidade inerente aos grandes sistemas de software. 
Essas técnicas se tornaram parte da engenharia de software e são agora amplamente mas não universalmente utilizadas. No 
entanto ainda há problemas em produzir software complexo que atenda às expectativas dos usuários e que seja entregue 
dentro do prazo e do orçamento estabelecido. Muitos projetos de software ainda têm problemas e isso levou alguns críticos 
(Pressman 1997) a sugerirem que a engenharia de software está em um estado de aflição crônica. 
À medida que nossa capacidade de produzir software aumentou também cresceu a complexidade dos sistemas de software 
requeridos. Novas tecnologias que resultam da convergência de sistemas de computadores e de comunicação trazem novas 
questões para os engenheiros de software. Por essa razão e pelo fato de muitas empresas não aplicarem as técnicas de 
engenharia de software de maneira eficaz ainda temos problemas. A situação não é tão ruim quanto os pessimistas sugerem 
mas com certeza há espaço para melhorias. 
Semana 03 - Aula 02
quarta-feira, 12 de março de 2014 19:00
 Página 1 de COM210 - Engenharia de Software 
mas com certeza há espaço para melhorias. 
Houve um grande progresso desde 1968 e o desenvolvimento da engenharia de software melhorou de modo marcante o 
software que produzimos. Temos uma compreensão muito melhor das atividades envolvidas no desenvolvimento de 
software. Desenvolvemos métodos eficazes de especificação projeto e implementação de software. novas notações e 
ferramentas reduzem o esforço necessário para produzir sistemas grandes e complexos. 
Os engenheiros de software podem com razão se orgulhar de suas realizações. Sem softwares complexos não teríamos 
explorado o espaço, não teríamos a internet e as modernas telecomunicações todos os meios de viagem seriam mais 
perigosos e dispendiosos. A engenharia de software tem contribuído muito em sua curta existência e estou convencido de que 
à medida que essa disciplina amadurecer sua contribuição no século XXI será ainda maior.
Fonte: Sommerville, Ian. Engenharia de Software. 6. ed. São Paulo: Addison Wesley, 2003. De 
<http://unifei.bv3.digitalpages.com.br/users/publications/9788588639072/pages/5> 
Mitos e verdades sobre desenvolvimento de software
Os principais mitos da engenharia de software
Um bom manual, repleto de padrões e regras, fornecerá a equipe tudo que ela precisa saber•
Os mitos de software são “falsas verdades” que existem no mundo da indústria de software. Tanto jovens engenheiros quanto 
pessoas mais experientes tendem a acreditar neles, distorcendo a verdadeira face do processo de engenharia. Os mais comuns são:
Caso ocorra atraso no cronograma este poderá ser contornado alocando-se mais programadores ao projeto.•
Desenvolvimento não é uma receita de bolo! Os clientes são diferentes, os projetos são diferentes, os programadores são 
diferentes, as prioridades dependem do projeto. Basicamente, TUDO é diferente. Não pense que um site de ecommerce que você 
desenvolveu para a empresa X valerá para a empresa Y, e vice-versa. O planejamento é fundamental e só então você poderá 
levantar os requisitos necessários e trabalhar em cima de um novo projeto.
Terceirizar um projeto é garantia de tranquilidade e nenhum trabalho.•
Por mais que exista o conceito de “Fábrica de Software” não podemos pensar no processo de desenvolvimento como uma linha de 
produção. Ao se inserir um programador em um projeto, ele levará algum tempo para se familiarizar com o código e com o que está 
sendo feito, para então, começar de fato a produzir. Outro grande pecado que muitos gestores comentem é tratar o programador 
como “pedreiro”, como um “peão”. Se o o desenvolvedor não entende nada do processo da empresa para o qual está 
desenvolvendo, tenha certeza que não poderá contribuir da melhor maneira possível. Mais um vez, quero frisar: Desenvolvimento 
não é linha de produção. Alocar programadores para resolver um problema de cronograma poderá surgir efeito contrário, causando 
mais problemas!
Quando um projeto é muito trabalhoso, requer know-how maior do que a sua equipe possui ou o cronograma está apertado, muitos 
optam pela terceirização achando que esta é uma garantia de tranquilidade e nenhum trabalho. Contudo, tome cuidado: Se a 
empresa X contratou você, você é o responsável pelo trabalho que está entregando. Ou seja, qualquer problema será um problema
seu também! A maioria das empresas terceiriza o serviço, mas ao comprar o código, fica responsável por suas manutenções. Aí fica a 
pergunta: A terceirização fez o serviço direito? Comentou o código? Documentou o que foi feito? Sua equipe tem pessoal para 
trabalharnesse código? Pense bem antes de terceirizar algo que não poderá trabalhar bem no futuro. É melhor recusar um projeto 
do que faze-lo mal feito.
Um software pode ser construído observando-se o seu propósito geral – os detalhes podem ser levados em conta 
posteriormente.
•
Se você é desenvolvedor já deve ter se deparado com um usuário que só queria um ajustizinho no sistema: “só adicione um botão
que faça isso e busque aquilo e faça isso ficar cor de rosa e brilhar girando”. Sim, essas coisas acontecem! Ao se pensar em um 
software deve-se mapear o máximo possível de suas funcionalidades a serem desempenhadas. É claro que em um primeiro 
momento é difícil pensar em tudo, alguma coisa ou outra vai entrar como correção. Mas pensar em algo básico demais e querer 
enfeita-lo demais depois, envolve mais tempo e o pior: retrabalho! Desenvolvedores geralmente não gostam de destruir algo para 
 Página 2 de COM210 - Engenharia de Software 
Mesmo que os requisitos de um software mudem, as alterações são realizadas facilmente pois temos uma boa equipe que sabe como
fazer o serviço muito bem.
•
enfeita-lo demais depois, envolve mais tempo e o pior: retrabalho! Desenvolvedores geralmente não gostam de destruir algo para 
faze-lo de outra forma, pois o cliente mudou de ideia. Aliás, ninguém gosta. Como eu disse, existem exceções, mas se você não 
entende de desenvolvimento e só gerencia o processo, não pense que os seus “detalhes” são realmente detalhes quando viram 
linhas de código!
Se o programa funciona, nosso trabalho está completo.•
Se o programa ainda não está finalizado e “rodando”, não posso avaliar sua qualidade.•
Mais uma vez, se você não é desenvolver e não entende do processo, não julgue uma atualização como simples. Somente um 
programador poderá avaliar o quão simples uma alteração é – e muitas vezes, ela só vai realmente ter a ideia depois que 
estiver trabalhando com o código. Mesmo que você tenha uma boa equipe, modificações devem ser analisadas, 
discutidas com relação a sua viabilidade e testadas. Lembre-se sempre: alocar um programador requer algum tempo 
para que esse se familiarize com o que vem sendo feito. As coisas não são tão simples.
O único produto que entregarei ao cliente é o código executável.•
Esses dois tópicos são assutadoramente passados adiante e você já deve ter ouvido isso de alguém. Se um programa roda isso não 
garante que o seu trabalho está feito. Todo o processo de desenvolvimento deve buscar a qualidade e apenas funcionar não lhe 
garante isso – ou seja, o processo da avaliação de qualidade não se limita a essa etapa. O seu código é bem comentado? 
Está bem feito? Otimizado? A tecnologia utilizada é adequada? Os banco de dados estão otimizados? Sua relações 
foram criadas corretamente? A infraestrutura do cliente suporta o que está sendo desenvolvido? Se o seu sistema foi 
feito para suportar vários acessos, ele realmente suporta isso? Um programa é mais do que o executável. Você vende 
todo o processo.
O processo de planejamento fará com que criemos documentação volumosa que atrasará a execução do projeto, atrasando o 
cronograma.
•
Em alguns casos, o produto “palpável” que o cliente recebe é somente o executável. Em outros, trabalha-se com o código fonte e 
com a documentação. Contudo, independente do caso, lembre que, como foi dito no item anterior: Um programa é mais do que o 
executável. Você vende todo o processo de desenvolvimento. Por isso, deve-se pensar e faze-lo com perfeição.
Planejamento é fundamental! Muitas pessoas aindam confundem planejamento com “papelada” e estas estão terrivelmente 
enganadas! Mesmo trabalhando-se em um time Agile, planejar é fundamental! A documentação do projeto será trabalhada na 
melhor metodologia adotada mas um plano do que será feito deverá ser estudado antes de “colocar a mão na massa”. Somente 
com o estudo dos processos e necessidades do cliente você conseguirá criar um software que trabalhe com excelência!
De <http://eufacoprogramas.com/os-principais-mitos-da-engenharia-de-software/> 
Verdades:
O que é software?
Software não é apenas o programa mas também toda a documentação associada e os dados de configuração 
necessários para fazer com que esses programas operem corretamente. Um sistema de software usualmente consiste 
em uma série de programas separados arquivos de configuração que são utilizados para configurar esses programas, 
documentação do sistema, que descreve a estrutura desse sistema e documentação do usuário que explica como 
utilizar o sistema e no caso dos produtos de software, sites web para os usuários fazerem o download das informações 
recentes sobre o produto. 
Os engenheiros de software se ocupam de desenvolver produtos de software isto é software que possa ser vendido a 
um cliente. Há dois tipos de produtos de software: 
1. produtos genéricos: são sistemas do tipo standalone produzidos por uma organização de desenvolvimento e vendidos 
no mercado a qualquer cliente capaz de adquiri-los. Algumas vezes referimo-nos a eles como pacotes de software. 
Dentre os exemplos desse tipo de produto estão as bases de dados os processadores de texto os pacotes de desenho e 
 Página 3 de COM210 - Engenharia de Software 
Dentre os exemplos desse tipo de produto estão as bases de dados os processadores de texto os pacotes de desenho e 
as ferramentas de gerenciamento de projetos. 
2. produtos sob encomenda (ou personalizados): são os sistemas encomendados por um cliente em particular. O 
software é desenvolvido especialmente para aquele cliente por uma empresa de software. Dentre os exemplos desse 
tipo de software destacam-se os sistemas de controle para dispositivos eletrônicos, sistemas escritos para serem 
compatíveis com um processo de negócios específico e sistemas de controle de tráfego aéreo. 
Uma diferença importante entre esses diversos tipos de software é que, nos produtos genéricos a organização que 
desenvolve o software controla sua especificação. Para os produtos personalizados a especificação é usualmente 
desenvolvida e controlada pela organização que está comprando o software. Os desenvolvedores de software devem 
trabalhar de acordo com essa especificação
O que é um processo de software?
É um conjunto de atividades, cuja meta é o desenvolvimento ou a evolução do software.
Quais os custos da engenharia de software?
Aproximadamente 60 por centos dos custos são relacionados ao desenvolvimento e 40 por cento são custos referentes 
aos testes. Para o software personalizado, os custos de evolução frequentemente excedem os custos de 
desenvolvimento.
Quais são os atributos de um bom software?
O software deve proporcionar ao usuário a funcionalidade e o desempenho requeridos e deve ser passível de 
manutenção, confiável e de fácil uso.
Fonte: Sommerville, Ian. Engenharia de Software. 6. ed. São Paulo: Addison Wesley, 2003. De 
<http://unifei.bv3.digitalpages.com.br/users/publications/9788588639072/pages/5> 
Esforço = Qtd. Funcionalidades * Fatores Ambientais * Fatores Técnicos * Produtividade (Média)
Qualidade de Projeto
Satisfaz as necessidades estabelecidas no contrato•
Adequação ao uso•
Dentro do prazo acordado•
Dentro do custo acordado•
Mitos e Verdades
Gerentes de projetos•
→ Dedicação 
 Profissional
→ Tecnologia 
→Experiência da Equipe na tecnologia
→ Orientada a Objetos
Processo : Conjunto de Atividades
Entrada e a transforma Saída
Histórico
 Página 4 de COM210 - Engenharia de Software 
Produto
Processo (o processo está sendo executado conforme planejado?)
Garantia de qualidade (realidade)
Manuais prontos (mito) -○
Ferramentas de desenvolvimento de software de última geração (mito)○
Paralelismo
Etc
Algumas atividades são necessariamente sequenciais
1 pedreiro -> 10 d
2 pedreiros -> 6 d
3 pedreiros -> 4,5d 
Leidos Retornos Decrescentes
 Declaração geral dos projetos para preencher os detalhes mais tarde
Adicionar mais programadores em projetos atrasados (mito)○
Gerentes de projetos•
○ Mudança tardiamente 
Clientes•
 Manutenção
○ Aplicativo pronto
Profissionais•
 Página 5 de COM210 - Engenharia de Software