36 References  Legislative Counsel Committee, CHAPTER 284—Organizations for Economic Development (http:/ / www.
us/ ors/ 284.
html) (2007) (last accessed Feb.
 http:/ / www.
gov/ DAS/ OPB/ os.
shtml#Oregon_Shines__1989_  WAHPEPAH, WILDA (June 7, 1990).
“GOLDSCHMIDT’S CHALLENGE: PROTECT OREGON’S LIVABILITY”.
 Wong, Peter (March 14, 2008).
“Foundations give money to Oregon Shines”.
The Statesman Journal.
 MAPES, JEFF (April 19, 2005).
“OREGONIANS, YOUR STATE IS AVERAGE, ACCORDING TO ITS BIENNIAL BAROMETER”.
 “Oregonians’ information gap”.
April 5, 2009.
 “Progress Board finds little change”.
The Associated Press (The Bend Bulletin).
February 19, 2009.
External links • • • • Statutory foundation for OPB (http://www.leg.state.or.us/ors/284.html) (ORS 284) Official OPB web site (http://www.oregon.gov/DAS/OPB/index.shtml) Oregon Shines web site (http://www.oregon.gov/DAS/OPB/os.shtml) A 1995 Executive Order by Gov.
John Kitzhaber, relating to the OPB (http://google.com/ search?q=cache:dxy5tYNh-KEJ:www.sos.state.or.us/archives/governors/Kitzhaber/web_pages/governor/ legal/execords/eo95-05.pdf) Performance engineering Performance engineering within systems engineering, encompasses the set of roles, skills, activities, practices, tools, and deliverables applied at every phase of the Systems Development Life Cycle which ensures that a solution will be designed, implemented, and operationally supported to meet the non-functional performance requirements defined for the solution.
It may be alternatively referred to as software performance engineering within software engineering; however since performance engineering encompasses more than just the software, the term performance engineering is preferable.
Adherence to the non-functional requirements is validated by monitoring the production systems.
This is part of IT service management (see also ITIL).
Performance engineering has become a separate discipline at a number of large corporations, and may be affiliated with the enterprise architecture group.
It is pervasive, involving people from multiple organizational units; but predominantly within the information technology organization.
Performance Engineering Objectives • Increase business revenue by ensuring the system can process transactions within the requisite timeframe • Eliminate system failure requiring scrapping and writing off the system development effort due to performance objective failure • Eliminate late system deployment due to performance issues • Eliminate avoidable system rework due to performance issues • Eliminate avoidable system tuning efforts • Avoid additional and unnecessary hardware acquisition costs • Reduce increased software maintenance costs due to performance problems in production • Reduce increased software maintenance costs due to software impacted by ad hoc performance fixes • Reduce additional operational overhead for handling system issues due to performance problems Performance engineering 37 Performance Engineering Approach Because this discipline is applied within multiple methodologies, the following activities will occur within differently specified phases.
However if the phases of the rational unified process (RUP) are used as a framework, then the activities will occur as follows: Inception During this first conceptual phase of a program or project, critical business processes are identified.
Typically they are classified as critical based upon revenue value, cost savings, or other assigned business value.
This classification is done by the business unit, not the IT organization.
High level risks that may impact system performance are identified and described at this time.
An example might be known performance risks for a particular vendor system.
Finally performance activities, roles, and deliverables are identified for the Elaboration phase.
Activities and resource loading are incorporated into the Elaboration phase project plans.
Elaboration — Monitoring To ensure that there is proper feedback validating that the system meets the NFR specified performance metrics, any major system needs a monitoring subsystem.
The planning, design, installation, configuration, and control of the monitoring subsystem is specified by an appropriately defined Monitoring Process.
The benefits are as follows: 1.
It is possible to establish service level agreements at the use case level.
It is possible to turn on and turn off monitoring at periodic points or to support problem resolution.
It enables the generation of regular reports.
It enables the ability to track trends over time – such as the impact of increasing user loads and growing data sets on use case level performance.
The trend analysis component of this cannot be undervalued.
This functionality, properly implemented, will enable predicting when a given application undergoing gradually increasing user loads and growing data sets will exceed the specified non functional performance requirements for a given use case.
This permits proper management budgeting, acquisition of, and deployment of the required resources to keep the system running within the Performance engineering parameters of the non functional performance requirements.
41 References Further reading • • • • Modern trend in Performance Engineering (http://www.amendtechnologies.com/Whitepaperpdf.pdf) A Performance Engineering Strategy (http://www-128.ibm.com/developerworks/rational/library/4215.html) A Performance Process Maturity Model (http://test.cmg.org/conference/cmg2004/awards/4083.pdf) Exploring UML for Performance Engineering (http://webdiis.unizar.es/CRPetri/papers/jcampos/ 03_MC_SERP.pdf) • Introduction to Modeling Based Performance Engineering (http://fortuitous.com/docs/primers/ PE_Model_Intro.pdf) • Leveraging ITIL to Improve Application Performance (http://www.ins.com/assets/ A6BE9064-50DC-4E00-9B52-BA265DA722D6.pdf) • Patterns & Practices Performance Engineering (http://channel9.msdn.com/wiki/default.aspx/ PerformanceWiki.PerformanceEngineering) • Performance and Scalability of Distributed Software Architectures (http://www.perfeng.com/papers/pdcp.
pdf) • Performance Engineering Best Practices (High Level) (http://www.perfeng.com/papers/bestprac.pdf) • Performance Assurance: A Cynic’s Brief Collection of Dos and Don’ts (http://www.b.king.dsl.pipex.com/ PerformanceAssuranceDosAndDonts.pdf) • Principles of Capacity Management (http://www.sarquol.com/documents/Principles of Capacity Management.
pdf) • Software Engineering and Performance: A Road-map (http://delivery.acm.org/10.1145/340000/336553/ p189-pooley.pdf?key1=336553&key2=4989881611&coll=GUIDE&dl=GUIDE,ACM&CFID=11111111& CFTOKEN=2222222) • The Vicious Cycle of Computer Systems Performance and IT Operational Costs (http://fortuitous.com/docs/ whitepapers/Performance_Cost.pdf) • Microsoft Windows Server Performance Team (http://blogs.technet.com/winserverperformance/) • Gathering Performance Requirements (http://www.cmg.org/measureit/issues/mit23/m_23_2.html) Performance Operational analysis 42 Performance Operational analysis In Performance Engineering, Operational Analysis is a set of basic quantitative relationships between performance quantities.
Basically the Operational Analysis is based on operational laws, eg.
Utilization Law, Service Demand Law, The Forced Flow Law, Little’s Law and Interactive Response Time Law and is used to predict the Response Time, Throughput, Availability, Reliability, Security, Scalability and Extensibility.
Simple Example: Utilization Law for a Single Server System Following Denning, consider a single server queuing system.
It has a stream of arriving requests, which first go into a queue and then into a server — eventually completing.
This system has four basic quantities that can be observed in a finite period: • • • • T – the length of the period A – the number of arrivals occurring during the period B – the total amount of time during which the server is busy during the period C – the number of completions during the period From those we can derive some more quantities: • • • • lambda = A/T – the arrival rate X = C/T – the output rate U = B/T – the utilization S = B/C – the mean service time The utilization law is U = XS.
This is established by nothing more than algebra.
There is a corresponding law in more general settings.
Read more about ITIL: