the concept of multi-paradigm programming language – (Manjunath M)

Programming languages are often classified according to their paradigms, e.g. imperative, functional, logic, constraint-based, object-oriented, or aspect-oriented. A paradigm characterizes the style, concepts, and methods of the language for describing situations and processes and for solving problems, and each paradigm serves best for programming in particular application areas. Real-world problems, however, are often best implemented by a combination of concepts from different paradigms, because they comprise aspects from several realms, and this combination is more comfortably realized using multiparadigm programming languages.

In object-oriented programming, programmers can think of a program as a collection of interacting objects, while in functional programming a program can be thought of as a sequence of stateless function evaluations. When programming computers or systems with many processors, process oriented programming allows programmers to think about applications as sets of concurrent processes acting upon logically shared data structures

Some languages are designed to support one particular paradigm (Smalltalk supports object-oriented programming,Haskell supports functional programming), while other programming languages support multiple paradigms

Many programming paradigms are as well known for what techniques they forbid as for what they enable. For instance, pure functional programming disallows the use of Side effects while Structured programming disallows the use of the goto statement. Partly for this reason, new paradigms are often regarded as doctrinaire or overly rigid by those accustomed to earlier styles.

Multi-paradigm programming language

List of multi-paradigm programming languages

A multi-paradigm programming language is a programming languages that supports more than one programming paradigm[As edadesignertimothy Bodd puts it: “The idea of a multiparadigm language is to provide a framework in which programmers can work in a variety of styles, freely intermixing constructs from different paradigms.” The design goal of such languages is to allow programmers to use the best tool for a job, admitting that no one paradigm solves all problems in the easiest or most efficient way.

All these languages follow the procedural paradigm. That is, they describe, step by step, exactly the procedure that should, according to the particular programmer at least, be followed to solve a specific problem. The efficacy and efficiency of any such solution are both therefore entirely subjective and highly dependent on that programmer’s experience, inventiveness and ability.

Later, Object Oriented l;anguages (like C++, Eiffel and java) were created. In these languages, data, and methods of manipulating the data, are kept as a single unit called an object. The only way that a user can access the data is via the object’s ‘methods’ (subroutines). Because of this, the internal workings of an object may be changed without affecting any code that uses the object. The necessity of every object to have associative methods leads some skeptics to associate OOP with software bloat. polymorphism was developed as one attempt to resolve this dilemma.

Since object-oriented programming is considered a paradigm, not a language, it is possible to create even an object-oriented assembler language. High Level Assembly (HLA) is an example of this that fully supports advanced data types and object-oriented assembly language programming – despite its early origins.

Within imperative programming, which is based on procedural languages, an alternative to the computer-centered hierarchy of structured programming is literate pgming, which structures programs instead as a human-centered web, as in a hypertext essay – documentation is integral to the program, and the program is structured following the logic of prose exposition, rather than compiler convenience.

Independent of the imperative branch,Declearative programming paradigms were developed. In these languages the computer is told what the problem is, not how to solve the problem – the program is structured as a collection of properties to find in the expected result, not as a procedure to follow. Given a database or a set of rules, the computer tries to find a solution matching all the desired properties. The archetypical example of a declarative language is the Fourth generation language SQL, as well as the family of functional languages and Logic programming

Functional programming is a subset of declarative programming. Programs written using this paradigm use functions, blocks of code intended to behave like mathematical functions. Functional languages discourage changes in the value of variables through  assignment, making a great deal of use of recursion instead.

The Logic Programming paradigm views computation as automated reasoning over a corpus of knowledge. Facts about the problem domainare expressed as logic formulae, and programs are executed by applying inference rules over them until an answer to the problem is found, or the collection of formulae is proved inconsistent.


the ISO 9001 and ISO 9126 standards covering software quality – (Manjunath M)

The most challenging goal of software engineering is to find better techniques and methods for developing quality and error – resistant software at reasonable cost. In today’s world of information, computers have been applied in to a number of large and critical areas of the industry

Quality characteristics of the software can be measured with a set of attributes defined for each characteristic. These characteristics help evaluating the quality of software, but they do not define a guidance of constructing high quality software products. Quality characteristics are defined in the standard ISO/IEC 9126.

Quality management system requirements are defined in the ISO 9001 standard. The main goal of these requirements is to satisfy the customer needs, which is the measure of quality software product.

In the context of Software engineering software quality refers to two related but distinct notions that exist wherever quality is defined in a business context.

Software functional quality reflects how well it complies with or conforms to a given design, based on functional requirements or specifications. That attribute can also be described as the fitness for purpose of a piece of software or how it compares to competitors in the marketplace as a worthwhile product.

Software structural quality refers to how it meets non-functional requirements that support the delivery of the functional requirements, such as robustness or maintainability, the degree to which the software was produced correctly.

Structural quality is evaluated through the analysis of the software inner structure, its source code, in effect how its architecture adheres to sound principles of software architecture. In contrast, functional quality is typically enforced and measured through software testing.

The structure, classification and terminology of attributes and metrics applicable to softwrae quality management have been derived or extracted from the ISO 9126-3 and the subsequent ISO 25000:2005 quality model, also known as Square. Based on these models, the Consortium for IT Software Quality (CISQ ) has defined 5 major desirable structural characteristics needed for a piece of software to provide business value  Reliability, Efficiency, Security, Maintainability and (adequate) Size.

Software quality measurement quantifies to what extent a software or system rates along each of these five dimensions. An aggregated measure of software quality can be computed through a qualitative or a quantitative scoring scheme or a mix of both and then a weighting system reflecting the priorities. This view of software quality being positioned on a linear continuum is supplemented by the analysis of “critical programming errors” that under specific circumstances can lead to catastrophic outages or performance degradations that make a given system unsuitable for use regardless of rating based on aggregated measurements.


ISO is the International Organization for Standardization that has membership from countries all around the world. It has developed about 19000 International Standards and about 1000 new standards every year.

ISO standards published in recent years are in fields of information and societal security, climate change, energy efficiency and renewable resources, sustainable building design and operation, water services, nanotechnologies, intelligent transport systems, food safety management, and health informatics.


ISO/IEC 9126 ISO/IEC 9126 is one of the best software quality standards in the world. It is intended to specify the required software product quality for software development and software evaluation.

This standard is divided into four parts:

• Quality model

• External metrics

• Internal metrics

• Quality in use metrics

This quality model can be applied in many sectors. It describes the quality model framework that explains the relationships between the different approaches to quality and it consists of six characteristics them is divided into a set of sub-characteristics:

Functionality – a set of software attributes with specific properties that provide functions that satisfy the needs of the user

 Reliability – A set of software attributes with ability to maintain its specific level of performance under the specific stated conditions for a stated period of time.

 Usability – A set of software attributes that are measure of the effort needed user to learn to use the product.

Efficiency – A set of software attributes that represents the ability of the software product to provide relationship between level of performance of the software and the amount of recourses that are used under the stated conditions.

Maintainability – A set of software attributes that are  needed to avoid unexpected effects from specified modifications. This characteristic describes the ease with which the software product can be changed.

Portability – A set of software attributes that are needed for software to be transferred from one environment to another. This is important when the application is made for using on different distributed platforms.

Internal Metrics are metrics that are static and that do not rely on software execution and describe the internal metrics used to measure the characteristics and sub-characteristics identified in quality model.

External metrics rely on running software and they describe the external metrics used to measure the characteristics and sub characteristics identified in quality model.

Quality in use metrics can be measured only when the final product is used in real environment with real conditions and it identifies the metrics used to measure the effects of the quality Characteristics.

Figure 1: ISO/IEC 9126-1 external and internal quality attributes.

In the past years ISO 9000 has proven to be very important and effective tool that cannot be overlooked. According to a study done in Sweden which was focused on factors for implementing the standard, benefits gained after implementation and motives for implementing it, it was determined that the essential interests for getting certification is to increase corporate reputation and quality.

Idea for certification.

ISO 9001 has a goal to implement a group of requirements that when definitely implemented, should supply the costumer and the retailer with confirmation that the goods and services supplied:

• Meet the needs and expectations

• Comply with applicable regulations

copyleft, gnu-linux, creative commons, GPL, DRM. – (Manjunath M)

Creative Commons

Creative Commons helps you share your knowledge and creativity with the world. Creative Commons develops, supports, and stewards legal and technical infrastructure that maximizes digital creativity, sharing, and innovation.

Creative Commons (CC) is a non profit organization headquartered in Mountain view, California, United States devoted to expanding the range of creative works available for others to build upon legally and to share. The organization has released several Copyright licenses known as Creative Common licenses free of charge to the public.

These licenses allow creators to communicate which rights they reserve, and which rights they Waive for the benefit of recipients or other creators. An easy to understand one-page explanation of rights, with associated visual symbols, explains the specifics of each Creative Commons license. Creative Commons licenses do not replace copyright, but are based upon it. They replace individual negotiations for specific rights between copyright owner (Licensor) and license,which are necessary under an “all rights reserved” copyright management with a “some rights reserved” management employing standardized licenses for re-use cases where no commercial compensation is sought by the copyright owner. The result is an agile, low overhead and cost copyright management regime, profiting both copyright owners and licensees.


The GNU General Public License is a free software license (one of many ) created to protect the four essential freedoms of software users. Those freedoms are:

Freedom 0. the freedom to use the software for any purpose,

Freedom 1. the freedom to change the software to suit your needs,

Freedom 2. the freedom to share the software with your friends and neighbors, and

Freedom 3. the freedom to share the changes you make.

The license is the child of Richard M Stallman – the founder of the free softwrae movement and the free softwrae foundation – the not-for-profit organization that was born from his vision. There are multiple incarnations of the license, each with their own distinct purposes:

GNU General Public License (GPL) – Designed to protect and enforce the aforementioned freedoms. All derivative works must also be licensed under the GPL or a GPL compatible license.

GNU Lesser General Public License (LGPL) – Designed to protect the four freedoms, but permits usage in proprietary applications to a limited degree. Derivative works must still be licensed under a GPL-compatible license.

GNU Affero General Public License (AGPL) – The most noble and powerful of the GPL licenses. It is an extension of the GNU GPL, with an added clause requiring that users accessing sodtware through a server must have access to the softwares source code (e.g. a website/web service). All derivative works must be licensed under the AGPL or a compatible license.

The GPL is a guardian to those who believe that the user should, above all else, be free to use, alter and distribute the program as they wish. The GPL is a curse to those who wish to take advantage of their users by creating proprietary software in order to control and exploit them.


Copyleft is a play on thw word copyright to describe the practice of using copyright law to offer the right to distribute copies and modified versions of a work and requiring that the same rights be preserved in modified versions of the work. In other words, copyleft is a general method for making a program (or other work) free (libre), and requiring all modified and extended versions of the program to be free as well. This free does not necessarily mean free of cost (gratis), but free as in freely available to be modified.

Copyleft is a form of licensing and can be used to maintain copyright conditions for works such as computer software, documents and art . In general, copyright law is used by an author to prohibit others from reproducing, adapting, or distributing copies of the author’s work. In contrast, under copyleft, an author may give every person who receives a copy of a work permission to reproduce, adapt or distribute it and require that any resulting copies or adaptations are also bound by the same licensing agreement.

Copyleft licenses (for software) require that information necessary for reproducing and modifying the work must be made available to recipients of the executable. The source code  files will usually contain a copy of the license terms and acknowledge the author(s).

Copyleft type licenses are a novel use of existing copyright law to ensure a work remains freely available. The  GNU General Public License , originally written by Richard M Stallman, was the first copyleft license to see extensive use, and continues to dominate the licensing of copy lefted software.Creative Commons, a  non profit organization founded by Lawrence Lessing, provides a similar license provision condition called share alike.


Digital rights management (DRM) is a class of controversial acess control technologies that are used by hardware manufacturers, publishers, copyright holders, and individuals with the intent to limit the use of digital content and devices after . DRM is any technology that inhibits uses of digital content that are not desired or intended by the content provider. DRM also includes specific instances of digital works or devices.  the digital Millenium copyright Act (DMCA) was passed in the United States to impose criminal penalties on those who make available technologies whose primary purpose and function  are to circumvent content protection technologies.

The use of digital rights management is not universally accepted. Some content providers claim that DRM is necessary to fight copyright infringement online and that it can help the copyright holder maintain artistic control or ensure continued revenue streams. Those opposed to DRM contend there is no evidence that DRM helps prevent copyright infringement, arguing instead that it serves only to inconvenience legitimate customers, and that DRM helps big business stifle innovation and competition. Further, works can become permanently inaccessible if the DRM scheme changes or if the service is discontinued. Proponents argue that digital locks should be considered necessary to prevent “intellectual property” from being copied freely, just as physical locks are needed to prevent personal property from being stolen.

Digital locks placed in accordance with DRM policies can also restrict users from doing something perfectly legal, such as making backup copies of CDs or DVDs, lending materials out through a library, accessing works in the public domain, or using copyrighted materials for research and education under fair use laws. Some opponents, such as the Free software foundation (FSF) through its Defective by design campaign, maintain that the use of the word “rights” is misleading and suggest that people instead use the term “digital restrictions management”. Their position is that copyright holders are restricting the use of material in ways that are beyond the scope of existing copyright laws, and should not be covered by future laws. TheElectronic Frontier foundation  (EFF) and the FSF consider the use of DRM systems to beanti compertitive practice.

LAB Evaluation 5

ISO/IEC 12207:Software Life Cycle Process

What Is ISO?

Standards are documented agreements containing technical specifications or other precise criteria to be used consistently as rules, guidelines, or definitions of characteristics, to ensure that materials, products, processes and services are fit for their purpose.

The International Organization for Standardization (ISO) is a worldwide federation of national standards bodies from some 100 countries, one from each country, and is a non-governmental organization established in 1947. Many people will have noticed a seeming lack of correspondence between the official title when used in full, International Organization for Standardization, and the short form, ISO. Shouldn’t the acronym be “IOS”? Yes, if it were an acronym – which it is not. International standardization began in the electrotechnical field. The International Electrotechnical Commission (IEC) was created in 1906.


ISO/IEC 12207 was published on 1 August 1995 and was the first International Standard to provide a comprehensive set of life cycle processes, activities and tasks for software that is part of a larger system, and for standalone software products and services. The ISO/IEC 12207 Amendments in 2002 and 2004 added process purpose and outcomes to the International Standard and established a Process Reference Model in accordance with the requirements of ISO/IEC 15504-2.

This International Standard can be used in one or more of the following modes:

  1. By an organization
  2. By a project
  3. By an acquirer and a supplier
  4. By organizations and assessors


The purpose of this International Standard is to provide a defined set of processes to facilitate communication among acquirers, suppliers and other stakeholders in the life cycle of a software product. This International Standard is written for acquirers of systems and software products and services and for suppliers, developers, operators, maintainers, managers, quality assurance managers, and users of software products. Limitation of this International Standard does not detail the life cycle processes in terms of methods or procedures required to meet the requirements and outcomes of a process. It does not provide documentation for that ISO/IEC 15289 is being used.

Application of this International Standard:

This clause presents an overview of the software life cycle processes that can be employed to acquire, supply, develop, operate, maintain, and dispose of software products and services. The objective is to provide a road map for the users of this International Standard so that they can orient themselves in it and apply it judiciously.

  1. Relationship between systems and software:

    As we know a software is a part of a system which performs some functions in that system. It is a fundamental premise of this standard that software always exists in the context of a system, even if the system consists of only the processor upon which the software is executed.

    This standard has a strong relationship with ISO/IEC 15288:2008, System Life Cycle Processes, and may be used in conjunction with it. In many cases, the processes of this International Standard directly correspond to processes of ISO/IEC 15288 but with some specialization for software products and services.

  2. Organizations and parties:

    An organization is a body of persons with identified responsibilities and authorities organized for some specific purpose, such as a club, union, corporation, or society. When an organization, as a whole or a part, enters into a contract, it is a party. Parties may be from the same organization or from separate organizations. An individual is an example of an organization, if the individual is assigned responsibilities and authorities.



Categories of Life Cycle Processes:

This International Standard groups the activities that may be performed during the life cycle of a software system into seven process groups. Each of the life cycle processes within those groups is described in terms of its purpose and desired outcomes and lists activities and tasks which need to be performed to achieve those outcomes.

a) Agreement Processes — two processes

