Análise de Sistemas aula 1

Prévia do material em texto

Análise de Sistemas 
Aula 01 - Introdução à Análise de Sistemas
2
Conversa Inicial 
Olá, seja bem-vindo a nossa aula de Análise de Sistemas. 
Em nossa primeira aula, vamos abordar a evolução da Análise de Sistemas, desde os anos 50 até os dias atuais. Veremos como vários fatores do dia a dia em tecnologia nos levou a chamada “Crise do Software”. Iniciaremos nosso estudo conversando sobre Software. Afinal, o que é software? Podemos dizer que é o conjunto dos programas e dos meios não materiais que possibilitam o funcionamento do computador na execução de diversas tarefas. 
Nesse contexto, temos a Análise de Sistemas que é a atividade de identificar os problemas do domínio, bem como apresentar alternativas de soluções e o estudo da viabilidade de um software. Por fim, conheceremos os métodos clássicos de análise e desenvolvimento de software. 
Boa aula! 
3
Contextualizando 
No final dos anos 40 até os anos 60, quando se iniciou a evolução dos sistemas computadorizados, grande parte dos esforços, e consequentes custos, eram concentrados no desenvolvimento de hardware, em razão, principalmente das limitações e dificuldades encontradas na época. À medida que a tecnologia de hardware foi sendo dominada, as preocupações se voltaram, para o desenvolvimento de software. Surgia então, os primeiros sistemas operacionais, assim como as chamadas linguagens de programação de alto nível, como FORTRAN e COBOL. 
4
Na década de 70, houve uma grande expansão do mercado computacional. Sistemas complexos começaram a surgir e por consequência, modelos mais robustos foram propostos. Nesse período surge a programação estruturada e no final da década a análise e o projeto estruturado. Nos anos 80, surge a necessidade por interfaces homem-máquina mais sofisticadas, o que originou a produção de sistemas de software mais complexos. A análise estruturada se consolidou na primeira metade dessa década e em 1989 Edward Yourdon lança o livro Análise Estruturada Moderna, tornando-o uma referência no assunto. 
5
http://vod.grupouninter.com.br/2015/AGO/MT180010-A01-P02.mp4
No período da década de 1990, surge um novo paradigma de modelagem, a Análise Orientada a Objetos, como resposta a dificuldades encontradas na aplicação da análise estruturada a certos domínios de aplicação. No final da década de 90 até o momento atual o paradigma da orientação a objetos atinge a sua maturidade.
No vídeo a seguir o professor explora mais o contexto que estudamos. 
6
Pesquise 
Já fizemos um breve estudo histórico sobre a evolução da Análise de Sistemas. Neste momento, veremos os conceitos de padrões de projetos (design patterns), frameworks de desenvolvimento, componentes e padrões de qualidade. 
Por meio da leitura do artigo a seguir, podemos ampliar nosso conhecimento a respeito dos temas citados. 
Artigo 
O que são Design Patterns?
Por Jéssica Schissato, Rodolfo Pereira | 12 de março, 2012 | 19 comentários
Design patterns (padrões de projeto) surgiram com a motivação de ajudar a solucionar problemas que ocorrem frequentemente, e, se usados com bom senso, podem se tornar ferramentas poderosas para qualquer desenvolvedor de software, uma vez que já foram testadas, utilizadas e aprimoradas a partir da experiência e conhecimento de outros programadores.
Preparamos um post explicando o que são design patterns e seus princípios comuns, baseado no livro “Professional ASP.NET Design Patterns” de Scott Millett.
Tirinha retirada do site Vida de Programador, o qual publica tirinhas diárias com histórias engraçadas e verídicas sobre o dia-a-dia de um programador.
Explicando Design Patterns
Design patterns (Padrões de projeto) são soluções de templates abstratas de alto nível. Pense nelas como um “blueprint” (desenho técnico ou documentação de uma arquitetura, etc.) para soluções e não como uma solução por si própria. Você não achará um framework que você poderá simplesmente aplicar para a sua aplicação; ao invés disso, você chegará ao design patterns através da refatoração do seu código e generalização do seu problema.
Design patterns não são somente aplicados em desenvolvimento de software; design patterns podem ser encontrados em diversas áreas da vida, da engenharia até da arquitetura. Em fato, foi o arquiteto Christopher Alexander que introduziu a ideia de patterns em 1970 para construir um vocabulário comum para discussões sobre design. Ele escreveu:
Cada pattern descreve um problema que ocorre várias vezes ao nosso redor e com isso, descrevem a solução para o problema de uma maneira que você pode usar essa solução diversas vezes sem ter que fazer a mesma coisa duas ou mais vezes.
Origem
As origens do design patterns que prevalecem hoje na arquitetura de software nasceram das experiências e conhecimento dos programadores utilizando a programação orientada a objeto. O conjunto dos mais conhecidos design patterns estão catalogados no livro chamado “Design Patterns: Elements of Reusable Object-Oriented Software”, mais conhecido como “Design Patterns Bible”. Esse livro foi escrito por Erich Hamma, Richard Helm, Ralph Johson e John Vlissdes, mais conhecidos como “Gang of Four”.
Eles coletaram 23 design patterns e organizaram em 3 grupos:
Creational Patterns (Padrões de Criação): Tratam da construção do objeto e o de referência;
Structural Patterns (Padrões Estruturais): Tratam da relação entre objetos e como eles interagem entre sim para formarem grandes objetos complexos;
Behavioral Patterns (Padrões Comportamentais): Tratam da comunicação entre os objetos, especialmente em termos de responsabilidade e de algoritimos.
Utilidade
O valor dos design patterns reside no fato que eles são soluções que foram utilizadas e testadas, o que nos dá confiança em sua eficácia.
Design patterns focam na reutilização de soluções. Todos os problemas não são iguais, mas se você puder “quebrar” o problema e achar similiaridades com problemas que você já resolveu antes, você pode aplicar essas soluções. Depois de décadas de programação orientada a objeto, a maioria dos problemas que você encontrará já terão sido resolvidas no passado, e haverá um pattern disponível para ajudar você na implementação da solução. Mesmo se você acredita que o seu problema é único, ao quebrá-lo em pequenas partes, você será capaz de generalizá-lo o suficiente para encontrar a solução apropriada.
O nome dos design patterns são úteis porque refletem o seu comportamento e propósito, e fornecem um vocabulário comum em um brainstorming de solução. É muito mais fácil falarmos em termos do nome do pattern do que detalhar sobre como essa implementação deveria funcionar.
O que eles não são
Design patterns não são a bala de prata (solução de todos os problemas). Você deve ter o entendimento geral do seu problema, generalizá-lo e então aplicar o pattern apropriado para a solução desse problema. Porém, nem todos os problemas requerem um design pattern. É verdade que o design pattern pode ajudar a tornar problemas complexos em problemas simples, porém eles também podem tornar problemas simples em problemas complexos.
Princípios comuns de design
Há diversos princípios comuns de design, que, assim como os design patterns, se tornaram boas práticas através dos anos e ajudaram a formar uma fundação no qual o nível empresarial e software de fácil manutenção podem ser construídos. Abaixo, segue um resumo dos princípios mais conhecidos:
Keep It Simple Stupid (KISS)
Mantenha Isto Estupidamente Simples
Um problema comum em programação de software é a necessidade de complicar demais a solução. O objetivo do princípio KISS é manter o código simples, mas não simplista, assim evitando complexidade desnecessária.
Don’t Repeat Yourself (DRY)
Não Repita Você Mesmo
O princípio do DRY é evitar a repetição de qualquer parte do sistema abstraindo as coisas que são comuns entre si e colocá-las em um lugar único. Esse princípio não se preocupa somente com o código, mas qualquer lógica que está duplicada no sistema.
Tell, Don’t Ask
Fale, não pergunte
O principio Tell, Don’t Askestá estreitamente alinhado com o encapsulamento e a atribuição de responsabilidades para as suas classes corretas. O princípio afirma que você deve dizer aos objetos quais ações você quer que eles realizem, ao invés de fazer perguntas sobre o estado do objeto e então tomar uma decisão por si próprio em cima da ação que você quer realizar. Isso ajuda a alinhar as responsabilidades e evitar o forte acoplamento entre as classes.
You Ain’t Gonna Need It (YAGNI)
Você Não Vai precisar Disso
O princípio YAGNI se refere a necessidade de adicionar somente as funcionalidades que são necessárias para a aplicação e deixar de lado qualquer tentação de adicionar outras funcionalidades que você acha que precisa. A metodologia de projeto que adere ao YAGNI é a test-driven development (TDD) – desenvolvimento orientado a testes. TDD se baseia na escrita de testes que comprovam a funcionalidade do sistema e então escrevem somente o codigo para obter êxito no teste.
Separation Of Concerns (SoC)
Separação de Responsabilidades
SoC é o processo de dissecação de uma parte de software em distintas características que encapsulam um único comportamento e dados que podem ser utilizados por outras classes. Geralmente, a responsabilidade representa uma características ou comportamento da classe. O ato de separar um programa em discretas responsabilidades aumenta significativamente a reutilização de código, manutenção e testabilidade.
Fonte: Professional ASP.NET Design Patterns
7
http://vod.grupouninter.com.br/2015/AGO/MT180010-A01-P03.mp4
Foi no final da década de 90 que surgiu a Linguagem de Modelagem Unificada (UML), que é a ferramenta de modelagem utilizada no desenvolvimento atual de sistemas. 
Para mais informação acesse o link a seguir. 
Saiba Mais 
UML
Por Marina Martinez
A UML (Unified Modeling Language), que significa Linguagem Unificada de Modelagem é uma linguagem padrão para modelagem orientada a objetos. Ela surgiu da fusão de três grandes métodos, do BOOCH, OMT (Rumbaugh) e OOSE (Jacobson). Esta linguagem de modelagem não proprietária de terceira geração, não é um método de desenvolvimento. Têm como papel auxiliar a visualizar o desenho e a comunicação entre objetos. Ela permite que desenvolvedores visualizem os produtos de seu trabalho em diagramas padronizados, e é muito usada para criar modelos de sistemas de software.
Além de fornecer a tecnologia necessária para apoiar a prática de engenharia de software orientada a objetos, a UML poderá ser a linguagem de modelagem padrão para modelar sistemas concorrentes e distribuídos. Utiliza-se de um conjunto de técnicas de notação gráfica para criar modelos visuais de software de sistemas intensivos, combinando as melhores técnicas de modelagem de dados, negócios, objetos e componentes. É uma linguagem de modelagem única, comum e amplamente utilizável.
Embora com a UML seja possível representar o software através de modelos orientados a objetos, ela não demonstra que tipo de trabalho deve ser feito, ou seja, não possui um processo que define como o trabalho tem que ser desenvolvido. O objetivo então é descrever "o que fazer", "como fazer", "quando fazer" e "porque deve ser feito". É necessária a elaboração completa de um dicionário de dados, para descrever todas as entidades envolvidas, refinando, com isso, os requisitos funcionais do software.
A Linguagem Unificada de Modelagem possui diagramas (representações gráficas do modelo parcial de um sistema) que são usados em combinação, com a finalidade de obter todas as visões e aspectos do sistema.
Os Diagramas da UML estão divididos em Estruturais e Comportamentais.
Diagramas Estruturais
De Classe: Este diagrama é fundamental e o mais utilizado na UML e serve de apoio aos outros diagramas. O Diagrama de Classe mostra o conjunto de classes com seus atributos e métodos e os relacionamentos entre classes.
De Objeto: O diagrama de objeto esta relacionado com o diagrama de classes e, é praticamente um complemento dele. Fornece uma visão dos valores armazenados pelos objetos de um Diagrama de Classe em um determinado momento da execução do processo do software.
De Componentes: Está associado à linguagem de programação e tem por finalidade indicar os componentes do software e seus relacionamentos.
De implantação: Determina as necessidades de hardware e características físicas do Sistema.
De Pacotes: Representa os subsistemas englobados de forma a determinar partes que o compõem.
De Estrutura: Descreve a estrutura interna de um classificador.
Diagramas Comportamentais
De Caso de Uso (Use Case): Geral e informal para fases de levantamento e análise de Requisitos do Sistema.
De Máquina de Estados: Procura acompanhar as mudanças sofridas por um objeto dentro de um processo.
De Atividades: Descreve os passos a serem percorridos para a conclusão de uma atividade.
De Interação: Dividem-se em: 
De Sequência: Descreve a ordem temporal em que as mensagens são trocadas entre os objetos.
Geral interação: Variação dos diagramas de atividades que fornece visão geral dentro do sistema ou processo do negócio.
De comunicação: Associado ao diagrama de Seqüência, complementando-o e concentrando-se em como os objetos estão vinculados.
De tempo: Descreve a mudança de estado ou condição de uma instância de uma classe ou seu papel durante o tempo.
Diagramas da UML
Referências Bibliográficas:
http://pt.wikipedia.org/wiki/UML
http://computacao.unitri.edu.br/downloads/monografia/49351143168297.pdf
http://projetos.inf.ufsc.br/arquivos_projetos/projeto_721/artigo.tcc.pdf
http://www.macoratti.net/uml_vb.htm
8
Trocando Ideias 
Com as situações criadas pelo desenvolvimento das tecnologias entramos na CRISE DE SOFTWARE. Mas o que de fato seria a “crise de software”? Refere-se a um conjunto de problemas encontrados no desenvolvimento de software e na etapa de Manutenção. Entre elas destacamos: 
As estimativas de prazo e de custo frequentemente são imprecisas. 
Insatisfação do cliente com o sistema concluído. 
A qualidade de software às vezes é menos que adequada. 
Difícil de manter (Sem Manutibilidade). 
9
Todos esses itens tiveram causas atreladas aos seguintes fatores: 
Caraterísticas próprias do software. 
Falhas das pessoas responsáveis pelo desenvolvimento de software. 
Com isso chegamos na aplicação de uma abordagem sistemática, disciplinada e possível de ser medida para o desenvolvimento, operação e manutenção do software que abrange um conjunto de três elementos fundamentais: métodos, ferramentas e procedimentos para projetar, construir e manter grandes sistemas de software de forma profissional. 
As etapas que constituem cada elemento compõem o que chamamos de Ciclo de Vida de Software, onde temos alguns ciclos mais conhecidos, Ciclo de Vida Clássico, Prototipação, Modelo Espiral. Como estes ciclos podem contribuir para a minimização da crise de software? 
Aproveite este momento para acessar o fórum e participar de nossa discussão. 
Quer se aprofundar nesse assunto? 
Então faça a leitura do livro “Tópicos de Matemática Aplicada”. 
Livro : http://ava.grupouninter.com.br/tead/hyperibook/IBPEX/278php/
Se você se interessou pela Teoria dos Conjuntos de Cantor, leia o artigo a seguir e fique por dentro de cada detalhe de sua elaboração. 
Artigo : http://www.scielo.br/pdf/paideia/n2/08.pdf
10
Na Prática 
A seguir aprofundaremos um pouco mais nosso estudo. O modelo Cascata é um modelo de engenharia projetado para ser aplicado no desenvolvimento do software. A ideia principal que o dirige é que as diferentes etapas de desenvolvimento seguem uma sequência. 
Ciclo de Vida Clássico 
Modelo mais antigo e o mais amplamente usado da engenharia de software. Requer uma abordagem sistemática, sequencial ao desenvolvimento de software. 
11
Prototipação 
Processo que possibilita ao desenvolvedor criar um modelo do software que deve ser construído. Idealmente, o modelo (protótipo) serve como um mecanismo para identificar os requisitos de software, sendo apropriado para quando o cliente já definiuum conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída com detalhes. 
Ciclo de Vida em Espiral 
Engloba as melhores características do ciclo de vida Clássico e da Prototipação, adicionando um novo elemento: a Análise de Risco. Segue a abordagem de passos sistemáticos do Ciclo de Vida Clássico incorporando-os em uma estrutura interativa que reflete mais realisticamente o mundo real e pode usar a Prototipação, em qualquer etapa da evolução do produto, como mecanismo de redução de riscos. 
12
Chegou o momento de compreender um pouco como tudo isso funciona na prática e, para isso, assista a videoaula a seguir. 
http://vod.grupouninter.com.br/2015/AGO/MT180010-A01-P04.mp4
13
Sabemos que um processo de desenvolvimento de software pode ser visto como um conjunto de atividades organizadas, usadas para definir, desenvolver, testar e manter um software.
Existem diversos processos de desenvolvimento de software, no entanto há algumas atividades básicas comuns à grande parte dos processos existentes como o levantamento de requisitos. Veja a seguir. 
Detalhes sobre o levantamento de requisitos
• Requisitos são "cortes" no espaço de solução.
• Entendimento do que o usuário quer.
• O resultado é uma promessa para o cliente.
Não só requisitos funcionais, mas também:
• Facilidade de uso necessária
• Quem utilizará o produto
• Hardware e software alvo para o produto
• Qualidade/robustez
• Desempenho
• Segurança
• Compatibilidade com outros produtos/versões e necessidades de migração
• Necessidades de internacionalização do produto
• Suporte
• Preço da solução
• Documentação necessária
• Uso de padrões
• Aspectos legais
• Integração com outros produtos
• Packagin
• Não se fala "como" as coisas serão feitas
"Use cases" descrevem cenários de funcionalidade desejada
Também chamados de "User Stories", pois é o usuário que decide o que deve ser feito.
Detalhes sobre a fase de Construção
Hoje, é considerado errado ter um processo que gere um "big bang!"
Não se deve ter o software inteiro funcionando por inteiro no primeiro release.
O risco é grande demais!
Um processo de desenvolvimento deve ser:
Iterativo
Incremental
Uma iteração dura entre 2 semanas e 2 meses.
Sempre tem algo para entregar para o cliente apressado (a última iteração).
Os requisitos mudam com tempo e um processo iterativo mantém frequentes contatos com o cliente o que ajuda a manter os requisitos sincronizados.
Altamente motivador para a equipe de desenvolvimento (e o cliente) ver o software funcionando cedo.
14
Síntese 
Estamos quase no fim de nossa aula e já vimos muitos conceitos e abordagens no que compreende a Análise de Sistemas e Desenvolvimento de Software. Para Sommerville, software compreende tudo que é necessário para um sistema computacional funcionar: programa de computador, documentação, arquivos de configuração, entre outros e existe por causa das necessidades de clientes. 
A questão a se levantar é: como transformar necessidades em software? Primeiramente, devem ser consideradas as atividades de como entender as necessidades do cliente, em seguida, planejar a solução, implementar a solução, validar esta solução e entregar o produto ao cliente. 
15
http://vod.grupouninter.com.br/2015/AGO/MT180010-A01-P05.mp4
Essas atividades são executadas ordenadamente ou não, formalmente ou informalmente. Todo processo de transformação tem início e fim. Essa variável temporal, denominada de ciclo de vida, determina as fases do desenvolvimento de software.
Para nos encaminharmos para o final de nossa aula, assista a videoaula com uma breve síntese sobre o que estudamos e discutimos hoje. 
16
Compartilhando 
Chegamos ao fim do nosso encontro e conseguimos perceber que a partir de modelos convencionais de desenvolvimento de sistemas, apura-se questões que fragilizam o processo de desenvolvimento, fundamentalmente nas ações interativas entre desenvolvedor e usuário. A engenharia de requisitos acentua como forma científica de interpretar os requisitos do sistema, uma diversidade grande de técnicas que fortalecem o rigor de compreensão dos modelos funcionais de dados e de processos. 
Aproveite este momento para compartilhar com amigos e profissionais da área interessados os conhecimentos adquiridos em nosso estudo. 
Até a próxima aula!