Software Design vs Software Engineering...

In some engineering disciplines; the concepts of "design" and "engineering" are segregated. It is occasionally argued that such separation is beneficial to software systems, as well...

Design consists of the specification of requirements (functional, etc.) needed to satisfy the customer and other relevant external parties (the law, etc.) The job of a designer is to gather such requirements from various sources; asking customers directly, market research, academic research into relevant fields, domain knowledge, study of the law and of relevant standards and practices, and a bit of intuition and produce a specification of some sort.

The designer is concerned with many human factors; aesthetics, functionality, ease-of-use, fitness for purpose and quality; the designer is less concerned with implementation details.Engineering consists of the translation of these requirements into a technical specification describing a system which conforms to these requirements. In many traditional engineering disciplines, the role of engineer is generally not concerned with things such as aesthetics or fitness-for-purpose; instead the engineer is concerned with coming up with a system (or specification) which is correct, safe, and cost-effective.

The chief distinction between an engineer and a designer is that the engineer is personally (legally speaking) responsible for knowing said correctness and safety of the system. The processes of technical specification and other standard procedures exist so that the engineer can convince himself and others of this knowledge. In many fields it is possible for the engineer to be completely unrelated to the design process and only be responsible for the validation of the design...

Give me a Name

I am two week old and its now time to give me a name......

Post your enteries as comments to this post and win a prize

eQuaility Quiz 2:

eQuaility Quiz 2:

1. REQM stands for

a) Requirement Equality Management
b) Requirement Management
c) Requires Equal Maintenance
d)Request Management
****************************************************

2. REQM process area belongs to following Maturity level:
a) One
b) Two
c) Three
d) Four
****************************************************

3. Which of the following is not the specific practice of the Goal of Manage Requirements
a) Obtain Commitment to Requirements
b) Maintain Bidirectional Traceability of Requirements
c) Analyze Requirements
d) Identify Inconsistencies Between Project Work and Requirements

***********************************************************

4. The purpose of requirements management:
a) Manage Changing Requirements
b) Ensure that requirements are complete
c) Obtain Sign off of Requirements
d) All of the above
****************************************************

5. What is Bidirectional Traceability:
a) Tracing Requirements sources to the product
b) Tracing each unique work product to its associated requirement
c) Tracing Requirements sources to the product and back to its associated requirement.
d) None of the above

*************************************************************

Post your answers as comment to this post !!!

eQuality Jokes

eQuality Jokes

A new vacuum cleaner salesman knocked on the door on the first house of the street.
A tall lady open the door.

Before she could speak, the enthusiastic salesman barged into the living room and opened a big black plastic bag and poured all the cow droppings onto the carpet.

"Madam, if I could not clean this up with the use of this new powerful Vacuum cleaner in the next 10 mins, I will EAT all this dung!"

Exclaimed the eager salesman.

"Do you need chilly sauce or ketchup with that" asked the lady.

The bewildered salesman asked, "Why, madam?? "

"There's no electricity in the house..." said the lady.

Moral of the story: Gather all requirements and resources before working on any project and committing to the client...!!!

eQuality Jokes

This is the result of IMPROPER Requirements Management in a Project !!!

To create something ,
Meaningful..
make sure U know,
What to MAKE !!!

Requirment Management for DUMMIES !

The purpose of requirements management is to assure the organization documents, verifies and meets the needs and expectations of its customers and internal or external stakeholders. Requirements management begins with the analysis and elicitation of the objectives and constraints of the organization.

Requirements management further includes supporting planning for requirements, integrating requirements and the organization for working with them (attributes for requirements), as well as relationships with other information delivering against requirements, and changes for these. The traceabilities thus established are used in managing requirements to report back fulfillment of company and stakeholder interests, in terms of compliance, completeness, coverage and consistency.

Traceabilities also support change management as part of requirements management in understanding the impacts of changes through requirements or other related elements (e.g., functional impacts through relations to functional architecture), and facilitating introducing these changes.

Requirements management involves communication between the project team members and stakeholders, and adjustment to requirements changes throughout the course of the project. To prevent one class of requirements from overriding another, constant communication among members of the development team is critical.

For example, in software development for internal applications, the business has such strong needs that it may ignore user requirements, or believe that in creating use cases, the user requirements are being taken care of.

So, basically,, This will happen to U if you dont implement requirements management :

Requirement Management...The CMMi way

You do not want to be in our Dilbert's position, so what will you do? We suggest follow the CMMi way? What is CMMi way? To know..Read On....

Each Process Areas in CMMi has Specific Goals and Common Goals. These goals can be achieved by following the specific and general practices respectively

Requirement Management is one of the Process Areas of CMMi Level 2. It has a specific goal of "Manage Requirements" and it can be achieved by following below mentioned specific practices.

SG 1 Manage Requirements

• SP 1.1 Obtain an Understanding of Requirements
• SP 1.2 Obtain Commitment to Requirements
• SP 1.3 Manage Requirements Changes
• SP 1.4 Maintain Bidirectional Traceability of Requirements
• SP 1.5 Identify Inconsistencies Between Project Work and Requirements
  
  
  

Requirement Management (REQM)

The requirements are the foundation, upon which the software process is built, and the Requirements Management (RM) process emerges as a systematic approach to find, document, organize, and track all system's requirements during the life cycle.