b) Organizational Project-Enabling Processes — five processes

c) Project Processes — seven processes

d) Technical Processes — eleven processes

e) Software Implementation Processes — seven processes

f) Software Support Processes — eight processes

g) Software Reuse Processes — three processes

The purposes and outcomes of the life cycle processes constitute a Process Reference Model.

Summary of Life Cycle Processes:

There are two major sub-divisions of process in this International Standard. Clause 6 provides a system context for dealing with a standalone software product or service or a software system. Clause 7 contains the software-specific processes for use in implementing a software product or service that is an element of a larger system.

[A] System Context Processes:

6.1 Agreement Processes:

These processes define the activities necessary to establish an agreement between two organizations.

6.1.1 Acquisition Process:

The purpose of acquisition process is to obtain the product or service which satisfies the needs needed by acquirer- stakeholder that acquires or procures a product or service from a supplier. The process begins with the identification of customer needs and ends with the acceptance of the product and/or service needed by the acquirer.

The acquirer begins the acquisition process by describing a concept or a need to acquire, develop, or enhance a system, software product or software service, by defining and analyzing system requirements, by preparing acquisition plan. The acquisition documentation should include, as appropriate:

a) System requirements.

b) Scope statement.

c) Instructions for bidders.

d) List of software products.

e) Terms and conditions.

