Portfólio Engenharia de Software

Prévia do material em texto

...............................................................................................................................
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS - EAD
ANDRÉ DOS SANTOS SILVA - 504702018
ENGENHARIA DE SOFTWARE
...............................................................................................................................
Guarulhos
2018
André dos santos Silva
ENGENHARIA DE SOFTWARE
Trabalho apresentado ao Curso Análise e Desenvolvimento de Sistemas do Centro Universitário ENIAC para a disciplina Engenharia de Software.
Guarulhos
2018
.............................................................................................................
1. O que é um requisito?
O conceito de requisito é também utilizado formalmente na ciência de computação, engenharia de software e engenharia de sistemas, referindo-se à definição de uma característica, atributo, habilidade ou qualidade que um sistema (ou qualquer um de seus módulos e sub-rotinas) deve necessariamente prover para ser útil a seus usuários.
Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir os seus objetivos; as descrições das funções e restrições são os requisitos do sistema;
Um requisito é uma propriedade que o software deve exibir para resolver algum problema no mundo real;
Uma condição ou uma capacidade que deve ser alcançada ou estar presente em um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto
2. O que são requisitos de domínio?
São requisitos derivados do domínio da aplicação e descrevem características do sistema e qualidades que refletem o domínio. Podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas. Dois exemplos de requisitos do domínio são:
O cálculo da média final de cada aluno é dado pela fórmula: (Nota1 * 2 + Nota2 * 3) /5;
Um aluno pode se matricular em uma disciplina desde que ele tenha sido aprovado nas disciplinas consideradas pré-requisitos
3. O que é o estudo de viabilidade?
Estimativa dos investimentos necessários à implantação de projetos e de custos operacionais. Faz-se através de análises técnico-econômico-financeiras, da definição de localização da empresa e do estabelecimento do esquema de captação de recursos humanos.
4. Qual a função da validação de requisitos?
Demonstrar que o documento de requisitos produzido corresponde, de fato, ao sistema que o cliente pretende.
À semelhança do que sucede na análise dos requisitos, pretende-se encontrar problemas/conflitos na especificação, porém ao contrário das fases anteriores esta fase lida com uma especificação completa dos requisitos
A validação é especialmente importante em sistemas de grandes dimensões uma vez que erros encontrados demasiado tarde (durante o desenvolvimento ou já depois de o sistema estar a ser usado) no documento de requisitos têm repercussões proporcionais à dimensão do projeto. Uma vez que alterações em requisitos já consolidados têm um custo muito superior a alterações no código ou design, este tipo de erro traduz-se em elevados custos e necessidade de refazer muito do trabalho que se julgava já concluído.
Durante a fase de validação dos requisitos, devem ser verificados (através de checklists) os seguintes atributos dos requisitos:
Validade: a especificação resulta da análise dos requisitos identificados junto das diversas partes interessadas envolvidas. Como tal, requisitos identificados individualmente (isto é, junto de cada parte interessada) podem diferir da especificação final que se atinge após o cruzamento de informação e é necessário que cada cliente compreenda e aceite a especificação final obtida.
Consistência: não devem existir conflitos entre os requisitos identificados.
Compreensibilidade / Ambiguidade: os requisitos devem poder ser compreendidos de forma inequívoca pelas partes interessadas.
Completude: todas as funcionalidades pretendidas devem fazer parte da especificação do sistema.
Realismo: dadas as restrições do projeto (tecnológicas, financeiras e temporais) o sistema especificado tem de ser implementável.
Verificabilidade: de forma a evitar futuras discordâncias quanto à concretização dos requisitos especificados, estes devem ser descritos de modo a que seja possível verificar se foram ou não concretizados, isto é, se o sistema final corresponde à especificação inicial.
Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar claramente identificada. Entre outros motivos, isto é importante para facilitar a gestão futura dos requisitos.
Conformidade com normas: para além dos aspectos funcionais dos requisitos, a sua especificação deve obedecer às normas usadas ao longo de todo o documento.
5. O que define a limitação da complexidade?
O custo da complexidade não é linear, é exponencial, e o custo da complexidade acaba por fim dominando todos os outros custos na maioria dos sistemas de software. Um código complexo é frágil e se quebra facilmente, tornando quase impossível modificamo-lo de forma segura. Empresas de desenvolvimento de softwares sensatas colocam no topo a prioridade de manter a base do código simples, limpa e pequena.
6. Como devem ser as histórias nos testes de aceitação?
Cada história deve ter valor de negócio na visão do cliente e é uma pequena parte da funcionalidade, não necessariamente uma especificação completa, o que minimiza a necessidade de uma extensa documentação.
A história de usuário é escrita pelo próprio cliente e, também, serve para conduzir a criação de teste de aceitação, o qual tem o propósito de avaliar a qualidade externa do produto e, na medida do possível, a qualidade de uso e experiência do usuário. A automatização dos testes de aceitação é criada para certificar de que a história foi implementada corretamente.
7. No que o XP é baseado?
Comunicação: A má comunicação é motivo de insucesso em quase todo tipo de projeto, inclusive nos projetos de software. Logo, este é um dos valores mais importantes do XP, bem como das metodologias ágeis como um todo. Esta comunicação deve fluir constantemente através das técnicas a serem aplicadas no processo de desenvolvimento;
Simplicidade: Manter a simplicidade é difícil e é um dos princípios do XP advindos do JIT. Assim, faça a coisa mais simples que pode funcionar, mesmo assim, é um dos princípios mais difíceis de se alcançar, pois somos tentados a fazer algo complexo pensando no futuro, mas é importante lembrar que uma das filosofias do JIT é a eliminação de desperdício, assim, simplicidade é uma obrigação.
Feedback: Muito se fala em feedback na atualidade e aqui ele não é só necessário, como um dos princípios que fazem com que o XP tenha sucesso. Para isso, o uso do TDD passa a ser tão importante, além disso, é importante o feedback do cliente, por isso os ciclos curtos, a integração contínua etc.
Coragem: Este é o último valor do XP, mas não menos importante, pois é necessário ter coragem de jogar um código fora e iniciar do zero, coragem para mudanças. A comunicação nos dá coragem para a mudança, pois temos a noção das reais necessidades do cliente.
Com base nestes valores, temos os princípios do XP.
Os quatro valores geram os princípios básicos do XP, que segundo Kent Beck são:
Feedback rápido através de ciclos curtos (iteração de uma a duas semanas) e comunicação continua (com todos os envolvidos no processo);
Simplicidade presumida, onde deve-se tratar os problemas de forma simples, ou seja, evitar tratar o problema com complexidade, utilizando recursos que nunca serão utilizados, fazendo apenas o necessário;
As mudanças devem ser feitas de forma incremental. Grandes modificações normalmente trazem grandesproblemas, então tratar a mudança com ciclos de mudanças curtos é mais eficiente e atende.
8. Quais os quatro tipos de manutenção?
Coletivamente de engenharia de sistemas de computador. Frequentemente o termo é usado no contexto de análise de requisitos 
De software. Entretanto a análise de sistemas é realizada com os objetivos de identificar a necessidade do usuário; avaliar a concepção do sistema quanto a sua exiguidade; executar a análise econômica e técnica; atribuir funções ao hardware, ao software às pessoas, aos bancos de dados e aos demais elementos do sistema; estabelecer as restrições de prazo e custos; criar uma definição do sistema que constitua uma base para o trabalho de engenharia subsequente. Tanto a perícia em hardware quanto em software é exigida para que se possa atingir com sucesso os objetivos relacionados. 
 
