pejman moghbelzadeh's List: Article

• The Concentration Ratio is often determined for the top 4, 8, 20, 25, and 50 largest markets participants by revenue. 

• However, the most prominent Concentration Ratio used to measure market competitiveness is the CR4 which is determined by measuring the total market share (MS) of the 4 largest market players.  The formula for determining any Concentration Ratio is as follows:

   

  CR’n’ = MS1 + MS2 + MS3 + MS4…+ MS’n’, where ‘n’ is typically 4, 8, 20, 25, or 50.

• 
• Porter's Five Forces Analysis is an important tool for assessing the potential for profitability in an industry.
• With a little adaptation, it is also useful as a way of assessing the balance of power in more general situations.
• • Supplier Power: The power of suppliers to drive up the prices of your inputs;
  • Buyer Power: The power of your customers to drive down your prices;
  • Competitive Rivalry: The strength of competition in the industry;
  • The Threat of Substitution: The extent to which different products and services can be used in place of your own; and
  • The Threat of New Entry: The ease with which new competitors can enter the market if they see that you are making good profits (and then drive your prices down)

2 more annotations...

• Collaborative -You work as a team member with both user groups and the development team. You are a boundary spanner and work across organisational boundaries.

  Representative - You are genuinely representation the best interests of your (real) customers, and they know it. They have given you authority to represent them, not just at a formal level but at a personal level.

  Accountable - You are willing to stand by your decisions, but you are also willing to wear the consequences of your mistakes.

  Committed - You want the project to succeed to the degree you are willing to work beyond the requirements of the job description.

  Knowledgeable - you have sufficient knowledge of the development process, of the customer domain and of good business practice generally, and this is sufficient to help you make on the spot decisions without having to refer all questions upline to frontline users or customers. This usually takes some sort of ongoing market research to establish and maintain.

• change happens on two  dimensions: the business dimension (vertical axis) and the people dimension (horizontal  axis). Successful change happens when both dimensions of change occur  simultaneously. 

• "It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change
• over 80% of incidents emerge from performed changes
• There is a connection of Change with all other ITSM disciplines, but especially with Release, Configuration and Capacity Management.
• • RFC - Request For Change: can be triggered from different sources: Incident/Problem resolution, introduction/upgrade/removal of the CI...
  • FSC - Forward Schedule of Changes: details of all the Changes approved for implementation and their proposed implementation dates
  • PSA - Projected Service Availability: contains details of Changes to agreed SLAs and service availability because of the currently planned FSC
  • CAB - Change Advisory Board: a body that approves Changes and assists Change Management in the assessment and prioritization of changes, composed of major stakeholders impacted by the change and technical staff responsible for tech. implementation
  • CAB/EC - Change Advisory Board / Emergency Comitee: a smaller body with authority to make emergency decisions in case of Urgent Changes
  • CMDB - Configuration Management Database
• • raising and recording Changes
  • assessing the impact, cost, benefits and risk of Changes
  • developing the business justification and obtaining approval
  • management and co-ordination of Change implementation
  • monitoring and reporting on the implementation
  • closing and reviewing the Change requests
• Inaccurate configuration details leading to poor impact assessment
• • Review all submitted RFCs. As appropriate, determine and provide details of their likely impact, the implementation resources, and the ongoing costs of all Changes.
  • Attend all relevant CAB or CAB/EC meetings. Consider all Changes on the agenda and give an opinion on which Changes should be authorized. Participate in the scheduling of all Changes.
  • (CAB/EC only). Be available for consultation should an urgent Change be required.
  • Provide advice to Change Management on aspects of proposed urgent Changes.

5 more annotations...

• The literature is rife with inconsistent usage of terminology. At one extreme, McConnell [69-72]  makes no distinction between errors and defects in the examples he cites. At the polar opposite,  Humphrey [311-313] elaborately states a bug is a defect but not all defects are bugs, and all defects  result from errors but not all errors produce defects. Even the software measurements collected by  pseudo-authoritative organizations reflect a lack of consensus: NASA and DoD refer to  "defects", the Software Engineering Laboratory refers to "errors", and the  Army refers to "faults" and "anomalies". [Christensen and Thayer, 478-483]
• (IEEE) anything observed in the documentation or operation of software  that deviates from expectations based on previously verified software products or reference  documents.
• (1) things the software does that it is not supposed to do, [or] something  the software doesn't do that it is supposed to. [Telles and Hsieh, 5];

   

  (2) a fault in a program which causes the program to perform in an unintended or unanticipated  manner.