f) Control of subcontracts.

g) Technical constraints (e.g., target environment).

6.1.2 Supply Process:

The purpose of the Supply Process is to provide a product or service to the acquirer that meets the agreed requirements. Outcomes from this process are identification of acquirer for a product, response to the request of acquirer, based on agreed requirements product is delivered.

6.2 Organizational Project-Enabling Processes:

The Organizational Project-Enabling Processes manage the organization’s capability to acquire and supply products or services through the initiation, support and control of projects.

6.2.1 Life Cycle Model Management Process:

The purpose of the Life Cycle Model Management Process is to define, maintain, and assure availability of policies, life cycle processes, life cycle models, and procedures for use by the organization with respect to the scope of this International Standard.

Here in this process which life cycle model is to be used, which policies are best suitable for a software, responsibility for life cycle management are defined.

6.2.2 Infrastructure Management Process:

The purpose of the Infrastructure Management Process is to provide the enabling infrastructure and services to projects to support organization and project objectives throughout the life cycle. The infrastructure elements may include hardware, software, methods, tools, techniques, standards, and facilities for development, operation, or maintenance

6.2.3 Project Portfolio Management Process:

The purpose of the Project Portfolio Management Process is to initiate and sustain necessary, sufficient and suitable projects in order to meet the strategic objectives of the organization. Resources and budgets for each project are identified and allocated in this process