9. O que é abstração? 
 
Abstração é a capacidade que temos em abstrair o mundo real em objetos. Ou seja, criarmos representações (por meio de objetos) do mundo real. Da mesma forma como ocorre no mundo real, teremos objetos com identidade (nome) características e que executem ações afim de prover o funcionamento do sistema como um todo. 
Faz-se uso deste conceito ao abstrair as coisas do mundo real e pegar somente o que for relevante para sua classe. Por exemplo, se eu quisesse fazer uma aplicação para manipular e armazenar dados de um carro para um estacionamento, eu deveria pegar os dados relevantes dos carros-clientes, como: Número da placa, cor, modelo, ano. Estes são chamados atributos. Muito falaremos de “atributos”, como sendo partes de classes. Um veículo tem muitas características, porém só nos interessa pegar o que nos for relevante para a aplicação. 
10. O que é engenharia de software? 
 
Engenharia de software é o processo de analisar as necessidades do usuário e projetar, construir e testar aplicações de usuários finais que irão satisfazer essas necessidades através do uso de linguagens de programação de software. É a aplicação de princípios de engenharia para o desenvolvimento de software. Em contraste com a programação simples, a engenharia de software é usada para sistemas de software maiores e mais complexos, que são usados como sistemas críticos para empresas e organizações. 
Um engenheiro de software leva em conta as necessidades de software dos usuários finais e consequentemente desenvolve ou projeta novas aplicações. Além disso, a engenharia de software pode envolver o processo de análise de software existente e modificá-lo para atender às necessidades atuais da aplicação. 
À medida que o hardware do computador se torna mais barato, o foco se transfere para os sistemas de software. Grandes sistemas de software podem ser mais complexos do que o hardware usado para os executar, por isso há grande demanda por melhores práticas e processos de engenharia que podem ser aplicados ao desenvolvimento de software. 
Deve haver disciplina e controle durante a engenharia de software, bem como qualquer esforço de engenharia complexa. 
11. O que é tecnologia em camadas? 
 
