Trabalho individual.

Prévia do material em texto

SISTEMA DE ENSINO Á DISTÂNCIA CONECTADO 
CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E 
DESENVOLVIMENTO DE SISTEMAS 
 
Késia Barbosa da Silva 
 
 
 
 
 
 
 
 
FUNDAMENTOS DE TECNOLOGIA DA INFORMAÇÃO 
 
 
 
 
 
 
 
 
 
 
Parauapebas-PA 
2013 
 
 
 
Késia Barbosa da Silva 
 
 
 
 
 
 
FUNDAMENTOS DE TECNOLOGIA DA INFORMAÇÃO 
 
 
 
 
 
Trabalho apresentado ao Curso Análise e 
Desenvolvimento de Sistemas da UNOPAR - 
Universidade Norte do Paraná, para a disciplina 
Processo de Negócio de Software. 
 
Prof.Marco Ikuro Hisatomi, Profª. Polyanna P. G. 
Fabris 
 
 
 
 
 
 
 
 
 
 
Parauapebas-PA 
2013 
 
 
 
Sumário 
 
Introdução .......................................................................................................... 4 
Modelo Cascata .............................................................................................. 5 
Desenvolvimento Evolucionário ................................................................... 8 
Vantagens e Desvantagens ............................................................................. 11 
Linguagem de Programação Java ................................................................ 13 
Conclusão .................................................................................................. 14 
Referências ............................................................................................... 15 
 
 
 
Página | 4 
 
 
Introdução 
 
Software tornou-se profundamente incorporado em praticamente todos os 
aspectos de nossas vidas e, consequentemente, o número de pessoas 
interessadas nos recursos e nas funções oferecidas por uma determinada 
aplicação tem crescido significativamente. Quando uma aplicação ou um 
sistema embutido estão para ser desenvolvido, muitas vozes devem ser 
ouvidas. E, algumas vezes, parece que cada uma delas possui uma ideia 
ligeiramente diferente de quais funções ou recursos o software deve oferecer. 
Depreende-se, portanto, que se deve fazer um esforço concentrado para 
compreender o problema antes de desenvolver uma solução de software. 
Os sistemas de software estão em todos os lugares. Praticamente todo 
equipamento elétrico apresenta algum tipo de software; o software é utilizado 
para ajudar nas operações da indústria manufatureira, das escolas e 
universidades, do setor de assistência á saúde, das finanças e do governo. 
Muitas pessoas utilizam software de diferentes tipos para fins de 
entretenimento e de educação. 
 
 
Página | 5 
 
 
1. Processo de Software 
Um processo de software é um conjunto de atividades relacionadas que levam 
á produção de um produto de software. Essas atividades podem envolver o 
desenvolvimento de software a partir do zero em linguagem padrão de 
programação como Java ou C. No entanto, aplicações de negócios não são 
necessariamente desenvolvidas dessa forma. Atualmente, novos softwares de 
negócios são desenvolvidos por meio da extensão e modificação de sistemas 
existentes ou por meio da configuração e integração de prateleira ou 
componentes do sistema. 
No contexto de engenharia de software, um processo não é uma prescrição 
rígida de como desenvolver um software. Ao contrário, é uma abordagem 
adaptável que possibilita às pessoas (a equipe de software) realizar o trabalho 
de selecionar e escolher o conjunto apropriado de ações e tarefas. A intenção é 
a de sempre entregar software dentro do prazo e com qualidade suficiente para 
satisfazer aqueles que patrocinaram sua criação e aqueles que irão utilizá-lo. 
Processo de software que é apresentada a partir de uma perspectiva 
especifica. Os modelos pela sua natureza são simplificações; e, assim, um 
modelo de processo de software é uma abstração do processo real que está 
sendo descrito. Dentre os modelos de processos destacam-se atividades que 
são parte do processo software, produtos de software e o papel das pessoas 
envolvidas na engenharia de software. Um dos exemplos dos tipos de modelos 
de processos de software é o modelo cascata. 
2. Modelo Cascata 
Há casos em que os requisitos de um problema são bem compreendidos 
quando o trabalho flui da comunicação ao emprego de forma relativamente 
linear. Essa situação ocorre algumas vezes quando adaptação ou 
aperfeiçoamentos bem definidos precisam ser feitos em um sistema existente. 
Pode ocorrer também em um número limitado de novos esforços de 
desenvolvimento, mas apenas quando os requisitos estão definidos e são 
razoavelmente estáveis. 
Página | 6 
 