6.2.4 Human Resource Management Process:

The purpose of the Human Resource Management Process is to provide the organization with necessary human resources and to maintain their competencies, consistent with business needs. Human should be skilled enough to perform software life cycle processes to achieve organization.

6.2.5 Quality Management Process:

The purpose of the Quality Management Process is to assure that products, services and implementations of life cycle processes meet organizational quality objectives and achieve customer satisfaction. The organization shall establish quality management policies, standards and procedures, quality management goals

6.3 Project Processes:

In this International Standard, the project has been chosen as the context for describing processes concerned with planning, assessment and control. The principles related to these processes can be applied in any area of an organization’s management. There are two categories of Project Processes. The Project Management Processes are used to plan, execute, assess and control the progress of a project. The Project Support Processes support specialized management objectives.

Project management includes these two processes:

6.3.1 Project Planning Process:

The purpose of the Project Planning Process is to produce and communicate effective and workable project plans.

6.3.2Project Assessment and Control Process:

The purpose of the Project Assessment and Control Process is to determine the status of the project and ensure that the project performs according to plans and schedules, and within projected budgets, and that it satisfies technical objectives.

Project Support Processes includes following processes:

6.3.3 Decision Management Process:

The purpose of the Decision Management Process is to select the most beneficial course of project action where alternatives exist. A decision-making strategy, alternative and preferred course of action is defined during this process.