According to a SEI’s Study, the top two out of ten factors that contribute to the failure of system
development projects are requirements problems. These problems are mainly associated with an inadequate requirements specification and/or an insufficient requirements change management. Also the Standish Group's CHAOS report found that the major factors that cause software projects to fail are:

• Lack of user input
• Incomplete requirements specifications
• Changing requirement specifications.
  

Therefore, RM process is considered the cornerstone of the software lifecycle and CMMI identifies the enormous importance of the RM, granting the category of “Process Area” and placing it in the CMMI, staged representation, maturity level two. According to the CMMI, the Requirements Management major aim is establishing an agreement between the customer and the software team on the meaning of the requirements.

eQuality Quiz 1:

1) eQuality stands for ____________

a) Encouraging Quality
b) Ensuring Quality
c) Emerging Quality
d) Ending Quality

***********************************
2) eQuality punch line

a) It's not about what, it’s about why
b) It's not about why, it’s about what
c) Lets learn CMMi
d) CMMi awareness drive

***********************************
3) Select the correct sequence of Levels in CMMi

a) Initial, Defined, Managed, Quantitatively managed, Optimized
b) Initial, Defined, Managed, Optimized, Quantitatively managed
c) Initial, Managed, Defined, Optimized, Quantitatively managed
d) Initial, Managed, Defined, Quantitatively managed, Optimized

***********************************
4) Our organization is getting reassessed for CMMi Level 5 in year

a) 2010
b) 2011
c) 2012
d) None of above

***********************************
5) CMMI (Capability Maturity Model Integration) is a __________ improvement approach

a) Quality
b) Coding
c) Process
d) None of above

Post your answers as comment to this post !!!

Quick description of CMMI level 5 process areas

Quick description of CMMI level 5 process areas

OID – Organizational Innovation and DeploymentThe purpose of OID is to select and deploy improvements that measurably improve the organization’s processes. The improvements support the organization’s quality and process performance objectives as derived from the organization’s business objectives. Keep in mind that you need to prove that the proposed innovations has improved organization’s process.

CAR – Causal Analysis & ResolutionThe purpose of this process area is to identify causes of defects and take action to prevent them from occurring in the future. Tip: A Six Sigma initiative can help a lot high maturity.

The question "WHY" is very powerful...

A preety self explanatory graphics to show the first step of initiating a CMMi process...

eQuality Jokes

Levels of the Capability Maturity Model (CMMi)

There are five levels defined along the continuum of the CMM, and, according to the SEI: "Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief."


1. Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new process.
2. Managed - the process is managed according to the metrics described in the Defined stage.
3. Defined - the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the latter being Work Instructions).
4. Quantitatively managed
5. Optimized - process management includes deliberate process optimization/improvement.


Within each of these maturity levels are Key Process Areas (KPAs) which characterise that level, and for each KPA there are five definitions identified:
1. Goals
2. Commitment
3. Ability
4. Measurement
5. Verification


The KPAs are not necessarily unique to CMM, representing — as they do — the stages that organizations must go through on the way to becoming mature.


The CMM provides a theoretical continuum along which process maturity can be developed incrementally from one level to the next. Skipping levels is not allowed/feasible.


Level 1 - Initial (Chaotic)
It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes.


Level 2 - Managed
It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. Process discipline is unlikely to be rigorous, but where it exists it may help to ensure that existing processes are maintained during times of stress.


Level 3 - Defined
It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization.


Level 4 - Quantitatively Managed
It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level.


Level 5 - Optimized
It is a characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements.
At maturity level 5, processes are concerned with addressing statistical common causes of process variation and changing the process (for example, to shift the mean of the process performance) to improve process performance. This would be done at the same time as maintaining the likelihood of achieving the established quantitative process-improvement objectives.





(For More Info : http://en.wikipedia.org/wiki/Capability_Maturity_Model#Levels_of_the_Capability_Maturity_Model)

Five Levels of CMMi

CMMi (Capability Maturity Model Integration)

What Is CMMI?

CMMI (Capability Maturity Model Integration) is a process improvement approach that provides organizations with the essential elements of effective processes that ultimately improve their performance.
CMMI can be used to guide process improvement across a project, a division, or an entire organization.
It helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.

Is not about what, it’s about why.

"Is not about what, it’s about why."

We all know that Hexaware is getting reassessed for CMMi Level 5 in year 2011.But the question which may be coming to everyone mind will be “ Why our Organization need to be CMMi 5 certified?”

CMMi allows:

• Detailed coverage of the product life cycle than other process-improvement products used alone


• CMMi provides an opportunity to eliminate the stovepipes and barriers that typically exist in different parts of an organization and that typically are not addressed otherwise
  

• CMMi products incorporate lessons learnt that were learnt as a result of many other standard processes. Therefore they inherently, handle some of the common problems faced by other process improvement approaches

• Promotes collaboration between systems and software engineering
  

• Allows users to choose model representation that best suits them and their objectives
  
  
  
  

  

eQuality Team

Is not about what, it’s about
why.

eQuality stands for “ensuring Quality”. We are one of the CMMi awareness team of E&Y DDC-Mumbai. We aim to make everyone CMMi aware so that we can incorporate CMMi approach in our work.