Reunião de metodologias, métodos, ferramentas, procedimentos e princípios a serem utilizados durante o processo de produção de software (percepção do problema, planejamento, implantação e manutenção) com o intuito de obter produtos de alta qualidade. 
Qualidade: É a camada que suporta a engenharia software, tendo como foco um software total com qualidade Processo: É o conjunto de atividade e resultados associados que geram um produto de software. Há quatro atividades de processo fundamentais comuns a todos os processos de software. Especificação as funcionalidades (requisitos funcionais) as restrições tecnológicas (requisitos não-funcionais ou atributos) e as restrições de negócios (requisitos de domínio) devem ser definidas. Desenvolvimento do software: Detalhamento, solução e codificação devem ser realizadas de modo que atenda as especificações. 
Validação do software: O software tem de ser validado para garante que ele realize o que foi especificado. 
Evolução do software: O Software deve evoluir para atender às necessidades mutáveis do cliente/usuário. 
Métodos: São abordagens para o desenvolvimento de software que incluem: modelos, notações, regras, recomendações e diretrizes. É a camada que fornece a técnica de como fazer para construir softwares, ou seja a maneira como conduzir um processo.
Ferramentas: É a camada que proporciona apoio automatizado aos processos e métodos, como por exemplo, a ferramenta CASE. 
12. De acordo com as fases de definição, qual o papel da análise de sistemas? 
 
A função da fase de Análise, baseada no documento de requisitos, ou seja, no resultado gerado pelo documento do sistema, é identificar as classes de objetos existentes no sistema, descrever os relacionamentos entre elas e definir as operações que poderão ser executadas pelo sistema. A fase de Análise mostra "o que" o sistema faz e não "como" ele é feito, obtendo-se ao final desta fase um " documento de especificações" que permitirá a transição à Fase de Projeto. A construção de dois principais modelos estáticos são os objetivos da fase de Análise, os quais tratam de aspectos diferentes, sendo a modelagem das classes de objetos e a modelagem dos cenários, os quais possibilitam identificar e derivar as operações do sistema. Assim, esta fase do processo é responsável pelas seguintes descrições: classes de objetos (sem associar quaisquer métodos às classes); relacionamentos entre classes; operações do sistema; sequência permissível de eventos de entrada e saída. No entanto, a proposta de um processo cíclico exige que os requisitos a serem tratados sejam melhor detalhados. Assim, a proposta para a fase de Análise prevê que os requisitos sejam inicialmente refinados modelando-os por Objetivo (Modelo de Requisitos por Objetivo) e adotando-se os Cenários para melhor visualizá-los. 
Análise de sistemas engloba a maioria das tarefas que chamamos coletivamente de engenharia de sistemas de computador. Frequentemente o termo é usado no contexto de análise de requisitos de software. Entretanto a análise de sistemas é realizada com os objetivos de identificar a necessidade do usuário; avaliar a concepção do sistema quanto a sua exiguidade; executar a análise econômica e técnica; atribuir funções ao hardware, a o software às pessoas, aos bancos de dados e aos demais elementos do sistema; estabelecer as restrições de prazo e custos; criar uma definição do sistema que constitua uma base para o trabalho de engenharia subsequente. Tanto a perícia em hardware quanto em software é exigida para que se possa atingir com sucesso os objetivos relacionados. 
 
 
 
13. De acordo com as fases de definição, qual o papel da análise de requisitos? 
 
Requisitos são definidos durante as fases iniciais do desenvolvimento do sistema como uma especificação do que deveria ser implementado. São
Descrições de como o sistema deveria comportar-se. 
Assim sendo, pode-se considerar que a ER é uma das fases mais importantes do processo de engenharia de software a fim de melhorar a qualidade dos requisitos 
Segundo Kotonya e Sommerville (1997), um requisito pode descrever 
. •. Uma facilidade para o usuário; por exemplo, um corretor de gramática e ortografia; 
 •. Uma propriedade muito geral do sistema; por exemplo, o sigilo de informações; 
• . Uma restrição específica no sistema; por exemplo, o tempo de varredura de um sensor; 
 •. Uma restrição no desenvolvimento do sistema; por exemplo, a linguagem que deverá ser utilizada para o desenvolvimento do sistema
CONCLUSÃO / PARECER
Uma das vantagens oferecidas e que considero a mais importante foi o conhecimento que tive a respeito da Engenharia e como ela é atuante neste mundo globalizado de hoje em dia. Foi um estudo muito interessante e instrutivo elaborado através de uma visão geral e proporcionando um melhor conhecimento sobre Engenhariade Software.