ENGENHARIA DE SOFTWARE - AULA 1

Prévia do material em texto

AULA 1 
 
 
 
 
 
 
 
 
 
ENGENHARIA DE SOFTWARE 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Prof. Emerson Antonio Klisiewicz 
 
 
 
 
 
02 
CONVERSA INICIAL 
 Nessa aula 1, estudaremos sobre os modelos clássicos de 
desenvolvimento de sistemas e a introdução à Engenharia de Software. 
CONTEXTUALIZANDO 
O que são softwares? 
 “Software”, segundo o Dicionário Michaelis, consiste em “qualquer 
programa ou grupo de programas que instrui o hardware sobre a maneira como 
ele deve executar uma tarefa, inclusive sistemas operacionais, processadores de 
texto e programas de aplicação.” (Software, 2017). 
O que são Sistemas? 
 Observe as frases: 
 O sistema telefônico no Brasil foi implantado em 1877. 
 O sistema de coleta de lixo funciona bem. 
 O sistema de avaliação é rigoroso para os professores. 
 O sistema circulatório de Tadeu está comprometido. 
 O sistema de vendas em seu relatório mostrou uma desaceleração no 
mercado. 
 Considerando as afirmações acima, podemos definir que os sistemas têm 
sempre o seu objetivo, logo, o objetivo declarado de um sistema é, a priori, a razão 
de sua existência. 
 Hoje, qualquer país, seja desenvolvido ou não, depende de softwares. 
Precisamos, portanto, desenvolver sistemas confiáveis, com um desenvolvimento 
que se dê de forma econômica e em um curto espaço de tempo. 
 Aí fica uma pergunta: “Existe uma diferença entre ser um artista e um 
engenheiro”? 
TEMA 1 – SOFTWARES 
 Instruções: quando executadas, produzem a função e o desempenho 
desejados. 
 
 
03 
 Estruturas de dados: possibilitam que os programas manipulem 
adequadamente a informação. 
 Documentos: descrevem a operação e o uso dos programas. 
1.1 Características do Software 
a. Desenvolvido ou projetado por engenharia, não manufaturado no sentido 
clássico. 
b. Não se desgasta, mas se deteriora. 
c. A maioria é feita sob medida. 
1.2 Aplicações do software 
a. Básico: programas escritos para dar apoio a outros programas. 
b. De tempo real: software que monitora, analisa e controla eventos do 
mundo real. 
c. Comercial: sistemas de operações comerciais e tomadas de decisões 
administrativas. 
d. Científico: caracterizado por algoritmos de processamento de números. 
1.3 Evolução do software 
(1950 – 1965) 
 O hardware sofreu contínuas mudanças. 
 O software arte "secundária" para poucos métodos. 
 O hardware era de propósito geral. 
 O software específico para cada aplicação. 
 Sem documentação. 
(1965 – 1975) 
 Multiprogramação e sistemas multiusuários. 
 Sistemas tempo real. 
 Primeira geração de SGBD’s. 
 Bibliotecas de Software. 
 Cresce o número de sistemas baseado em computador. 
 Manutenção quase impossível. 
 
 
 
04 
TEMA 2 – CRISE DE SOFTWARE 
 Conjunto de problemas encontrados no desenvolvimento de software. 
1. As estimativas de prazo e de custo frequentemente são imprecisas. 
2. A produtividade das pessoas da área de software não acompanha a 
demanda por seus serviços. 
3. A qualidade de software, às vezes, não é adequada. 
4. O software existente é muito difícil de manter. 
Diante desse cenário, as seguintes situações acabaram acontecendo: 
 estimativas de prazo e de custo ; 
 produtividade das pessoas ; 
 qualidade de software ; 
 software difícil de manter . 
2.1 Problemas associados à Crise de Software 
2.1.1 Próprio caráter do software 
 Podemos dizer que Software é a parte lógica do computador. Por 
consequência, determinaremos o seu sucesso pela medição da qualidade de 
apenas uma entidade. O software não sofrerá, como algo físico, um desgaste com 
o passar do tempo, mas, certamente, será corroído pelo tempo, necessitando de 
alterações (manutenções). 
2.1.2 Falhas das pessoas responsáveis pelo desenvolvimento do software 
 Gerentes sem conhecimento ou nulas experiências em softwares. 
Profissionais da área que não recebem novos treinamentos ou especializações 
técnicas de desenvolvimento. Também podemos encontrar, dentro das empresas, 
grande resistência na implementação de mudanças. 
2.1.3 Mitos do software 
 Propagaram desinformação e confusão. 
 
 
05 
 Lenda: Em nossa empresa, possuímos um manual com todos os padrões 
para desenvolvimento de um software. Minha equipe terá tudo o que é 
necessário em termos de conhecimento? 
 Verdade: Esse material é usado pela equipe? Todos os profissionais têm 
conhecimento da sua existência? Nele já estão contidas as formas 
modernas de desenvolvimento? O material está completo? 
 Lenda: Minha equipe usa ferramentas de última geração para o 
