FACULDADE DO LITORAL SUL PAULISTA FALS CLAYTON DE SOUZA SILVA REQUISITOS DE SOFTWARE

FACULDADE DO LITORAL SUL PAULISTA FALS CLAYTON DE SOUZA SILVA REQUISITOS DE SOFTWARE PRAIA GRANDE 2010

CLAYTON DE SOUZA SILVA REQUISITOS DE SOFTWARE Trabalho de conclusão de curso, Faculdade do Litoral Sul Paulista, sob orientação do Prof. Ana Lucia Pegetti. PRAIA GRANDE 2010

CLAYTON DE SOUZA SILVA REQUISITOS DE SOFTWARE Trabalho de conclusão de curso, Faculdade do Litoral Sul Paulista, sob orientação do Prof. Ana Lucia Pegetti. AVALIAÇÃO: NOTA: ( ), de de. Local data

RESUMO A Engenharia de Software é uma disciplina distinta que utiliza um conjunto de métodos, técnicas e ferramentas para analisar, projetar e gerenciar desenvolvimento e manutenção de software. O conjunto de técnicas de levantamento, documentação e análise forma a engenharia de requisitos, que é uma das disciplinas da Engenharia de Software, após ser estabelecido os requisitos teremos um projeto que definirá os objetivos e necessidades que deverão ser alcançados, possibilitando a definição do escopo do projeto com precisão, nesta fase é necessário detalhar todos os aspectos funcionais e não-funcionais estabelecendo um conjunto de especificações com um nível máximo de detalhamento, neste caso os requisitos de software é o processo de identificação de todos os envolvidos onde é documentado para análise e posterior implementação. PALAVRAS CHAVES: Requisitos e projetos.

ABSTRACT Software Engineering is a discipline that uses a distinct set of methods, techniques and tools to analyze, design and manage development and maintenance of software. The set of elicitation techniques, documentation and analysis as to requirements engineering, which is one of the disciplines of Software Engineering, having been established requirements will have a project that will define the goals and needs to be achieved, allowing for the scoping project with precision at this stage is necessary to detail all the functional and nonfunctional establishing a set of specifications with a maximum level of detail, in this case the software requirements is the process of identifying all those involved where it is documented for analysis and subsequent implementation. KEYWORDS TOOL: Requirements and projects.

SUMÁRIO 1. INTRODUÇÃO... 1 2. JUSTIFICATIVA... 2 3. OBJETIVO DO TRABALHO... 3 4. REFERENCIAL CONCEITUAL... 4 4.1. Objetivos da Engenharia de Software...5 4.2. Princípios da Engenharia de Software...6 4.3. Processos de Software...7 4.4. Tipos de Processos...8 5. ENGENHARIA DE REQUISITOS E SEUS PROCESSOS... 12 5.1 Ciclos de Vida do Software...13 5.2 Etapas do Projeto de elaboração de Software...17 5.3 Projetos e seus processos...18 6. REQUISITOS DE SOFTWARE... 21 6.1 Modelo do Problema...24 6.2 Modelo do Sistema...25 6.3 Modelagem do Processo, Caso de Uso e Qualidade de Software...26 7. TIPOS DE REQUISITOS DE SOFTWARE... 30 7.1 Requisitos de Usuários...32 7.2 Especificação e Analise de requisitos de software...34 7.3 Requisitos e interfaces externas...35 8. CONCLUSÃO... 36 9. ANEXOS MODELOS DE DOCUMENTOS DE REQUISITOS... 37

10. REFERENCIAS BIBLIOGRAFICAS... 41 11. REFERENCIAS ELETRONICAS... 42

