A maior rede de estudos do Brasil

Grátis
182 pág.
Apostila ENGENHARIA DE SOFTWARE unicesumar

Pré-visualização | Página 5 de 38

ele existe? O livro reflete a prática moderna da engenharia de software? É 
adaptável, está alinhado para melhorar o tempo de entrega, mantendo o 
foco na qualidade? Em muitos casos, a resposta para essas perguntas é “não”.
Mito: se o cronograma atrasar, poderemos acrescentar mais programa-
dores e ficarmos em dia?
Realidade: o desenvolvimento de software não é um processo mecânico 
como os das fábricas. Nas palavras de Brooks[Bro95]: “acrescentar pes-
soas num projeto de software atrasado o tornará mais atrasado ainda”. 
O que ocorre com a chegada de novas pessoas em um projeto, as que já 
estavam terão de gastar tempo situando os recém-chegados, reduzindo 
consequentemente o tempo destinado ao desenvolvimento produtivo. 
Para que sejam inseridas novas pessoas esta ação deverá ser de forma 
planejada e coordenada.
Mito: posso terceirizar o projeto de software e simplesmente relaxar e dei-
xar a essa empresa realizá-lo.
Realidade: caso essa organização não saiba gerenciar e controlar projetos 
de software, provavelmente irá se deparar com dificuldades.
2. Mitos de Clientes: 
É importante sabermos que os clientes solicitantes do software podem ser pes-
soas comuns, ou seja, não necessariamente é preciso conhecimento específico 
na área computacional, porém, é necessário saber da sua regra de negócio.
Mito: definição geral é suficiente para começar a escrever os programas.
Realidade: nem sempre será possível uma definição ampla e estável dos 
requisitos. Estes são obtidos somente por meio da comunicação entre 
cliente e desenvolvedor, sendo assim nem sempre é possível. 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E24
3. Mitos de profissionais da área:
Tem residido por mais de 50 anos de cultura de programação. Modos e 
atitudes antigos dificilmente são esquecidos.
Mito: uma vez feito programa e colocado em uso, nosso trabalho está 
terminado?
Realidade: uma vez que alguém já disse que “o quanto antes se começa a 
codificar, mais tempo levará para termina-lo”.
Mito: até que um programa entre em funcionamento, não há maneira de 
avaliar sua qualidade.
Realidade: um dos mecanismos de garantia da qualidade de software mais 
eficaz pode ser aplicado desde a concepção de um projeto.
Mito: o único produto passível de entrega é o programa em funcionamento.
Realidade: um programa funcionando é somente uma parte de uma con-
figuração de software que inclui muitos elementos. 
Mito: a engenharia de software nos fará criar documentação volumosa 
e desnecessária.
Realidade: a engenharia de software não trata de criação de documentos, 
mais sim da criação de um produto de qualidade.
Ter ciência das realidades dos profissionais que trabalham com software é 
o primeiro passo para buscar soluções práticas na engenharia de software. 
Por isso, muitos profissionais de software reconhecem com facilidade om 
mitos que acabamos de descrever.
“Se o processo estiver correto, os resultados falarão por si mesmos.” 
Takashi Osada
Software Legado
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
25
SOFTWARE LEGADO
Denominam-se aos softwares antigos os que são foco de contínua atenção e pre-
ocupação desde os anos 1960. Dayani-Fard e seus colegas [Day99] descrevem 
software legado da seguinte forma:
Sistemas de software legado... Foram desenvolvidos há décadas atrás e 
tem sido continuamente modificado para se adequar a mudanças dos 
requisitos de negócio e a plataformas computacionais. A proliferação de 
tais sistemas está causando dores de cabeça para grandes organizações 
que consideram dispendiosos de manter e arriscado de evoluir. 
Liu e seus colegas [Liu98] observaram que “muitos sistemas legados permane-
cem dando suporte para funções de negócios vitais e são ‘indispensáveis’ para 
o mesmo”. 
Softwares legados, por sua vez, podem apresentar projetos não expansí-
veis, código intrincado, documentação inexistente ou escassa, testes que nunca 
foram arquivados. E que, mesmo assim, esses softwares possuem funções vitais 
de negócios e são indispensáveis para ele. Surge-nos, então, a pergunta, o que 
devemos fazer? Nada, isso mesmo, nada, até que o software legado se submeta 
a modificações significativas. 
Vale lembrarmos que, caso o software legado atenda às necessidades de seus 
usuários, possibilitando confiança e vitalidade, não precisa ser “consertados”. 
Entretanto, esses sistemas evoluem com o passar do tempo, por uma ou mais 
das seguintes razões (Pressman 2011): 
 ■ O software deve ser adaptado para atender às necessidades de novos 
ambientes ou de novas tecnologias computacionais.
 ■ O software deve ser aperfeiçoado para implementar novos requisitos de 
negócio.
 ■ O software deve ser expandido para torná-lo interoperável com outros 
bancos de dados ou softwares mais modernos.
 ■ O software deve ser rearquitetado para torná-lo viável dentro de um 
ambiente de rede.
INTRODUÇÃO À ENGENHARIA DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E26
O objetivo da engenharia de software moderna é de “elaborar metodologias 
baseadas na evolução”, ou seja, os softwares modificam-se continuamente e que 
novos softwares são construídos a partir dos antigos... [Day99].
INTRODUÇÃO À QUALIDADE DE SOFTWARE
Para que o software possa ser funcional e prático, é preciso qualidade na pro-
dução e na manutenção. A qualidade em software se refere às características 
dos produtos que atendam requisitos de funcionalidade. Esses requisitos estão 
ligados, diretamente, com a área de utilização do programa. Para cada requi-
sito, temos um campo de abrangência, uma especificidade. Esses requisitos são: 
funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade, por-
tabilidade, estabilidade. 
Esses requisitos fazem parte da qualidade do software de forma que cada 
produto, cada programa, possa atender às necessidades tecnológicas, 
econômicas, sociais, intelectuais e práticas do setor ao qual se 
destinam, observando as especificidades de cada área onde o produto é 
utilizado. Assim deve se levar em consideração a utilização do produto. 
Em áreas econômicas certos requisitos serão mais necessários do que 
na área educacional, onde os requisitos de um programa atendem 
as necessidades daquele público em particular. (VASCONCELOS, 
ROUILLER, MACHADO, MEDEIROS, 2006).
Ao observar essas especificidades, o software responde aos anseios de um mer-
cado em particular. Sem deixar de levar em consideração o que cada um precisa. 
Áreas de lazer precisam de certos requisitos, áreas educacionais outros, áreas 
sociais outros. O programa atende às necessidades de cada setor, sem perder a 
sua qualidade.
Software Legado
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
27
A qualidade se torna uma parte importante em todo o processo de pro-
dução de um software, em que se leva em consideração não apenas aspectos 
tecnológicos, econômicos ou sociais, mas a praticidade do mesmo, as funções 
que desempenha, a facilidade de uso, a capacidade de ser reciclado, manuten-
ção, entre outros. A qualidade visa apresentar um produto completo que atenda 
a todas as necessidades do setor a qual se destina. 
O que é engenharia reversa?
O nome “engenharia reversa” define muito bem o conceito do que ela faz. 
Trata-se do estudo de um objeto, seja um processador, um monitor, um pro-
grama ou até mesmo um simples relógio, desmontando-o e analisando suas 
peças,