desenvolvimento dos sistemas. Recentemente, também adquirimos novas 
máquinas para o desenvolvimento. 
 Verdade: É necessário possuir mais que apenas novos computadores para 
produzir software com qualidade. Todo o conhecimento, aqui também, deve 
estar incluso. 
 Lenda: Como nosso projeto de desenvolvimento de software está atrasado, 
incluiremos novos profissionais na equipe e, com isso, tiraremos o atraso. 
 Verdade: Desenvolver um software é diferente de produzir um produto em 
um processo industrial. Incluir mais pessoas em um projeto pode torná-lo 
mais atrasado ainda. Há que se ter um critério bem definido e planejado 
para a inclusão de novos profissionais em uma equipe de projeto. 
 Lenda: Ter uma visão superficial dos objetivos para o desenvolvimento de 
determinado software é o suficiente para começar a desenvolver os 
programas. O detalhamento pode ser feito posteriormente. 
 Verdade: Uma pobre definição inicial dos requisitos é a grande vilã e, 
talvez, a maior causa de fracassos dos projetos de desenvolvimento de 
software. Ter uma descrição formal e detalhada de toda a informação, 
funcionalidade, desempenho, interfaces internas e externas, restrições e 
validações dos sistemas desenvolvidos são vitais para o sucesso do 
projeto. 
 Lenda: O nosso usuário, constantemente, sugere mudanças em nosso 
projeto. Sem problemas, pois qualquer mudança pode ser facilmente 
implementada, porque o nosso projeto é totalmente flexível. 
 Verdade: Pequenas alterações, solicitadas quando o projeto já está em 
desenvolvimento avançado, podem causar problemas muito maiores do 
que uma grande alteração solicitada durante as fases iniciais do 
desenvolvimento. Tal feito pode ocasionar consideráveis prejuízos à 
qualidade final do produto e do projeto. 
 
 
06 
 Lenda: A partir do momento em que o programa/sistema entrar em 
funcionamento, o trabalho de nossa equipe de desenvolvimento estará 
encerrado. 
 Verdade: É errado pensar dessa forma. Pelas estatísticas das empresas 
de desenvolvimento de software, serão usados, após a entrega do 
programa aos usuários, de 50% a 70% do tempo e esforço gastos com o 
seu desenvolvimento. 
 Lenda: Sem ter em mãos o sistema já funcionando, não é possível avaliar 
a sua qualidade. 
 Verdade: Hoje em dia, ter o programa funcionando é apenas uma parte da 
configuração de Software. Além do mais, com novas formas de 
desenvolvimento, com as metodologias ágeis, temos sempre a entrega de 
artefatos agregando funcionalidades aos programas em que a qualidade é 
vital. 
TEMA 3 – ENGENHARIA DE SOFTWARE 
3.1 Métodos 
 Proporcionam os detalhes de como fazer para construir o software. 
 Mostram o planejamento e a estimativa de projeto. 
 Desenvolvem a análise de requisitos de software e de sistemas. 
 Modelam o projeto da estrutura de dados. 
 Dizem como codificar algoritmo de processamento. 
 Trazem a forma da codificação. 
 Informam como deve ser a fase de teste. 
 Traráas normas a serem seguidas na manutenção. 
3.2 Ferramentas 
 Suportam de forma automatizada os métodos de desenvolvimento. 
Atualmente, existem ferramentas específicas para cada método. Quando 
integradas, é possível estabelecer um sistema de suporte ao processo de 
desenvolvimento de software, o que chamamos de CASE - Computer Aided 
Software Engineering. 
3.3 Procedimentos 
 
 
07 
 Constituem o elo entre os métodos e as ferramentas. São as sequências 
em que os métodos serão aplicados. Informam quais produtos devem ser 
entregues. Definem os controles que ajudam assegurar a qualidade e a coordenar 
as alterações. Trazem as referências que ajudam a administrar o progresso do 
software. 
 O conjunto das etapas que envolvem métodos, ferramentas e 
procedimentos é conhecido como componente de Ciclos de Vida de software. 
 Para a escolha de um Ciclo de Vida de software, devemos levar em conta 
a natureza do projeto e da aplicação, os métodos e as ferramentas a serem 
usados e saber quais controles e produtos precisam ser entregues. 
TEMA 4 – CICLO DE VIDA CLÁSSICO (CASCATA) 
Figura 1 – Ciclo de vida em cascata 
 
 
4.1 Análise e engenharia de sistemas 
 Nessa fase, é preciso realizar a coleta dos requisitos ao nível de sistema, 
já desenvolvendo uma pequena quantidade do projeto e da análise para a criação 
do software/sistema em questão. 
 Essa fase é de suma importância, principalmente quando o software fizer 
interface com hardware, pessoas ou banco de dados. 
4.2 Análise de requisitos de software 
 O processo de levantamento dos requisitos, nessa fase, é reforçado e 
concentrado especificamente no que será desenvolvido. 
 
 
08 
 Deve-se compreender o funcionamento do software e todo o domínio da 
informação, como também saber quais interfaces serão exigidas pelo sistema. 
 Esses requisitos devem ser documentados, revistos e validados junto aos 
