Vous êtes sur la page 1sur 11

AULA 1

ENGENHARIA DE SOFTWARE

Prof. Emerson Antonio Klisiewicz


CONVERSA INICIAL

Nessa aula 1, estudaremos sobre os modelos clssicos de


desenvolvimento de sistemas e a introduo Engenharia de Software.

CONTEXTUALIZANDO

O que so softwares?

Software, segundo o Dicionrio 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 aplicao. (Software, 2017).

O que so Sistemas?

Observe as frases:

O sistema telefnico no Brasil foi implantado em 1877.


O sistema de coleta de lixo funciona bem.
O sistema de avaliao rigoroso para os professores.
O sistema circulatrio de Tadeu est comprometido.
O sistema de vendas em seu relatrio mostrou uma desacelerao no
mercado.

Considerando as afirmaes acima, podemos definir que os sistemas tm


sempre o seu objetivo, logo, o objetivo declarado de um sistema , a priori, a razo
de sua existncia.
Hoje, qualquer pas, seja desenvolvido ou no, depende de softwares.
Precisamos, portanto, desenvolver sistemas confiveis, com um desenvolvimento
que se d de forma econmica e em um curto espao de tempo.
A fica uma pergunta: Existe uma diferena entre ser um artista e um
engenheiro?

TEMA 1 SOFTWARES

Instrues: quando executadas, produzem a funo e o desempenho


desejados.

02
Estruturas de dados: possibilitam que os programas manipulem
adequadamente a informao.
Documentos: descrevem a operao e o uso dos programas.

1.1 Caractersticas do Software

a. Desenvolvido ou projetado por engenharia, no manufaturado no sentido


clssico.
b. No se desgasta, mas se deteriora.
c. A maioria feita sob medida.

1.2 Aplicaes do software

a. Bsico: 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 operaes comerciais e tomadas de decises
administrativas.
d. Cientfico: caracterizado por algoritmos de processamento de nmeros.

1.3 Evoluo do software

(1950 1965)
O hardware sofreu contnuas mudanas.
O software arte "secundria" para poucos mtodos.
O hardware era de propsito geral.
O software especfico para cada aplicao.
Sem documentao.

(1965 1975)
Multiprogramao e sistemas multiusurios.
Sistemas tempo real.
Primeira gerao de SGBDs.
Bibliotecas de Software.
Cresce o nmero de sistemas baseado em computador.
Manuteno quase impossvel.

03
TEMA 2 CRISE DE SOFTWARE

Conjunto de problemas encontrados no desenvolvimento de software.

1. As estimativas de prazo e de custo frequentemente so imprecisas.


2. A produtividade das pessoas da rea de software no acompanha a
demanda por seus servios.
3. A qualidade de software, s vezes, no adequada.
4. O software existente muito difcil de manter.

Diante desse cenrio, as seguintes situaes acabaram acontecendo:

estimativas de prazo e de custo ;


produtividade das pessoas ;
qualidade de software ;
software difcil de manter .

2.1 Problemas associados Crise de Software

2.1.1 Prprio carter do software

Podemos dizer que Software a parte lgica do computador. Por


consequncia, determinaremos o seu sucesso pela medio da qualidade de
apenas uma entidade. O software no sofrer, como algo fsico, um desgaste com
o passar do tempo, mas, certamente, ser corrodo pelo tempo, necessitando de
alteraes (manutenes).

2.1.2 Falhas das pessoas responsveis pelo desenvolvimento do software

Gerentes sem conhecimento ou nulas experincias em softwares.


Profissionais da rea que no recebem novos treinamentos ou especializaes
tcnicas de desenvolvimento. Tambm podemos encontrar, dentro das empresas,
grande resistncia na implementao de mudanas.

2.1.3 Mitos do software

Propagaram desinformao e confuso.

