Do You have the employees, contractors, temporary right for your area?In the area of IT and IS it is almost complete compatibility between the person and the technology used by your corporation. The hiring is hard to fit you personality, certifications and experience coupled with the confidence provided by the applicant for a position in IT or IS.Much of the interaction between employees, years in the same corporation can take them to be friends or enemies of eternal hell. The relations in corporations can get to the wedding. How many of you readers have not started dating industry to work alongside, or even married a work that met the same corporation?In fact, they are common situations that occur every day around the world, but when it becomes the enemy that lives next door, how to proceed in such a situation?When you have such a situation, your best bet is to ignore the fact, make use of political and / or seek understanding or search for another corporation.There are situations in which the constraint is the main event. In this situation, the best thing is to go get other companies where this would be a lesser incidence.Ha true "wheel" formed to remove a manager who's main goal is control of the area. True political coup order is the "POWER"."Fortunately, all ends well for those who live well."There are cases where such facts can not be solved alone and attitudes should be taken where the problem is resolved in the best way always watching the best for the corporation.The "political power" will exist in any corporation and there will always be the "malicious" facing up against the well-intentioned. The worst behavior is that it uses the so-called "hardcore" to take the blow to his fellow man.A manager will always have problems in managing people, he is the owner of a professional area with two or ten thousand. The facts go unnoticed to those in a large number of employees and that is why areas of the subdivisions are headed to minimize these impacts and others.Technology is not very different from treating people of their assets. When this manager has a problem into an asset, the impact can cause other chain. The important thing is to treat it in discussion groups to improve service and focus on the solution as quickly as possible.The People Management is more complicated than its assets, no doubt, treat people is an art different from the treatment of assets, but their similarities are in search of solutions.The good manager is one that keeps your staff in control, measuring techniques and personal skills, making these alignment to achieve the objectives of the area, and the corporation's own staff.When there is a malware, viruses and / or other problem affecting our assets, we have to eliminate them. When we have people have to deal with the behavior, the situation and when all attempts failed to eliminate them from the area still may not be a solution.The search for the best team, the best staff for better management role is one in which the managers involved add up all the qualities and defects and hangs in the balance of "Ideality Business."
Inscrever-se
Postagens
Comentários
quinta-feira, 24 de novembro de 2011
quarta-feira, 26 de outubro de 2011
UNIVERSITY - SECURITY AND QUALITY
The quality of the IT environment provide our customers for their education institution is sufficient to serve its students, teachers and contractors?
Institutions of Higher Education, have been driven to invest in IT. Many higher education institutions provide Internet access to students in order to research, training and application in items related to the courses offered. But this availability is rampant and constantly dangerous when it comes to information security related to it.
Advances in IT investments to Universities when there are significant administrative integration coupled with the awareness of managers of the institution in terms of improving the IT environment, making structural changes, cultural and work processes and improve information security.
In academics, Racing teaching, research and extension has been observed with respect to investment shy Information Security, leaving a large gap in this area in their applications.
Make changes are needed to put them in a satisfactory level of safety.
A proper diagnosis can suggest the best use of Universities their environment and provide them a broad view of what is and what is needed to meet current demand. The item quality, as a rule, with the implementation of ISO9000 can respond and improve many existing procedures and other important form also needed. Then leave for Information Security standards with other allies, today there are flaws that can be controlled or even cease to exist.
In fact, many do not care about security on the Web Just because something is important to us, does not mean he is (or should be) important for all others.
I have examined some sites in consultancy work and the thing is really ugly when it comes to safety on the web. On the development side, it does what it can count up to code analyzer and when we see the security perimeter is also possible to assess how quickly businesses are going in the opposite direction of safety. There raises the question: when will the time is right to spend money on security?
As with any capital investment or operating expenses, application security is a choice;
Like an internal policy of access to their respective punishments can coerce a more secure access, combine preventive, reactive and proactive to form an item of comprehensive security information elsewhere in the Universities is extremely important;
The quest for quality assurance in education is quite unique.
The misunderstanding of ISO9000 among academics is very clear and often have a mistaken view about the standard of quality. The pursuit of accreditation standards of education, shows the intention of strengthening the reputation of the Universities
"Teaching is a creative art, it is emotion and commitment. As one could reduce it to a set of
Standards and procedures? "
To meet the requirement the standard must be presented so that there is flexibility for the Academic and persuasion.
The ISO9000 in Universities should be seen as a matter of organizational culture and attitude.
Therefore, ISO 9000 can become a viable alternative, a means of building procedures to develop a better education. Think about it!.
Institutions of Higher Education, have been driven to invest in IT. Many higher education institutions provide Internet access to students in order to research, training and application in items related to the courses offered. But this availability is rampant and constantly dangerous when it comes to information security related to it.
Advances in IT investments to Universities when there are significant administrative integration coupled with the awareness of managers of the institution in terms of improving the IT environment, making structural changes, cultural and work processes and improve information security.
In academics, Racing teaching, research and extension has been observed with respect to investment shy Information Security, leaving a large gap in this area in their applications.
Make changes are needed to put them in a satisfactory level of safety.
A proper diagnosis can suggest the best use of Universities their environment and provide them a broad view of what is and what is needed to meet current demand. The item quality, as a rule, with the implementation of ISO9000 can respond and improve many existing procedures and other important form also needed. Then leave for Information Security standards with other allies, today there are flaws that can be controlled or even cease to exist.
In fact, many do not care about security on the Web Just because something is important to us, does not mean he is (or should be) important for all others.
I have examined some sites in consultancy work and the thing is really ugly when it comes to safety on the web. On the development side, it does what it can count up to code analyzer and when we see the security perimeter is also possible to assess how quickly businesses are going in the opposite direction of safety. There raises the question: when will the time is right to spend money on security?
As with any capital investment or operating expenses, application security is a choice;
Like an internal policy of access to their respective punishments can coerce a more secure access, combine preventive, reactive and proactive to form an item of comprehensive security information elsewhere in the Universities is extremely important;
The quest for quality assurance in education is quite unique.
The misunderstanding of ISO9000 among academics is very clear and often have a mistaken view about the standard of quality. The pursuit of accreditation standards of education, shows the intention of strengthening the reputation of the Universities
"Teaching is a creative art, it is emotion and commitment. As one could reduce it to a set of
Standards and procedures? "
To meet the requirement the standard must be presented so that there is flexibility for the Academic and persuasion.
The ISO9000 in Universities should be seen as a matter of organizational culture and attitude.
Therefore, ISO 9000 can become a viable alternative, a means of building procedures to develop a better education. Think about it!.
terça-feira, 18 de outubro de 2011
SECURITY OFFICER - THIS IS THE GUY......
Do not think that managing an area of Information Security is an irrelevant fact and conditional. Unlike what many think, the poor suffer SI Manager in relation to other areas trying to do their best work in research and audit. Yes, SI has also audits. The manager lives in this area pointing out the problems and trying to solve them as best as possible. Unfortunately, and especially the IT department forces him to wake up (agreements) to meet them promptly and quickly. The fact is that cater to IT means to reconcile the conflicting non-participation, ie, a conflict of interest can cause a bad image to the security area if our Information Manager itself does not take into account their political image. Sounds complicated, is not ... No .... The ability of the right manager in this area leads to the highest level of the organization, leading him to be respected by other areas.
This guy is tired of seeing situations where the word "stopgap" in the dictionary of IT and therefore it does not exist in the dictionary of the SI.
For this and other reasons that the area, in my humble opinion, should be isolated from the IT and in many cases responding to another Board. Cases in which the SI is under the jurisdiction of the final conflict ends in IT Management disturbing this area as well as the work related to it.
I have seen cases in which sparks between the IS and Management Boards were instrumental in the relationship between the areas. An Information Security Manager in addition to very patient must have a hip enough to get rid of these troublesome conflicts of interest and the power to know that your area is so great that even though Manager will be considered as "the Almighty". Do not make this phrase your motto in the Corporation, because then you'll be overpowering other areas and other managers. Humility and knowledge will be your weapons against the existing conflicts. Politically act with determination, because they know that their ability and understanding of all the parties will do better.
The world of Information Security Management in racing is to know without being hit forcing achieve improvements in processes and consequently better results Corporation.
Thinking about yourself is not thinking about YOU. When this occurs the corporation will lose. Hitting others with harsh words also will not make the winner between areas. Be tough with someone who was hard on you will do the same to the Manager which caused it.
The Information Security Manager will always be the guy that makes for its area, other areas and the corporation. The word "Envy" maybe here is very strong but have a sure thing my dear reader tiespecialistas;
"Do or Do Not, There Is No Try" for an Information Security Manager
This guy is tired of seeing situations where the word "stopgap" in the dictionary of IT and therefore it does not exist in the dictionary of the SI.
For this and other reasons that the area, in my humble opinion, should be isolated from the IT and in many cases responding to another Board. Cases in which the SI is under the jurisdiction of the final conflict ends in IT Management disturbing this area as well as the work related to it.
I have seen cases in which sparks between the IS and Management Boards were instrumental in the relationship between the areas. An Information Security Manager in addition to very patient must have a hip enough to get rid of these troublesome conflicts of interest and the power to know that your area is so great that even though Manager will be considered as "the Almighty". Do not make this phrase your motto in the Corporation, because then you'll be overpowering other areas and other managers. Humility and knowledge will be your weapons against the existing conflicts. Politically act with determination, because they know that their ability and understanding of all the parties will do better.
The world of Information Security Management in racing is to know without being hit forcing achieve improvements in processes and consequently better results Corporation.
Thinking about yourself is not thinking about YOU. When this occurs the corporation will lose. Hitting others with harsh words also will not make the winner between areas. Be tough with someone who was hard on you will do the same to the Manager which caused it.
The Information Security Manager will always be the guy that makes for its area, other areas and the corporation. The word "Envy" maybe here is very strong but have a sure thing my dear reader tiespecialistas;
"Do or Do Not, There Is No Try" for an Information Security Manager
terça-feira, 23 de agosto de 2011
CRACKER X HACKER - original in http://www.tiespecialistas.com.br/2011/08/cracker-x-hacker/
In my last article I explained to you what I mean about hackers and crackers, different as they are in good and bad. Some people questioned me about the two words here and spend a little history and comments.
"CRACKER ... wafer is not and has no taste, an invasion occurs only when there is that we learn of what tastes.
The bitter taste of all that building was destroyed. "
In the Wikipedia definition is as follows:
Cracker is a term used to describe someone who practices the breaking (or cracking) of a security system, illegally or unethically. This term was coined in 1985 by hackers against journalistic use of the term hacker. Use of this reflects the strong revolt against theft and vandalism committed by cracking.
In other words.
He who does the security breach on a system.
In the Wiki also talk about the controversy of the term, but it follows a bit of opinion. Using both neologisms reflects a strong revulsion against the theft and vandalism on the net. 'The neologism "cracker" in this sense may have been influenced by the slang term "cracker," which in Shakespearean English meant an unpleasant person and in modern colloquial American English survives as a synonym for evil delicate called "white trash." While it is expected that any real hacker has done some raids, with undeniable skill of their techniques, the term "cracker" falls into oblivion and raises "HACKER" the position of the dark side of the Force.
Thus, there is far less overlap between hacker and cracker than regular reader misled by sensationalistic journalism might expect. Crackers tend to gather in small groups, very close and secret but well known in the media due to its disclosure. Though crackers often like to describe themselves as hackers. An easy way to distinguish and detect the difference between hackers and crackers is that crackers use names that hide their identities. Hackers never do this because they rarely use noms de guerre in everything they do, and when they do is to show rather than conceal.
Changing the subject a bit, has anyone thought to ask if the attacks are one more reason to hasten the DIGITAL LAW OF CRIMES IN BRAZIL??
In fact the very attackers know it or ever think about that.
"Hacker" is the malicious security cracker.
It is good just for a story as interesting as this. We would be forever writing it is extremely culture and history is something we can call "NO MATTER THE END BUT THE ACTS"
Whether for the WELL ... Are in the history of information security,
Whether for BAD ... Are in the history of information security,
They are nothing more than history and leverage the IT upgrades in its entirety.
Below the names of some hackers / crackers famous, only to remember .. click to see links
terça-feira, 9 de agosto de 2011
hacker attacks in Brazil
There are about two to three years I was with Mr Julio Semeghini and Dr Renato Opice Blum in a debate on computer crime law by Decision Report.
In this debate were also Cristine Hoepers CERT.BR the other guests, follows a link to verify a portion of the transmission; http://www.youtube.com/watch?v=wjXF50ZWKcM&feature=player_embedded
Even then, in 2009, the project was of long standing waiting for approvals, (PL 84/99) seems to have no right and no end date.
With so many rodeos to put it into practice, once approved as amended and the "strikethrough" PLS 84 attacks and that more attacks will happen and these digital crimes even if they identified their attackers can not be punished because they still do not have a law that defines this type of crime.
I'm no lawyer, but I believe there is no fitness for Computer Crime still in Brazil. It seems that only the Decree Law 2.848/40 has something to define but not all of the offense. The fact is that the short memory of Brazilian politicians do not remember the attack in January 2011 complaining about the government Dilma, whose group Fatal Error Crew took the incident and claiming that the attack in June with the same group allied with Brazil Lulzsec
Other interesting dates were 2005 and 2007, when strange blackouts left more than 4 million people in the dark. Dates were also possible causes Hacker ...
And so we left behind even in Laws, as countries such as Chile and Argentina already have a Digital Law.
Forming groups and foundations such as the hackers hacking group Lulzsec Brazil, Anonymous, etc ... will be greater and greater number attacks committed;
There will always be attackers and defenders. When new holes are conquered, sites and more sites have attempted intrusions and / or invasion.
Governmental units are apparent when attacked, but what happens to the sites of small and medium enterprises?.
These are in constant attacks but not much media for this, only when a large bank or a large company is the target, then yes ....
For hackers, train invasion is easy when you have such sites to test, approve
and put into production in just over one hour.
The same tools used for safety and good of an organization, is also used by hackers, and most of the time, with greater dexterity.
It is worth mentioning here that several hackers memorable names such as Kevin Mitinik, but I believe his record as a hunter was the best hacker in his time and his name is Tsutomu Shimomura whose side was good. There is a word that hacker turned to bad programming. Hacker has always been and always will be the subject of raids, but at other times, this word was deemed knowledgeable in the improvement of our environment and that in this new era fading to the dark side of the Force Word Cracker better define an invasion but this is a topic for another story here in the IT specialists (www.tiespecialistas.com.br).
quarta-feira, 3 de agosto de 2011
A TRUE STORY
Alarming results were announced after a recent survey by the Ponemon Institute Research and Juniper Networks. The result is related to what we have seen in the media recently, hackers are almost always successful in their efforts to invade a site, and stop them is no easy task. The news shows that 90% of companies suffered some type of attack in the last 12 months. Over 77% who had actually suffered attacks internal problems due to the success of hackers in the raid. Respondents reported a very low trust in their ability to prevent attacks. Many believe that simply are not prepared. 53% believe they will also face some sort of attack in the next 12 months. Attacks on websites are often using classic vulnerabilities as "SQL Injection and Cross Site Scripting (XSS). " What are the biggest barriers to implementing an effective security strategy?
Almost half (48%) of companies surveyed said they found the security procedures too complex to implement. Another 48% mentioned the lack of resources. Companies are looking at the costs of security procedures and practices and complex, analyzing them as expensive to implement. Thus check the possibilities are cheaper. Vulnerability scanners are becoming an ever more effective in detecting faults and take corrective measures at a reduced cost. As for the consequences of these attacks, companies are seeing that the data theft and business interruption losses are more severe. With so much money being lost in breaches, companies need to invest more money in more preventative security measures even at reduced cost. "What you see is that in today's environment, systems" hacked "is almost a statistical certainty."
A fact
He warned that there would be an invasion of the sites of the corporation, but no one took action.
For several times the analyst said the SI had vulnerabilities in the IT development of corporate web sites. He analyzed, identified, reported and noted that should be considered for settlement, but was not granted.
Months passed and patch updates were installed, new devices were placed to improve perimeter security, however the application had not a single line of code updated for protection, only lines to improve customer service and streamline the business.
How many of you have heard this story?
When this occurs, the IT loses itself, along with the corporation, she takes the blame for failing to observe safety guidelines and parameters in its internal development.
A notification of security is proactive rather than an invasion and subsequent tagging of the site developed, whether outsourced or internal development, the role of SI is also possible to analyze vulnerabilities and liabilities.
An important example of success occurred on one occasion, when an analysis done on a Brazilian website in the U.S.. The analysis demonstrated vulnerabilities in the site more than holes in Swiss cheese. A notice sent to holders of the site in the country warned that the problem for biggest surprise was resolved in just over two weeks. Impressive concern and better for the Corporation as the situation was resolved in a timely manner.
The same situation occurred in the enterprise with a site available only in Brazil did not have the same attention and resolution of vulnerabilities. Guess what happened with this site?
La graffiti was a Brazilian to traditional modes of common invaders.
segunda-feira, 1 de agosto de 2011
Segurança em T,I.
Assegurar que seus dados estejam protegidos é mais que necessário nos dias de hoje. Validar informações, monitorar e adequar a niveis de segurança aceitaveis é nosso papel em ajuda-los.
domingo, 31 de julho de 2011
UMA HISTORIA REAL
Resultados alarmantes foram anunciadas depois de uma recente pesquisa realizada pelo Ponemon Institute Research e Juniper Networks. O resultado tem relação com o que temos visto na mídia recentemente; hackers são quase sempre bem sucedidos em seus esforços para invadir um site, e pará-los não é tarefa fácil.
A noticia mostra que 90% das empresas sofreram algum tipo de ataque nos últimos 12 meses. Mais de 77% que sofreram ataques tiveram realmente problemas internos devido ao sucesso dos hackers na invasão.
Os entrevistados relataram ter uma confiança muito baixa na sua capacidade em evitar ataques. Muitos acreditam que simplesmente não estão preparados.
53% também acreditam que vão enfrentar algum tipo de ataque nos próximos 12 meses.
Ataques a sites são muitas vezes utilizando vulnerabilidades clássicas como “SQL Injection e Cross Site Scripting (XSS). “
Quais são as maiores barreiras à implementação de uma estratégia de segurança eficaz?
Quase metade (48%) das empresas pesquisadas disseram que encontraram os procedimentos de segurança muito complexo de implementar. Outros 48% também mencionaram a falta de recursos. As empresas estão observando os custos de procedimentos de segurança e práticas complexas e, analisando-os como caros de implementar.
Desta forma passam a verificar possibilidades mais baratas.
Scanners de vulnerabilidade estão se tornando uma forma cada vez mais eficazes em detectar falhas e tomar medidas corretivas com custo reduzido.
Quanto às conseqüências destes ataques, as empresas estão vendo que o roubo de informação e interrupções de negócios são as perdas mais graves. Com tanto dinheiro sendo perdido em violações, as empresas precisam investir mais dinheiro em mais medidas de segurança preventiva mesmo com custo reduzido.
“O que se vê, é que no ambiente de hoje, sistemas “hackeados” é quase uma certeza estatística”.
Um fato real
Ele avisou que haveria uma invasão nos sites da corporação, mas ninguém tomou atitude.
Por varias vezes o analista de SI informou a TI que havia vulnerabilidades nos desenvolvimentos de web sites da corporação. Ele analisou, identificou, reportou e apontou que deveriam ser levados em consideração para acerto, no entanto não foi atendido.
Meses se passaram e atualizações de patches foram instaladas, novos dispositivos foram colocados para melhorar a segurança do perímetro, no entanto a aplicação não havia uma única linha de código atualizada para proteção, somente linhas para melhorar o atendimento ao cliente e agilizar o negócio.
Quantos de vocês já ouviram esta história?
Quando isto ocorre, a própria TI perde, junto com a corporação, ela leva a culpa por não observar diretrizes e parâmetros de segurança em seu desenvolvimento interno.
Uma notificação de segurança em pró-atividade é melhor que uma invasão e conseqüente pichação do site desenvolvido, Seja ele terceirizado ou de desenvolvimento interno, o papel da SI tambem é analisar vulnerabilidades possíveis e passiveis.
Um exemplo digno de acerto ocorreu em certa ocasião, quando uma analise feita em um site brasileiro nos EUA. A analise demonstrou mais vulnerabilidades no site do que buracos em um queijo suíço. Uma notificação enviada aos detentores do site neste país alertou o problema que para maior surpresa, foi resolvida em pouco mais de duas semanas. Impressionante a preocupação e melhor para a Corporação como a situação foi resolvida em tempo hábil.
A mesma situação ocorrida na corporação com um site disponível somente no Brasil não teve a mesma atenção e resolução de suas vulnerabilidades. Adivinha o que aconteceu com este site?
Estava La uma pichação brasileira aos modos tradicionais dos usuais invasores.
A noticia mostra que 90% das empresas sofreram algum tipo de ataque nos últimos 12 meses. Mais de 77% que sofreram ataques tiveram realmente problemas internos devido ao sucesso dos hackers na invasão.
Os entrevistados relataram ter uma confiança muito baixa na sua capacidade em evitar ataques. Muitos acreditam que simplesmente não estão preparados.
53% também acreditam que vão enfrentar algum tipo de ataque nos próximos 12 meses.
Ataques a sites são muitas vezes utilizando vulnerabilidades clássicas como “SQL Injection e Cross Site Scripting (XSS). “
Quais são as maiores barreiras à implementação de uma estratégia de segurança eficaz?
Quase metade (48%) das empresas pesquisadas disseram que encontraram os procedimentos de segurança muito complexo de implementar. Outros 48% também mencionaram a falta de recursos. As empresas estão observando os custos de procedimentos de segurança e práticas complexas e, analisando-os como caros de implementar.
Desta forma passam a verificar possibilidades mais baratas.
Scanners de vulnerabilidade estão se tornando uma forma cada vez mais eficazes em detectar falhas e tomar medidas corretivas com custo reduzido.
Quanto às conseqüências destes ataques, as empresas estão vendo que o roubo de informação e interrupções de negócios são as perdas mais graves. Com tanto dinheiro sendo perdido em violações, as empresas precisam investir mais dinheiro em mais medidas de segurança preventiva mesmo com custo reduzido.
“O que se vê, é que no ambiente de hoje, sistemas “hackeados” é quase uma certeza estatística”.
Um fato real
Ele avisou que haveria uma invasão nos sites da corporação, mas ninguém tomou atitude.
Por varias vezes o analista de SI informou a TI que havia vulnerabilidades nos desenvolvimentos de web sites da corporação. Ele analisou, identificou, reportou e apontou que deveriam ser levados em consideração para acerto, no entanto não foi atendido.
Meses se passaram e atualizações de patches foram instaladas, novos dispositivos foram colocados para melhorar a segurança do perímetro, no entanto a aplicação não havia uma única linha de código atualizada para proteção, somente linhas para melhorar o atendimento ao cliente e agilizar o negócio.
Quantos de vocês já ouviram esta história?
Quando isto ocorre, a própria TI perde, junto com a corporação, ela leva a culpa por não observar diretrizes e parâmetros de segurança em seu desenvolvimento interno.
Uma notificação de segurança em pró-atividade é melhor que uma invasão e conseqüente pichação do site desenvolvido, Seja ele terceirizado ou de desenvolvimento interno, o papel da SI tambem é analisar vulnerabilidades possíveis e passiveis.
Um exemplo digno de acerto ocorreu em certa ocasião, quando uma analise feita em um site brasileiro nos EUA. A analise demonstrou mais vulnerabilidades no site do que buracos em um queijo suíço. Uma notificação enviada aos detentores do site neste país alertou o problema que para maior surpresa, foi resolvida em pouco mais de duas semanas. Impressionante a preocupação e melhor para a Corporação como a situação foi resolvida em tempo hábil.
A mesma situação ocorrida na corporação com um site disponível somente no Brasil não teve a mesma atenção e resolução de suas vulnerabilidades. Adivinha o que aconteceu com este site?
Estava La uma pichação brasileira aos modos tradicionais dos usuais invasores.
sexta-feira, 1 de julho de 2011
INVEST IN INFORMATION SECURITY
One of the most problematic areas in IT Information Security when it comes to IT-related area. In fact there are complications when the SI has to monitor and restrict the area of IT activity in favor of a clean and without detours. The fact is that there is no conflict of interest in terms of databases and tied with strong passwords, the corporation can be said that information security is well with life and IT.
But this only occurs in companies that value the security posture of information and counts on his fingers which ones are. Take the example of a corporation where control of access is not tied to a Single Sign On, or even the control profiles. This corporation brings with it problems of hacking and fraud consequently indisputable. All this is due to the simple fact of investments in the SI and the control of the CIO. Investments of this size for tasks should be directed to the area to protect the corporation itself. In fact what is being proposed to ensure better control how users today in many companies is to invest in the correct timing.
Some companies spend time on investments that should have run. A project this takes about 1 ½ years to close, if indeed there are many stones on the road. Most stone will be one in which the database must contain a connector where it manages some tables whose owner will not want to use it ...
It seems a little problem, which will make a big problem.
The Project Management must determine all the guidelines of the deployment process before someone gets up in the middle of the road trying to block or add items not postulates. Yes, there are always new features to include, but should evaluate the cost-benefit, align deadlines in areas and complete a project as successful.
The various players in the market is becoming increasingly upgraded this type of project designing the new Information Security and quick control methods to prevent certain actions excuses apply after termination of contract is a third-party provider or employee.
In the digital world is connected to the SI is to understand how to support, protect and add context information which turns as a demand to the corporation where mandatory audits based on international, national and internal are fully in compliance with business goals.
It is not easy to adjust these items to IT to be completely linked with the SI, but without specific criteria aligned with the best design concepts using appropriate tools and completing a good relationship between all areas of clouds problems become solutions.
It is necessary to review the relationships between areas, so that all work on the basis of one mind;
Helping the company to grow and grow as a result the corporation.
The interest in the project, providing services to the premises of the IS and the functional relationships should be aligned to a single goal;
Ensure business to win other business.
But this only occurs in companies that value the security posture of information and counts on his fingers which ones are. Take the example of a corporation where control of access is not tied to a Single Sign On, or even the control profiles. This corporation brings with it problems of hacking and fraud consequently indisputable. All this is due to the simple fact of investments in the SI and the control of the CIO. Investments of this size for tasks should be directed to the area to protect the corporation itself. In fact what is being proposed to ensure better control how users today in many companies is to invest in the correct timing.
Some companies spend time on investments that should have run. A project this takes about 1 ½ years to close, if indeed there are many stones on the road. Most stone will be one in which the database must contain a connector where it manages some tables whose owner will not want to use it ...
It seems a little problem, which will make a big problem.
The Project Management must determine all the guidelines of the deployment process before someone gets up in the middle of the road trying to block or add items not postulates. Yes, there are always new features to include, but should evaluate the cost-benefit, align deadlines in areas and complete a project as successful.
The various players in the market is becoming increasingly upgraded this type of project designing the new Information Security and quick control methods to prevent certain actions excuses apply after termination of contract is a third-party provider or employee.
In the digital world is connected to the SI is to understand how to support, protect and add context information which turns as a demand to the corporation where mandatory audits based on international, national and internal are fully in compliance with business goals.
It is not easy to adjust these items to IT to be completely linked with the SI, but without specific criteria aligned with the best design concepts using appropriate tools and completing a good relationship between all areas of clouds problems become solutions.
It is necessary to review the relationships between areas, so that all work on the basis of one mind;
Helping the company to grow and grow as a result the corporation.
The interest in the project, providing services to the premises of the IS and the functional relationships should be aligned to a single goal;
Ensure business to win other business.
segunda-feira, 27 de junho de 2011
sábado, 4 de junho de 2011
Mapping of Risk Management in PMBOK, RUP and CMMI-SW
Abstract. Software development is a complex activity, Involving Several factors "
Which are Sometimes unpredictable and hard to control. This complexity Causes
schedule delays, cost overruns, quality problems and missing functionality. In this
context, an effective management is fundamental to the success of software projects.
The Uncertainty is the Inherent to this kind of problem, risk management has Become
more notable in this knowledge area. This paper presents the risk management map
in three models: PMBOK, CMMI and RUP, with the Objectives of the Investigate
Similarities and differences Among Them to software projects in order to make the
software development more robust.
Keywords: PMBOK, CMMI, RUP, risk management, software quality.
Abstract. Software development is a complex activity involving numerous factors, often unpredictable and difficult to control. This complexity means that most software projects exceed the time limit and the budget, and it does not meet customer expectations in terms of functionality and quality. In this context, effective management is fundamental to the success of software projects. As uncertainty is inherent in
this type of project, risk management is becoming increasingly relevant in this field. This paper presents a mapping risk management described in three models: PMBOK, CMMI and RUP, to investigate the similarities and differences between approaches
these models for software projects, to strengthen the process of software development.
Keywords: PMBOK, CMMI, RUP, risk management, quality software.
1. Introduction
Software development is a complex activity involving many factors that are often unpredictable and difficult to control, such as technological innovations and changes
listed on customer requirements, among many others. This complexity makes large part of software development projects exceeds the deadline and budget provided, and do not meet customer expectations in terms of features and quality. Given this scenario, effective management has been marked as fundamental importance to the success of software projects. Once the uncertainty is 280 inherent in this type of project, risk management is becoming increasingly relevant here. Risk management works just with the uncertainty in order to identifying potential problems and opportunities before they occur in order to eliminate or reduce the likelihood and impact of negative events for
project objectives, potentiate the effects of the occurrence of positive events. Risk management is addressed by several models among which the PMBOK (2000), CMMI (2002), and RUP (2003). The PMBOK Guide (A Guide to the Project Management
Body of Knowledge) deals with project management in a comprehensive way, not being
specific software. The CMMI (Capability Maturity Model Integration for Software)
provides a framework for the implementation and improvement of software process
organizations. RUP (Rational Unified Process) is a process based on best
software engineering practices. This paper presents a mapping of risk management from the three mentioned models, to investigate the similarities and differences between approaches the same for software projects, to strengthen and improve the process of
software development.
This paper is organized as follows. In section 2, is presented to management risk of PMBOK, Section 3, we show the risk management of CMMI; Section 4, is outlined the approach to risk management of RUP. In Section 5, is prepared to mapping of the risk management process in the PMBOK, CMMI and RUP. In section 6, presents the conclusion of the work. 2. Risk Management in PMBOK
The PMBOK (2000) describes the knowledge and best practices in managing projects. According to the PMBOK, the knowledge needed to manage projects is divided into nine areas: Integration Management, Scope Management, Time Management, Cost Management, Quality Management, Human Resource Management, Management
Communication, Risk Management and Procurement Management.
The project risk management includes the processes related to planning risk anagement, identification, analysis, planning and responses to the control and monitoring of risks in a project. These processes interact with processes and other areas of knowledge. The objectives of risk management are to increase likelihood and impact of positive events and minimize the likelihood and the impact of adverse events to project objectives. The processes of risk management are [PMBOK, 2000]:
• Planning for risk management: planning activities of the risk management be completed for the project.
Which are Sometimes unpredictable and hard to control. This complexity Causes
schedule delays, cost overruns, quality problems and missing functionality. In this
context, an effective management is fundamental to the success of software projects.
The Uncertainty is the Inherent to this kind of problem, risk management has Become
more notable in this knowledge area. This paper presents the risk management map
in three models: PMBOK, CMMI and RUP, with the Objectives of the Investigate
Similarities and differences Among Them to software projects in order to make the
software development more robust.
Keywords: PMBOK, CMMI, RUP, risk management, software quality.
Abstract. Software development is a complex activity involving numerous factors, often unpredictable and difficult to control. This complexity means that most software projects exceed the time limit and the budget, and it does not meet customer expectations in terms of functionality and quality. In this context, effective management is fundamental to the success of software projects. As uncertainty is inherent in
this type of project, risk management is becoming increasingly relevant in this field. This paper presents a mapping risk management described in three models: PMBOK, CMMI and RUP, to investigate the similarities and differences between approaches
these models for software projects, to strengthen the process of software development.
Keywords: PMBOK, CMMI, RUP, risk management, quality software.
1. Introduction
Software development is a complex activity involving many factors that are often unpredictable and difficult to control, such as technological innovations and changes
listed on customer requirements, among many others. This complexity makes large part of software development projects exceeds the deadline and budget provided, and do not meet customer expectations in terms of features and quality. Given this scenario, effective management has been marked as fundamental importance to the success of software projects. Once the uncertainty is 280 inherent in this type of project, risk management is becoming increasingly relevant here. Risk management works just with the uncertainty in order to identifying potential problems and opportunities before they occur in order to eliminate or reduce the likelihood and impact of negative events for
project objectives, potentiate the effects of the occurrence of positive events. Risk management is addressed by several models among which the PMBOK (2000), CMMI (2002), and RUP (2003). The PMBOK Guide (A Guide to the Project Management
Body of Knowledge) deals with project management in a comprehensive way, not being
specific software. The CMMI (Capability Maturity Model Integration for Software)
provides a framework for the implementation and improvement of software process
organizations. RUP (Rational Unified Process) is a process based on best
software engineering practices. This paper presents a mapping of risk management from the three mentioned models, to investigate the similarities and differences between approaches the same for software projects, to strengthen and improve the process of
software development.
This paper is organized as follows. In section 2, is presented to management risk of PMBOK, Section 3, we show the risk management of CMMI; Section 4, is outlined the approach to risk management of RUP. In Section 5, is prepared to mapping of the risk management process in the PMBOK, CMMI and RUP. In section 6, presents the conclusion of the work. 2. Risk Management in PMBOK
The PMBOK (2000) describes the knowledge and best practices in managing projects. According to the PMBOK, the knowledge needed to manage projects is divided into nine areas: Integration Management, Scope Management, Time Management, Cost Management, Quality Management, Human Resource Management, Management
Communication, Risk Management and Procurement Management.
The project risk management includes the processes related to planning risk anagement, identification, analysis, planning and responses to the control and monitoring of risks in a project. These processes interact with processes and other areas of knowledge. The objectives of risk management are to increase likelihood and impact of positive events and minimize the likelihood and the impact of adverse events to project objectives. The processes of risk management are [PMBOK, 2000]:
• Planning for risk management: planning activities of the risk management be completed for the project.
• Identification of risks: identifying the risks that may affect the project, documenting their characteristics.
• Analysis of qualitative risk: qualitatively analyze the risks, prioritizing its effects on the project.
• Analysis of quantitative risk: measuring the probability of risks and its consequences and implications for estimating the project.
• Planning the response to risk: creating procedures and techniques to assess opportunities, in order to mitigate the threats to the project.
• Monitoring and controlling the risks, monitoring residual risks, identifying new
risks, implement plans to mitigate risks and evaluate its effectiveness during cliclos entire project life.
3. Risk Management in CMMI-SW CMMI-SW (Capability Maturity Model Integration for Software) is designed to integrate CMM several models that meet the various activities related to developing software, and still make it compatible with ISO / IEC 15504 (2003). The purpose of this integration is guide the assessment and improvement of processes and the ability of organizations to manage the development, acquisition and maintenance of products or services.
CMMI-SW has two representations: (i) by stages, and (ii) continuous. The representation in stages, objects of this work is the maturity level of the organization
as a whole, containing five maturity levels: initial, managed, defined, quantitatively managed and optimizing. Each level consists of a set of process areas, consisting of specific objectives and overall goals. Each objective specific can be composed of a set of specific practices. A specific goal (SG) describes the characteristics that must be present to satisfy a process area. A specific practice (SP) is a description of a
activity that is considered important to achieve the specific goal associated with it.
The issue of risk is addressed in the areas of Project Planning process, Project Monitoring and Control and Risk Management. The first two areas process are at level 2 and the last is at level 3 of CMMI-SW. In Planning Project, we have the SG Plan Development Project with SP Identify Risks Project, which consists in the identification and risk analysis to determine the impact, probability of occurrence and the period that may occur, so that risks can be prioritized. In Monitoring and Control Project, has the SG Monitoring Project Under the Plan, which is inserted SP Monitor Project Risks.
The Risk Management aims to identify potential problems before occur, so that the activities of management of these risks can be planned and performed in accordance with their needs, throughout the life cycle of the product or project, to mitigate potential adverse impacts. Table 1 shows the relationship of specific objectives with their specific practices for the management of risk.
• Analysis of qualitative risk: qualitatively analyze the risks, prioritizing its effects on the project.
• Analysis of quantitative risk: measuring the probability of risks and its consequences and implications for estimating the project.
• Planning the response to risk: creating procedures and techniques to assess opportunities, in order to mitigate the threats to the project.
• Monitoring and controlling the risks, monitoring residual risks, identifying new
risks, implement plans to mitigate risks and evaluate its effectiveness during cliclos entire project life.
3. Risk Management in CMMI-SW CMMI-SW (Capability Maturity Model Integration for Software) is designed to integrate CMM several models that meet the various activities related to developing software, and still make it compatible with ISO / IEC 15504 (2003). The purpose of this integration is guide the assessment and improvement of processes and the ability of organizations to manage the development, acquisition and maintenance of products or services.
CMMI-SW has two representations: (i) by stages, and (ii) continuous. The representation in stages, objects of this work is the maturity level of the organization
as a whole, containing five maturity levels: initial, managed, defined, quantitatively managed and optimizing. Each level consists of a set of process areas, consisting of specific objectives and overall goals. Each objective specific can be composed of a set of specific practices. A specific goal (SG) describes the characteristics that must be present to satisfy a process area. A specific practice (SP) is a description of a
activity that is considered important to achieve the specific goal associated with it.
The issue of risk is addressed in the areas of Project Planning process, Project Monitoring and Control and Risk Management. The first two areas process are at level 2 and the last is at level 3 of CMMI-SW. In Planning Project, we have the SG Plan Development Project with SP Identify Risks Project, which consists in the identification and risk analysis to determine the impact, probability of occurrence and the period that may occur, so that risks can be prioritized. In Monitoring and Control Project, has the SG Monitoring Project Under the Plan, which is inserted SP Monitor Project Risks.
The Risk Management aims to identify potential problems before occur, so that the activities of management of these risks can be planned and performed in accordance with their needs, throughout the life cycle of the product or project, to mitigate potential adverse impacts. Table 1 shows the relationship of specific objectives with their specific practices for the management of risk.
282
Table 1. Relationship of the SG and SP of Risk Management in CMMI-SW
SG 1 Prepare for Risk Management
SP 1.1 Determine Risk Sources and Categories
SP 1.2 Define Risk Parameters
SP 1.3 Establish a Strategy for Risk Management
SG 2 Identify and Analyze Risk
SP 2.1 Identify Risks
SP 2.2 Evaluate, Categorize, and Prioritize Risks
SG 3 Mitigate Risks
SP 3.1 Develop Risk Mitigation Plans
SP 3.2 Implement Risk Mitigation Plans
The process areas of Project Planning and Project Monitoring and Control, Level 2, handle risk management in a reactive way, focusing simply on identification of risk awareness, and reaction as they occur. The area of Process Risk Management, Level 3, this risk management in a proactive, describing the evolution of specific practices to systematically plan, anticipate, and mitigate risk in order to proactively minimize their impact on the project.
Table 1. Relationship of the SG and SP of Risk Management in CMMI-SW
SG 1 Prepare for Risk Management
SP 1.1 Determine Risk Sources and Categories
SP 1.2 Define Risk Parameters
SP 1.3 Establish a Strategy for Risk Management
SG 2 Identify and Analyze Risk
SP 2.1 Identify Risks
SP 2.2 Evaluate, Categorize, and Prioritize Risks
SG 3 Mitigate Risks
SP 3.1 Develop Risk Mitigation Plans
SP 3.2 Implement Risk Mitigation Plans
The process areas of Project Planning and Project Monitoring and Control, Level 2, handle risk management in a reactive way, focusing simply on identification of risk awareness, and reaction as they occur. The area of Process Risk Management, Level 3, this risk management in a proactive, describing the evolution of specific practices to systematically plan, anticipate, and mitigate risk in order to proactively minimize their impact on the project.
4. Risk Management in RUP
RUP (2003) is a software engineering process based on best practices development and fundamental principles, among which are to be directed at cases of use, focusing on architecture, directed the risks and be iterative. According to the RUP (2003), the risks must be identified and attacked as soon as possible in the life cycle of the project, always aiming to guarantee the production of software High quality, according to users' needs and are produced on time and within provided. Every project has a number of risks involved and many are not discovered until system integration is performed.
Unidentified risks mean that you can be investing in an architecture failure or a non-optimized set of requirements. In addition, all risks involved is directly related to the difference between the estimate of how long it will long before the project is completed. To obtain accurate estimates is needed identify and address the risks beforehand.
The RUP has two dimensions. The first is the dimension that represents the static
static structure of the process, describing how the process elements are grouped
logically into subjects. Courses are logical groupings of roles, activities, artifacts and other guides to the description of a process, and are represented by a flow work. The second is the dynamic dimension that is represented by time and expressed the
process through cycles, broken down into stages, which are divided into iterations
milestones of completion. The software development process RUP is iterative, where an iteration incorporates a set of activities in business modeling, requirements analysis and design, implementation, testing and deployment in various proportions, depending on where the iteration is located in the development cycle. One of the main benefits of the approach iterative identification and treatment is the major project risks in a timely manner.
RUP (2003) is a software engineering process based on best practices development and fundamental principles, among which are to be directed at cases of use, focusing on architecture, directed the risks and be iterative. According to the RUP (2003), the risks must be identified and attacked as soon as possible in the life cycle of the project, always aiming to guarantee the production of software High quality, according to users' needs and are produced on time and within provided. Every project has a number of risks involved and many are not discovered until system integration is performed.
Unidentified risks mean that you can be investing in an architecture failure or a non-optimized set of requirements. In addition, all risks involved is directly related to the difference between the estimate of how long it will long before the project is completed. To obtain accurate estimates is needed identify and address the risks beforehand.
The RUP has two dimensions. The first is the dimension that represents the static
static structure of the process, describing how the process elements are grouped
logically into subjects. Courses are logical groupings of roles, activities, artifacts and other guides to the description of a process, and are represented by a flow work. The second is the dynamic dimension that is represented by time and expressed the
process through cycles, broken down into stages, which are divided into iterations
milestones of completion. The software development process RUP is iterative, where an iteration incorporates a set of activities in business modeling, requirements analysis and design, implementation, testing and deployment in various proportions, depending on where the iteration is located in the development cycle. One of the main benefits of the approach iterative identification and treatment is the major project risks in a timely manner.
283
Risk management in RUP is within the discipline of management Project, which aims to balance competing goals, manage risks and constraints to as the supply of product to satisfy your customers and users. This discipline provides a framework where the project is built and managed. Risk management is integrated into the development process, where iterations are planned and are based on the risks of higher priority. In one approach iterative, risks are mitigated earlier, because the elements are integrated progressively. Once each iteration exercises many aspects of the project, it becomes easier to find to what point the perceived risks are materializing, but also discover new and unsuspected risks, as risks are easier to locate and the costs involved are
minors. In RUP, the iterative life cycle is divided into four phases, which focus on
problem of risk of a cooperative manner:
· Design: focus on treatment of risks related to business affairs.
· Development: focus mainly on technical risks, examining the risks of architecture and, if necessary, revising the scope of the project as their requirements become better understood.
• Construction: focus on the risks of "logistics" and in obtaining the completion of major part of the job.
· Transition: focus on the risks associated with the logistics of product delivery to your
user. The role involved with risk management in RUP is the project manager,
performing activities Develop Risk Management Plan, identify and
Assess Risks and Monitor Project Status, which have as input or output artifacts
Overview (requirements document), Risk Management Plans, and Risk List.
5. Mapping of Risk Management in PMBOK, RUP and CMMI-SW
This section presents the mapping between the approaches of risk management
PMBOK (2000), CMMI-SW (2002) and RUP (2003), keeping in view the process of
software development, according to Table 2. This mapping was also based
in Gusmão et al. (2003) and Reinehr et al. (2003). Then an analysis will be presented
the relationship between these models.
The PMBOK is used as the basis for this mapping through the area Risk Management knowledge, being a widely used model, containing best practices for project management in general. To CMMI-SW, will be used the area of Risk Management process, Level 3, with their specific goals (SG) and practical specific (SP) corresponding to the RUP, will be used workflows (workflows) detailed (with their corresponding activities), belonging to the Management discipline Project.
284
Table 2. Process Risk Management PMBOK x x RUP CMMI-SW PMBOK RUP CMMI-SW
Area:
Risk Management
Process Area:
Risk Management
Discipline:
Project Management
Planning
Risk Management
Prepare for Risk Management (SG 1):
• Determine Risk Sources and Categories (SP1.1)
• Define Risk Parameters (SP 1.2)
• Establish a Strategy for Management Risk (SP 1.3) Project Planning Develop Plan Risk Management
Identification of Risks
Identify and Analyse Risk (SG 2)
Identify Risks (SP 2.1)
Assessing the Scope of the Project and
Risks Identify and Evaluate
Risks Qualitative Analysis
Risk Identify and Analyse Risk (SG 2)
Evaluate, Categorize and Prioritize Risks (SP 2.2)
Assessing the Scope of the Project and Risks
Identify and Evaluate Risks
Quantitative Analysis Risk
Identify and Analyse Risk (SG 2) Evaluate, Categorize and Prioritize Risks (SP 2.2)
Risk management in RUP is within the discipline of management Project, which aims to balance competing goals, manage risks and constraints to as the supply of product to satisfy your customers and users. This discipline provides a framework where the project is built and managed. Risk management is integrated into the development process, where iterations are planned and are based on the risks of higher priority. In one approach iterative, risks are mitigated earlier, because the elements are integrated progressively. Once each iteration exercises many aspects of the project, it becomes easier to find to what point the perceived risks are materializing, but also discover new and unsuspected risks, as risks are easier to locate and the costs involved are
minors. In RUP, the iterative life cycle is divided into four phases, which focus on
problem of risk of a cooperative manner:
· Design: focus on treatment of risks related to business affairs.
· Development: focus mainly on technical risks, examining the risks of architecture and, if necessary, revising the scope of the project as their requirements become better understood.
• Construction: focus on the risks of "logistics" and in obtaining the completion of major part of the job.
· Transition: focus on the risks associated with the logistics of product delivery to your
user. The role involved with risk management in RUP is the project manager,
performing activities Develop Risk Management Plan, identify and
Assess Risks and Monitor Project Status, which have as input or output artifacts
Overview (requirements document), Risk Management Plans, and Risk List.
5. Mapping of Risk Management in PMBOK, RUP and CMMI-SW
This section presents the mapping between the approaches of risk management
PMBOK (2000), CMMI-SW (2002) and RUP (2003), keeping in view the process of
software development, according to Table 2. This mapping was also based
in Gusmão et al. (2003) and Reinehr et al. (2003). Then an analysis will be presented
the relationship between these models.
The PMBOK is used as the basis for this mapping through the area Risk Management knowledge, being a widely used model, containing best practices for project management in general. To CMMI-SW, will be used the area of Risk Management process, Level 3, with their specific goals (SG) and practical specific (SP) corresponding to the RUP, will be used workflows (workflows) detailed (with their corresponding activities), belonging to the Management discipline Project.
284
Table 2. Process Risk Management PMBOK x x RUP CMMI-SW PMBOK RUP CMMI-SW
Area:
Risk Management
Process Area:
Risk Management
Discipline:
Project Management
Planning
Risk Management
Prepare for Risk Management (SG 1):
• Determine Risk Sources and Categories (SP1.1)
• Define Risk Parameters (SP 1.2)
• Establish a Strategy for Management Risk (SP 1.3) Project Planning Develop Plan Risk Management
Identification of Risks
Identify and Analyse Risk (SG 2)
Identify Risks (SP 2.1)
Assessing the Scope of the Project and
Risks Identify and Evaluate
Risks Qualitative Analysis
Risk Identify and Analyse Risk (SG 2)
Evaluate, Categorize and Prioritize Risks (SP 2.2)
Assessing the Scope of the Project and Risks
Identify and Evaluate Risks
Quantitative Analysis Risk
Identify and Analyse Risk (SG 2) Evaluate, Categorize and Prioritize Risks (SP 2.2)
Assessing the Scope of the Project and Risks
Identify and Evaluate Risks Planning Risk Response Mitigating Risks (SG 3)
Develop Risk Mitigation Plans (SP 3.1)
Assessing the Scope of the Project and Risks
Identify and Evaluate Risks
Monitoring and Control Risks
Mitigating Risks (SG 3)
Implement the Risk Mitigation Plans (SP 3.2)
Monitor and Control Project
• Track the Status of Project
5.1. Risk Management Planning The Risk Management Planning in the PMBOK is the process of deciding how to approach and conduct risk management activities for a project. This is important to ensure the level, type and visibility of risk management are commensurate with the risk and importance of the project for the organization. This will also ensure resources and deadlines sufficient for the activities of risk management, establishing a consensual basis for risk assessment. The result of this process is the Risk Management Plan, which describes how management should be structured and executed the project.
In CMMI-SW, preparing for Risk Management is conducted through the establishment and maintenance of a strategy to identify, analyze and mitigate risks. Typically, this is documented in a Risk Management Plan. The strategy of Risk management refers to specific actions and management approach used to implement and control the risk management program. This includes identifying the sources of risk, the scheme
used to categorize risks, and the parameters used to assess, limit and control risks for an effective manipulation. In RUP, the Risk Management Plan is an artifact of the output activity Develop Risk Management Plan, which belongs to the workflow
Detailed Project Planning. This activity aims to create a plan documented process for identifying, analyzing and prioritizing risks and identify strategies management to the most relevant risks of the project.
Identify and Evaluate Risks Planning Risk Response Mitigating Risks (SG 3)
Develop Risk Mitigation Plans (SP 3.1)
Assessing the Scope of the Project and Risks
Identify and Evaluate Risks
Monitoring and Control Risks
Mitigating Risks (SG 3)
Implement the Risk Mitigation Plans (SP 3.2)
Monitor and Control Project
• Track the Status of Project
5.1. Risk Management Planning The Risk Management Planning in the PMBOK is the process of deciding how to approach and conduct risk management activities for a project. This is important to ensure the level, type and visibility of risk management are commensurate with the risk and importance of the project for the organization. This will also ensure resources and deadlines sufficient for the activities of risk management, establishing a consensual basis for risk assessment. The result of this process is the Risk Management Plan, which describes how management should be structured and executed the project.
In CMMI-SW, preparing for Risk Management is conducted through the establishment and maintenance of a strategy to identify, analyze and mitigate risks. Typically, this is documented in a Risk Management Plan. The strategy of Risk management refers to specific actions and management approach used to implement and control the risk management program. This includes identifying the sources of risk, the scheme
used to categorize risks, and the parameters used to assess, limit and control risks for an effective manipulation. In RUP, the Risk Management Plan is an artifact of the output activity Develop Risk Management Plan, which belongs to the workflow
Detailed Project Planning. This activity aims to create a plan documented process for identifying, analyzing and prioritizing risks and identify strategies management to the most relevant risks of the project.
285
The three approaches point to the need to plan the management of risks similarly. However, RUP is risk management as essential only for larger projects or high risk, and places it as an option for smaller projects, which would be enough to just drawing up the Risk List.
The three approaches point to the need to plan the management of risks similarly. However, RUP is risk management as essential only for larger projects or high risk, and places it as an option for smaller projects, which would be enough to just drawing up the Risk List.
5.2. Risk Identification
The Risk Identification in the PMBOK involves determining what risks may occur in a particular project, determine which ones may affect this project and document characteristics. This is an iterative process because new risks may arise during the life cycle of the project. The frequency of iterations and who should attend each cycle varies case by case basis. The project team should be involved in order to develop a sense of responsibility for the risks and take necessary actions. The process of Risk Identification is related rather to the process of Qualitative Risk Analysis. Alternatively, this may be related directly with the process of Quantitative Risk Analysis, when driven by a
manager with experience in risk. In some cases the mere identification of risk have suggested answers to these, and that should be recorded for later analysis and implementation in process of Risk Response Planning. To CMMI-SW, the identification of potential situations, dangers, threats and vulnerabilities that could negatively affect efforts or plans of work, is the basis for successful risk management. Risks must be identified and documented in a concise language, including the context, conditions and
consequences of its occurrence, so they can be analyzed and managed properly.
The use of categories and parameters developed in the strategy of risk management,
together with the identified sources of risk, can provide discipline and optimization
appropriate to risk identification.
The identified risks form a basis for the beginning of activities of risk management. The list of risks should be reviewed periodically so that if identify possible new sources of risk and changes in the risks identified earlier, or even risks that were overlooked or did not exist when risk management strategy was drafted. The product of the specific practice Identify Risks, belonging to the specific objective to identify and analyze risk, is the list of risks identified, including the context, conditions and consequences of the risk occurring.
The activity Identify and Assess Risks RUP is meant to identify, analyze and prioritize risks to the project and determine the appropriate risk management. The following steps of this activity are directly linked to Identification of risks:
Identify potential risks: aims to create and keep updated the list of risks.
Risks "to review during the Iteration: aims to check what has changed.
"To review risks at the End of an Iteration: aims to eliminate risks which have been
fully mitigated and introduce newly discovered risks. The list of risks, which is the product of the activity Identify and Assess Risk, is a artifact fundamental to the RUP, it serves as a focal point for activities
The Risk Identification in the PMBOK involves determining what risks may occur in a particular project, determine which ones may affect this project and document characteristics. This is an iterative process because new risks may arise during the life cycle of the project. The frequency of iterations and who should attend each cycle varies case by case basis. The project team should be involved in order to develop a sense of responsibility for the risks and take necessary actions. The process of Risk Identification is related rather to the process of Qualitative Risk Analysis. Alternatively, this may be related directly with the process of Quantitative Risk Analysis, when driven by a
manager with experience in risk. In some cases the mere identification of risk have suggested answers to these, and that should be recorded for later analysis and implementation in process of Risk Response Planning. To CMMI-SW, the identification of potential situations, dangers, threats and vulnerabilities that could negatively affect efforts or plans of work, is the basis for successful risk management. Risks must be identified and documented in a concise language, including the context, conditions and
consequences of its occurrence, so they can be analyzed and managed properly.
The use of categories and parameters developed in the strategy of risk management,
together with the identified sources of risk, can provide discipline and optimization
appropriate to risk identification.
The identified risks form a basis for the beginning of activities of risk management. The list of risks should be reviewed periodically so that if identify possible new sources of risk and changes in the risks identified earlier, or even risks that were overlooked or did not exist when risk management strategy was drafted. The product of the specific practice Identify Risks, belonging to the specific objective to identify and analyze risk, is the list of risks identified, including the context, conditions and consequences of the risk occurring.
The activity Identify and Assess Risks RUP is meant to identify, analyze and prioritize risks to the project and determine the appropriate risk management. The following steps of this activity are directly linked to Identification of risks:
Identify potential risks: aims to create and keep updated the list of risks.
Risks "to review during the Iteration: aims to check what has changed.
"To review risks at the End of an Iteration: aims to eliminate risks which have been
fully mitigated and introduce newly discovered risks. The list of risks, which is the product of the activity Identify and Assess Risk, is a artifact fundamental to the RUP, it serves as a focal point for activities
286
project and is the basis around which iterations are organized. The risk directs plans of iterations, which are geared to the treatment of specific risks, trying to eliminate them
or reduce them. The list of risks should be reviewed periodically to assess the effectiveness of risk mitigation strategies, which in turn lead to revisions of the project plan and subsequent iterations of the plans.
It appears that all three approaches have a strong line with regard to process of identifying risks. All emphasize that risk identification should be done iteratively during the project life cycle, there must be involvement of project team and that is a fundamental process for managing the project as a whole. The list of risk is the product of the process in all approaches concerned emphasizing the importance of keeping it updated often.
5.3. Qualitative Risk Analysis
A Qualitative Analysis of Risks in the PMBOK is generally a quick way to establish
priorities for planning the response of the risk and provide the basis for analysis
Quantitative risk, if this is required. This process evaluates the priority of risk
identified using their probability of occurrence and its impact on project objectives if the risks occur. Definitions of the levels of probability and impact, interviews with experts and assessing the quality of information available in the project can help correct the polarizations, which are often present in the data used in this process. The analysis
qualitative risk should be reviewed during the lifecycle of the project to be updated
according to changes in project risks. In CMMI-SW, a qualitative analysis of risks is specified in the specific practice Evaluate, Categorize and Prioritize Risks, which belongs to the specific objective to identify and Analyze Risk. The assessment and categorization of each identified risk is done using categories and parameters of risk and then, its priority is determined. The defined risk parameters may include likelihood, consequence (severity or impact) and limits. The parameter values assigned to the risk can be integrated to produce additional measures, such as exposure to risk, which can be used to prioritize risks.
The risk assessment is needed to determine the relative importance of each
identified risk, being used in the determination of when appropriate management attention is required. The work product of this practice is the list of risks with their respective priority.
The activity Identify and Assess Risks RUP is meant to identify, analyze and prioritize risks to the project and determine the appropriate risk management. The following steps of this activity are directly linked to risk analysis:
· Analyse and Prioritize Risks: Match similar risks (to reduce the
List size of risks) and to classify them in terms of its impact on project.
287
Risks "to review during the Iteration: objective guarantee that the list of risks is maintained
updated throughout the project, including with regard to the prioritization of risks.
"To review risks at the End of an Iteration: reassesses the magnitude and reordering the risks
After the elimination of risks mitigated, and also introduces new risks to the list of risks.
Once again it is found that the three approaches maintain a high synergy in refers to the process of Qualitative Risk Analysis. All emphasize the importance of determine the likelihood and impact of the risk, the categorization of these risks and the continuous updating of the risk list. However, it should be noted that the PMBOK divides risk analysis in qualitative and quantitative analysis, while the other approaches do not make this distinction. Thus, the PMBOK provides a more elaborate analysis risks.
5.4. Quantitative Risk Analysis
The Quantitative Risk Analysis in the PMBOK aims to analyze numerically
probability of each identified risk and its consequence to the project objectives.
It also presents a quantitative approach to decision making in the presence of uncertainty, using techniques such as decision tree analysis and Monte Carlo simulation
Carlo (PMBOK, 2000).
This process usually follows the qualitative analysis of risks, although managers
with experience in risk tend sometimes to run it directly after the identification of
risk. In some cases, the quantitative analysis of the risk may not be required to
develop effective responses to risk. The availability of time and budget and the
need for qualitative or quantitative statements about risk and its impacts determine which methods should be used for a particular project. In CMMI-SW, the quantitative analysis of risks is referenced in the specific practice Evaluate, Categorize and Prioritize Risks in sub-practice Evaluate the Risks Identified, using defined parameters, which require that each risk is evaluated and receives a assignment of values according to parameters defined for it. These parameters can be aggregated and produce additional measures, such as exposure to risk, which can be used to prioritize them.
Generally, a scale with three to five values is used to evaluate the probability and the consequence of risk. Probable values are often used to quantify the probability. Consequences are generally related to cost, schedule, the environmental or human measures (such as time lost from work and severity of injury). This assessment is often a difficult task and it consumes time. Technical specialties or specific group may be necessary to evaluate risks and gain confidence in time to prioritize them.
In RUP, the quantitative analysis of risks is also referenced in the activity Identify and assess risks where it is emphasized that the risks are prioritized according to general exposure that it poses to the software project. To determine the exposure of each risk should be the estimation of the following information:
project and is the basis around which iterations are organized. The risk directs plans of iterations, which are geared to the treatment of specific risks, trying to eliminate them
or reduce them. The list of risks should be reviewed periodically to assess the effectiveness of risk mitigation strategies, which in turn lead to revisions of the project plan and subsequent iterations of the plans.
It appears that all three approaches have a strong line with regard to process of identifying risks. All emphasize that risk identification should be done iteratively during the project life cycle, there must be involvement of project team and that is a fundamental process for managing the project as a whole. The list of risk is the product of the process in all approaches concerned emphasizing the importance of keeping it updated often.
5.3. Qualitative Risk Analysis
A Qualitative Analysis of Risks in the PMBOK is generally a quick way to establish
priorities for planning the response of the risk and provide the basis for analysis
Quantitative risk, if this is required. This process evaluates the priority of risk
identified using their probability of occurrence and its impact on project objectives if the risks occur. Definitions of the levels of probability and impact, interviews with experts and assessing the quality of information available in the project can help correct the polarizations, which are often present in the data used in this process. The analysis
qualitative risk should be reviewed during the lifecycle of the project to be updated
according to changes in project risks. In CMMI-SW, a qualitative analysis of risks is specified in the specific practice Evaluate, Categorize and Prioritize Risks, which belongs to the specific objective to identify and Analyze Risk. The assessment and categorization of each identified risk is done using categories and parameters of risk and then, its priority is determined. The defined risk parameters may include likelihood, consequence (severity or impact) and limits. The parameter values assigned to the risk can be integrated to produce additional measures, such as exposure to risk, which can be used to prioritize risks.
The risk assessment is needed to determine the relative importance of each
identified risk, being used in the determination of when appropriate management attention is required. The work product of this practice is the list of risks with their respective priority.
The activity Identify and Assess Risks RUP is meant to identify, analyze and prioritize risks to the project and determine the appropriate risk management. The following steps of this activity are directly linked to risk analysis:
· Analyse and Prioritize Risks: Match similar risks (to reduce the
List size of risks) and to classify them in terms of its impact on project.
287
Risks "to review during the Iteration: objective guarantee that the list of risks is maintained
updated throughout the project, including with regard to the prioritization of risks.
"To review risks at the End of an Iteration: reassesses the magnitude and reordering the risks
After the elimination of risks mitigated, and also introduces new risks to the list of risks.
Once again it is found that the three approaches maintain a high synergy in refers to the process of Qualitative Risk Analysis. All emphasize the importance of determine the likelihood and impact of the risk, the categorization of these risks and the continuous updating of the risk list. However, it should be noted that the PMBOK divides risk analysis in qualitative and quantitative analysis, while the other approaches do not make this distinction. Thus, the PMBOK provides a more elaborate analysis risks.
5.4. Quantitative Risk Analysis
The Quantitative Risk Analysis in the PMBOK aims to analyze numerically
probability of each identified risk and its consequence to the project objectives.
It also presents a quantitative approach to decision making in the presence of uncertainty, using techniques such as decision tree analysis and Monte Carlo simulation
Carlo (PMBOK, 2000).
This process usually follows the qualitative analysis of risks, although managers
with experience in risk tend sometimes to run it directly after the identification of
risk. In some cases, the quantitative analysis of the risk may not be required to
develop effective responses to risk. The availability of time and budget and the
need for qualitative or quantitative statements about risk and its impacts determine which methods should be used for a particular project. In CMMI-SW, the quantitative analysis of risks is referenced in the specific practice Evaluate, Categorize and Prioritize Risks in sub-practice Evaluate the Risks Identified, using defined parameters, which require that each risk is evaluated and receives a assignment of values according to parameters defined for it. These parameters can be aggregated and produce additional measures, such as exposure to risk, which can be used to prioritize them.
Generally, a scale with three to five values is used to evaluate the probability and the consequence of risk. Probable values are often used to quantify the probability. Consequences are generally related to cost, schedule, the environmental or human measures (such as time lost from work and severity of injury). This assessment is often a difficult task and it consumes time. Technical specialties or specific group may be necessary to evaluate risks and gain confidence in time to prioritize them.
In RUP, the quantitative analysis of risks is also referenced in the activity Identify and assess risks where it is emphasized that the risks are prioritized according to general exposure that it poses to the software project. To determine the exposure of each risk should be the estimation of the following information:
288
· Impact of risk: deviations related to the planning schedule, effort or costs if the risk occurs.
· Impact of risk: deviations related to the planning schedule, effort or costs if the risk occurs.
· Probability of occurrence: the probability that the risk actually occurs (Usually expressed as a percentage)
· Exposure to risk: the impact of product probability.
In the process of Qualitative Risk Analysis, note that the PMBOK is more complete, specifying various items to be quantified, tools and techniques to be used, providing the update of the risk list containing the following items:
• analyze probabilistic design;
· Probability of achieving the goals of cost and time;
• List of prioritized risks quantified;
· Trends in the results of quantitative risk analysis.
5.5. Risk Response Planning
The Risk Response Planning is the process of developing options and determine actions to expand opportunities and reduce threats to project objectives.
Follows the process of Qualitative Risk Analysis and Quantitative Risk Analysis.
It includes the identification and assignment of individuals or groups who will be responsible for each risk response plan and insert resources and tasks on budget, on schedule and on project management plan, if necessary.
This process should be appropriate to the seriousness of the risk, weighing the costs with respect the challenges faced, considering the opportunity to succeed, be realistic within the context of the project and be accepted by all parties involved. Sometimes it is necessary select the best answer to the risk of several options available.
To CMMI-SW, the steps include developing risk treatment options risk treatment, monitoring and implementing risk treatment activities, when the limits are exceeded. The risk mitigation plans are developed and run so that the potential impact of risk occurrence are selected proactively reduced. This may also include contingency plans to deal with impact of selected risks that may occur despite attempts to mitigate them.
The parameters used to trigger the activities of the treatment of risk are defined
the strategy of risk management. The mitigation plan for a risk includes techniques and
methods used to prevent, reduce and control the probability of its occurrence, and extent of damage if it occurs (contingency plan). Mitigation plans and contingency risk are often generated only for selected risks, where the consequences of certain risks are as high or unacceptable. Other risks can be accepted and simply monitored. The options for the treatment of risks typically include alternatives such as:
· Cancellation of risks: changing or downloading while still meeting the requirements
users' needs.
• Control of risks: take action to minimize risks.
· Transfer of risk: review the design requirements to lower risks.
289
• Monitoring risk: periodically reassess risks to identify possible changes in the parameters assigned to the risks.
The activity Identify and Assess Risks in RUP is meant to identify, analyze and prioritize risks to the project and determine the appropriate risk management. The following steps of this activity are directly linked with the Risk response planning:
Identify Strategies for Preventing Risks: aims to reorganize the project to eliminate risks.
Identify Strategies to Mitigate Risks: develop plans for mitigating the risk to reduce the impact of risks.
Identify Contingency Strategies: generates alternative plans, which must contain the indicator of the risk and action to take if it occurs.
All approaches have a great similarity with regard to the process of Risk Response Planning. All deal with strategies for dealing with risk through disposal, transfer or acceptance, development and the mitigation plan contingency plan. In all approaches, there is an update of the list of risks with inclusion of plans, responsible for risk, the warning signs that the risk will occur and updating the project plan according to feedback selected.
· Exposure to risk: the impact of product probability.
In the process of Qualitative Risk Analysis, note that the PMBOK is more complete, specifying various items to be quantified, tools and techniques to be used, providing the update of the risk list containing the following items:
• analyze probabilistic design;
· Probability of achieving the goals of cost and time;
• List of prioritized risks quantified;
· Trends in the results of quantitative risk analysis.
5.5. Risk Response Planning
The Risk Response Planning is the process of developing options and determine actions to expand opportunities and reduce threats to project objectives.
Follows the process of Qualitative Risk Analysis and Quantitative Risk Analysis.
It includes the identification and assignment of individuals or groups who will be responsible for each risk response plan and insert resources and tasks on budget, on schedule and on project management plan, if necessary.
This process should be appropriate to the seriousness of the risk, weighing the costs with respect the challenges faced, considering the opportunity to succeed, be realistic within the context of the project and be accepted by all parties involved. Sometimes it is necessary select the best answer to the risk of several options available.
To CMMI-SW, the steps include developing risk treatment options risk treatment, monitoring and implementing risk treatment activities, when the limits are exceeded. The risk mitigation plans are developed and run so that the potential impact of risk occurrence are selected proactively reduced. This may also include contingency plans to deal with impact of selected risks that may occur despite attempts to mitigate them.
The parameters used to trigger the activities of the treatment of risk are defined
the strategy of risk management. The mitigation plan for a risk includes techniques and
methods used to prevent, reduce and control the probability of its occurrence, and extent of damage if it occurs (contingency plan). Mitigation plans and contingency risk are often generated only for selected risks, where the consequences of certain risks are as high or unacceptable. Other risks can be accepted and simply monitored. The options for the treatment of risks typically include alternatives such as:
· Cancellation of risks: changing or downloading while still meeting the requirements
users' needs.
• Control of risks: take action to minimize risks.
· Transfer of risk: review the design requirements to lower risks.
289
• Monitoring risk: periodically reassess risks to identify possible changes in the parameters assigned to the risks.
The activity Identify and Assess Risks in RUP is meant to identify, analyze and prioritize risks to the project and determine the appropriate risk management. The following steps of this activity are directly linked with the Risk response planning:
Identify Strategies for Preventing Risks: aims to reorganize the project to eliminate risks.
Identify Strategies to Mitigate Risks: develop plans for mitigating the risk to reduce the impact of risks.
Identify Contingency Strategies: generates alternative plans, which must contain the indicator of the risk and action to take if it occurs.
All approaches have a great similarity with regard to the process of Risk Response Planning. All deal with strategies for dealing with risk through disposal, transfer or acceptance, development and the mitigation plan contingency plan. In all approaches, there is an update of the list of risks with inclusion of plans, responsible for risk, the warning signs that the risk will occur and updating the project plan according to feedback selected.
5.6. Monitoring and Controlling Risk
The Monitor and Control Risks is the process of identifying, analyzing and planning the new risks that arise, monitoring the identified risks and those on the watch list, monitoring the "trigger conditions" contingency plans, monitoring risks
wastewater and reviewing the implementation of risk response to evaluate their effectiveness.
This process applies new tools, such as analysis of variance and trend requiring the use of performance data generated during the execution of the project. This process may involve choosing alternative strategies, implementing a plan contingency or emergency, taking corrective actions or redesign the project. It also includes the inclusion of lessons learned in the project databases and models Risk management for the benefit of future projects. CMMI-SW requires to effectively monitor and manage risks during work effort is to be followed a proactive program to regularly monitor the risks and status, and the results of follow-up actions of the risks. The strategy Risk management determines the intervals at which the risk status should be reviewed. This can result in the discovery of new risks and new options for handling, which may require re-planning and reassessment. At both events, the acceptance limits associated with the risk should be compared with the status, to determine the need for implementation of the plan for risk mitigation. The specific practice to which this monitoring is Implement Risk Mitigation Plans. In RUP, the activity Monitor the Status of the Project consists of the following:
· Capturing the Job Status: gathering information quality and progress of project to assess the current status. The Monitor and Control Risks is the process of identifying, analyzing and planning the new risks that arise, monitoring the identified risks and those on the watch list, monitoring the "trigger conditions" contingency plans, monitoring risks
wastewater and reviewing the implementation of risk response to evaluate their effectiveness.
This process applies new tools, such as analysis of variance and trend requiring the use of performance data generated during the execution of the project. This process may involve choosing alternative strategies, implementing a plan contingency or emergency, taking corrective actions or redesign the project. It also includes the inclusion of lessons learned in the project databases and models Risk management for the benefit of future projects. CMMI-SW requires to effectively monitor and manage risks during work effort is to be followed a proactive program to regularly monitor the risks and status, and the results of follow-up actions of the risks. The strategy Risk management determines the intervals at which the risk status should be reviewed. This can result in the discovery of new risks and new options for handling, which may require re-planning and reassessment. At both events, the acceptance limits associated with the risk should be compared with the status, to determine the need for implementation of the plan for risk mitigation. The specific practice to which this monitoring is Implement Risk Mitigation Plans. In RUP, the activity Monitor the Status of the Project consists of the following:
· Deriving Indicators of Progress: properly evaluate the project progress regarding plans.
290
· Derive Quality Indicators: using quality metrics.
Evaluate Indicators x Plans: compares the state expected the project according
with what was defined in the Development Plan and the Plan Iteration.
All approaches strongly indicate that the risks must be monitored and managed throughout the lifecycle of the project through the reassessment of risk and monitoring indicators.
6. Conclusion
This paper presented a mapping of risk management from the PMBOK, CMMI, and RUP, with the aim to investigate similarities and differences between the approaches
the same for software projects.
From this survey, it was found that these risk management models is consistent in all essentials, for no fundamental incompatibility between them. This demonstrates the importance of risk management for software projects, particularly by giving a proper treatment of uncertainties, and promoting the improvement of software processes.
Only the process of Quantitative Risk Analysis is not described in the PMBOK
separately in CMMI or RUP. As in the PMBOK this practice is treated as a process, there is greater clarity about how it should be conducted. Moreover, it suggests elements to be included in the list of risks, which are not considered in other models.
As the focus is specifically the PMBOK project management, it offers greater detail with regard to the descriptions of inputs, tools and techniques suggested and outputs. However, as this is not a specific model for software, missing explicit link with the specifics during the development process software.
References
CMMI Product Team. 2002. CMMI for Systems Engineering / Software Engineering, Version
1.1 Staged Representation (CMU/SEI-2002-TR-029, ESC-TR-2002-029). Pittsburgh, PA:
Software Engineering Institute, Carnegie Mellon University.
Gusmao, C. M. G., Moura, P. H. 2003. ISO, CMMI, and PMBOK Risk Management: a
Comparative Analysis. The International Journal of Applied Management and
Technology, Volume 1, Number 1.
ISO / IEC 15504. 2003. Software Process Assessment.
PMBOK. 2000. PMI Standards Committee. A Guide to the Project Management Body of Knowledge, PMI Publishing Division, Philadelphia, USA.
Reinehr, S.S., Baldwin, R., Machado, C. A. F., Person, M. S. 2003. Implementing ISO / IEC Standard 12207 using Rational Unified Process. Software Engineering Research and Practice.
RUP. 2003. Rational Unified Process, Version 2003.06.00.65, CD-ROM. Rational Software Corporation, Cupert
Assinar:
Postagens (Atom)