O primeiro modelo de processo de desenvolvimento de software publicado 
originou-se de processos mais gerias de engenharia de sistema. Devido ao 
encadeamento de uma fase com outra, esse modelo é conhecido como modelo 
em cascata ou ciclo de vida do software. Os principais estágios do modelo 
demonstram as atividades fundamentais de desenvolvimento: 
1. Análise e definição de requisitos. Os serviços, restrições e objetivo do 
sistema são definidos por meio de consulta aos usuários do sistema. 
Eles são, portanto, definidos detalhadamente e servem como uma 
especificação de sistema. 
2. Projeto de sistema e software. O processo de projeto de sistema divide 
os requisitos em sistemas de hardware ou de software. Ele estabelece 
uma arquitetura geral do sistema. O projeto de software envolve a 
identificação e a descrição das abstrações fundamentais do sistema de 
software e suas relações. 
3. Implementação e teste de unidade. Durante esse estágio, o projeto de 
software é realizado como um conjunto de programas ou unidades de 
programa. O teste unitário envolve a verificação de que cada unidade 
atende á uma especificação. 
4. Integração e teste de sistema. As unidades individuais de programa ou 
os programas são integrados e testados como um sistema completo 
para garantir que os requisitos de software foram atendidos. Após os 
testes, o sistema de software é liberado para o cliente. 
5. Operação e manutenção. Geralmente (embora não necessariamente) 
esta é a fase mais longa do ciclo de vida. O sistema é instalado e 
colocado em operação. A manutenção envolve a correção de erros não 
detectados nos estágios anteriores do ciclo de vida, no aprimoramento 
da implementação das unidades de sistema e na ampliação dos serviços 
de sistema à medida que novos requisitos são identificados. 
Em principio, o resultado de cada fase consiste de um ou mais documentos 
aprovados. A fase seguinte não deve começar antes que a fase anterior tenha 
terminado. Na prática, esses estágios se sobrepõem e trocam informações 
entre si. Durante o projeto, são identificados problemas com requisitos; durante 
a codificação, são encontrados problemas de projeto e assim por diante. O 
Página | 7 
 
processo de software não é um modelo linear simples; envolve uma sequencia 
de iterações das atividades de desenvolvimento. 
Devido aos custos de produção e aprovação de documentos, as iterações são 
onerosas e envolvem um ―retrabalho‖ significativo. Portanto, após um pequeno 
número de iterações, é normal suspender partes do desenvolvimento, com a 
especificação, e prosseguir com os estágios posteriores do desenvolvimento. 
Os problemas são resolvidos posteriormente, ignorados ou reprogramados. O 
congelamento prematuro de requisitos pode significar que o sistema não fará o 
que o usuário deseja. Isso pode também levar a sistema mal estruturados, pois 
os problemas de projeto foram contornados por meio de artifícios de 
implementação. 
Durante a fase final do ciclo de vida (operação e manutenção), o software é 
colocado em uso. Errose omissões nos requisitos originais de software são 
descobertos. Os erros de programação e projeto emergem e a necessidade de 
novas funcionalidades é identificada. O sistema deve, portanto, evoluir para 
permanecer útil. Essas mudanças (manutenção de software) podem implicar 
repetição de estágios anteriores do processo. 
 
Modelo Cascata 
Página | 8 
 
 
3. Desenvolvimento Evolucionário 
 
Historicamente, sempre houve uma separação entre processo de 
desenvolvimento e o de evolução do software As pessoas pensam no 
desenvolvimento de software como uma atividade criativa em que um sistema 
é desenvolvido a partir de um conceito inicial até um sistema funcional. Por 
outro lado, pensam na manutenção do software como maçante e 
desinteressante. Embora os custos de manutenção são, em alguns casos, 
considerados menos desafiadores do que o desenvolvimento do software 
original. 
O desenvolvimento evolucionário baseia-se na idéia de desenvolvimento de 
uma implementação inicial, expondo o resultado aos comentários do usuário e 
refinando esse resultado por meio de várias versões até que seja desenvolvida 
um sistema adequado. As atividades de especificação, desenvolvimento e 
validação são intercaladas, em vez de serem separadas, com feedback rápido 
que permeia as atividades. 
Existem dois tipo fundamentais de desenvolvimento evolucionário: 
1. Desenvolvimento exploratório, na qual o objetivo do processo é trabalhar 
com o cliente para explorar os requisitos e entregar um sistema final. O 
desenvolvimento começa com as partes do sistema compreendidas. O 
sistema evolui por meio da adição de novas características propostas 
pelo cliente. 
2. Protipação throwaway, na qual o objetivo do processo de 
desenvolvimento evolucionário é compreender os requisitos do cliente e, 
a partir disso, desenvolver melhor definição de requisitos para o sistema. 
O protótipo se concentra na experimentação dos requisitos mal 
compreendidos do cliente. 
Em algumas organizações, a evolução pode ser um processo informal 
no qual as solicitações de mudanças, na maioria de vezes , provêm de 
conversas entre os usuários e desenvolvedores. Em outras empresas, é 
Página | 9 
 
