Curso: DESS

Disciplina: Engenharia de Software.

Responsável: Prof. Joaã o Gilberto Pinho
Identificação da tarefa: Tarefa 2.2. Segunda tarefa final da disciplina. Envio de
arquivo.
Pontuação: 10 pontos de 40

TAREFA 2.2

Elabore um texto respondendo as perguntas a seguir:

1 Suponhamos que voceê seja o gerente de uma empresa de projetos que constroó i
software para produtos de consumo. Voceê foi contratado para construir o software para
um sistema de segurança domeó stico sofisticado. Desenvolva um esboço detalhado (seja
taã o especíófico quanto possíóvel) dos passos que deveria realizar para administrar esse
projeto. Suponhamos que voceê ainda tenha de se reunir com seu cliente.

Qual paradigma de engenharia de software escolheria?

2 Atraveó s da validaçaã o de software, podemos antecipar qualquer problema na aplicaçaã o?

Justifique sua resposta atraveó s de um estudo de caso praó tico.

Resposta 1 tratados individualmente, sendo passíóveis de
negociaçaã o caso fujam do escopo inicialmente
Ao iniciar o projeto, eó importante colher o maó ximo estipulado.
de informaçoã es do cliente, buscando sempre
entender qual a sua real preocupaçaã o e quais pontos Para garantir agilidade no desenvolvimento e
saã o essenciais para sua plena satisfaçaã o. Essa etapa prevenir falhas de escopo na entrega final, optarei
constitui o levantamento do requisito e deve utilizar pelo paradigma Ciclo de Vida em Espiral, que agrega
principalmente a teó cnica de entrevista, sendo o paradigma Ciclo de Vida Claó ssico e a Prototipaçaã o
bastante eficaz junto ao cliente e de prefereê ncia em com acreó scimo da Anaó lise de Risco. Esse paradigma
sua resideê ncia, permitindo visualizar o ambiente no preveê ciclos de incremento no produto, incluindo o
qual seraó utilizado o software. cliente nas validaçoã es de cada passo, prevenindo
desvios no escopo. Dessa forma o produto se
O levantamento de requisitos envolve os tipos desenvolve em ciclos, garantindo maior maturidade
funcionais, representando as operaçoã es que o e menos manutençaã o no final do projeto.
software realiza, e os naã o funcionais, que estipula as
caracteríósticas teó cnicas de uso do programa, como Resposta 2
desempenho, confiabilidade e segurança.
Sim. Com o uso da validaçaã o de software podemos
Apoó s o levantamento dos requisitos, uma proposta antecipar os problemas que o software apresentaria
formal sintetiza o que seraó desenvolvido e entregue quando fosse efetivamente utilizado pelo cliente. A
ao cliente, garantindo entendimento mutuo da validaçaã o de software atesta os requisitos
soluçaã o que se pretende elaborar. levantados no iníócio do projeto, tanto os requisitos
funcionais e naã o funcionais.
Para facilitar o gerenciamento e apontar possíóveis
falhas e atrasos no projeto, eó imprescindíóvel a A validaçaã o pode se dar por testes durante o
elaboraçaã o do cronograma, definindo as atividades desenvolvimento do projeto bem como em cada
de desenvolvimento e seus status de progresso, passo no qual as funcionalidades vaã o sendo
sendo possíóvel indicar as diversas fases em que o concluíódas, e homologaçaã o com o cliente em cada
projeto esteja dividido. fase finalizada.

Juntamente com a definiçaã o das etapas e atividades
do projeto, eó feita a anaó lise de custos gerais
envolvidos no desenvolvimento da soluçaã o,
indicando o valor de cada item envolvido na
construçaã o do produto.
Quando o cliente concorda com o escopo definido na
proposta formal para o projeto, temos condiçoã es de
iniciar o desenvolvimento, e a cada iteraçaã o
concluíóda, podemos validar um protoó tipo ou
funcionalidade diretamente com o cliente. Qualquer
necessidade nova identificada na validaçaã o do
software ou mesmo comportamentos naã o previstos
ou implementados de forma equivocadas saã o
Uma aplicaçaã o praó tica de validaçaã o pode ser
definida em uma aplicaçaã o que realize caó lculo de
equaçoã es matemaó ticas. Podemos realizar scripts de
teste que informem como entrada para o sistema
uma equaçaã o conhecida e verifique se sua resoluçaã o
foi realizada de forma correta.
Devemos realizar tantos testes quanto forem os
tipos de funçoã es suportadas pelo programa, tendo o
cuidado de testar fluxos de exceçaã o. Dessa forma
protegemos a aplicaçaã o de comportamentos
inesperados e bugs que poderiam ser descobertos
apenas apoó s implantaçaã o ou distribuiçaã o ao cliente.