• the sudden and complete failure of a computer system or component.
• (1) (IEEE) a product anomaly
• (2) synonymous with fault, both imply a quality problem discovered after the software has  been released to end-users (or to another activity in the software process); [Pressman, 203]
• (3) fault; [SWEBOK, Ch.5, p.6]
• (4) error, fault, or failure; [SWEBOK, Ch.11, p.9]
• (1) (ISO) a discrepancy between a computed, observed, or measured value or  condition and the true, specified, or theoretically correct value or condition;

   

  (2) a quality problem discovered by software engineers (or others) before the software  is released to the end-user (or to another activity in the software process). [Pressman, 203]
• (IEEE) an event that causes suspension of normal program execution; types  include addressing exception, data exception, operation exception, overflow exception, protection  exception, underflow exception.
• (IEEE) the inability of a system or component to perform its required  functions within specified performance requirements.
• an incorrect step, process, or data definition in a computer program which  causes the program to perform in an unintended or unanticipated manner.
• a human action that produces an incorrect result, and the subject  of the quality improvement process.
• (1) (IEEE) a condition or capability needed by a user to solve a  problem or achieve an objective;

• First, we state the following indisputable facts: (see tangent discussion in  Scenarios)

   
   
  • There is the user/customer's intention or expectation.
   
  • There is a specification (or documented requirement).
   
  • There is a software implementation, provided by the developer/vendor.
• error

  any observed event (incident) or detected deviation between the  specification and the implementation.
• a deviation between the specification and the implementation, detected  after release to the customer (or the next activity in the software process).
• Expectation = Specification != Implementation. Error or defect to be corrected by  developer/vendor.
• Expectation != Specification = Implementation. Customer is unhappy with code-to-specifications.  Customer has a requirements bug, to be addressed by a change request or reset expectations.

17 more annotations...

• To me a bug is erroneous operation of the software based on the customer's requirements
• That's fine when both sides agree to what the requirements are
• But if anything can be declared a bug, it becomes more difficult to make management and the customer believe the claims you make about your software development process and practices.
• The term "bug" and the term "defect" don't always mean the same thing:
  
  • Bug tends to refer to something "wrong" in the code (either due to nonconformance with design or requirements).
  
  
  • Defect often means something that is "wrong" in any work-product (including the requirements).
  
  
  • Hence, many consider ALL of incorrect, inconsistent, incomplete, or unclear requirements to be "defects": if they believe a requirement is"missing" or incorrectly interpreted, it's still a "bug" in their eyes.
  
  
  • Ive also seen some folks define "bug" as: anything that requires changing ONLY the code to make it work "as expected". If it requires a change to docs, the consider it a "change request" (and the issue ofwhether or not it is still a "defect" isnt really addressed)
  
  
  • Also, many folk's metrics (particularly waterfall-ish metrics for phase containment and/or screening, but I think also orthogonal-defect classification -- ODC) explicitly identify "missing requirements" as a kind of defect
• We fix "bugs" for free as we guarantee our code to work to specification defined and agreed to by the client
• Expectation = Specification = Implementation. No bugs. Many happy campers.
  Expectation = Specification != Implementation. Error or defect to be corrected by developer/vendor.
  Expectation = Implementation != Specification. Customer is happy with code-to-intent. Vendor has a requirements bug, to be addressed in the "as-built" product specification.
  Expectation != Specification = Implementation. Customer is unhappy with code-to-specifications. Customer has a requirements bug, to be addressed by a change request or reset expectations.
  Expectation != Specification != Implementation. Likely the result of ambiguous or undocumented requirement(s). General disagreement, unhappiness, and finger pointing.

4 more annotations...

• Triage the work item, assigning the task to an iteration
• At SSW, we are using Agile process to manage our project. The Agile template in TFS provides two different kind of "task" work item, scenario and task. Scenario is a bigger view of a group of Tasks, which can improve the overall tracking capability by giving project manager a better understanding of the project progress; while Tasks will focus on each individual details of the implementation, should be used and assigned to developers as their job unit.

• Keep the clutter down
• Don't mix Requirements with Design
• Industry Best Practices
• The IEEE 830 Standard explains how to create Software Requirements Specifications (SRS).
• Industry standards are wisdom - make sure that they are part of your best practices.
  
