Processo de desenvolvimento de software

Um processo de desenvolvimento de software um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software. estudado dentro da rea de Engenharia de Software, sendo considerado um dos principais mecanismos para se obter software de qualidade e cumprir corretamente os contratos de desenvolvimento, sendo uma das respostas tcnicas adequadas para resolver a Crise do software.

Passos/Atividades Processo
Anlise Econmica
Visa a estabelecer se o projeto de Software gerar lucro, e se a receita gerada ser o suficiente para cobrir os custos.

Anlise de requisitos de software

A extrao dos requisitos de um

Especificao
A especificao a tarefa de descrever precisamente o software que ser escrito, preferencialmente de uma forma matematicamente rigorosa. Na prtica, somente especificaes mais bem sucedidas foram escritas para aplicaes bem compreendidas e afinadas que j estavam bem desenvolvidas, embora sistemas de software de misso crtica sejam freqentemente bem especificados antes do desenvolvimento da aplicao. Especificaes so mais importantes para interfaces externas que devem permanecer estveis. o

Arquitetura de Software
A arquitetura de um sistema de software remete a uma representao abstrata daquele sistema. Arquitetura concernente garantia de que o sistema de software ir ao encontro de requisitos do produto, como tambm assegurar que futuros requisitos possam ser atendidos. A etapa da arquitetura tambm direciona as interfaces entre os sistemas de software e outros produtos de software, como tambm com o hardware bsico ou com o sistema operacional.

Implementao (ou codificao)

A transformao de um projeto para um cdigo deve ser a parte mais evidente do trabalho da engenharia de software, mas no necessariamente a sua maior poro..

Teste

Teste de partes do software, especialmente onde tenha sido codificado por dois ou mais engenheiros trabalhando juntos, um papel da engenharia de software

Documentao
Uma importante tarefa a documentao do projeto interno do software para propsitos de futuras manutenes e aprimoramentos. As documentaes mais importantes so das interfaces externas.

Suporte e Treinamento de Software

Uma grande porcentagem dos projetos de software falham pelo fato de o desenvolvedor no perceber que no importa quanto tempo a equipe de planejamento e desenvolvimento ir gastar na criao do software se ningum da organizao ir us-lo. As pessoas ocasionalmente resistem mudana e evitam aventurar-se em reas pouco familiares. Ento, como parte da fase de desenvolvimento, muito importante o treinamento para os usurios de software mais entusiasmados, alternando o treinamento entre usurios neutros e usurios favorveis ao software. Usurios iro ter muitas questes e problemas de software os quais conduziro para a prxima fase.

Manuteno
A manuteno e melhoria de software lidam com a descoberta de novos problemas e requisitos. Ela pode tomar mais tempo que o gasto no desenvolvimento inicial do mesmo. No somente pode ser necessrio adicionar cdigos que combinem com o projeto original, mas determinar como o software trabalhar em algum ponto depois da manuteno estar completa, pode requerer um significativo esforo por parte de um engenheiro de software. Cerca de de todos os engenheiros de software trabalham com a manuteno, mas estas estatsticas podem estar enganadas. Uma pequena parte destes trabalha na correo de erros. A maioria das manutenes para ampliar os sistemas para novas funcionalidades, as quais, de diversas formas, podem ser consideradas um novo trabalho. Analogamente, cerca de de todos os engenheiros civis, arquitetos e construtores trabalham com manuteno de uma forma similar.

Padres
O processo de desenvolvimento de software tem sido objetivo de vrios padres, que visam a certificao de empresas como possuidoras de um processo de desenvolvimento, o que garantiria certo grau de confiana aos seus contratantes. Alguns padres existentes atualmente:

CMMI (anteriormente CMM) SPICE ISO 12207 MPS/Br

CMMI
O CMMI (Capability Maturity Model Integration) um modelo de referncia que contm prticas (Genricas ou Especficas) necessrias maturidade em disciplinas especficas (Systems Engineering (SE), Software Engineering (SW), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)). Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI uma evoluo do CMM e procura estabelecer um modelo nico para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas. O CMMI foi baseado nas melhores prticas para desenvolvimento e manuteno de produtos. H uma nfase tanto em engenharia de sistemas quanto em engenharia de software, e h uma integrao necessria para o desenvolvimento e a manuteno. A verso atual do CMMI (verso 1.3) foi publicada em 27 de outubro de 2010 e apresenta trs modelos:

CMMI for Development (CMMI-DEV), voltado ao processo de desenvolvimento de produtos e servios. CMMI for Acquisition (CMMI-ACQ), voltado aos processos de aquisio e terceirizao de bens e servios. CMMI for Services (CMMI-SVC), voltado aos processos de empresas prestadoras de servios.