usuários/clientes. 
4.3 Projeto 
 É nessa fase que fazemos a transformação dos requisitos do software para 
representações avaliadas antes que a codificação propriamente dita comece. 
 Concentra-se em 4 atributos do programa: 
a. Estrutura de dados. 
b. Arquitetura de software. 
c. Detalhes procedimentais. 
d. Caracterização de interfaces. 
4.4 Codificação 
 Trata-se da passagem de todas as representações do projeto de 
desenvolvimento para uma linguagem de programação definida pela equipe de 
projeto, resultando nas instruções/comandos executáveis pelo computador. 
4.5 Testes 
 Concentram-se, principalmente: 
 Nas características lógicas do software, garantindo que todas as 
instruções/comandos tenham sido testadas ao menos uma vez. 
 Nos quesitos funcionais, os testes visam descobrir erros e garantir que as 
entradas definidas em projeto produzam resultados considerados corretos 
pelos requisitos dos usuários. 
4.6 Manutenção 
 É certo que o software sofrerá mudanças depois de entregue/implantado 
no cliente/usuário. 
 As prováveis situações que podem provocar mudanças são: erros, 
adaptação no software para aceitar determinadas mudanças, alterações de 
 
 
09 
ambiente, solicitações dos usuários para que sejam incluídas alterações 
funcionais e de melhora do desempenho. 
 Podemos citar várias situações-problema na utilização desse modelo, 
como: 
 Projetos reais raramente seguem o fluxo sequencial que o modelo propõe. 
 Logo no início, é difícil estabelecer explicitamente todos os requisitos, pois, 
no começo dos projetos sempre existe uma incerteza natural. 
 O cliente deve ter paciência. 
 Uma versão executável do software só fica disponível numa etapa 
avançada do desenvolvimento. 
TEMA 5 – CICLO DE VIDA EM ESPIRAL 
Figura 2 – Prototipação 
 
 Esse processo clássico de desenvolvimento une suas melhores 
características com o processo de Prototipação, incluindo um novo item 
importantíssimo: a Análise de Risco. Ele segue os passos sistemáticos do Ciclo 
de Vida Clássico, incluindo-os em uma organização iterativa que refletirá, de 
forma mais próxima, o mundo real. O processo de Prototipação pode ser usado 
em qualquer etapa do desenvolvimento, como forma de reduzir os riscos do 
desenvolvimento. 
5.1 Etapas do Ciclo de Vida em Espiral 
 Planejamento: determinará os objetivos, as alternativas e as restrições 
quanto ao desenvolvimento do software. 
 
 
010 
 Análise de risco: realizará uma análise de alternativas e identificação / 
resolução dos possíveis riscos. Normalmente, há 3 alternativas. 
 Construção: codificação dos requisitos, passando-os para a linguagem 
computacional propriamente dita. 
 Avaliação do cliente: homologação do que foi entregue/implantado pelos 
usuários/clientes, para que se efetue o planejamento dos novos passos. 
 Esta é, atualmente, a abordagem mais realística para o desenvolvimento 
de software em grande escala. Capacita o desenvolvedor e o cliente a entenderem 
e reagirem aos riscos em cada etapa evolutiva. Pode ser difícil convencer os 
clientes que uma abordagem "evolutiva" é controlável. Também exige 
considerável experiência na determinação de riscos e depende dessa experiência 
para ter sucesso. 
FINALIZANDO 
 O surgimento de sistemas complexos de software resultou na necessidade 
de reavaliar a forma de desenvolver sistemas. A técnica tem evoluído de forma 
impressionante, notavelmente, no que tange ao seu desenvolvimento. A 
engenharia de software apareceu como o processo ideal para solucionar 
problemas definidos pela crise de software. Independentemente de ser uma crise 
ou um problema crônico, o fato é que as dificuldades persistem, “sendo o 
desenvolvimento de software tarefa árdua que leva muitos desenvolvedores a 
derrota”. (Pressman; Maxim, 2002). Essas situações aumentam o interesse de 
toda a comunidade de desenvolvedores em buscar metodologias que possam 
ajudar, eliminar e minimizar as dificuldades enfrentadas no desenvolvimento dos 
projetos. 
 Deste modo, formalidade, documentação, cumprimento das fases 
estabelecidas e produtos definidos, que fazem parte da abordagem tradicional, e 
em qualquer projeto de desenvolvimento de aplicações, sempre buscarão a 
qualidade final do produto e, consequentemente, a satisfação do cliente. 
 
 
 
011 
REFERÊNCIAS 
PAULA FILHO, W. de P. Engenharia de software: fundamentos, métodos e 
padrões. 3 ed. São Paulo: LTC, 2009. 
PRESSMAN, R.; MAXIM, B. Engenharia de software: uma abordagem 
profissional. Trad. João Eduardo Nóbrega Tortello. 8. ed. Porto Alegre, RS: 
AMGH, 2016. 
SOFTWARE. Michaelis. Dicionário Brasileiro da Língua Portuguesa. Disponível 
em: <http://michaelis.uol.com.br/busca?id=EZ5mx>. Acesso em: 13 set. 2017.