• who originally suggested that

4 more annotations...

• Instead agilists   will do just enough    initial   requirements envisioning to identify   their project scope and develop   a high-level schedule and   estimate
• agilists strive to truly manage change, not to prevent it.
• Stakeholders are responsible for prioritizing the requirements whereas developers are responsible for estimating. 
• 1. Start.  At the start of an iteration the team takes the   highest priority requirements   from the top of the stack which   they believe they can implement   within that iteration.  If you have not been modeling ahead, more on this below, you will need to discuss each of the requirements that you pulled off the stack so that you the team can plan how it will proceed during the iteration.  In short, you will be doing some modeling at the beginning of each iteration as part of your overall iteration planning effort, often using using inclusive modeling tools such as paper or whiteboards.
   
  2.   Middle.  The team then develops working software which meets the intent of the requirements, working closely with stakeholders throughout the iteration to ensure that they build software which meets their actual needs.  This will likely include some model storming to explore the requirements in greater detail.
   
  3.   End.  The team will optionally demo the working software to a wider audience to show that they actually did what they promised to do.  Although a demo is optional I highly recommend doing it: because working software is the primary measure of progress on a software development project, you want to communicate your team's current status by regularly demoing your work.
   
   

   
• Scrum suggests that you freeze   the requirements for the current   iteration to provide a level of   stability for the developers.    If you do this then any change   to a requirement you’re   currently implementing should be   treated as just another new   requirement
• XP and OpenUP support changing requirements during the iteration if you wish to work that way, although doing so may force you to sometimes move some requirements to the next iteration to make room for new requirements introduced during the current iteration.  Both approaches are perfectly fine, you just need to choose the approach which makes the most sense for your situation.
• It's a significant risk to do detailed modeling up front
• The requirements in the current iteration must be understood in detail
• You may decide model a bit ahead
• You just need enough detail to estimate the later requirements.
• They realize they didn't   understand their actual need.  It's common   to show a stakeholder your working system to   date only to have them realize that what they asked for really   isn't what they want after all.  This is one reason   why    active stakeholder participation and short   iterations are important to your success.
• New requirements, including defects   identified as part of your user testing activities, are   prioritized by your   project stakeholders and added to   the stack in the appropriate place
• Fundamentally a single person needs   to be the final authority when it comes to requirement   prioritization.  In   Scrum this person is called the   product owner.
• On some projects   a   business analyst may take on this responsibility
• Smaller requirements are easier to   estimate.  Shall statements, such as “the system shall   convert feet to meters”, are an example of very small   requirements.     User stories are a little larger but still   relatively easy to estimate.    Use cases, a staple of the   Rational Unified Process   (RUP) and the    Agile Unified Process (AUP), can become too large to estimate effectively   although you can reorganize them into smaller and more   manageable artifacts if you’re flexible
• It isn’t clear how much the system will   cost up front.  As the requirements change the cost must also   change.  So what?  The stakeholders have   control over the budget, scope, and schedule and get   concrete feedback on a regular basis.  In this   situation stakeholders don't need an estimate up   front because of the increased level of control   which they have.    Would you rather have a detailed, and very likely wrong,   estimate up front or would you rather be in control and   spend your money wisely?  The approach I’m   describing enables the latter, and according to the    2007 Project Success survey, that's what the   vast majority of people desire.  Furthermore,   with a bit of    initial requirements envisioning you can easily   gather sufficient information about the project   scope to give a reasonable, ranged estimate early in   the project.
• Someone needs to be the final authority when it   comes to requirement prioritization.  In   Scrum this   person is called the product owner
• Your stakeholders might prioritize the   requirements in such a way as to push an architecturally   significant (read devastating) requirement several   months out.  For example, the need to support several   technical platforms or several cultures will often cause   significant havoc to projects teams which are unprepared   for these changes.  My experience is that the order of   requirements really doesn’t matter as long as you do two   things:  First, keep your design modular and of the   highest quality possible via  code refactoring   and database refactoring.  Second, just as you do some  initial requirements modeling up front you should   also do some   initial architectural modeling up front.    This model effort should still be agile, it’s surprising   how quickly you can sketch a few whiteboard diagrams   which captures a viable architectural strategy for your   team. 

16 more annotations...