04
Lenda: Em nossa empresa, possumos um manual com todos os padres
para desenvolvimento de um software. Minha equipe ter tudo o que
necessrio em termos de conhecimento?
Verdade: Esse material usado pela equipe? Todos os profissionais tm
conhecimento da sua existncia? Nele j esto contidas as formas
modernas de desenvolvimento? O material est completo?
Lenda: Minha equipe usa ferramentas de ltima gerao para o
desenvolvimento dos sistemas. Recentemente, tambm adquirimos novas
mquinas para o desenvolvimento.
Verdade: necessrio possuir mais que apenas novos computadores para
produzir software com qualidade. Todo o conhecimento, aqui tambm, 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 critrio bem definido e planejado
para a incluso de novos profissionais em uma equipe de projeto.
Lenda: Ter uma viso superficial dos objetivos para o desenvolvimento de
determinado software o suficiente para comear a desenvolver os
programas. O detalhamento pode ser feito posteriormente.
Verdade: Uma pobre definio inicial dos requisitos a grande vil e,
talvez, a maior causa de fracassos dos projetos de desenvolvimento de
software. Ter uma descrio formal e detalhada de toda a informao,
funcionalidade, desempenho, interfaces internas e externas, restries e
validaes dos sistemas desenvolvidos so vitais para o sucesso do
projeto.
Lenda: O nosso usurio, constantemente, sugere mudanas em nosso
projeto. Sem problemas, pois qualquer mudana pode ser facilmente
implementada, porque o nosso projeto totalmente flexvel.
Verdade: Pequenas alteraes, solicitadas quando o projeto j est em
desenvolvimento avanado, podem causar problemas muito maiores do
que uma grande alterao solicitada durante as fases iniciais do
desenvolvimento. Tal feito pode ocasionar considerveis prejuzos
qualidade final do produto e do projeto.

05
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 estatsticas das empresas
de desenvolvimento de software, sero usados, aps a entrega do
programa aos usurios, de 50% a 70% do tempo e esforo gastos com o
seu desenvolvimento.
Lenda: Sem ter em mos o sistema j funcionando, no possvel avaliar
a sua qualidade.
Verdade: Hoje em dia, ter o programa funcionando apenas uma parte da
configurao de Software. Alm 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 Mtodos

Proporcionam os detalhes de como fazer para construir o software.


Mostram o planejamento e a estimativa de projeto.
Desenvolvem a anlise de requisitos de software e de sistemas.
Modelam o projeto da estrutura de dados.
Dizem como codificar algoritmo de processamento.
Trazem a forma da codificao.
Informam como deve ser a fase de teste.
Trar as normas a serem seguidas na manuteno.

3.2 Ferramentas

Suportam de forma automatizada os mtodos de desenvolvimento.


Atualmente, existem ferramentas especficas para cada mtodo. Quando
integradas, possvel estabelecer um sistema de suporte ao processo de
desenvolvimento de software, o que chamamos de CASE - Computer Aided
Software Engineering.

3.3 Procedimentos
06
Constituem o elo entre os mtodos e as ferramentas. So as sequncias
em que os mtodos sero aplicados. Informam quais produtos devem ser
entregues. Definem os controles que ajudam assegurar a qualidade e a coordenar
as alteraes. Trazem as referncias que ajudam a administrar o progresso do
software.
O conjunto das etapas que envolvem mtodos, 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 aplicao, os mtodos e as ferramentas a serem
usados e saber quais controles e produtos precisam ser entregues.

TEMA 4 CICLO DE VIDA CLSSICO (CASCATA)

Figura 1 Ciclo de vida em cascata

4.1 Anlise e engenharia de sistemas

Nessa fase, preciso realizar a coleta dos requisitos ao nvel de sistema,


j desenvolvendo uma pequena quantidade do projeto e da anlise para a criao
do software/sistema em questo.
Essa fase de suma importncia, principalmente quando o software fizer
interface com hardware, pessoas ou banco de dados.

4.2 Anlise de requisitos de software

O processo de levantamento dos requisitos, nessa fase, reforado e


concentrado especificamente no que ser desenvolvido.