Uma das premissas do modelo "A qualidade influenciada pelo processo", e seu foco "Melhorar processo de uma empresa".

Histrico
O CMMI surgiu durante a dcada de 1980 como um modelo para avaliao de risco na contratao de empresas de software pelo Departamento de Defesa dos Estados Unidos que desejava ser capaz de avaliar os processos de desenvolvimento utilizados pelas empresas que concorriam em licitaes como indicao da previsibilidade da qualidade, custos e prazos nos projetos contratados. Para desenvolver esse processo, o DOD contituiu junto a Carnegie-Mellon University o SEI (Software Engineering Institute), o qual alm de ser responsvel pela evoluo da famlia CMM, realiza diversas outras pesquisas em engenharia de software. Os processos de melhoria nasceram de estudos realizados por Deming (Out of the Crisis), Crosby (Quality is Free: The Art of Making Quality Certain) e Juran, cujo objetivo principal era a melhoria da capacidade dos processos. Entende-se por capacidade de um processo a habilidade com que este alcana o resultado desejado. Um modelo tem como objetivo estabelecer - com base em estudos, histricos e conhecimento operacional - um conjunto de "melhores prticas" que devem ser utilizadas para um fim especfico.

O CMMI tem como origens em trs outros modelos de maturidade - SW-CMM (SEI Software CMM), EIA SECM (Electronic Industries Alliances's Systems Engineer Capability Model) e IPD-CMM (Integrated Product Development CMM).

Dimenses
O CMMI foi construdo considerando trs dimenses principais: pessoas, ferramentas e procedimentos. O processo serve para unir essas dimenses.

Disciplinas
O processo inclui trs disciplinas ou corpos de conhecimento (body of knowledges), sendo elas:

Engenharia de sistemas Engenharia de software Engenharia de hardware

A engenharia de software similar engenharia de sistemas em relao s reas de processo, apenas com enfoque diferente nos processos. As reas de processo requeridas para engenharia de sistemas so as mesmas para engenharia de software, mas o nvel de maturidade que diferente.

Representaes
O CMMI possui duas representaes: "contnua" ou "por estgios". Estas representaes permitem organizao utilizar diferentes caminhos para a melhoria de acordo com seu interesse.

Representao Contnua
Possibilita organizao utilizar a ordem de melhoria que melhor atende os objetivos de negcio da empresa. caracterizado por: Nveis de Capacidade (Capability Levels):

Nvel 0: Incompleto (Ad-hoc) Nvel 1: Executado Nvel 2: Gerenciado / Gerido Nvel 3: Definido Nvel 4: Gerenciado quantitativamente Nvel 5: Em otimizao

Nesta representao a capacidade medida por processos separadamente, onde possvel ter um processo com nvel um e outro processo com nvel cinco, variando de acordo com os interesses da empresa.

No nvel 1(um) o processo executado de modo a completar o trabalho necessrio para a execuo de um processo.

No nvel 2(dois) sobre planejar a execuo e confrontar o executado contra o que foi planejado. No nvel 3(trs) o processo construdo sobre as diretrizes do processo existente, e mantido uma descrio do processo. No nvel 4(quatro) quando o processo gerenciado quantitativamente atravs de estatsticas e outras tcnicas. No nvel 5(cinco) o processo gerido quantitativamente alterado e adaptado para atender s necessidades negociais/estratgicas da empresa.

A representao contnua indicada quando a empresa deseja tornar apenas alguns processos mais maduros, quando j utiliza algum modelo de maturidade contnua ou quando no pretende usar a maturidade alcanada como modelo de comparao com outras empresas.

Representao Por Estgios

Disponibiliza uma seqncia pr-determinada para melhoria baseada em estgios que no deve ser desconsiderada, pois cada estgio serve de base para o prximo. caracterizado por Nveis de Maturidade (Maturity Levels):

Nvel 1: Inicial (Ad-hoc) Nvel 2: Gerenciado / Gerido Nvel 3: Definido Nvel 4: Quantitativamente gerenciado / Gerido quantitativamente Nvel 5: Em otimizao

Nesta representao a maturidade medida por um conjunto de processos. Assim necessrio que todos os processos atinjam nvel de maturidade dois para que a empresa seja certificada com nvel dois. Se quase todos os processos forem nvel trs, mas apenas um deles estiver no nvel dois a empresa no ir conseguir obter o nvel de maturidade trs. Esta representao indicada quando a empresa j utiliza algum modelo de maturidade por estgios, quando deseja utilizar o nvel de maturidade alcanado para comparao com outras empresas ou quando pretende usar o nvel de conhecimento obtido por outros para sua rea de atuao.

reas de Processo
O modelo CMMI v1.2 (CMMI-DEV) contm 22 reas de processo. Em sua representao por estgios, as reas so divididas da seguinte forma: Nvel 1: Inicial (Ad-hoc) No possui reas de processo. Nvel 2: Gerenciado / Gerido

Gerenciamento de Requisitos - REQM (Requirements Management)

Planejamento de Projeto - PP (Project Planning) Acompanhamento e Controle de Projeto - PMC (Project Monitoring and Control) Gerenciamento de Acordo com Fornecedor - SAM (Supplier Agreement Management) Medio e Anlise - MA (Measurement and Analysis) Garantia da Qualidade de Processo e Produto - PPQA (Process and Product Quality Assurance) Gerncia de Configurao - CM (Configuration Management)

Nvel 3: Definido

Desenvolvimento de Requisitos - RD (Requirements Development) Soluo Tcnica - TS (Technical Solution) Integrao de Produto - PI (Product Integration) Verificao - VER (Verification) Validao - VAL (Validation) Foco de Processo Organizacional - OPF (Organizational Process Focus) Definio de Processo Organizacional - OPD (Organizational Process Definition) Treinamento Organizacional - OT (Organizational Training) Gerenciamento Integrado de Projeto - IPM (Integrated Project Management) Gerenciamento de Riscos - RSKM (Risk Management) Anlise de Deciso e Resoluo - DAR (Decision Analysis and Resolution)

Nvel 4: Quantitativamente gerenciado / Gerido quantitativamente

Desempenho de Processo Organizacional - OPP (Organizational Process Performance) Gerenciamento Quantitativo de Projeto - QPM (Quantitative Project Management)

Nvel 5: Em otimizao

Gesto de Processo Organizacional - OPM (Organizational Process Management) Anlise Causal e Resoluo - CAR (Causal Analysis and Resolution)

Modelos e reas de processo

As reas de processo variam com base no modelo escolhido, no sendo as mesmas reas para todos os modelos (CMMI-DEV, CMMI-ACQ ou CMMI-SVC).

ISO/IEC 15504
A ISO/IEC 15504, tambm conhecida como SPICE, define um "processo para relatrios tcnicos no assessoramento em desenvolvimento de software", e similarmente ao CMMI possui nveis de maturidade para cada processo. O CMMI no baseado nesta norma, mas sim compatvel.

Histrico de Avaliaes
At o ano de 2002, os EUA tinham realizado 1,5 mil avaliaes de CMMI, a ndia feito 153, o Reino Unido 103 e o Brasil apenas 15. Em 2004 a TATA Consultancy Services (empresa indiana) alcanou o nvel 5 em todas as unidades da empresa, tendo sido avaliada inclusive a unidade brasileira (a primeira empresa presente no Brasil a receber o nvel mximo na avaliao). Entre abril de 2002 e junho de 2006 foram conduzidas 1581 avaliaes em 1377 organizaes. Segue abaixo o resultado obtido pelas empresas na avaliao (resultados encaminhados para o SEI at 30 de junho de 2006):

18,2%: nvel 5 (Optimizing); 4,4%: nvel 4 (Quantitatively Managed); 33,8%: nvel 3 (Defined); 33,3%: nvel 2 (Managed); 1,9%: nvel 1 (Initial); 8,4%: sem qualificao (Not Given).

SPICE
SPICE (acrnimo de Simulated Program with Integrated Circuits Emphasis, ou Programa de Simulao com nfase em Circuitos Integrados) um software de simulao de circuitos analgicos. uma poderosa ferramenta usada para testar, e antever comportamento de circuitos contendo circuitos integrados, resistores, transistores, capacitores, diodos e outros componentes eltricos e eletrnicos.

Histria
O software foi desenvolvido no ano de 1975 pelos pesquisadores Larry Nagle e Donald Petterson nos laboratrios de pesquisas sobre eletrnica da Faculdade de Engenharia Eltrica e Cincias da Computao da Universidade da Califrnia, campus de Berkeley. Tanto essa verso, como a segunda verso (criada em 1983) foram codificadas utilizando a linguagem de programao Fortran e rodados em mainframes. A partir da terceira verso, o programa foi codificado em C, mas utilizando a sintaxe de Fortran para descrever circuitos. Algumas verses comerciais mantm compatibilidade com a verso de Berkeley, mas outras adcionaram extenses que incompatibilizou essas verses com a verso de Berkeley. As verses mais recentes incluram interfaces grficas. Algoritmos diferentes so usados para resolver diferentes tipos de circuitos. Por exemplo, para circuitos no-lineares (circuitos que possuem elementos no-lineares), utilizado o mtodo de Newton-Raphson. ...

Verses comerciais

PSpice/OrCAD

SPICE OPUS HSpice (para UNIX) HSIM MicroCad Dr. Spice T-Spice Intusoft Spice-It! SIMetrix (disponvel para Windows e Linux) TopSPICE NG-spice MultiSIM SmartSpice TINA Spectre Eldo UltraSim MacSpice NanoSim NSPICE B2SPICE ICAP/4 TINA-TI Proteus ISIS (Labcenter Electronics) LTSpice IV (Linear Technology)

O famoso programa Electronics Workbench tambm baseado no SPICE.

ISO 12207
ISO 12207 uma norma definida pela International Organization for Standardization, que se aplica em engenharia de software. Esta estabelece um processo de ciclo de vida do software, contendo processos, atividades e so aplicadas durante a aquisio e configurao dos servios do sistema, de forma a melhor-los. Esta norma tem como principal objetivo fornecer uma estrutura comum para que o adquirente, fornecedor, desenvolvedor, mantenedor, operador, gerentes e tcnicos, envolvidos com o desenvolvimento de software. Faz parte desta estrutura o uso de uma linguagem comum que estabelecida na forma de processos bem definidos. A estrutura da norma foi concebida de maneira a ser flexvel, modular e adaptvel s necessidades de quem a utiliza. Para isso, est fundamentada em dois princpios bsicos: modularidade e responsabilidade. Modularidade, no sentido de processos com mnimo acoplamento e mxima coeso. Responsabilidade, no sentido de estabelecer um responsvel nico por cada processo, facilitando a aplicao da norma em projetos, onde vrias pessoas podem estar legalmente envolvidas.

Conforme citado anteriormente, a norma composta por um conjunto de processos, atividades e tarefas que podem ser adaptados de acordo com os projetos de software. Estes processos so classificados em trs tipos: fundamentais, de apoio e organizacionais. Os processos fundamentais so instanciados de acordo com a situao. Enquanto que os processos de apoio e organizacionais devem existir independentemente da organizao e do projeto que est sendo executado. Basicamente, correspondido ao ISO 12207.

Melhoria de Processos do Software Brasileiro

O MPS.BR ou Melhoria de Processos do Software Brasileiro simultaneamente um movimento para a melhoria da qualidade (Programa MPS.BR) e um modelo de qualidade de processo (Modelo MPS). Voltado para a realidade do mercado de pequenas e mdias empresas de desenvolvimento de software no Brasil, ele baseado nas normas ISO/IEC 12207 e ISO/IEC 15504 e compatvel com o CMMI. O projeto tem apoio do Ministrio da Cincia e Tecnologia, da FINEP e do Banco Interamericano de Desenvolvimento. No Brasil o projeto desenvolvido pela Softex, interagindo com as universidades e com o Governo Federal. Uma das principais vantagens do modelo seu custo reduzido de certificao em relao as normas estrangeiras, sendo ideal para micro, pequenas e mdias empresas que so a grande maioria no Brasil. Um dos objetivos do projeto replicar o modelo na Amrica Latina, incluindo o Chile, Argentina, Costa Rica, Peru e Uruguai.

Motivao
O Brasil um pas cujo desenvolvimento de produtos de software est entre os maiores do mundo, e a cada dia, aumenta o nvel de exigncia por parte dos clientes no que diz respeito qualidade e complexidade dos produtos. A partir deste ponto, podemos observar que as empresas esto buscando cada vez mais a maturidade nos seus processos de software para atingir padronizaes de qualidade e produtividade internacionais, que so essenciais para a sobrevivncia no mercado de TI. Porm, o custo de uma certificao para uma empresa pode ser de at US$ 400 mil, o que se torna invivel para empresas de micro, pequeno e mdio porte. Ento, em uma parceria entre a Softex, Governo e Universidades, surgiu o projeto MPS.Br (melhoria de

processo de software brasileiro), que a soluo brasileira compatvel com o modelo CMMI, est em conformidade com as normas ISO/IEC 12207 e 15504, alm de ser adequado realidade brasileira.

O modelo
O MPS.Br dividido em 3 partes: MR-MPS, MA-MPS, MN-MPS

MR-MPS (Modelo de referncia para melhoria do processo de software)

O MPS.BR apresenta 7 nveis de maturidade (o que um diferencial em relao aos outros padres de processo) que so:

A - Em Otimizao; B - Gerenciado quantitativamente; C - Definido; D - Largamente Definido; E - Parcialmente Definido; F - Gerenciado; G - Parcialmente Gerenciado.

Cada nvel de maturidade possui suas reas de processo, onde so analisados:

processos fundamentais o aquisio; o gerncia de requisitos; o desenvolvimento de requisitos; o soluo tcnica; o integrao do produto; o instalao do produto; o liberao do produto. processos organizacionais o gerncia de projeto; o adaptao do processo para gerncia de projeto; o anlise de deciso e resoluo; o gerncia de riscos; o avaliao e melhoria do processo organizacional; o definio do processo organizacional; o desempenho do processo organizacional; o gerncia quantitativa do projeto; o anlise e resoluo de causas; o inovao e implantao na organizao. processos de apoio o garantia de qualidade; o gerncia de configurao; o validao; o medio; o verificao; o treinamento.

Em seguida vem a Capacidade, onde so obtidos os resultados dos processos analisados, onde cada nvel de maturao possui um nmero definido de capacidades a serem vistos.

AP 1.1 - O processo executado; AP 2.1 - O processo gerenciado; AP 2.2 - Os produtos de trabalho do processo so gerenciados; AP 3.1 - O processo definido; AP 3.2 - O processo est implementado; AP 4.1 - O processo medido; AP 4.2 - O processo controlado; AP 5.1 - O processo objeto de inovaes; AP 5.2 - O processo otimizado continuamente.

MA-MPS (Mtodo de avaliao para melhoria do processo de software)

Tem como objetivo orientar a realizao de avaliaes, em conformidade com a norma ISO/IEC 15504, em empresa e organizaes que implementaram o MR-MPS. Avaliao MA-MPS:

Equipe de avaliao: 3 a 8 pessoas, sendo: 1 avaliador lder no mnimo 1 avaliador adjunto no mnimo 1 tcnico da empresa

Durao: 2 a 4 dias; Validade: 3 anos;

Estruturao da Avaliao:

Planejar e preparar avaliao Plano de Avaliao / Descrio dos indicadores de processo;

Conduzir Avaliao Resultado da avaliao;

Relatar resultados Relatrio da avaliao;

Registrar e publicar resultados Banco de dados Softex (Ver portal MPS.BR nas 'Ligaes Externas')

MPS.BR

MN-MPS (Modelo de negcio para melhoria do processo de software)

Instituies que se propem a implantar os processos MPS.Br (Instituies Implementadoras) podem se credenciar atravs de um documento onde apresentada a instituio proponente, contendo seus dados com nfase na experincia em processos de software, estratgia de implementao do modelo, estratgia para seleo e treinamento de consultores para implementao do MR.MPS, estratgia para seleo e treinamento de avaliadores, lista de consultores de implementao treinados no modelo e aprovados em prova especfica, lista de avaliadores treinados no modelo e aprovados em prova especfica.

Cursos e certificao
A Softex realiza cursos para formao de consultores, compradores e avaliadores MPS.BR. So ao todo 4 cursos:

Curso de Introduo - C1 Curso de Implementao - C2 Curso de Avaliaao - C3 Curso de Aquisio - C4

Periodicamente, so realizadas provas em nvel nacional para certificar profissionais em cada um dos cursos descritos acima. Tanto os cursos e as provas so realizadas nos Agentes SOFTEX em cada estado, por exemplo:

SOFTEX Campinas (SP) ITS (So Paulo - SP) FUMSOFT (Belo Horizonte - MG) RIOSOFT (Rio de Janeiro - RJ) SOFTSUL (Porto Alegre - RS) Entre outras

Prximos passos
O modelo MPS.Br tem como objetivo implementar o Modelo de Referncia para melhoria de processo de software em 120 empresas. E como objetivos secundrios, a disseminao em diversos locais do pas, capacitao no uso do modelo e o credenciamento de instituies implementadoras e avaliadoras do modelo, especialmente instituies de ensino e centros tecnolgicos e tambm a implementao e avaliao do modelo com foco em grupos de empresas. A avaliao conjunta de grupos empresariais objetiva reduo dos custos, porm, h uma perda de foco, pois no h uma especificidade para cada empresa e sim um mesmo modelo de referncia para todas elas. O MPS.Br j uma realidade e existe um projeto para, dentro de alguns anos, a sua implantao em seis pases da Amrica Latina, so eles: Chile, Argentina, Costa Rica, Peru, Uruguai e Cuba.