6.3.4 Risk Management Process:

The purpose of the Risk Management Process is to identify, analyze, treat and monitor the risks continuously

6.3.5 Configuration Management Process:

The purpose of the Configuration Management Process is to establish and maintain the integrity of all identified outputs of a project or process and make them available to concerned parties.

6.3.6 Information Management Process:

The purpose of the Information Management Process is to provide relevant, timely, complete, valid and, if required, confidential information to designated parties during and, as appropriate, after the system life cycle.

6.3.7 Measurement Process:

The purpose of the Measurement Process is to collect, analyze, and report data relating to the products developed and processes implemented within the organizational unit, to support effective management of the processes, and to objectively demonstrate the quality of the products.

6.4 Technical Processes:

The Technical Processes are used to define the requirements for a system, to transform the requirements into an effective product, to permit consistent reproduction of the product where necessary, to use the product, to provide the required services, to sustain the provision of those services and to dispose of the product when it is retired from service

6.4.1 Stakeholder Requirements Definition Process:

The purpose of the Stakeholder Requirements Definition Process is to define the requirements for a system that can provide the services needed by users and other stakeholders in a defined environment.

6.4.2 System Requirements Analysis Process:

The purpose of System Requirements Analysis is to transform the defined stakeholder requirements into a set of desired system technical requirements that will guide the design of the system.

