Engenharia de Software

1. O processo de desenvolvimento de software

Um processo de desenvolvimento de software compreende todas as atividades necessrias para definir, desenvolver, testar e manter um produto de software. Alguns objetivos de um processo de desenvolvimento so: definir quais as atividades a serem executadas ao longo do projeto; quando, como e por quem tais atividades sero executadas; prover pontos de controle para verificar o andamento do desenvolvimento; padronizar a forma de desenvolver software em uma organizao.

2. Atividades tpicas de um processo de desenvolvimento.

2.1 Levantamento de requisitos. A atividade de levantamento de requisitos corresponde a etapa de compreenso do problema aplicada ao desenvolvimento de software. Nessa etapa os desenvolvedores, juntamente com os clientes, tentam levantar e definir as necessidades dos futuros usurios do sistema a ser desenvolvido. Essas necessidades so geralmente denominadas requisitos. O produto do levantamento de requisitos o documento de requisitos, que declara os diversos tipos de requisitos do sistema. O enfoque prioritrio do levantamento de requisitos responder claramente a questo O que o usurio necessita do novo sistema ?. 2.2 Anlise de requisitos Assim como no levantamento de requisitos, a analise de requisitos no leva em conta o ambiente tecnolgico a ser utilizado. Nesta atividade, o foco de interesse tentar construir uma estratgia de soluo sem se preocupar com os detalhes da tecnologia a ser utilizada. 2.3 Projeto Na fase de projeto, determina-se como o sistema funcionar para atender aos requisitos, de acordo com os recursos tecnolgicos existentes. O projeto consiste de duas atividades principais: projeto da arquitetura ( alto nvel ) e projeto detalhado ( baixo nvel ). Em um processo de desenvolvimento orientado a objetos, o projeto da arquitetura consiste em distribuir as classes de objetos relacionadas do sistema em subsistemas e seus componentes. Consiste tambm em distribuir esses componentes fisicamente pelos recursos de hardware disponveis. No projeto detalhado, so modeladas as colaboraes entre objetos de cada mdulo com o objetivo de realizar as funcionalidades do mdulo. Tambm so realizados o projeto da interface com o usurio, e o projeto do banco de dados. Os diagramas da UML utilizados nesta fase do projeto so: diagrama de classes, diagrama de casos de uso, diagrama de interao, diagrama de estados e diagrama de atividades. Embora a anlise e o projeto sejam descritos em sees separadas neste livro, importante notar que no h uma distino assim to clara entra essas duas fases. Principalmente no desenvolvimento de sistemas orientados a objetos.

2.4 Implementao Na implementao, o sistema codificado, ou seja ocorre a traduo da descrio computacional da fase de projeto em cdigo executvel atravs do use de uma ou mais linguagens de programao. 2.5 Testes Diversas atividades de teste so realizadas para verificao do sistema construdo, levando-se em conta a especificao feita na fase de projeto. O principal produto dessa fase o relatrio de erros detectados no software. 2.6 Implantao O sistema empacotado, distribudo e instalado no ambiente do usurio.

3. O componente humano ( participantes do projeto )

3.1 Gerentes de projeto Como o prprio nome diz, o gerente de projetos o profissional responsvel pela gerncia ou coordenao das atividades necessrias a construo do sistema. Esse profissional tambm responsvel por fazer o oramento do projeto de desenvolvimento, como por exemplo, estimar o tempo necessrio para o desenvolvimento do sistema, definir qual o processo do desenvolvimento, o cronograma de execuo das atividades, a mo-de-obra especializada, os recursos de hardware e software etc. 3.2 Analistas O analista de sistemas o profissional que deve ter o conhecimento do domnio do negcio. Esse profissional deve entender os problemas do domnio do negocio para que possa definir os requisitos do sistema a ser desenvolvido. Tipicamente, o analista de sistemas o profissional responsvel por entender as necessidades dos clientes em relao ao sistema a ser desenvolvido e repassar esse entendimento aos demais desenvolvedores do sistema. Neste sentido, o analista de sistemas representa uma ponte de comunicao entre duas faces: a dos profissionais de computao e a dos profissionais de negcios. 3.3 Projetistas O projetista de sistemas o componente da equipe de desenvolvimento cujas funes so (1) avaliar as alternativas de soluo do problema resultante da anlise e (2) gerar a especificao de uma soluo computacional detalhada. 3.4 Arquitetos de software O objetivo desse profissional elaborar a arquitetura do sistema como um todo. ele quem toma decises sobre quais so os subsistemas que compem o sistema como um todo e quais so as interfaces entre esses subsistemas.