um processo formalizado, com documentação estruturada e produzida 
em cada estágio do processo. 
Propostas de mudanças no sistema são os direcionadores da evolução 
de sistemas em todas as organizações. Essas propostas de mudanças 
podem envolver requisitos existentes ainda não implementados no 
sistema liberado, solicitações de novos requisitos ou reparos de defeitos 
detectados pelos stakeholders do sistema, além de novas ideias e 
propostas de aprimoramento de software solicitadas pela equipe de 
desenvolvimento, os processos de identificação de mudança e evolução 
são cíclicos e continuam ao longo do ciclo de vida de um sistema. 
O processo de evolução inclui as atividades fundamentais de análise de 
mudanças, planejamento de releases, implementação de mudanças e 
liberação de um sistema para os clientes. O custo e o impacto dessas 
mudanças são avaliados para descobrir quanto do sistema é afetado 
pelas mudanças e quanto pode custar para implementar a mudança. 
Durante o planejamento de releases, todas as mudanças propostas são 
consideradas. Uma decisão é então tomada sobre quais mudanças 
devem ser implementadas na próxima versão do sistema. 
As mudanças são implementadas e validadas, e um novo release do 
sistema é liberado. O processo se repete com um novo conjunto de 
mudanças propostas para o próximo release. 
O processo de implementação de mudanças é, essencialmente, uma 
iteração do processo de desenvolvimento na qual as revisões do 
sistema são projetadas, implementadas e testadas. Contudo, uma 
diferença importante é que o estágio inicial da implementação de 
mudanças é a compreensão do programa. Durante essa fase, você deve 
entender como o programa está estruturado e como ele entrega sua 
funcionalidade. Ao implementar uma mudança, você usa esse 
entendimento para assegurar que a mudança implementada não 
prejudicará o sistema existente. 
De preferência, o estágio de implementação de mudanças desse 
processo deve modificar a especificação, o projeto e a implementação 
do sistema para refletir as mudanças no sistema. Novos requisitos que 
refletem as mudanças no sistema são propostos, analisados e 
Página | 10 
 
validados. Os componentes de sistema são reprojetados e 
implementados, e o sistema é retestado. Caso apropriado, pode ser 
realizada a prototipação das mudanças propostas como parte do 
processo de análise. 
Quando ocorre uma mudança no software, são desenvolvidos 
sucessivos releases do sistema. Esses releases são compostos de 
novas versões de componentes do sistema. Você deve acompanhar as 
versões para garantir que as versões corretas dos componentes estão 
sendo usadas em cada release do sistema. 
Durante o processo de evolução, os requisitos são analisados em 
detalhes e, frequentemente, surgem implicações não aparentes no início 
do processo de análise das mudanças. Isso significa que as mudanças 
propostas podem ser alteradas e discussões posteriores com o cliente 
podem ser necessárias antes que as mudanças sejam implementadas. 
 
 
Processos de identificação de mudança e evolução 
 
 
 
Página | 11 
 
 
Processo desenvolvimento protótipo 
 
 
Processo de evolução de sistema 
 
 
Implementação de mudança 
 
4. Vantagens e desvantagens 
 
O modelo cascata é o paradigma mais antigo da engenharia de software. 
Entretanto, ao longo das ultimas três décadas, as críticas a este modelo de 
processo fez com que até mesmo seus mais ardentes defensores 
questionassem sua eficácia. 
O problema com o modelo em cascata é sua inflexível divisão do projeto 
nesses estágios distintos. Os acordos devem ser feitos em um estágio inicial do 
processo, e isso significa que é difícil responder aos requisitos do cliente, que 
sempre se modificam. Portanto, o modelo em cascata deve ser utilizado 
somente quando os requisitos forem bem compreendidos. Contudo, ele reflete 
Página | 12 
 