6.4.3 System Architectural Design Process:

The purpose of the System Architectural Design Process is to identify which system requirements should be allocated to which elements of the system.

6.4.4 Implementation Process:

The purpose of the Implementation Process is to realize a specified system element.

6.4.5 System Integration Process:

The purpose of the System Integration Process is to integrate the system elements (including software items, hardware items, manual operations, and other systems, as necessary) to produce a complete system that will satisfy the system design and the customers’ expectations expressed in the system requirements.

6.4.6 System Qualification Testing Process:

The purpose of the Systems Qualification Testing Process is to ensure that the implementation of each system requirement is tested for compliance and that the system is ready for delivery.

6.4.7 Software Installation Process:

The purpose of the Software Installation Process is to install the software product that meets the agreed requirements in the target environment.

6.4.8 Software Acceptance Support Process:

The purpose of the Software Acceptance Support Process is to assist the acquirer to achieve confidence that the product meets requirements.

6.4.9 Software Operation Process:

The purpose of the Software Operation Process is to operate the software product in its intended environment and to provide support to the customers of the software product.

6.4.10 Software Maintenance Process:

The purpose of the Software Maintenance Process is to provide cost-effective support to a delivered software product.

6.4.11 Software Disposal Process:

The purpose of the Software Disposal Process is to end the existence of a system’s software entity. This process destroys or stores system software elements and related products in a sound manner, in accordance with legislation, agreements, organizational constraints and stakeholder requirements. Where required, it maintains records that may be monitored.

[B] Software Specific Process:

6.5 Software Implementation Processes:

The Software Implementation Processes are used to produce a specified system element (software item) implemented in software. Those processes transform specified behaviour, interfaces and implementation constraints into implementation actions resulting in a system element that satisfies the requirements derived from the system requirements

6.5.1 Software Implementation Process:

The purpose of the Software Implementation Process is to produce a specified system element implemented as a software product or service.

6.5.2 Software Requirements Analysis Process:

The purpose of Software Requirements Analysis Process is to establish the requirements of the software elements of the system.

6.5.3 Software Architectural Design Process:

The purpose of the Software Architectural Design Process is to provide a design for the software that implement and can be verified against the requirements.

6.5.4 Software Detailed Design Process:

The purpose of the Software Detailed Design Process is to provide a design for the software that implements and can be verified against the requirements and the software architecture and is sufficiently detailed to permit coding and testing.

6.5.5 Software Construction Process:

The purpose of the Software Construction Process is to produce executable software units that properly reflect the software design.

6.5.6 Software Integration Process:

The purpose of the Software Integration Process is to combine the software units and software components, producing integrated software items, consistent with the software design, that demonstrate that the functional and non-functional software requirements are satisfied on an equivalent or complete operational platform.

6.5.7 Software Qualification Testing Process:

The purpose of the Software Qualification Testing Process is to confirm that the integrated software product meets its defined requirements.

6.6 Software Support Processes:

The Software Support Processes provide a specific focused set of activities for performing a specialized software process. A supporting process assists the Software Implementation Process as an integral part with a distinct purpose, contributing to the success and quality of the software project. There are eight of these processes:

6.6.1 Software Documentation Management Process:

The purpose of the Software Documentation Management Process is to develop and maintain the recorded software information produced by a process.

6.6.2 Software Configuration Management Process:

The purpose of the Software Configuration Management Process is to establish and maintain the integrity of the software items of a process or project and make them available to concerned parties.

6.6.3 Software Quality Assurance Process:

The purpose of the Software Quality Assurance Process is to provide assurance that work products and processes comply with predefined provisions and plans.

6.6.4 Software Verification Process:

The purpose of the Software Verification Process is to confirm that each software work product and/or service of a process or project properly reflects the specified requirements.

6.6.5 Software Validation Process:

The purpose of the Software Validation Process is to confirm that the requirements for a specific intended use of the software work product are fulfilled.

6.6.6 Software Review Process:

The purpose of the Software Review Process is to maintain a common understanding with the stakeholders of the progress against the objectives of the agreement and what should be done to help ensure development of a product that satisfies the stakeholders. Software reviews are at both project management and technical levels and are held throughout the life of the project.

6.6.7 Software Audit Process:

The purpose of the Software Audit Process is to independently determine compliance of selected products and processes with the requirements, plans and agreement, as appropriate.

