Escolar Documentos
Profissional Documentos
Cultura Documentos
Modelo em Cascata
Tambm chamado de clssico, ou linear, o mais tradicional processo de
desenvolvimento de software.
Esse modelo sugere uma abordagem sequencial e sistemtica para o
desenvolvimento de software, aplicando as atividades de maneira linear. Em
cada fase desenvolvem-se artefatos (produtos de software) que servem de
base para as fases seguintes.
Vide figura proposta por Pressman (2011) para esse modelo.
Modelo Incremental
Este modelo foi proposto como uma alternativa ao modelo em cascata,
aplicando-o iterativamente, tendo como objetivo a elaborao de um
produto operacional a cada incremento. Os primeiros incrementos so
verses simplificadas do produto final, mas oferecem capacidades que
servem ao usurio, alm de servir como uma plataforma de avaliao.
Em cada iterao uma parte concebida como a menor unidade que pode
ser implementada e ainda assim fornecer alguma funcionalidade til para os
usurios.
Os modelos incrementais combinam elementos dos fluxos de processos
lineares e paralelos.
Na figura seguinte, o modelo incremental aplica sequncias lineares, de
forma escalonada, medida que o tempo vai avanando. Cada sequncia
linear gera incrementais (entregveis/aprovados/liberados) do software.
Vantagens da prototipagem:
maior participao e comprometimento dos clientes e usurios; e
os resultados so apresentados mais rapidamente.
Crticas:
forte dependncia das linguagens e ambientes utilizados, bem como da
experincia da equipe;
o cliente tende a considerar o prottipo como verso final, podendo
comprometer a qualidade do projeto; e
o desenvolvedor tende a fazer concesses na implementao, a fim de
colocar um prottipo em funcionamento rapidamente. Estas concesses
podem se tornar parte integrante do sistema.
Modelo Espiral
No modelo Espiral, assume-se que o processo de desenvolvimento ocorre em
ciclos, cada um contendo fases de avaliao e planejamento em que a opo
de abordagem para a prxima fase (ou ciclo) determinada.
Neste modelo acrescenta-se a Anlise dos Riscos ao ciclo de vida para
auxiliar as decises a respeito da prxima iterao. A figura seguinte
apresenta o esquema desse modelo.
Testes (Test);
Distribuio ou Entrega (Deployment);
Gerncia de Configurao e Mudanas (Configuration and Change
Management); e
Ambiente (Enviroment).
Processo gil
A Engenharia de Software vem h anos criando tcnicas de modelagem,
projeto e desenvolvimento de sistemas. Dentre os desafios dos pesquisadores
da rea, pode-se citar a preocupao em desenvolver softwares com qualidade
garantida, no prazo estabelecido e sem alocar recursos alm do previsto. No
entanto, muitas das metodologias criadas so consumidoras de muitos
recursos, aplicando-se principalmente a grandes sistemas.
SCRUM
O Scrum um processo de desenvolvimento gil de software baseado em
grupos de prticas e papeis pr-definidos. Ele um processo iterativo e
incremental para gerenciamento de projetos e desenvolvimento de
sistemas, em que cada sprint uma iterao que segue um ciclo PDCA (Plan,
Do, Check, Act) e entrega um incremento de software pronto.
Os principais papis do Scrum so: Product Owner, Scrum Master e
Scrum Team (equipe do projeto).
No h como fazermos um mapeamento direto entre os papis do Scrum e os
papis convencionais conhecidos. No existe a figura nica do Gerente de
Projetos. Suas responsabilidades esto diludas entre os papis citados. Cada
um conhece sua participao frente ao projeto e trabalha em conjunto para
conseguir alcanar o goal definido.
Seus artefatos principais so: o Product Backlog (Produto Backlog) e
Sprint Backlog artefatos que representam seus requisitos/atividades, alm
de Burndown charts e impediment backlogs.
eXtreme Programming
A eXtreme Programming faz parte tambm de uma srie de mtodos
denominados geis (agile). Estes mtodos foram inicialmente considerados
leves (lightweight) para diferenci-los dos mtodos tradicionais de
desenvolvimento considerados pesados (heavyweight), os quais seriam
baseados na produo de uma grande quantidade de documentao e modelos
para guiar a programao.
Ao contrrio dos mtodos tradicionais que so orientados ao planejamento,
previsibilidade e ao controle, os mtodos geis so orientados construo,
testes e principalmente, s pessoas. As metodologias geis enfatizam
os aspectos humanos, as relaes pessoais, uma vez que buscam
valorizar o pensamento criativo dos indivduos envolvidos no projeto,
em que o conhecimento fator importante para o sucesso do projeto.
No desenvolvimento gil a metodologia deve produzir conhecimento e no
apenas documentao. Mas isto no significa que nos ambientes geis no
exista documentao, apenas deixa de existir a filosofia de que tudo tem que
ser documentado e sim documentar apenas o necessrio uma vez que a
documentao apenas auxilia e no guia o desenvolvimento.
Na prxima figura podemos comparar a XP ao modelo tradicional de
desenvolvimento de software.
Valores
Para implantar a XP necessrio que se norteie o trabalho baseado em quatro
valores:
Comunicao: o principal valor da XP. Grande parte das tcnicas da XP
est baseada na comunicao, e se esta no for eficiente, pode causar
problemas e atrasos no desenvolvimento do sistema.
Simplicidade: a XP utiliza-se da simplicidade para implementar apenas
aquilo que suficiente para o cliente, no se procura fazer especulaes
sobre necessidades futuras, pois quase sempre so especulaes errneas,
deixamos os problemas do futuro para o futuro.
Feedback: o cliente deve receber o sistema o quanto antes, a fim de poder
dar um feedback rpido, guiando assim o desenvolvimento do software.
Coragem: preciso muita coragem para mudar a maneira pela qual
desenvolve-se sistemas. Colocar um sistema em produo assim que ele
tenha valor para o cliente, fazer apenas o que se precisa para o momento e
calcar o processo de anlise principalmente na comunicao no fcil, e
precisa que a equipe esteja realmente decidida a mudar o seu processo de
desenvolvimento.
Prticas
A XP baseada em um conjunto de tcnicas fundamentais (prticas), que
podem ser aplicadas individualmente, cada uma delas gerando melhorias no
processo de desenvolvimento, mas que funcionam melhor em conjunto, uma
vez que uma tcnica refora o resultado da outra. Apresenta-se a seguir uma
descrio de cada prtica.
Cliente Presente (On-site customer)
Na XP todas as decises sobre o rumo do projeto devem ser tomadas pelo
cliente. Ele deve priorizar as tarefas, ser responsvel pelos testes de aceitao,
e, acima de tudo, orientar e tirar dvidas dos desenvolvedores durante o
processo de programao.
Se o cliente no puder estar junto dos desenvolvedores, algumas tcnicas
podem ser utilizadas, como, por exemplo, nomear um membro da equipe para
representar o cliente. Tambm se podem agendar reunies de
acompanhamento com o cliente, pelo menos uma vez por semana. Nestas
reunies haver muita discusso sobre prioridades, mas deve-se destinar uma
parte significativa da mesma para que os programadores possam saber o que
e como desenvolver.
Jogo do Planejamento (The Planning Game)
O XP utiliza o planejamento para assegurar que a equipe de desenvolvimento
esteja sempre trabalhando naquilo que ir gerar maior valor para o cliente a
cada dia de trabalho. Este planejamento feito diversas vezes ao longo do
projeto, para que todos tenham a oportunidade de revisar as prioridades.
Na XP o planejamento um processo contnuo, e o mesmo constantemente
refinado pelo cliente e pela equipe de desenvolvimento, deixando assim a
metodologia bastante flexvel e entregando para o cliente sempre o mximo
valor pelo investimento dele.
Pequenos Lanamentos (Small Releases)
Para que o cliente possa fornecer constantemente feedback sobre o andamento
do sistema, fazendo possvel que o jogo do planejamento (planning game) seja
executado, importante que o sistema tenha releases pequenos, a fim de
ajustar o desenvolvimento s necessidades que vo surgindo no decorrer do
processo.
Normalmente, trabalha-se com pequenas iteraes gerando releases mais
curtos, mas algumas empresas vm suprimindo a etapa das iteraes,
lanando direto um release por semana.
Quanto menor o intervalo de tempo entre cada verso que o cliente recebe,
mais fcil ser corrigir eventuais problemas, pois no ter sido entregue uma
quantidade muito grande de funcionalidades, e mais fcil ser fazer algum
ajuste no software para atender a uma mudana de requisitos. Alm disso, o
XP recomenda que o cliente busque selecionar as funcionalidades que mais vo
gerar valor para ele, com isso fazemos com que o cliente tenha um retorno de
investimento o mais cedo possvel.
Desenvolvimento Guiado pelos testes (Test First Design)
O desenvolvimento guiado pelos testes define que qualquer mtodo de um
objeto que possa falhar deve ter um teste automatizado que garanta o seu
funcionamento.
Modelo Concorrente
Esse modelo, algumas vezes denominado engenharia concorrente,
possibilita equipe de software representar elementos concorrentes e
iterativos de qualquer um dos modelos de processos aqui descritos. Como
exemplo, a atividade de modelagem definida para o modelo espiral pode ser
realizada invocando uma ou mais das seguintes aes de engenharia de
software: prototipagem, anlise e projeto (Pressman, 2011).
Objetivos
Medir o tamanho das funcionalidades requisitadas e recebidas pelo usurio
Medir desenvolvimento e manuteno de software independente da
tecnologia. Por buscar independncia da tecnologia utilizada para a
construo do software, a APF independe da linguagem de programao
utilizada.
Viso do Usurio
Usurio qualquer pessoa ou coisa que interaja com a aplicao ou
especifique seus requisitos, como: Pessoa fsica; outra aplicao; Hardware;
Ator em um caso de uso; Gestores de negcio que o software ir atender.
Uma viso do usurio representa uma descrio formal das necessidades do
negcio do usurio, na linguagem do usurio.
uma descrio das funes do negcio.
aprovada pelo usurio.
Pode ser usada para contar pontos de funo. Pode variar na forma fsica
(ex., catlogo de transaes, propostas, documento de requisitos,
especificaes externas, especificaes detalhadas, manuais do usurio).
Processo de Clculo:
Avaliar o impacto de cada uma das 14 caractersticas em relao
ao sistema que est sendo avaliado, atribuindo pontuao de 0 a 5
para cada caracterstica.
Comentrios
Encapsular colocar em uma cpsula. Por mais estranho que parea, pense
que voc poderia colocar todos os itens desejados em uma cpsula (como em
um remdio) e proteger os componentes internos da ao externa.
Em Orientao a Objetos bem semelhante. A ideia de encapsular criar uma
proteo para os itens do objeto de forma que somente por meio das
interfaces criadas possa ocorrer o acesso s estruturas internas. Isto cria uma
proteo para os itens do objeto, que passam a ter o acesso controlado por
meio da interface.
O objetivo separar os aspectos externos (o que faz) dos aspectos internos
(como faz):
Aspectos externos = interface, contrato;
Aspectos internos = implementao.
O encapsulamento pode ser visto como um complemento da abstrao:
A abstrao foca o comportamento observvel de um objeto.
Comentrios
Na orientao a objetos, o conceito de identidade define que um objeto
uma instncia nica de uma classe, ocupando uma posio de memria
especfica. Ento, podemos ter dois objetos no-idnticos (ocupam posies de
memria distintas), mas iguais (so da mesma classe e possuem os mesmos
valores para os atributos).
Alm disso, cada objeto ao ser criado, aloca espao de memria para si e
possui seus dados armazenados em estrutura prpria. No h confuso entre
os objetos, especialmente quanto identidade. Para simplificar o
entendimento, podemos pensar em cada objeto como uma varivel
estruturada contendo os atributos.
Gabarito: item correto.
3. (CESPE/2010/TRE-MT/Tcnico Judicirio/Programao de
Sistemas) A estrutura interna de um objeto possui dois componentes
bsicos: atributos, que descrevem o estado do objeto; e mtodos, que so
responsveis pela comunicao entre objetos.
Comentrios
Em orientao a objeto, um mtodo uma subrotina que executada por um
objeto ao receber uma mensagem. Os mtodos determinam o comportamento
dos objetos de uma classe e so anlogos funes ou procedimentos da
programao estruturada. A comunicao entre os objetos realizada por
mensagens que um objeto envia a outro.
Gabarito: item errado.
Comentrios
A UML (Unified Modeling Language - Linguagem Unificada para
Modelagem) normalmente definida como uma linguagem de modelagem e
no um mtodo propriamente dito. A UML apresenta uma srie de diagramas
para a modelagem de sistemas orientados a objetos.
De todos os diagramas da UML, o diagrama de classes o mais comumente
utilizado pelas empresas. Esse diagrama, de forma simplificada, descreve os
tipos de objetos do software e os vrios tipos de relacionamentos estticos
que existem entre eles. Uma proposta de processo de desenvolvimento que
pode ser utilizada em conjunto o RUP (Rational Unified Process), definido por
Booch, Jacobson e Rumbaugh.
Objetos
Classes
Permitem que sejam representados no mundo computacional elementos
do mundo real, ou seja, do problema para o qual o software est sendo
desenvolvido.
Elas permitem descrever um conjunto de objetos que compartilhem os
mesmos atributos, operaes, relacionamentos e semntica, e
representam o principal bloco de construo de um
software orientado a objetos.
Comentrios
Os objetos comunicam-se por meio de mensagens (interface) e os
relacionamentos acontecem por meio de associaes.
Gabarito: item errado.
Comentrios
Item a. Coleo de mtodos que indica que uma classe possui algum
comportamento alm do que herda de suas superclasses. Os mtodos includos
em uma interface no definem esse comportamento; essa tarefa definida nas
classes que implementam a interface. ITEM FALSO.
Item b. Permite que referncias de tipos de classes mais abstratas
representem o comportamento das classes concretas que referenciam. Assim,
possvel tratar vrios tipos de maneira homognea (atravs da interface do
tipo mais abstrato). O termo polimorfismo originrio do grego e significa
"muitas formas" (poli = muitas, morphos = formas). ITEM VERDADEIRO.
Item c. o mecanismo pelo qual uma classe (sub-classe) pode estender outra
classe (super-classe), aproveitando seus comportamentos (mtodos) e
variveis possveis (atributos). Um exemplo: Mamfero super-classe de
Humano. Logo, um Humano um mamfero. H herana mltipla quando uma
sub-classe possui mais de uma super-classe. ITEM FALSO.
Item d. Consiste na separao de aspectos internos e externos de um objeto.
Este mecanismo utilizado amplamente para impedir o acesso direto ao
Comentrios
"Melhorar o projeto depois que foi escrito" uma premissa do XP.
o processo de mudar um sistema de software de tal forma que no se
altera o comportamento externo do cdigo, mas melhora sua estrutura
interna. um meio disciplinado de limpar o cdigo e que reduz as
possibilidades de introduzir erros. Em essncia quando voc refina o cdigo,
voc melhora o projeto depois que este foi escrito.
Gabarito: item correto.
Comentrios
A participao dos objetos de ambas as classes na associao obrigatria
porque o valor mnimo da multiplicidade 1 em ambos os lados, e deve ser
lembrado que a participao uma caracterstica da associao que est
Comentrios
Como a composio um tipo de relacionamento que expressa a ao de fazer
parte de algo, quando se fala que pedidos so formados por itens de pedido,
este tipo de relacionamento seria o que expressaria melhor o que esta frase
exprime.
Gabarito: letra D.
Comentrios
A resposta correta seria incluso, porque o caso de uso "Fornecer
identificao" inclui o comportamento de validar a senha do cliente no caso de
uso Realizar transferncia, sendo assim podemos dizer que Realizar
transferncia usa o caso de uso "Fornecer identificao".
Gabarito: letra E.
Comentrios
Item a. O Diagrama de Classe mostra as diferentes classes que fazem um
sistema e como elas se relacionam. Os diagramas de classe so chamados
diagramas estticos porque mostram as classes, com seus mtodos e
atributos bem como os relacionamentos estticos entre elas: quais classes
conhecem quais classes ou quais classes so parte de outras classes, mas
no mostram a troca de mensagens entre elas. ITEM FALSO.
Item b. Como foi mencionada na letra anterior, os Diagramas de Classe so
chamados diagramas estticos porque mostram as classes, com seus
mtodos e atributos bem como os relacionamentos estticos entre elas. ITEM
VERDADEIRO.
Comentrios
Uma subclasse (ou classe derivada) uma classe que herda comportamentos
de outra classe, podendo sobrecarregar funcionalidades e adicionar novas a
uma classe base (ou classe pai), construtores e destrutores no so herdados,
e somente mtodos e atributos pblicos e protegidos so herdados. Mtodos
pblicos e protegidos podem ser visveis por outras classes.
Gabarito: letra C.
A) Classes e Estados
B) Dados e Controle
C) Eventos e Estados
D) Dados e Estados
E) Classes e Controle
Comentrios
Os dois ltimos modelos dados e controle correspondem aos modelos de
Classes e Estados, letra A.
Classificao significa que os objetos com a mesma estrutura de dados
(chamados atributos) e o mesmo comportamento (chamados operaes ou
mtodos) so agrupados em uma classe. Classe uma abstrao que descreve
propriedades importantes para uma aplicao e ignora o restante. O objetivo
de um diagrama de classes descrever os vrios tipos de objetos no sistema e
o relacionamento entre eles.
Um diagrama de classes pode oferecer trs perspectivas, cada uma para um
tipo de observador diferente. So elas:
Conceitual
o Representa os conceitos do domnio em estudo.
o Perspectiva destinada ao cliente.
Especificao
o Tem foco nas principais interfaces da arquitetura, nos principais
mtodos, e no como eles iro ser implementados.
o Perspectiva destinada as pessoas que no precisam saber detalhes
de desenvolvimento, tais como gerentes de projeto.
Implementao - a mais utilizada de todas
o Aborda vrios detalhes de implementao, tais como
navegabilidade, tipo dos atributos, etc.
o Perspectiva destinada ao time de desenvolvimento.
Um diagrama de classes contm:
* Entidades
* Relacionamentos
Os Diagramas de Mquinas de Estados, ou simplesmente Diagramas de
Estados, descrevem o comportamento dinmico do sistema, representando os
estados que um objeto passa durante a execuo do sistema e como ele
muda de estado em respostas aos eventos. Cada diagrama representa uma
classe nica.
Em um diagrama de estado, um objeto possui um comportamento e um
estado. O estado de um objeto depende da atividade na qual ele est
E) Comportamental
Comentrios
O objetivo do diagrama de atividades mostrar o fluxo de atividades em um
nico processo. O diagrama mostra como uma atividade depende uma da
outra.
Gabarito: letra D.
Comentrios
O diagrama que foca os requisitos funcionais de um sistema o diagrama de
casos de uso.
Os casos de uso descrevem funcionalidades do sistema percebidas por atores
externos. Um ator uma pessoa (ou dispositivo, ou outro sistema) que
interage com o sistema.
Gabarito: letra A.
Comentrios
Item a. Ilustra como as classes devero se encontrar organizadas atravs da
noo de componentes de trabalho. Por exemplo, pode-se explicitar, para cada
componente, qual das classes que ele representa. Item FALSO.
Item b. Exibe uma interao, consistindo de um conjunto de objetos e seus
relacionamentos, incluindo as mensagens que podem ser trocadas entre eles.
Item VERDADEIRO.
Item c. uma variao do diagrama de classes e utiliza quase a mesma
notao. A diferena que o diagrama de objetos mostra os objetos que foram
instanciados das classes. O diagrama de objetos como se fosse o perfil do
sistema em um certo momento de sua execuo. Item FALSO.
Item d. Representa os fluxos conduzidos por processamentos.
essencialmente um grfico de fluxo, mostrando o fluxo de controle de uma
atividade para outra. Isso envolve a modelagem das etapas sequenciais em
um processo computacional. Item FALSO.
Item e. Descreve a funcionalidade proposta para um novo sistema, que ser
projetado. Representa uma unidade discreta da interao entre um usurio
(humano ou mquina) e o sistema. So tipicamente relacionados a "atores".
Um ator um humano ou entidade mquina que interage com o sistema para
executar uma determinada tarefa. Item FALSO.
Gabarito: letra B.
Comentrios
Item a. O Diagrama de Sequncia representa a sequncia de processos
(mais especificamente, de mensagens passadas entre objetos) num programa
de computador. Como um projeto pode ter uma grande quantidade de
mtodos em classes diferentes, pode ser difcil determinar a sequncia global
do comportamento. O diagrama de sequncia representa essa informao de
uma forma simples e lgica. Este descreve a maneira como os grupos de
objetos colaboram em algum comportamento ao longo do tempo. Ele registra o
comportamento de um nico caso de uso e exibe os objetos e as mensagens
passadas entre esses objetos no caso de uso. Item FALSO.
Comentrios
Item a. Item FALSO. Agregao uma forma especializada de associao na
qual um todo relacionado com suas partes. Tambm conhecida como relao
de contedo. representada como uma linha de associao com um diamante
junto Classe agregadora. A multiplicidade representada da mesma maneira
que nas associaes.
Complementando, a agregao um caso particular da associao. A
agregao indica que uma das classes do relacionamento uma parte, ou est
contida em outra classe. As palavras chaves usadas para identificar uma
agregao so: consiste em, contm, parte de.
Comentrios
Item a. Adornos so detalhes da especificao adicionados s extremidades
das linhas que representam os relacionamentos, usados na notao grfica.
Item FALSO.
Item b. Permite estender o vocabulrio da linguagem, criando novos elementos
de modelagem. O esteretipo estende a semntica mas no a estrutura do
elemento. Podem-se criar novos cones para representar esses elementos
numa forma grfica individualizada. Item VERDADEIRO.
Item c. Uma restrio estende a semntica de um elemento UML, permitindo
a definio de novas regras ou modificao de regras existentes. Item FALSO.
Item d. A UML no s uma linguagem grfica, por trs de toda parte grfica
h uma especificao que define a sintaxe e semntica de um elemento. A
especificao pode ser construda de forma incremental e estar sempre por
trs, valendo, para qualquer tipo de exibio utilizado. As especificaes UML
proveem um pano de fundo que envolve todas as partes de um modelo. Item
FALSO.
Item e. So relacionamentos de utilizao no qual uma mudana na
especificao de um elemento pode alterar a especificao do elemento
dependente. A dependncia entre classes indica que os objetos de uma classe
usam servios dos objetos de outra classe. Item FALSO.
Gabarito: letra B.
Comentrios
gil uma nova forma de gesto e desenvolvimento de Software que usa uma
abordagem de planejamento e execuo iterativa e incremental voltado para
processos empricos que divide o problema em produtos menores e que visa
entregar software funcionando regularmente, visa a aproximao e maior
colaborao do time de desenvolvimento com os experts de negcios,
comunicao face-to-face, reduo dos riscos associados as incertezas dos
projetos, abraar e responder as mudanas de forma mais rpida e natural e
claro a satisfao final dos clientes por meio da adoo de prticas de gesto e
de engenharia de software com foco nos valores e princpios do Lean e do
agile, resumindo, seu principal objetivo entregar o produto que o cliente
realmente deseja e que ser til e com qualidade.
Gabarito: letra B.
Comentrios
Um processo de software um conjunto de atividades e resultados associados
que levam produo de um produto de software.
Nesse contexto, Sommerville (2007, p. 43) destaca as quatro atividades
fundamentais do processos de software, comuns a todos eles, que so:
especificao de software, projeto e implementao de software,
validao de software e evoluo do software.
Comentrios
Sommerville (2007, p. 43) destaca as quatro atividades fundamentais do
processos de software, comuns a todos eles, que so: especificao de
software, projeto e implementao de software, validao de software
e evoluo do software. Segundo o autor, essas atividades so organizadas
de modo diferente nos diversos processos de desenvolvimento.
Pressman (2011) destaca que uma metodologia de processo genrica para
Engenharia de Software compreende cinco atividades:
Comunicao Antes de iniciar o trabalho, de vital importncia
comunicar-se e colaborar com o cliente (e outros interessados, como:
executivos, usurios finais, engenheiros de software, o pessoal de suporte,
etc.). A inteno aqui compreender os objetivos das partes interessadas
para com o projeto e fazer o levantamento das necessidades que ajudaro a
definir as funes e caractersticas do software.
Planejamento Estabelecimento do plano de projeto de software, que
descreve as tarefas tcnicas a ser conduzidas, os riscos provveis, os
recursos que sero necessrios, os produtos resultantes a ser produzidos e
um cronograma de trabalho.
Modelagem Criao de modelos representativos do software (para
melhor entender as necessidades do software e o projeto que ir atender a
essas necessidades).
Construo Essa atividade combina gerao de cdigo (manual ou
automatizada) e testes necessrios para revelar erros na codificao.
Entrega (Implantao) Entrega do produto ao cliente, que ir avalia-lo
e fornecer feedback baseado na avaliao.
Essas cinco atividades metodolgicas genricas podem ser utilizadas para o
desenvolvimento de programas pequenos e simples, para a criao de grandes
aplicaes para a Internet e para a engenharia de grandes e complexos
sistemas baseados em computador (Pressman, 2011).
As atividades metodolgicas so complementadas pelas atividades de apoio
(umbrella activities), como: controle e acompanhamento do projeto,
administrao de riscos, garantia da qualidade, gerenciamento da configurao
de software, dentre outras.
Observe que os 2 autores trabalham com um modelo genrico de processo de
software, e no com o ciclo de vida do software. No entanto, conceitualmente
falando, o modelo de processo de software no se diferencia do modelo de
ciclo de vida, ambos trazem uma descrio, em alto nvel, das atividades
envolvidas na construo de um software e suas dependncias. Ainda, cabe
destacar que as sequncias de atividades trazidas pelo Pressman e
Comentrios
A proposta da Engenharia de software possibilitar o desenvolvimento
adequado do software, frente a inmeros desafios, como: lidar com sistemas
legados (sistemas de software mais velhos que permanecem vital para uma
organizao), atender crescente diversidade e atender s exigncias quanto
a prazos de entrega limitados.
Gabarito: item correto.
Comentrios
A engenharia de sistemas uma atividade de especificao, projeto,
implementao, validao, implantao e manuteno de sistemas
sociotcnicos.
Os engenheiros de sistema so responsveis pelos softwares, e no somente
esses, mas tambm o hardware, as interaes do sistema com os usurios e
seu ambiente. Alm disso, servios que o sistema fornece, restries de
operao, criao e utilizao, a fim de atingir seu propsito (SOMMERVILLE,
2007).
Comentrios
Processo de Software: um conjunto de atividades, cuja meta o
desenvolvimento ou a evoluo do software.
Mtodos de Engenharia de Software: so as abordagens estruturadas
para o desenvolvimento de software, que incluem modelos de sistemas,
notaes, regras, recomendaes de projetos e diretrizes de processos.
Comentrios
O Modelo em Cascata (Tambm chamado de clssico, ou linear) sugere
uma abordagem sequencial e sistemtica para o desenvolvimento de
software, aplicando as atividades de maneira linear. Em cada fase
desenvolvem-se artefatos (produtos de software) que servem de base para
as fases seguintes.
A prototipao consiste em confirmar ou refutar hipteses. Senta-se com o
cliente e realiza um projeto rpido para atender somente a aspectos do
software que ficaro visveis (prottipo).Para tal, o prazo de construo do
mesmo deve ser obrigatoriamente curto, o que no possibilita formalismos
(abordagem sequencial e sistemtica), ao contrrio do que foi sugerido
no enunciado da questo.
Gabarito: item errado.
Comentrios
O Manifesto gil contm quatro valores fundamentais, que so:
Os indivduos e suas interaes acima de procedimentos e
ferramentas;
Software funcional acima de documentao abrangente;
A colaborao dos clientes acima da negociao de contratos;
A capacidade de resposta a mudanas acima de um plano pr-
estabelecido;
Fonte: http://manifestoagil.com.br/
Assim, temos:
Item A. Item errado. Temos aqui a capacidade de resposta s mudanas, ao
invs de seguir um plano pr-estabelecido.
Item B. Item correto. Os indivduos e suas interaes acima de
procedimentos e ferramentas.
Item C. Item errado. Software funcional acima de documentao
abrangente.
Comentrios
O teste caixa branca, comumente chamado de teste estrutural, uma tcnica
de teste que analisa o cdigo fonte (no caso de teste de software) ou cada n
de um circuito que pode vir a ser testado (no caso de teste de hardware) o que
significa que ele olha os procedimentos.
Gabarito: letra A.
Comentrios
Anlise de Pontos de Funo (APF) uma tcnica de medio das
funcionalidades fornecidas por um software do ponto de vista de seus usurios.
Ponto de funo (PF) a sua unidade de medida, que tem por objetivo tornar
a medio independente da tecnologia utilizada para a construo do software.
Ou seja, a APF busca medir o que o software faz, e no como ele foi
construdo.
Gabarito: letra C.
b) Reusabilidade.
c) Facilidade operacional.
d) Processamento complexo.
e) Disponibilidade 24x7.
Comentrios
As 14 caractersticas gerais da aplicao so:
1. Comunicao de dados 8.Atualizao on-line
2. Funes distribudas 9. Processamento complexo
3. Performance 10. Reusabilidade
4. Configurao do equipamento 11. Facilidade de implantao
5. Volume de transaes 12. Facilidade operacional
6. Entrada de dados on-line 13.Mltiplos locais
7. Interface com o usurio 14. Facilidade de mudanas
Conforme visto, disponibilidade 24x7 a nica que no se encontra na relao.
Gabarito: letra E.
a) Concepo.
b) Elaborao.
c) Construo.
d) Transio.
e) Produo.
Comentrios
O Rational Unified Process um processo de desenvolvimento iterativo e
incremental, no qual o software no implementado em um instante no fim
do projeto, mas , ao contrrio, desenvolvido e implementado em partes. A
cada iterao deste processo utiliza-se quatro fases, a saber: Concepo,
Elaborao, Construo e Transio.
Durante a Concepo ou Incio (Inception), estabelece-se a lgica do
domnio da aplicao para o projeto e decide o escopo do projeto. aqui
que se obtm o comprometimento do patrocinador do projeto para
seguir adiante. Nesta fase compreende-se o problema da tecnologia
empregada por meio da definio dos use cases mais crticos. Define-se
aqui o caso de negcio e escopo do projeto.
Na Elaborao (Elaboration) coleta-se requisitos mais detalhados, faz
uma anlise e um projeto de alto nvel para estabelecer uma arquitetura
bsica, e cria um plano para a construo do sistema. Deve-se analisar o
domnio do problema, estabelecer a arquitetura, desenvolver o plano do
projeto e eliminar elementos de alto risco.
A fase de Construo (Construction) consiste de vrias iteraes,
nas quais cada iterao constri software de qualidade de produo,
testado e integrado, que satisfaz um subconjunto de requisitos de
projeto. Cada iterao contm todas as fases usuais do ciclo de vida da
anlise, do projeto, da implementao e do teste. Desenvolve-se o
software e prepara-se o mesmo para a transio para os usurios. Alm
do cdigo, tambm so produzidos os casos de teste e a documentao.
Mesmo com este tipo de processo iterativo, algum trabalho tem que ser
deixado para ser feito no fim, na fase de Transio (Transition). Nesta
fase so realizados os treinamentos dos usurios e a transio do
produto para utilizao. Este trabalho pode incluir tambm testes beta e
ajuste de performance.
Gabarito: letra B.
a) Panorama.
b) Quadro.
c) Cenrio.
d) Prottipo.
e) Iterao.
Comentrios
Cenrio a descrio de uma das maneiras pelas quais um caso de uso pode
ser realizado. relacionado forma como ele pode ser realizado. Um cenrio
uma execuo especfica do caso de uso; pode ser visto como uma instncia
de um Caso de Uso.
Gabarito: letra C.
A) acoplamento.
B) coeso.
C) abstrao.
D) modularidade.
E) conectividade.
Comentrios
O acoplamento uma medida de quo fortemente uma classe est conectada,
possui conhecimento ou depende de outra classe.
Algumas observaes:
Coeso Medida da funcionalidade de um mdulo; o quanto
ele realiza uma tarefa especfica. O ideal que
tenhamos uma coeso ALTA!
Medidas de Coeso:
Gabarito: letra A.
Comentrios
O jeito aqui eliminarmos o que temos certeza de que no metodologia gil,
ento vamos l!
O modelo em Cascata (Waterfall), tambm chamado de Clssico, o mais
tradicional processo de desenvolvimento de software, e ento podemos
descartar as letras (d) e (e).
O Rational Unified Process (RUP) um exemplo de modelo de processo de
desenvolvimento baseado no Unified Process (Processo Unificado) desenvolvido
pela Rational. Ento j eliminados RUP e UP (Processo Unificado) que no tem
relao com a metodologia gil, o que excluir as assertivas (a)e(d).
Por eliminao, chegamos letra D.
O Scrum um processo de desenvolvimento gil de software baseado em
grupos de prticas e papeis pr-definidos. Ele um processo iterativo e
incremental para gerenciamento de projetos e desenvolvimento de
sistemas, em que cada sprint uma iterao que segue um ciclo PDCA (Plan,
Do, Check, Act) e entrega um incremento de software pronto.
Por fim, o DSDM (Dynamic Systems Development Method - Mtodo de
Desenvolvimento de Sistemas Dinmicos), segundo Pressman (2011, p. 96)
uma abordagem de desenvolvimento de software gil que oferece uma
metodologia para construir e manter sistemas que atendem restries de
prazo apertado atravs do uso da prototipagem incremental em u ambiente de
projeto controlado.
Gabarito: letra B.
Comentrios
O modelo clssico ou cascata, que tambm conhecido por abordagem top-
down, foi proposto por Royce em 1970. Considerado um dos mais importantes
modelos, o modelo Clssico a referncia para muitos outros modelos,
servindo de base para diversos projetos atuais. Pode-se dizer que a verso
original deste modelo foi melhorada ao longo do tempo e continua sendo muito
utilizado hoje em dia.
Gabarito: letra B.
a) em cascata.
b) gil.
c) espiral.
d) incremental.
e) unificado.
Comentrios
O modelo em Cascata sugere uma abordagem sequencial e sistemtica
para o desenvolvimento de software, aplicando as atividades de maneira
Comentrios
De uma maneira geral, as etapas de desenvolvimento de um sistema dividem-
se em:
Levantamento de Requisitos: tem por objetivo propiciar que usurios
e desenvolvedores tenham a mesma compreenso do problema a ser
resolvido.
Anlise: tem por objetivo construir modelos que determinam qual o
problema para o qual estamos tentando conceber uma soluo de
software.
Projeto: estgio no qual o modelo de anlise ter de ser adaptado de tal
modo que possa servir como base para implementao no ambiente
alvo.
Codificao (implementao): a codificao do sistema
efetivamente executada.
Teste: consiste na verificao do software.
Implantao: entrada em produo do sistema.
Gabarito: letra A.
Comentrios
O modelo em Cascata (Waterfall), tambm chamado de Clssico, o mais
tradicional processo de desenvolvimento de software. Este modelo sugere uma
abordagem sequencial para o desenvolvimento de software, aplicando as
atividades de maneira linear. Exige, portanto, que todos os requisitos sejam
conhecidos e corretamente especificados no incio do ciclo de vida, dificultando
a acomodao de mudanas que surjam nas fases seguintes. Esse modelo
possui como vantagem principal a simplicidade para a sua aplicao e
gerncia. No entanto, algumas desvantagens podem ser observadas:
projetos reais raramente seguem este fluxo sequencial.
dificuldade do cliente em declarar todas as suas necessidades no incio do
projeto, dificultando a implementao de mudanas que surjam nas fases
posteriores;
demora em apresentar resultados ao cliente.
Gabarito: letra C.
Comentrios
O modelo em espiral foi originalmente proposto por Boehm (BOEHM, 1988),
em que a sequncia de atividades substituda pelo processo em espiral. Cada
loop na espiral representa uma fase do processo de software. Dessa forma,
segundo Sommerville (2007), o loop mais interno pode estar relacionado
viabilidade do sistema; o loop seguinte, definio de requisitos; o prximo,
ao projeto do sistema e assim por diante.
Cada loop na espiral est dividido em quatro setores:
Definio de objetivos: os objetivos especficos dessa fase do projeto so
definidos. As restries sobre o processo e o produto so identificadas e um
plano detalhado de gerenciamento elaborado. Os riscos de projeto so
identificados. Dependendo disso, estratgias alternativas podem ser
planejadas.
Avaliao e reduo de riscos. Para cada risco de projeto identificado,
uma anlise detalhada realizada. Providncias so tomadas para reduzir o
risco. Por exemplo, se houver risco de que os requisitos no sejam
aprovados, um prottipo do sistema poder ser desenvolvido.
Desenvolvimento e validao. Aps a avaliao de risco, um modelo de
desenvolvimento para o sistema selecionado.
Planejamento. O projeto revisado e uma deciso tomada para
prosseguimento ao prximo loop da espiral. Se a deciso for pelo
prosseguimento, sero elaborados planos para a prxima fase do projeto.
Abortar um projeto se ele apresentar um alto fator de risco.
A elaborao dos objetivos representa o incio do ciclo em espiral, como
desempenho e funcionalidade. Os caminhos alternativos para alcanar esses
objetivos e as restries impostas sobre cada um deles so, ento,
enumerados. Cada alternativa avaliada em relao a cada objetivo e as
fontes de riscos de projeto so identificadas.
O prximo passo resolver esses riscos por meio de atividades de coleta de
informaes, tais como anlise mais detalhada, prototipao e simulao.
Aps a avaliao dos riscos, realizada uma parte do desenvolvimento,
seguida pela atividade de planejamento para a prxima fase do processo
(SOMMERVILLE, 2007).
Comentrios
Como todo produto industrial, o produto de software tem seu ciclo de vida:
ele concebido para tentar atender a uma necessidade;
especificado, quando essas necessidades so traduzidas em requisitos
viveis;
desenvolvido, transformando-se em um conjunto formado por cdigo e
outros itens, como modelos, documentos e dados;
passa por algum procedimento de aceitao e entregue a um cliente;
entra em operao, usado, e sofre atividades de manuteno, quando
necessrio;
Comentrios
O modelo de ciclo de vida em cascata enfatiza a progresso sequencial entre
uma fase e a seguinte.
Gabarito: letra A.
Comentrios
Se eu detectar um erro no incio do projeto, ou seja, na fase de requisitos,
melhor. Quanto mais tarde eu detectar um problema, pior ser.
Gabarito: letra D.
Comentrios
Observe o uso das setas, simbolizando o trmino de uma fase e incio de outra,
o que caracteriza uma abordagem sequencial, tpica do modelo em cascata.
Tambm temos os nomes das fases do modelo, anlise, projeto, codificao,
teste e manuteno.
O modelo em cascata ou ciclo de vida clssico segundo (Pressman, pg.32)
[...] requer uma abordagem sistemtica, sequencial ao desenvolvimento de
software, que se inicia no nvel do sistema e avana ao longo da anlise,
projeto, codificao, teste e manuteno. A ideia principal do Modelo Cascata
que as diferentes etapas de desenvolvimento seguem uma sequncia:
a sada da primeira etapa flui para a segunda etapa e a sada da segunda
etapa flui para a terceira e assim por diante. As atividades a executar so
agrupadas em tarefas, executadas sequencialmente, de forma que uma tarefa
s poder ter incio quando a anterior tiver terminado. Aps concluda uma
etapa ou fase, deve ser feita uma homologao, a fim de verificar se os
documentos gerados condizem com os requisitos do sistema. Sendo
necessrio, devem ser refeitas as tarefas com problemas. Uma vez aprovada a
fase, ela no deve ser alterada, pois implica em alterao na fase seguinte, e
consequentemente aumento dos custos.
Gabarito: letra B.
Comentrios
O nome das fases pode variar, mas temos uma sequncia lgica, e conforme
visto a seguir a letra A a que mais se adequa ao modelo Waterfall.
A figura seguinte, proposta por Eduardo Bezerra, mostra o modelo do ciclo
de vida clssico da engenharia de software, que dividido em seis
atividades. So elas:
Com unicao
Planejam ento
Modelagem
Construo
Im plantao
Gabarito: letra A.
Comentrios
O modelo em Cascata (Waterfall), tambm chamado de Clssico, o mais
tradicional processo de desenvolvimento de software. Este modelo sugere uma
abordagem sequencial para o desenvolvimento de software, aplicando as
atividades de maneira linear. Em cada fase desenvolvem-se artefatos
(produtos de software) que servem de base para as fases seguintes.
Tendncia na progresso sequencial entre uma fase e a seguinte.
Gabarito: item correto.
Comentrios
A sequncia de atividades e eventos apresentada est relacionada ao ciclo de
vida do PRODUTO. No ciclo de vida do projeto seriam mencionadas atividades
do PMBOK, a abordagem XP utiliza Scrum para gerenciamento, etc.
Gabarito: letra A.
Comentrios
Item a. O item est correto. O Scrum um framework de processo gil
utilizado para gerenciar e controlar o desenvolvimento de um produto de
software atravs de prticas iterativas e incrementais. composto por um
conjunto de boas prticas de gesto que admite ajustes rpidos,
acompanhamento e visibilidade constantes e planos realsticos.
Scrum um processo bastante leve para gerenciar e controlar
projetos de desenvolvimento de software e para a criao de
produtos.
Comentrios
O modelo de ciclo de vida de processo de software cujos principais
subprocessos so executados em estrita sequncia, o que permite demarc-los
como pontos de controle bem definidos, denominado Modelo em Cascata
(Waterfall), tambm chamado de Clssico, que o mais tradicional
processo de desenvolvimento de software.
Este modelo sugere uma abordagem sequencial para o desenvolvimento de
software, aplicando as atividades de maneira linear. Em cada fase
desenvolvem-se artefatos (produtos de software) que servem de base para as
fases seguintes.
O modelo em Cascata possui como vantagem principal a simplicidade para a
sua aplicao e gerncia. No entanto, algumas desvantagens podem ser
observadas:
Projetos reais raramente seguem este fluxo sequencial.
Dificuldade do cliente em declarar todas as suas necessidades no
incio do projeto.
Demora em apresentar resultados ao cliente.
Gabarito: letra B.
Comentrios
Somente a alternativa I est incorreta, isso porque o modelo em cascata
sequencial, e cada uma das fases integrantes do mesmo entrada para a
prxima, o que significa que no existe uma etapa de implementao inicial e
uma conversa com o usurio para aprimorar tal implementao, s na fase de
entrega que o desenvolvedor saber se fora realizado o que o cliente
desejava.
Gabarito: letra E.
Comentrios
Item a. Item correto. Na Elaborao (Elaboration) coletam-se requisitos
mais detalhados, faz uma anlise e um projeto de alto nvel para estabelecer
uma arquitetura bsica, e cria um plano para a construo do sistema.
Comentrios
Na XP todas as decises sobre o rumo do projeto devem ser tomadas pelo
cliente. Com o cliente sempre presente reforamos a necessidade de
comunicao entre as partes.
Gabarito: letra C.
Comentrios
Em cada fase do modelo de ciclo de vida em cascata desenvolvem-se artefatos
(produtos de software) que servem de base para as fases seguintes.
A figura seguinte, proposta por Eduardo Bezerra, mostra o modelo do ciclo
de vida clssico da engenharia de software, que dividido em seis
atividades. So elas:
CONSIDERAES FINAIS
Finalizando, desejo muito sucesso a todos nos estudos e concursos vindouros.
Todo o esforo feito nessa fase ser devidamente recompensado.
Se seus sonhos estiverem nas nuvens, no se preocupe,
pois eles esto no lugar certo; agora, construa os alicerces!"
Os alicerces para uma excelente prova so: persistncia, garra, fora de
vontade, estudo disciplinado e f em Deus!!!
Um abrao, Profa Patrcia Quinto
Profa. Patrcia Lima Quinto www.pontodosconcursos.com.br 72 de 92
TI EM EXERCCIOS P/ INSS
Conhecimentos especficos - Formao em Tecnologia da Informao (TEINF)
REFERNCIAS BIBLIOGRFICAS
QUINTO, Patrcia Lima. Notas de aula, 2012/2013.
BEZERRA, E. Princpios de Anlise e Projeto de Sistemas com UML, 2.
ed., Rio de Janeiro: Elsevier, 2007.
PRESSMAN, R. S. Engenharia de Software: Uma Abordagem
Profissional, 7. ed. Porto Alegre: Editora Mc GrawHill, 2011.
SOMMERVILLE, I., Engenharia de Software, 9. ed., So Paulo: Pearson
Addison - Wesley, 2011.
PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prtica.
2.ed., So Paulo: Prentice Hall, 2004.
3. (CESPE/2010/TRE-MT/Tcnico Judicirio/Programao de
Sistemas) A estrutura interna de um objeto possui dois componentes
bsicos: atributos, que descrevem o estado do objeto; e mtodos, que so
responsveis pela comunicao entre objetos.
C) Restrio.
D) Composio.
E) Classificao.
b) Reusabilidade.
c) Facilidade operacional.
d) Processamento complexo.
e) Disponibilidade 24x7.
a) Concepo.
b) Elaborao.
c) Construo.
d) Transio.
e) Produo.
a) Panorama.
b) Quadro.
c) Cenrio.
d) Prottipo.
e) Iterao.
A) acoplamento.
B) coeso.
C) abstrao.
D) modularidade.
E) conectividade.
a) em cascata.
b) gil.
c) espiral.
d) incremental.
e) unificado.
b) Cascata.
c) Prototipagem evolutiva.
d) Dirigidos por prazo.
GABARITO
1. Letra E. 35. Letra A.
2. Item correto. 36. Letra B.
3. Item errado. 37. Letra B.
4. Letra B. 38. Letra A.
5. Item errado. 39. Letra A.
6. Letra B. 40. Letra C.
7. Item correto. 41. Letra C.
8. Letra B. 42. Letra A.
9. Letra D. 43. Letra A.
10. Letra E. 44. Letra E.
11. Letra B. 45. Letra A.
12. Letra C. 46. Letra D.
13. Letra A. 47. Letra B.
14. Letra D. 48. Letra A.
15. Letra A. 49. Item correto.
16. Letra B. 50. Letra A.
17. Letra C. 51. Letra C.
18. Letra D. 52. Letra B.
19. Letra B. 53. Letra E.
20. Letra B. 54. Letra D.
21. Item correto. 55. Letra C.
22. Item correto. 56. Letra C.
23. Item correto. 57. Letra B.
24. Letra E.
25. Item correto.
26. Letra B.
27. Item correto.
28. Item errado.
29. Letra B.
30. Letra A.
31. Letra C.
32. Letra E.
33. Letra B.
34. Letra C.