e prática da engenharia. Consequentemente, os processos de software com 
base nessa abordagem ainda são utilizados no desenvolvimento de software, 
em particular quando fazem parte de um projeto maior de engenharia de 
sistema. 
Projetos reais raramente seguem o fluxo sequencial que o modelo propõe. 
Embora o modelo linear possa conter iterações, ele o faz indiretamente. Como 
consequência, mudanças podem provocar confusão à medida que a equipe de 
projeto prossegue. Frequentemente, é difícil para o cliente estabelecer 
explicitamente todas as necessidades. O modelo cascata requer isso e tem 
dificuldade para adequar a incerteza natural que existe no inicio de muitos 
projetos. 
O cliente deve ter paciência. Uma versão operacional do(s) programa(s) não 
estará disponível antes de estarmos próximos do final do projeto. Um erro 
grave, se não detectado até o programa operacional ser revisto, pode ser 
desastroso. 
Em uma interessante análise de projetos reais, Bradac descobriu que a 
natureza linear do ciclo de vida clássico conduz a ― estados de bloqueio‖, nos 
quais alguns membros da equipe do projeto têm de aguardar outros 
completarem tarefas dependentes. De fato, o tempo gasto na espera pode 
exceder o tempo gasto em trabalho produtivo! Os estados de bloqueio tendem 
a prevalecer no início e no final de um processo sequencial linear. 
Hoje em dia, o trabalho de software tem ritmo acelerado e está sujeito a uma 
cadeia de mudanças intermináveis (em características, funções e conteúdo de 
informações). O modelocascata é frequentemente inapropriado para tal 
trabalho. Entretanto, ele pode servir como um modelo de processo útil em 
situações as quais os requisitos são fixos e o trabalho deve ser realizado até 
sua finalização de forma linear. 
 
 
 
Página | 13 
 
5. Linguagem de programação Java 
 
Java é uma linguagem computacional completa, adequada para 
desenvolvimento de aplicações baseadas na rede internet, redes 
fechadas ou ainda programas stan-alone. Linguagem poderosa em 
ambientes distribuídos complexos como a rede internet, mas sua 
versatilidade permite ao programador ir além, oferecendo uma poderosa 
linguagem de programação de uso geral, com recursos suficientes para 
a construção de uma variedade de aplicativos. 
Diminuir as possibilidades de erro de programação, a linguagem tem um 
esquema de segurança para garantir a integridade de código. Esses 
recursos de segurança são notáveis principalmente dentro do ambiente 
do interpretador. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Página | 14 
 
6. Conclusão 
Não existe um processo correto ou incorreto, como não existe um modelo 
de desenvolvimento que seja a panaceia universal para o problema do 
desenvolvimento de software. 
Dependendo de sua aplicação, ambiente e objetivo, a utilização de um 
processo ou modelo específico pode ser vantajoso ou não. Cabe a cada 
organização avaliar o seu problema com cuidado e usar os modelos 
apresentados como um guia para o desenvolvimento do seu próprio 
processo de desenvolvimento. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Página | 15 
 
7. Referências 
 
Sommerville Ian, Engenharia de Software/Ian Sommerville; tradução Ivan 
Bosnic e Kalinka G. de O. Gonçalves: revisão técnica Kechi Hirama. – 9.ed.-
São Paulo: Pearson Prentice Hall, 2011. 
Sommervile Ian, Engenharia de Software/ Ian Sommerville; tradução: Selma 
Shin Shimizu Melnikoff, Reginaldo Arakaki, Edilson de Andrade Barbosa; 
revisão técnica: Kechi Kirama. –8ª ed.—São Paulo: Pearson Addison- Wesley, 
2007. 
Sommervile Ian, Engenharia de Software/ Ian Sommervile; tradução André 
Maurício de Andrade Ribeiro; revisão técnica Kechi Hirama.-6ª.ed.—São Paulo: 
Addison Wesley,2003. 
Pfleeger Shari Lawrence, Engenharia de Software: teoria e prática/ Shari 
Lawrence Pfleeger; tradução Dino Franklin; revisão técnica Ana Regina 
Cavalcanti da Rocha. –2ª.ed.—São Paulo: Prentice Hall, 2004. 
Perini Luis Cláudio, Engenharia de Software: Sistema II/ Luis Cláudio Perini, 
Marco Lkuro Hisatomi, Wagner Luiz Berto. –São Paulo: Pearson Prentice Hall, 
2009.