SUMÁRIO DAS FÍGURAS 1. FIGURA 1 (Processo de engenharia de software)... 7 2. FIGURA 2 (Modelo Cascata)... 8 3. FIGURA 3 (Desenvolvimento de software)... 10 4. FIGURA 4 (Espiral... 10 5. FIGURA 5 (Analíse de requisitos de software)... 13 6. FIGURA 6 (Gerenciamento dos requisitos)... 23 7. FIGURA 7 (Processo interativo)... 27 8. FIGURA 8 (As macro atividades da fase de RU)... 33

1. INTRODUÇÃO Nos projetos da engenharia de software evoluem da necessidade para a idéia e desta para a realidade, a disciplina de requisitos de software auxiliará a reunir as atividades que procuram obter o enunciado completo, claro e preciso dos requisitos de um projeto de software. Requisitos são objetivos ou restrições estabelecidos por clientes e usuários que definem as suas diversas propriedades do sistema. Os requisitos de software são, obviamente, os requisitos de sistema que dizem respeito a propriedades do software. Os requisitos de software de uma maneira objetiva é a base para a criação de um sistema com a menor probabilidade de erro ou falha. Um sistema de software é caracterizado por um conjunto de componentes abstratos como uma estrutura de dados e um algoritmo, unidos como uma forma de procedimento, funções, módulos, objetos ou agentes que de certa forma estão ligados compondo assim a Engenharia de Software, onde deverão ser executados em sistemas computacionais. Os fundamentos da Engenharia de Software são os modelos abstratos e preciosos, permitindo à especificação, o planejamento, a implementação e até mesmo manter um sistema com uma avaliação continua, garantindo assim sua qualidade. A importância da Engenharia de Software é que tem como objetivo principal o melhoramento da qualidade do software e um aumento da produtividade, por este motivo é fundamental ser bem estabelecido antecipadamente os requisitos de desenvolvimento de software, estes requisitos auxiliarão tanto para o desenvolvimento quanto para diagnosticar possíveis falhas no momento de implantação do sistema, isso ocorrera devido ao fato dos requisitos terem como finalidade serem utilizados ate mesmo como base para um desenvolvimento, sendo estabelecidos por pessoas ligadas diretamente ao produto final. 7

2. JUSTIFICATIVA A grande importância de se abordar os requisitos de software é chegar a um alcance da qualidade e quando é possível se alcançar todos os requisitos pré estabelecidos, antecipando e satisfazendo as necessidades do cliente, a qualidade é escrever previamente tudo o que devera ser realizado e se cumprir este relatório pré estabelecido, quanto maior a precisão e menor a margem de erro no desenvolvimento e implantação do projeto, será mais fácil de obter o sucesso. Por isso é fundamental constantes analises dos relatórios onde são denominados de requisitos de software, normalmente estes requisitos são estabelecidos antes do desenvolvimento de processos, onde esses requisitos deverão ser levantados pela equipe do projeto juntamente com o representante do cliente, usuário, e possivelmente, especialistas na área de aplicação. A engenharia de requisitos é o principal passo para o desenvolvimento de um bom produto em qualquer caso, os requisitos de alta qualidade são aqueles que possuem uma linguagem clara, consistentes, completos e testáveis. A definição dos requisitos consiste em uma lista em que são relatados todos os requisitos funcionais e os principais requisitos não-funcionais, sendo fundamental a identificação dos atores, dos casos de uso, dos relacionamentos entre atores, dos relacionamentos entre atores e os casos de uso, dos diagramas de contexto, das restrições de memória, dos modos de operação, dos requisitos de adaptação ao ambiente, das restrições ao produto, das hipóteses de trabalho. A principal função do analista de requisitos é auxiliar o gerente de projeto e também do desenvolvedor, pois são lançados fundamentos das atividades de análise. O principal resultado devera ser um pacote de descrição geral, da visão de requisitos do modelo do problema. 8

3. OBJETIVO DO TRABALHO O principal objetivo desta monografia é abordar de uma forma mais detalhada as principais restrições estabelecidas por clientes e usuários e apresentar as principais dificuldades e falhas que ocorrem em um projeto de software na elaboração de seus requisitos. Desenvolver software é uma atividade complexa por natureza. Uma das razões para esta afirmação é que não existe uma única solução para cada cenário de desenvolvimento. Além disso, lidamos o tempo todo com pessoas, o que torna o sucesso do projeto bastante relacionado à competência da equipe e à forma como trabalham, e, para dificultar ainda mais, muitas vezes não fazemos uso de um processo bem definido para apoiar as atividades do projeto. (Artigo Engenharia de Software Ana Luiza Ávila UNIFACS 2008) Conforme o artigo citado anteriormente, o que leva a uma motivação para aprofundamento do estudo sobre requisitos de software, é a busca por um resultado positivo no final da elaboração do projeto, para que isso ocorra é muito importante que os requisitos sejam bem definidos. Outro foco desta monografia é demonstrar com uma linguagem clara e objetiva as definições e a importância de cada fase do desenvolvimento de um projeto, para que se possa conquistar uma validação da empresa 9

4. REFERENCIAL CONCEITUAL Engenharia de Software Fundamentos, métodos e padrões Visando melhorar a qualidade dos produtos de software e aumentar a produtividade no processo de desenvolvimento, surgiu a Engenharia de Software. A Engenharia de Software trata de aspectos relacionados ao estabelecimento de processos, técnicas, métodos, ambientes e ferramentas de suporte ao desenvolvimento de software, os processos seguem os métodos e estes de utilizam de ferramentas visando solucionar problemas referentes ao processo e ao produto, seu objetivo é estabelecer uma abordagem de desenvolvimento, através de ferramentas e técnicas apropriadas, considerando restrições e recursos disponíveis. Os métodos utilizados na engenharia de software são abordagens estruturadas para o desenvolvimento de software que também incluem os modelos de software, notações, regras e maneiras de desenvolvimento. Segundo MARTIN e McCLURE (1991) a engenharia de software é: o estudo dos princípios e sua aplicação no desenvolvimento e manutenção de sistemas de software... tanto a engenharia de software como as técnicas estruturadas são coleções de metodologias de software e ferramentas... Para MAFFEO (1992) a engenharia de software é: a área interdisciplinar que engloba vertentes tecnológica e gerencial visando a abordar de modo sistemático (modular), os processos de construção, implantação e manutenção de produtos de software com qualidade assegurada por construção segundo cronogramas e custos previamente definidos. Segundo SOMMERVILLE (1992) a engenharia de software envolve questões técnicas e não-técnicas, tais como a especificação do conhecimento, técnicas de projeto e implementação, conhecimentos dos fatores humanos pelo engenheiro de software e ainda, gestão de projetos. Para PAULA FILHO (2001) a engenharia de software é conexa. Porém distinta, e envolve múltiplas variáveis, tais como arte, atendimento das necessidades humanas, 10

conhecimentos científicos, conhecimentos empíricos, habilidades especificas, recursos naturais, formas adequadas, dispositivos, estruturas e processos. Não deve ser confundida com a ciência e fornece problemas para seus estudos. Segundo CARVALHO e CHIOSSI (2001) a engenharia de software é uma disciplina que reúne metodologias, métodos e ferramentas a serem utilizados, desde a percepção do problema até o momento que o sistema desenvolvido deixa de ser operacional, visando resolver problemas inerentes ao processo de desenvolvimento e ao produto de software. Outras definições de engenharia de software costumam omitir a vertente gerencial. Concentram-se apenas no aspecto tecnológico do problema. Os aspectos gerenciais do desenvolvimento de software devem receber uma atenção cada vez maior nessa disciplina (PRESSMAN, 1995). Nesse sentido, a engenharia de software pode de caracterizar por um desenvolvimento de software pratico, ordenado e medido para produzir sistemas satisfatórios aos usuários e que respeitem prazos e orçamentos (PETERS; PEDRYCZ, 2001). Os benefícios dos novos ambientes de desenvolvimento de software sejam significativos, porém é importante ressaltar que os seus elementos básicos são as pessoas. Desta forma é essencial estabelecer que seja feito um planejamento no contexto de engenharia de software, para que assim suas necessidades sejam atendidas. Ao englobar as duas vertentes, tecnológica e gerencial, a definição para Engenharia de Software indica para a necessidade dos dois temas, desta forma ocorrera uma aprimoramento dos conhecimentos e métodos dessa disciplina, além de colaborar para os aspectos particulares de cada vertente. 4.1 - Objetivos da engenharia de software A engenharia de software tem como objetivo sistematizar a produção, evolução, a manutenção e a recuperação de produtos de software, de maneira que seja executado dentro de prazos e custos estimados, sempre utilizando métodos, tecnologia e processos. Os produtos que são desenvolvidos seguindo efetivamente esse processo e os preceitos 11

da Engenharia de Software tendem a atender uma qualidade satisfatória, deixando assim os seus usuários satisfeitos com suas tarefas. De modo geral, considera-se que os objetivos primários da Engenharia de Software são o aprimoramento da qualidade dos produtos de software e o aumento da produtividade dos engenheiros de software, além do atendimento aos requisitos de eficácia e eficiência, ou seja, efetividade (MAFFEO, 1992) Nesses casos de elaboração de produtos industriais e elaboração de sistemas de software, é necessário que seja feita a analise e especificação dos requisitos de forma rigorosa, à medida que seja considerado um produto que se deve haver manutenção durante esse tempo, essa característica impõe ao software uma complexidade em relação aos produtos tradicionais da engenharia, mas dificilmente modificam-se durante a operação. Associação a esses objetivos, o termo engenharia pretende indicar que o desenvolvimento de software deve submeter-se a leis similares as que governam a manufatura dos produtos industriais e engenharias tradicionais, pois ambos são metodológicos (MAFFEO, 1992). 4.2 - Princípios da engenharia de software Alguns princípios fundamentais deram inicio a engenharia de software, que devem ser levadas em consideração nas aplicações dos softwares nas organizações, esses elementos podem ser utilizados no processo em um produto final do software. O relacionamento entre processo e produto são muito próximo, quando um está correto o resultado do outro também estará. Os princípios requerem metodologias pertinentes e adequadas aos métodos e ferramentas que incorporam as propriedades desejadas aos processos e aos produtos do software (CARVALHO; CHIOSSI, 2001). Segundo (GUEZZU; JAZAYERI, 1991) alguns princípios podem ser destacados: formalidade para evitar a dependência e determinadas pessoas ou processos; abstração para identificar aspectos importantes de determinado fenômeno; decomposição para 12

subdividir problemas complexos; generalização para disseminar soluções semelhantes e reutilizar resultados; e flexibilização para facilitar eventuais mudanças modulares. 4.3 - Processos de software Os processos de software têm fundamentos e conceitos que equivalem a metodologias de desenvolvimento e manutenção de software, ambos são bases para a elaboração de software que contenham fases, subfases, produtos externados e pontos de avaliação de qualidade. Figura 1 - www.alexandrebartie.spaces.live.com Conforme a demonstração anterior, um processo de engenharia de software pode ser caracterizado por um tipo de modelo que estabeleça a forma de sistematização e que consiga controlar todas as atividades relacionadas à construção de softwares. Um bom processo deve ser estruturado em disciplinas que possibilitem o gerenciamento dos aspectos que estejam em um nível mais critico. Cada disciplina tem um determinado foco dentro do processo e define de que forma irá se organizar, conduzir e avaliar os procedimentos relacionados a estes aspectos críticos. 13

Porém, um processo de software é um modelo estático que indica de que maneira deve lidar com seus projetos de softwares. Conforme novas técnicas e ferramentas são criadas, naturalmente novas tecnologias são disponibilizadas e novos obstáculos são superados. Um processo é um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e transformações, usado para atingir uma meta. Essa meta está associada a uma ou mais resultados concretos finais, que são os produtos da execução do processo (PAULA FILHO, 2001). Um processo deve conter documentações para que se possa relatar o que será feito, quando e quem irá desenvolver, é preciso os requerimentos de necessidades e os resultados, o nível de aprofundamento e detalhamento dos processos a serem executados é decidido pela equipe de desenvolvimento do software. Os integrantes dessa equipe têm a liberdade de acrescentar detalhes ou até mesmo suprimir partes, desta forma é permitido alterar a sua ordem e executar paralelamente outras atividades, um subprocesso é caracterizado por elementos de um processo 4.4. Tipos de processos Modelo Cascata Figura 2 - Artigo: Metodologias Ágeis para desenvolvimento de software www.cpdti.com.br 14

O modelo cascata tem como referência fases bem definidas, com inicio e término para as próximas fases, de forma seqüencial. Para que possa dar sequencia às próximas fases é necessário obter um laudo da fase anterior com a aprovação para a próxima etapa. Um processo pode ser subdividido em diversas formas, mas basicamente o contexto principal consiste nas fases acima demonstradas na figura 2. Requisitos: Tem como embasamento os famosos stakeholders (clientes, usuários, gerentes, etc.), pois são eles que estão ligados diretamente ao projeto em questão, podendo ser usuários ou até mesmo futuros usuários. Análise: As especificações de requisitos transformam-se em modelos de software, mas sem obter muito detalhamento técnico. Projeto: São baseados na análise, nesta fase os modelos são detalhados para uma futura aplicação, os modelos representam de uma forma mais concreta o problema que for especificado. Implementação: Nesta fase o projeto e análise são implementados, de uma maneira mais automatizada utilizando linguagens de programação. Testes: São realizados testes unitários e conseqüentemente testes integrados, desta forma contendo todo o software. Implantação: É a fase em que o software é colocado em prática, diversas atividades são relacionadas, como por exemplo: bases de dados com dados reais, treinamento, instalação, etc. Porém as suas atividades dependeram muito da empresa e do ambiente em que o software irá ser executado. Com ou sem especificações dos requisitos funcionais os desenvolvedores de software codificam ou programam os processos. 15

Figura 3 - Artigo: Modelo de desenvolvimento de software www.inf.unisul.br Os processos são determinados por uma seqüência de desenvolvimento de software com demarcações predefinidas de avaliação. Caso o processo não permita certa flexibilidade do retorno nas seqüências, ele causará percas valiosas para seu usuário final. As suas fases são: definição e analise dos requerimentos do software; projeto do software, implementação e testes; implantação e integração do produto, em cada tipo de fases são definidas suas respectivas atividades e a partir desse conceito os produtos de saída são gerados. Espiral Figura 4 - www.engsoftwaredpsi.blogspot.com 16

Esse processo permite varias repetições entre as fases do desenvolvimento, cada repetição implica numa volta ao modelo espiral, desta maneira os desenvolvedores podem alcançar os resultados desejados em menos tempo, esse tipo de modelo de processos necessita de uma atenção especial dos seus gestores no que diz respeito ao processo de repetições, principalmente quanto à qualidade de seus produtos gerados. Entrega por estágios Esse processo de software libera partes do software aos clientes ou usuários finais. É uma combinação dos modelos cascata e prototipagem evolutiva. 17

5. ENGENHARIA DE REQUISITOS E SEUS PROCESSOS Todo projeto de software deverá ser desenvolvido a partir dos requisitos que deverão ser estabelecidos, antes mesmo de sua inicialização. Antes da analise e determinação dos requisitos é importante que os pré-requisitos sejam estabelecidos, pois a partir deles é que será tomada a grande maioria das decisões para o seu desenvolvimento. De uma forma mais ampla pode-se dizer que a palavra projeto possui um significado de empreendimento, e é um trabalho que visa à criação de um produto ou a execução de um serviço especifico temporário, ou não repetitivo, e que envolve de certa forma um grau de incerteza na sua realização. O trabalho de uma forma geral normalmente é executado por pessoas que irão consumir horas, estão limitadas no prazo, custo e escopo. Como em qualquer momento, empreendimento ou realização é necessário que seja feito, um planejamento, programados, e durante a sua execução é fundamental um monitoramento. O perfil do profissional de qualidade é ser um profissional que tenha a desenvoltura de se encaixar a todos os tipos de cliente final, ou seja, um profissional eclético, que tenha conhecimentos técnicos, mas que também tenha o conhecimento de negócios e principalmente do comportamento humano, isto é importante para que possa atender as necessidades dos clientes de acordo com o seu perfil. O comportamento humano, etnias e políticas estão de certa forma ligada às atividades de sistemas ou software. Existem também algumas atividades e habilidades que são adquiridas pelo mercado, para que se possa atingir a qualidade, produtividade e efetividade total, porém é necessário, que se tenha uma postura adequada e domínio das habilidades técnicas. 18

5.1. Ciclos de vida do software; O processo inclui a elaboração de um produto, esta elaboração poderá ser referida como ciclo de vida, pois ela relata a vida do produto de software, desde a concepção até a implantação, entrega, utilização e manutenção É fundamental no momento de desenvolvimento, estabelecer o ciclo de vida, determinar o usuário final, podendo ser um funcionário da organização, um cliente, departamento de marketing ou vendas da organização produtora, este ciclo de vida normalmente é feito a partir da percepção das necessidades, estará sujeito à manutenção quando necessário e será retirado de operação ao final de sua vida útil. Figura 5 - Análise de requisitos de software www.eps.ufsc.br Um ciclo de vida possui divisões e subdivisões, é fundamental observar a codificação que representa a escrita final, essa codificação é uma das principais tarefas do desenvolvedor de software. Muitas vezes o ciclo de vida é confundido com modelo de processo, o ciclo de vida descreve as fases do software, desde a sua criação até o fim de seu uso. Diversas denominações podem ser usadas para as fases do ciclo de vida de um software, neste modelo que veremos a seguir são 4 fases, cada fase possui suas atividades. Essas fases são: 19

Definição Desenvolvimento Operações Retirada Nesta fase de definição do software é possível agir em conjunto com outras atividades como a análise de sistemas e a modelagem de processos de negócios. É essencial saber primeiramente identificar os problemas, para que a partir daí possa criar uma proposta de solução de sistemas computacionais, nesta proposta deve-se incluir a analise e o custo-benefício do projeto, informações sobre hardware, software, procedimentos, informação e documentação. Não existe uma regra para se determinar o fim da fase de definição, isto varia muito com a complexidade do modelo de processo, dependendo do modelo adotado a fase de desenvolvimento pode iniciar antes mesmo que a fase de definição seja totalmente concluída. Na fase de desenvolvimento é subdividido em etapas como design, implementação, verificação e validação de software. Design é a parte ilustrativa do projeto que é subdividido em design conceitual, design de interface do usuário, design da arquitetura de software e design dos algoritmos e estruturas de dados. Design conceitual é a determinação dos elementos fundamentais de um software exercendo uma influencia da interface de usuário e na arquitetura do software. Design da interface de usuário é a estrutura principal para o sucesso do software, pois é a maneira do usuário realizar suas tarefas o layout das janelas e telas. Design de arquitetura de software é subdividida em visão conceitual, visão módulos, visão de códigos e visão de execução; A visão conceitual é de uma 20

maneira geral uma arquitetura de camadas e arquitetura cliente/servidor é composta por componentes conceituais. Design de algoritmo e estruturas de dados é a linguagem de programação adotada, soluções algorítmicas e estruturas de dados associados. A implementação são as atividades de codificação, compilação, integração e testes. A codificação é a transparência da estrutura e o comportamento descrito no design, seu principal objetivo é traduzir design no programa, utilizando-se de linguagem e ferramentas adequadas. No momento da implementação é fundamental um gerenciamento de versões para um controle correto de tudo que esta sendo codificado. Verificação e validação, principal função é analisar se o sistema esta de acordo com as expectativas de cliente e usuário, a validação assegura se o programa está de acordo com a definição e especificação, a verificação visa analisar se possui erros de execução, existem formas que podem ser utilizadas antes do programa ser codificado, como inspeção analítica e revisão de modelos, documentos e código fonte. A partir da execução de software existem vários fatores para uma analise de qualidade como, teste de correção, desempenho, confiabilidade, robustez, usabilidade, dentre outros, dentre estes fatores pode-se utilizar variadas técnicas para aplicação. A fase de operação do software é subdividida em atividades; Distribuição e entrega; Instalação e configuração Utilização Manutenção A distribuição e entrega pode ser feita de uma forma mais direta pelo desenvolvedor (quando personalizado), ou em pacote que poderão ser vendido por prateleiras de lojas, ou ate mesmo para ser baixado pela internet. 21

O processo de instalação e configuração. Poderá ser feito com o auxilio de softwares de instalação, que são disponibilizados por fabricantes de ambientes operacionais. software. O processo de utilização assim como o nome já diz é a usabilidade do O processo de manutenção poderá ser feito de duas maneiras: corretiva e evolutiva. A manutenção corretiva tem como seu objetivo principal a solução de problemas que poderão interferir na qualidade do software, como: falhas, baixo desempenho, entre outros. A manutenção evolutiva que também poder ser nomeada como evolução adaptativa, procura atender todos os requisitos do cliente através da criação de novas versões de software, ou adaptando as novas tecnologias que poderão surgir como (hardware, plataformas, linguagens, entre outros). No momento em que ocorrem novas mudanças, novas tecnologias de software e hardware, requerem uma evolução continuada. A fase Retida é uma das etapas mais difíceis, principalmente nos tempos atuais, pois a empresa de certa forma esta operando softwares que possuem excelentes níveis de confiabilidade e de correção, mas é necessário uma evolução para uma acompanhamento do desenvolvimento de uma maneira geral, para acompanhar os novos requisitos exigidos, também é considerada uma situação difícil, pois isso pode exigir ate mesmo que haja um treinamento da equipe operante, pois será um software novo, com novas exigências e comandos, onde a equipe não estará acostumada a lidar. Um fator também que dificulta este processo é a questão da confiabilidade, pois de uma maneira geral a organização já esta acostumada, confia no desenvolvimento de seu trabalho, tem consciência que o novo software servira para um aperfeiçoamento do anterior, mais muitas vezes poderão existir resistências do setor, no período de adaptação. O processo de software poderá ser aplicado para viabilizar a transferência de um software anterior para um novo proporcionando assim uma substituição suave. 22

O projeto de uma maneira geral é dividido em fases para se ter um controle gerencial e permitir uma melhor sintonia com os processos gerenciais, essas são determinadas como ciclo de vida de um projeto. O desenvolvimento de software é feito através do projeto, em todo projeto é indispensável uma data de inicio e uma data de fim, uma equipe juntamente a um gerente de projeto e outros recursos, ou seja, um projeto é a execução de um processo. Se o processo é bem estabelecido deverá ter subdivisões que permita a avaliação e correção, em caso de problema essas subdivisões são denominadas de fases, atividades ou interações, as subdivisões devem ser terminadas por marcos, sendo associados a resultados concretos como documentos, modelos ou porções do produto. O produto será associado ao marco de conclusão do projeto. 5.2. Etapas do Projeto de elaboração do software; A base de um projeto é a identificação das partes interessadas (stakeholders), ou seja, os responsáveis pelo resultado do empreendimento, mas existem outros interesses que devem ser considerados como os próprios desenvolvedores, os dirigentes da organização, os fornecedores de insumos e subcontratados e autoridades reguladoras. Estas partes no momento de atividade de especificação, planejamento, decisão, comunicação, revisões e avaliações, podem ter suas participações. Nem sempre será viável o envolvimento de todas as partes, exceto o seu ponto de vista que deverá ser representado por um componente da equipe. Este plano de projeto poderá ser composto de uma variedade componente para o seu desenvolvimento. Para o desenvolvimento de software é necessária a estruturação das tarefas requeridas para a elaboração com alta qualidade, pois o foco principal do desenvolvimento de software é a qualidade utilizando processos, métodos e ferramentas. 23

Caso o processo de desenvolvimento de um produto o resultado não seja satisfatório, sem duvida o produto obtido também será de baixa qualidade, desta forma vale ressaltar que não se deve focar apenas no processo, mas também no produto. O desenvolvedor de software necessita de uma resulto satisfatório tanto no processo de desenvolvimento como no resultado final. 5.3. Projeto e seus processos; Um fator que impulsiona o gerenciamento de projetos é o crescimento da competitividade. Quem for mais rápido e competente certamente conseguira melhores resultados. (VARGAS, 1999, p.5) Processo de gerenciamento do projeto é composta de um conjunto de processos que geram um produto final, este produto final precisa ser avaliado pela equipe envolvida ao seu termino. Alguns desses processos são: Processo de inicialização que é o momento em que o seu objetivo é reconhecer que um produto ou fase devera começar e se comprometer para a sua execução. Processo de Planejamento que tem como objetivo planejar e manter o esquema de trabalho com um meio de se atingir as exigências do projeto. Processo de execução tem como objetivo e foco principal a coordenação de pessoas e outros recursos para se executar o plano como um todo. Processos de controle procuram se manter um controle quanto ao desenvolvimento do projeto em questão, por meio de monitoramento e avaliação do seu processo, tomando ações e decisões quando necessário. Para se atingir os níveis de organização independente da quantidade de pessoas envolvidas o projeto muitas vezes extrapola fronteiras atingindo até os 24

fornecedores, clientes, parceiros e governo podendo fazer parte da estratégia de negocio da companhia. Alguns exemplos de projetos: Redação de uma livro Remuneração de um determinado setor Remuneração de um departamento da empresa Elaboração de um plano de marketing e publicidade Lançamento de um novo produto ou serviço Informatização de um determinado setor da empresa Aperfeiçoamento e substituição do software utilizado Realização de uma viagem O gerenciamento de processo de produção esta associado ao desenvolvimento tendo a necessidade de aplicação de métodos, técnicas e ferramentas, para isto é necessário que se tenha um planejamento de custos e prazos, montagem da equipe qualificada e garantia de qualidade do produto e do processo. A área de gestão de projetos normalmente é composta por nove áreas de conhecimento em gerenciamento de projetos: Gerenciamento de integração é um subconjunto do gerenciamento de projetos que procura assegurar que todos os elementos do projeto sejam coordenados de forma adequada. Gerenciamento de escopo é um subconjunto do gerenciamento de projetos que analise se todas as exigências e contextos que estão inclusos para uma elaboração bem sucedida. Gerenciamento de tempo é um subconjunto do gerenciamento de projetos que visa que o projeto e seu desenvolvimento ocorram dentro do prazo previsto. 25

Gerenciamento de custos é um subconjunto do gerenciamento de projetos que analise e vistoria se o projeto esta de acordo com Orçamento pré-estabelecido. Gerenciamento de qualidade é um subconjunto do gerenciamento de projetos que visa que seu produto esteja em conformidade com o cliente e ou contratante, com a melhor qualidade conforme contratada. Gerenciamento de recursos humanos é um subconjunto do gerenciamento de projetos que tem como objetivo melhor o envolvimento de uma forma adequada das pessoas do projeto. Gerenciamento das comunicações é um subconjunto do gerenciamento de projetos que visa que assegurar que as informações obtidas, comunicadas e disseminadas, ocorram de uma forma adequada. Gerenciamento de riscos é um subconjunto do gerenciamento de projetos onde são analisados todos os riscos que estabelecidos, previamente, durante e após a elaboração dos projetos. Na maioria das vezes estes riscos são determinados de acordo com o perfil principal do cliente em questão. Gerenciamento de suprimentos é um subconjunto do gerenciamento de projetos administra a forma de aquisição de bens e serviços fora da organização provedora do projeto em questão. 26

6. REQUISITOS DE SOFTWARE: A fase inicial para a elaboração dos requisitos é a elicitação de requisitos, onde nesta fase serão determinadas as funções do software, ou seja, identificar de uma forma conjunta com o cliente/usuário quais serão os objetivos do sistema, de que maneira o sistema deverá se adequar as necessidades do negócio. A parte mais complexa na criação de um software é conseguir identificar de maneira correta o que se deve construir, para que assim a aplicabilidade do sistema possa se encaixar com o que o projeto esteja impondo, essa fase do projeto pode comprometer o resultado final caso não seja elaborado um escopo de forma completa, os limites do sistema bem definidos e também é muito importante uma boa comunicação e compreensão entre o desenvolvedor e o cliente/usuário, é importantíssimo que o cliente/usuário detalhe as informações para o desenvolvedor definindo as necessidades que o sistema deverá abranger. A forma mais utilizada para superar esses obstáculos é a simplicidade na hora de abordar os requisitos, quanto mais direta e objetiva a informação for passada, mais fácil ficará o entendimento de ambas as partes. Na fase da análise dos requisitos é preciso que tenha um grande conhecimento e entendimento dos requisitos de software, nada adianta ser feito se o programa for analisado e especificado de maneira errada, o resultado final com certeza não irá satisfazer o cliente-usuário. A análise de requisitos requer um processo de modelagem, refinamento e especificação, diagramas, modelos, e fluxos também são utilizados para que o problema a ser resolvido possa ser bem explicitado de uma maneira que faça com que o entendimento seja visivelmente identificado. A analista é tido como um consultor e solucionador de problemas, porém a análise e especificação de requisitos não são tarefa fácil, a comunicabilidade entre as partes é constante, por este motivo a chance de ocorrer algum tipo de erro é maior devido a má interpretação de alguma informação que tenha sido passada. A documentação dos requisitos é a parte formal do processo, significa a especificação oficial dos requisitos do sistema para cliente/usuário final, e para o desenvolvedor do software. A documentação de requisitos deve descrever todos os 27

serviços e funcionalidades que o sistema deve oferecer, quais são suas restrições, informações sobre o domínio da aplicação, a documentação dos requisitos é tido também como um contrato entre o cliente/usuário e o gerente de projeto, pois válida o acordo firmado segundo a especificação requerida dos requisitos do cliente. A documentação de requisitos é utilizada também para que possa comunicar as necessidades do sistema a todos os envolvidos no processo de desenvolvimento de software. É necessária uma estrutura para a elaboração dessa documentação dos requisitos, esta estrutura deverá conter introdução, propósito do documento, escopo, definições, acrônimos e abreviações, referências, casos de uso, diagramas, entre outros. O processo de verificação e validação dos requisitos de software serve como base para que o software possa cumprir com as suas especificações e assim atenda às necessidades dos clientes/usuários. O processo de validação e verificação é muito abrangente, devem ser aplicados a cada etapa no que se diz respeito ao processo de desenvolvimento, seus principais objetivos são relatar algum possível erro no sistema e garantir se o sistema será ou não plausível de utilização operacional. É necessária a realização de testes de programas que auxiliará na identificação de possíveis erros ou ausência, existem alguns tipos de testes, dois exemplos de testes são os testes de defeito e os testes estatísticos. Os testes de defeito realizam testes com o intuito de descobrir defeitos do sistema, para que um teste seja bem sucedido é necessária a presença de defeitos no sistema, os testes estatísticos normalmente utilizados para testes de desempenho e confiabilidade dos programas, ou seja, tempo de execução e tempo de resposta, devendo ser utilizados de forma paralela com a verificação estática para a validação tendo uma cobertura total das atividades. As metas estabelecidas no processo de validação e verificação dos requisitos de software estabelecem um vínculo de confiança se adequando ao seu propósito, devendo ser suficientemente adequado para o uso, o tipo de uso identificara o grau de confiança que será necessário, não significando que será totalmente livre de defeitos. A confiança estabelecida no processo de validação e verificação será de acordo com o propósito do sistema, atendendo as necessidades dos usuários e do ambiente de mercado, a função e as expectativas do software será de acordo com 28

as exigências da organização, o ambiente de mercado tem como o objetivo principal inserir produtos no mercado, sendo mais importante esta inserção do que encontrar os defeitos dos programas. A verificação e validação e teste, tem como foco principal estabelecer a existência dos problemas e defeitos de um programa, já a depuração esta com um foco maior na eliminação desses defeitos O Processo de gerenciamento dos requisitos de software é o conjunto de todas essas etapas descritas anteriormente estando associada aos principais problemas e necessidades do desenvolvimento de software ele serve como um estrutura base para as próximas etapas. 1. FIGURA 6 - ARTIGO DA REVISTA ENGENHARIA DE SOFTWARE ARTIGO ENGENHARIA DE SOFTWARE INTRODUÇÃO A ENGENHARIA DE REQUISITOS. WWW.DEVMEDIA.COM.BR As atividades de produção de requisitos é uma concentração da maioria dos processos de engenharia de requisitos, com o fluxo entre as atividades, na há limites impostos entre elas. 29

são consideradas: No dia-a-dia há muita relação entre as atividades, no inicio do processo As descrições estabelecidas pelos stakeholders, As informações necessárias para a substituição do sistema com qualquer sistema que seja necessária a substituição, sendo primordial a interação entre eles; Seguir uma padronização adequada para auxiliar na pratica de desenvolvimento de sistema, gerencia de qualidade, entre outros; Obter um regulamento externo, como leis e regulamento de segurança ou saúde; Aquisição de domínio gerais de aplicação 6.1. Modelo do problema O modelo problema é um processo de elaboração de requisitos de um projeto, podendo referir-se a um produto indivisível de software ou um conjunto de componentes de software, as principais características deste modelo incluem, funcionalidades, interfaces externas, desempenho, outros atributos, restrições impostas pela aplicação. A confecção deste modelo problema é constituída por equipes de desenvolvimento de projeto tendo como participação obrigatória usuários do produto em pauta, este usuário deverá ser indicado pelo cliente para definir os requisitos do produto, sendo necessário ter o conhecimento e autoridade suficiente para definir as necessidades do produto. Normalmente esse usuário passa por treinamentos sobre técnicas e noções que serão utilizadas nas atividades da disciplina de requisitos. Os usuários devem ter a consciência da função indispensável que desempenham na modelagem do problema, é preciso também, informar o papel que terão no restante do projeto, como no desenho das interfaces de usuário, avaliações do produto, revisões, testes de aceitação e em todos os demais procedimentos de implantação que façam parte do projeto. 30

A especificação de requisitos serve apenas para a elaboração de um relatório destinado ao consumo dos clientes/usuários, quando se faz necessário uma documentação que sirva de base contratual para que se possam definir os requisitos que deverão ser suprimidos pelo produto. O conteúdo deste documento pode ser retirado do modelo do problema de uma forma automatizada. 6.2. Modelo do sistema Um produto de software deve conter toda a funcionalidade que o cliente necessita, ou fazer parte de um sistema maior, no caso do modelo do problema ele é relativo ao sistema maior, os requisitos de nível de sistema podem ser contidos nos seguintes artefatos, um modelo do sistema, documento de definição do produto ou uma proposta de desenvolvimento de sistema. O artefato mais completo é o modelo de sistema, ele define os requisitos aplicáveis ao sistema, os requisitos podem ser repassados aos componentes de software, já a parte de desenho do modelo do sistema define interfaces e os outros componentes de software. Os requisitos dos componentes de software não podem colidir com os requisitos do sistema total. Quando o software passar a fazer parte de um sistema maior, os requisitos do sistema e de seus componentes passaram a ser definidos em conjunto pelas equipes do sistema e negociados entre elas. Equipes com que as quais a equipe de modelagem dos requisitos de software pode ter de interagir, são os desenvolvedores de hardware, especialistas da área de aplicação, redes, banco de dados, além do departamento de marketing e das áreas financeira e administrativa. Esses grupos devem trabalhar em conjunto e também com os clientes e usuários chaves para a definição dos requisitos nos níveis de sistema, seu dever é indicar para os participantes do levantamento de requisitos de sistema se os requisitos que serão aplicados são viáveis, a equipe de produto de software deve aprovar o requisito de sistema caso ele tenha um grande impacto no desenvolvimento de software. 31

No decorrer do desenvolvimento dos requisitos de sistema, os participantes precisam definir quais as características dos requisitos são mais críticas, principalmente do ponto de vista dos clientes e usuários, é preciso estabelecer regras para o critério de aprovação de cada componente do sistema que um grupo deva fornecer aos outros grupos. 6.3. Modelagem de Processo, casos de uso e qualidade de software Modelagem de processos de software serve como auxilio para a equipe entender as descrições e os caminhos para elaboração do desenvolvimento do software, entre algumas razoes para a modelagem do processo estão a necessidade de a equipe registrar as descrições do processo de desenvolvimento do software, a criação de um modelo de processo refletindo os objetivos de desenvolvimento, sendo necessário primeiramente ser definida a situação na qual será utilizado. Um caso de uso representa uma unidade de funcionalidade, casos de uso são mais utilizados para descrever funções completas de um sistema, mas também podem ser usados no nível de subsistemas e até de classes. Os serviços oferecidos pelo caso de uso agregam valores externos que interagem com ele. No nível de sistema, um caso de uso realiza um aspecto maior da funcionalidade do produto, gerando benefícios para os clientes, usuários e sistemas, o conjunto dos casos de uso cobre a funcionalidade do produto, e cada caso de uso tem a sua representatividade em relação à funcionalidade. 32

Figura 7 - http://jonysberg.wordpress.com/category/mda/ A engenharia de requisitos se preocupa com o colhimento de informações para elaborar os requisitos de um sistema de software, armazenamento e gerenciamento. Um requisito é uma determinada função ou condição que o sistema tem que atender. O requisito funcional descreve uma determinada função que o sistema deve suportar já um requisito não funcional descreve um aspecto não funcional, mas que o sistema deve acolher, requisitos não funcionais estão ligados com os aspectos do sistema, como: desempenho, distribuição, segurança, integração com a internet, entre outros. Devido à influência de métodos desenvolvidos por volta da metade da década de 1990, a UML incluiu os diagramas de casos de uso que permitem uma aproximação mais focada nos usuários do sistema. A modelagem de requisitos funcionais, em meio à especificação e casos de uso, é considerada extremamente adequada, pois facilita a comunicação entre a equipe de projeto e os clientes, e, ainda viabiliza a comunicação, o gerenciamento e a forma como é conduzida o desenvolvimento do projeto. Essa relação entre casos de uso e requisitos é bem conturbada, há autores que consideram os casos de uso uma boa forma de representar os requisitos, já outros consideram requisitos e casos de uso como conceitos bem distintos; no entanto há relações entre eles que devem ser notadas. 33

Há algumas características importantes na especificação de requisitos, características ligadas com a sua apresentação, organização e nível de detalhe. Referente à sua organização e apresentação, há autores que defendem que os requisitos devem ser apresentados visualmente através de diagramas de casos de uso, e cada caso deve ser especificado detalhadamente em meio a uma descrição textual (definido pela equipe de projeto) e também por diagramas de colaboração ou projetos de interfaces homem-máquina. Quando os requisitos são descritos de forma textual, é recomendado que sejam organizados dentro de uma seqüência numérica e que haja pelo menos duas seqüências diferentes: uma para os requisitos funcionais e outra para os requisitos não funcionais. Por outro lado quando os casos de uso servem como base para os requisitos, é importante que se use o pacote da UML como estrutura, essas duas posições vão ser validas conforme forem utilizadas com freqüência e consistência. Porém a organização dos requisitos em conjunto com os casos de uso facilita a comunicação com os usuários e torna mais fácil o entendimento. Quanto à especificação de requisitos e casos de uso, esta inteiramente ligada ao tipo de projeto, perfil do cliente e ao tipo de sistema especificado. Porém é preciso estar ciente que é possível haver um caso de uso descrito com apenas 3 paginas ou em um com 40 páginas, em conseqüência desse fato é possível haver um sistema especificado em uma dezena ou em uma centena de paginas Qualidade de Software é estar em consonância com os requisitos estabelecidos com o cliente, qualidade é satisfazer e ate mesmo antecipar as necessidades e desejos do cliente, ter um controle e um relatório escrito a ser seguido também pode ser um significado de qualidade. 34

Toda decisão tomada no decorrer do processo de desenvolvimento do software poderá afetar a sua qualidade final. O produto final do processo de desenvolvimento é a soma das decisões e operações realizadas juntamente com o ciclo de desenvolvimento. Para que se possa produzir um software com alta qualidade é indispensável um investimento em qualidade e todos os outros pontos do processo. Qualidade de Software é um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos (Alexandre Bartié,Garantia da Qualidade de Software, pag. 16). Softwares mal testados ocasionam grandes prejuízos as organizações, um pequeno erro que venha a ocorrer internamente no projeto poderá acarretar gastos desnecessários para a organização, como solicitação de manutenção antecipadamente, manutenção de equipamentos, gerar estatísticas incoerentes, por este motivo é muito importante se obter a qualidade. 35

7. TIPOS DE REQUISITOS DE SOFTWARE: Existem vários tipos de requisitos de software entre eles estão os requisitos de usuário que possui uma linguagem bem natural onde também poderá ser representado por diagramas que explicitam as funções que o sistema ira ter e as suas restrições, seu desenvolvimento esta voltado para leitores como os Gerentes de clientes, usuários finais do sistema, engenheiros do cliente, gerentes do fornecedor e arquitetos de sistema. Requisitos do sistema, neste tipo de requisito exigem uma documentação um pouco mais detalhada relatando as funções e restrições do sistema, sua escritura deverá ser basicamente como se fosse um contrato entre o cliente e o desenvolvedor do software, estão voltados para leitores como usuário final de sistema, engenheiros do cliente, arquitetos do sistema e desenvolvedores de software. Especificação do software neste tipo de requisito exige se que a prescrição seja um pouco mais detalhada com relação ao software, pois servirá como base para o projeto e a implantação, sua escritura normalmente é feita diretamente para os desenvolvedores ou arquitetos de sistemas e raramente para engenheiros do cliente. Os Requisitos também podem ser definidos como requisitos funcionais, requisitos não funcionais e requisitos de domínio, os requisitos funcionais são basicamente as definições de serviços que o sistema devera fornecer e as reações que o sistema devera ter em situações como a entradas especificas, os requisitos não funcionais neste caso são as restrições sobre os serviços e funções que o sistema fornecerá, já os requisitos de domínio se origina da aplicação do sistema os refletem as características e definições do domínio, podendo ser ate mesmo requisitos funcionais e não funcionais. 36