3.5 Programadores Este profissional o responsvel pela implementao do sistema. Um programador pode ser proficiente em uma ou mais linguagens de programao, alm de ter conhecimento sobre bancos de dados e poder ler os modelos resultantes do trabalho do projetista.

4. Modelos de ciclo de vida

O desenvolvimento de um sistema envolve diversas fases. A um encadeamento especfico dessas fases para a construo do sistema d-se o nome de Modelo de Ciclo de Vida. Nesta seo, dois modelos de ciclo de vida de sistema so descritos: o modelo em cascata e o modelo iterativo e incremental. 4.1. O modelo de ciclo de vida em cascata Este ciclo de vida tambm chamado de clssico ou linear e se caracteriza por possuir uma tendncia na progresso sequencial entre uma fase e a seguinte 4.1. O modelo de ciclo de vida iterativo e incremental Um processo de desenvolvimento segundo essa abordagem divide o desenvolvimento de um produto de software em ciclos. Em cada ciclo de desenvolvimento, podem ser identificadas as fases de anlise, projeto, implementao e testes. Essa caracterstica contrasta com a abordagem clssica, na qual as fases de anlise, projeto, implementao e testes so realizadas uma nica vez. Cada um dos ciclos considera um subconjunto de requisitos. Os requisitos so desenvolvidos uma vez que sejam alocados a um ciclo de desenvolvimento. No prximo ciclo, um outro subconjunto dos requisitos considerado para ser desenvolvido, o que produz um novo incremento do sistema que contm extenses e refinamentos sobre o incremento anterior. Assim o desenvolvimento evolui em verses, atravs da construo incremental e iterativa de novas funcionalidades at que o sistema completo esteja construdo.

O modelo de Caso de uso

O modelo de casos de uso uma representao das funcionalidades externamente observveis do sistema e dos elementos externos ao sistema que interagem com ele. Este modelo parte integrante da especificao de requisitos. Este modelo bastante importante pois direciona diversas tarefas posteriores do clico de vida do sistema de software.. O modelo de casos de uso composto de casos de uso, de atores , e de relacionamento entre estes. Caso de uso Modelo textual Modelo Grfico

Um caso de uso a especificao de uma sequncia de interaes entre um sistema e os agentes externos que utilizam esse sistema. Um caso de uso deve definir o uso de uma parte da funcionalidade de um sistema sem revelar a estrutura e o comportamento internos desse sistema. Atores Na terminologia UML, qualquer elemento externo que interage com o sistema denominado ator. Os atores no fazem parte do sistema. O termo interage significa que um ator troa (envia e/ou recebe) informaes com o sistema. Relacionamentos Casos de uso e atores no existem sozinhos. Por exemplo, um ator deve estar relacionado a um ou mais casos de uso do sistema. Da mesmo forma, pode haver relacionamentos entre os casos de uso de um sistema. A UML define diversos tipos de relacionamentos no modelo de casos de uso: comunicao, incluso, extenso e generalizao. Use incluso quando o mesmo comportamento se repete em mais de um caso de uso. Esse comportamento comum deve ser definido em um novo caso de uso, o chamado caso de uso includo. Note que esse comportamento comum est contido em todos os cenrios dos casos de uso. Use extenso quando um comportamento opcional de um caso de uso tiver de ser descrito. Note que alguns cenrios do caso de uso estendido podem no utilizar esse comportamento opcional. O extensor faz referencia ao estendido; o estendido no sabe que o extensor existe. Use herana entre casos de uso quando voc identificar dois casos de uso com comportamentos semelhantes e um deles for uma forma especial do outro. O caso de uso mais especfico herda todo o comportamento e relacionamentos do mais genrico, porm pode adicionar mais comportamento e ter seus prprios relacionamentos. O especfico faz referencia ao geral; o geral no sabe que o especfico existe. Use herana entre atores quando precisar definir um ator que possui o mesmo comportamento de um ator preexistente, mas que possui comportamento particular. Decomposio funcional e relacionamentos entre casos de uso Um erro bastante comum na identificao de relacionamentos entre casos de uso, principalmente para desenvolvedores acostumados com as tcnicas de Anlise Estruturada, o de considerar o modelo de casos de uso equivalente ao modelo funcional utilizado na metodologia estruturada. Outro erro semelhante quebrar ( em dois ou mais casos de uso) funcionalidades que na verdade pertencem a um mesmo caso de uso. Um caso de uso uma descrio completa de uma sequncia de interaes; ele no normalmente um passo ou atividade individual em um processo. Em resumo, o enfoque ao utilizar casos de uso e seus relacionamentos identificar os objetivos

do usurio, em vez das funes do sistema. O modelo de casos de uso define uma viso externa do sistema. Modelo Textual - Objetivo - Descrever cenrio principal ( se tudo der certo ) - Cenrios alternativos.