07
Deve-se compreender o funcionamento do software e todo o domnio da
informao, como tambm saber quais interfaces sero exigidas pelo sistema.
Esses requisitos devem ser documentados, revistos e validados junto aos
usurios/clientes.

4.3 Projeto

nessa fase que fazemos a transformao dos requisitos do software para


representaes avaliadas antes que a codificao propriamente dita comece.
Concentra-se em 4 atributos do programa:

a. Estrutura de dados.
b. Arquitetura de software.
c. Detalhes procedimentais.
d. Caracterizao de interfaces.

4.4 Codificao

Trata-se da passagem de todas as representaes do projeto de


desenvolvimento para uma linguagem de programao definida pela equipe de
projeto, resultando nas instrues/comandos executveis pelo computador.

4.5 Testes

Concentram-se, principalmente:

Nas caractersticas lgicas do software, garantindo que todas as


instrues/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 usurios.

4.6 Manuteno

certo que o software sofrer mudanas depois de entregue/implantado


no cliente/usurio.
As provveis situaes que podem provocar mudanas so: erros,
adaptao no software para aceitar determinadas mudanas, alteraes de

08
ambiente, solicitaes dos usurios para que sejam includas alteraes
funcionais e de melhora do desempenho.
Podemos citar vrias situaes-problema na utilizao desse modelo,
como:

Projetos reais raramente seguem o fluxo sequencial que o modelo prope.


Logo no incio, difcil estabelecer explicitamente todos os requisitos, pois,
no comeo dos projetos sempre existe uma incerteza natural.
O cliente deve ter pacincia.
Uma verso executvel do software s fica disponvel numa etapa
avanada do desenvolvimento.

TEMA 5 CICLO DE VIDA EM ESPIRAL

Figura 2 Prototipao

Esse processo clssico de desenvolvimento une suas melhores


caractersticas com o processo de Prototipao, incluindo um novo item
importantssimo: a Anlise de Risco. Ele segue os passos sistemticos do Ciclo
de Vida Clssico, incluindo-os em uma organizao iterativa que refletir, de
forma mais prxima, o mundo real. O processo de Prototipao 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 restries


quanto ao desenvolvimento do software.
09
Anlise de risco: realizar uma anlise de alternativas e identificao /
resoluo dos possveis riscos. Normalmente, h 3 alternativas.
Construo: codificao dos requisitos, passando-os para a linguagem
computacional propriamente dita.
Avaliao do cliente: homologao do que foi entregue/implantado pelos
usurios/clientes, para que se efetue o planejamento dos novos passos.

Esta , atualmente, a abordagem mais realstica 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 difcil convencer os
clientes que uma abordagem "evolutiva" controlvel. Tambm exige
considervel experincia na determinao de riscos e depende dessa experincia
para ter sucesso.

FINALIZANDO

O surgimento de sistemas complexos de software resultou na necessidade


de reavaliar a forma de desenvolver sistemas. A tcnica tem evoludo 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 crnico, o fato que as dificuldades persistem, sendo o
desenvolvimento de software tarefa rdua que leva muitos desenvolvedores a
derrota. (Pressman; Maxim, 2002). Essas situaes 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, documentao, cumprimento das fases
estabelecidas e produtos definidos, que fazem parte da abordagem tradicional, e
em qualquer projeto de desenvolvimento de aplicaes, sempre buscaro a
qualidade final do produto e, consequentemente, a satisfao do cliente.

010
REFERNCIAS

PAULA FILHO, W. de P. Engenharia de software: fundamentos, mtodos e


padres. 3 ed. So Paulo: LTC, 2009.

PRESSMAN, R.; MAXIM, B. Engenharia de software: uma abordagem


profissional. Trad. Joo Eduardo Nbrega Tortello. 8. ed. Porto Alegre, RS:
AMGH, 2016.

SOFTWARE. Michaelis. Dicionrio Brasileiro da Lngua Portuguesa. Disponvel


em: <http://michaelis.uol.com.br/busca?id=EZ5mx>. Acesso em: 13 set. 2017.

011

Vous aimerez peut-être aussi