6.6.8 Software Problem Resolution Process:

The purpose of the Software Problem Resolution Process is to ensure that all discovered problems are identified, analyzed, managed and controlled to resolution.

6.7 Software Reuse Processes:

The Software Reuse Process Group consists of three processes that support an organization’s ability to reuse software items across project boundaries. These processes are unique because, by their nature, they operate outside the bounds of any particular project.

6.7.1 Domain Engineering Process:

The purpose of the Domain Engineering Process is to develop and maintain domain models, domain architectures and assets for the domain.

6.7.2 Reuse Asset Management Process:

The purpose of the Reuse Asset Management Process is to manage the life of reusable assets from conception to retirement.

6.7.3 Reuse Program Management Process:

The purpose of the Reuse Program Management Process is to plan, establish, manage, control, and monitor an organization’s reuse program and to systematically exploit reuse opportunities.

–>Current Existence of ISO 12207:

Software Engineering Process Technology (SEPT):

It is a firm specializing in meeting the software process standards information needs of the professional community, particularly concerning ISO/IEC 12207. SEPT was found in 1992 by stan magee CCP, the principle and president.[2]


[1] ISO/IEC 12207:2008(E) – IEEE std 12207-2008 paper


Benefits of FOSS

• Quality : In general, open source software gets closest to what users want because those users can have a hand in making it so. It’s not a matter of the vendor giving users what it thinks they want–users and developers make what they want
• Customizability: Since the code is open, it’s simply a matter of modifying it to add the functionality they want
• Freedom: users are in control to make their own decisions and to do what they want with the software.
• Flexibility. Open source software, is typically much less resource-intensive, meaning that you can run it well even on older hardware. It’s up to you–not some vendor–to decide when it’s time to upgrade.
• Interoperability: Open source software is much better at adhering to open standards than proprietary software is. If you value interoperability with other businesses, computers and users, and don’t want to be limited by proprietary data formats, open source software is definitely the way to go.
• Auditability: With closed source software, you have nothing but the vendor’s claims telling you that they’re keeping the software secure and adhering to standards, for example. It’s basically a leap of faith. The visibility of the code behind open source software, however, means you can see for yourself and be confident.
• Support Options :Open source software is generally free, and so is a world of support through the vibrant communities surrounding each piece of software. Most every Linux distribution, for instance, has an online community with excellent documentation, forums, mailing lists, forges, wikis, newsgroups and even live support chat.

For businesses that want extra assurance, there are now paid support options on most open source packages at prices that still fall far below what most proprietary vendors will charge. Providers of commercial support for open source software tend to be more responsive, too, since support is where their revenue is focused
• Cost :Between the purchase price of the software itself, the exorbitant cost of mandatory virus protection, support charges, ongoing upgrade expenses and the costs associated with being locked in, proprietary software takes more out of your business than you probably even realize

People Capability Maturity Model

People Capability Maturity Model (P CMM) was first published in 1995. It is a guideline following which an organization can improve is workforce. Here by workforce we mean knowledge, skill and process ability for performing organization business activity, since the nature of software developed by an organization depend on the people those who are all involved in the development of that software so it’s necessary for the organization to follow some guideline, by following which the workforce of an organization can be improved
P CMM consist of 5 level, where each level define certain change in the workforce
• The first level or initial level: In this level there is no fixed methodology to perform the work, the methodology changes with the project. The work is generally done without the good knowledge, how to complete the work, manager doesn’t have any reliable way of estimating the effort required to complete a project.
• The second level is called Managed level: In this level the manager is appointed whose work is to perform certain basic people management practice like staffing and managing performance. This ensure that the people are able to meet there commitment. This level involves the training of the employee to improve their skill.
• The third level or defined level: this level involves the identification and development of knowledge, skill and process abilities that can help the organization to achieve its business goal.
• The fourth level or predictable level: this involves
 Competency Integration: this involves the interaction with the individual from different competency communities. This help in to identify the problem among the product, service or the dependencies and to correct is as early as possible
 Empowered Work Group: The empowered involves the training of its member in the skill and process required for completing the work
 Quantitative performance management: It developed for identifying, measuring and analyzing the performance of the competency based process. The performance data are collected and analyze according to the strategy.
 Mentoring: the purpose of this is to improve the capability of workforce by transferring the knowledge of other individual.

• The fifth level or optimizing level: in this level everyone focus on how they can improve capability and