Author Archives: tanksmita

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


The Open Source Software

What is Open Source Software (OSS)?

Open source software is computer software that has a source code available to the general public for use as is or with modifications. This software typically does not require a license fee. Open source software is unique in that it is always released under a license that allows users to access, modify and redistribute the source code. Source code is a specialized language that allows software developers to create and modify computer programs. If you do not have legal access to the source code, then the program cannot be changed or moved to a different kind of computer.

There are open source software applications for a variety of different uses such as office automation, web design, content management, operating systems, and communications. The key fact that makes open source software (OSS) different from proprietary software is its license. As copyright material, software is almost always licensed. The license indicates how the software may be used. OSS is unique in that it is always released under a license that has been certified to meet the criteria of the Open Source Definition. These criteria include the right to:

• Redistribute the software without restriction;

• Access the source code;

• Modify the source code; and

•Distribute the modified version of the software.

Desirable software attributes

There is widespread debate over the relative merits of proprietary software and OSS. However, it is difficult to make general comparisons; most analysts say comparisons should be made only on a case-by-case basis. It is generally agreed that whether software is open source or proprietary, the following attributes are of key importance:

  • Reliability
  • Quality
  • Security
  • Flexibility
  • project management
  • open standards
  • switching costs
  • total cost of ownership (TCO)
  • user-friendliness

Use of open source software

The private sector

There is increasing awareness and uptake of OSS within the private sector, with OSS and proprietary software becoming increasingly interwoven. Major corporations such as IBM believe it enables them to make use of a worldwide community of developers to improve their products and services. Some industry commentators suggest that OSS will lead to a more competitive software industry. Currently over 67% of web-servers run open source software called Apache6. The majority of websites and email systems run on OSS. Worldwide, around 30% of infrastructural computers run GNU/Linux, an open source operating system. However, use of OSS on the desktop is more limited: over 96% of desktop computers still use Microsoft Windows. OSS has inspired new portable device projects, such as the ‘Simputer’. This is a small, inexpensive, handheld computer, intended to bring computing power to India and other emerging economies.

Open source software in government

Governments’ interest in OSS is increasing, due to their reliance on sophisticated software. The UK Office of Government Commerce released a series of case studies in October 2004 outlining how OSS has been used in the public sector .However, UK parliamentary responses to questions on the use of OSS in government show that uptake is still limited7. The Office of the Deputy Prime Minister is funding the ‘Open Source Academy’ project. This is intended to overcome barriers to uptake of OSS in local government such as lack of information, skills, confidence and lack of suitable products.

 Legal issues


Software is protected using the copyright system. Relying on the same protection as on books, music or film, the buyer of software is licensed the use of a copy of the product. Proprietary software is normally distributed under an ‘all rights reserved’ license where the rights to exploit the software are held by the copyright owner. Open source relies on copyright law to give legal backing to the licenses under which it is released.

Software patents

Whereas copyright protects software code from being copied, patents can be used to prevent the innovative solution or effects of the software from being copied (what it does and how it does it). Government grants the patent holder rights, in return for sharing the information on how the technical result was achieved. The extent to which software should be patentable is controversial. A key issue is whether the software has a ‘technical effect’ (for example controls the function of a robot arm) or is used for a ‘business process’ (no technical effect). In the US, it is possible to patent software used for business processes. Amazon, for example, has patented the ‘1-click’ process, which gives a monopoly on ‘clicking once’ using a mouse to buy a product from a website. As all websites are built on the idea of clicking links, patent experts have argued that these broad ‘business process’ patents can be destructive by granting a monopoly on standard processes. This affects open source developers because, when writing a piece of software, they may not realize that the software technique is patented. Currently, ‘business processes’ are not patentable in the EU. There is widespread debate over the ‘EU Computer Implemented Inventions Directive’, awaiting its second reading in the European Parliament. Under this directive, software will be patentable only if it has a technical effect. However, there are concerns that this may lead to widespread granting of patents, because it is hard to make the distinction between whether software is used for a business process or for a technical effect. Developers and users of OSS, and some small and medium sized enterprises (SMEs), have voiced concerns over the potential negative impact of the directive on the competitiveness of the software industry. Proponents say software patenting is already possible in the EU; the directive will not allow patents in new areas. The UK Patent Office says the directive aims to ‘clarify the situation’ and to ‘prevent a drift towards the more liberal regime of the US. Moreover, it is pointed out that business processes cannot be patented under the directive. Proponents (including some SMEs) also argue that patent protection is needed to encourage innovations and investment in research and development. 

Example of OSS are Mozilla, firebox, apache, Ubuntu, Open Office, etc.

Software Reusability

Software reuse can be defined as all activity that has using previously written software ( in the form of specification, design, code, or related texts) as its goal. Reuse is a matching between new and old contexts. Whenever matching succeeds partially or completely,reuse is possible.

Software reusability is the quality of a piece of software that enables it to be used again in another application, be it partial, modified or complete. In other words, software reusability is a measure of the ease with which previously acquired concepts and objects can be used in new contexts Software reuse is not only about the re-application of a software component in another context or environment, it is also about the reuse of knowledge. This knowledge can include mathematical, engineering, and any other competencies that were needed for the construction of the reused software.

Two basic reasons for software reuse are:

Increased productivity. If the emphasis is on production speed and minimizing cost/effort, then being able to plug-in a collection of ready-made parts will be of great help. There is a reduction in the need for software design, implementation, testing, and documentation.

• Increased software quality. If the emphasis is on quality, then it will be advantageous if one has access to well-designed, well-tested, and well-documented code that has a proven correct and well-understood behaviour.

In order to increase productivity and quality, a programmer or (virtual) organization ideally constructs a piece of software once, verifies that it functions correctly and efficiently,  and then reuses it as many times as possible in a variety of applications. In an environment where large-scale (international) software projects are carried out and multiple development projects exist at the same time, careful collaboration is needed to consider the possibilities for reuse.

Nevertheless, despite the above considerations, reuse of software happens all the time. Especially if one considers that writing programs in a high-level language involves reusing language constructs and definitions, standard libraries, low-level program generators (compilers), the operating system, etc. Appropriate questions are therefore: What forms of reuse are there? What is it that we are reusing? How can we promote reuse in all its forms? Reusable software is software (specification, design, code, etc.) made with reuse in mind. Planned reusable software may need upfront significantly extra investments and time to create while only at a later stage benefits can be reaped.

Development for reuse

Reuse impacts the software development process in two distinct ways:

1. Development with reuse.

Software design takes place in an environment where a significant number of potentially reusable components are available. It is an existing form of software reuse practice. An example of this kind is UNIX environment. The objective is to produce a software product. Reusable components are produced as a ‘side-effect’ of normal systems development. We have to put more effort to reuse these components because they are not made for reuse. During the past years of active research on reuse, most emphasis has been given to development with reuse. As a result, there is no large body of components, except in specific domains such as mathematical libraries, which have been generalized for reuse.

2. Development for reuse

An objective of the design process is to produce components which are potentially reusable. They should be easy to reuse because they have been designed for reuse. These components form building blocks for future development (over the long term) and are applicable for various situations and perhaps across application domains. They are generalized for reuse which means improved benefits such as quality, reliability, faster production, lower cost and greater pay-off over long-term reuse. But, extra cost and effort are involved to create potentially reusable components. Of course, these different modes of design are not mutually incompatible and design of components with reuse may result in new, potentially reusable components.

In development with reuse, the principal objective is to produce a software product. Reuse is desirable but there need be no resources expended in creating new reusable components. Development for reuse implies expending resources specifically to increase the reusability of components. In many cases, this process might follow development with reuse where components generated during normal system development are made more reusable by generalization and improvement.

In the development for reuse process, as shown in Figure (1), there are a number of stages to be followed which start from identifying an application domain, identify & classify reusable abstractions, language-oriented reuse, domain-oriented reuse, design components, assessment for reuse, improvement for reuse, and deliver potentially reusable components.

process of developement reuse

This development for reuse process falls into a number of stages.

1. Identify domain. Domain analysis has been identified as essential for effective reuse. The first step is to identify a specific application domain and define its boundary.

2. Identify and classify (frequently) reusable abstractions. To identify potentially reusable components, the reuse assessor must know what the important domain abstractions are and how frequently these abstractions are used in systems developed for that domain. There is not much point in devoting a lot of effort in producing a reusable domain abstraction if that abstraction is rarely used. Domain classification helps to identify effective reusable abstractions.

3. Identify design/ programming language constructs that support reuse. Selecting an appropriate language is an important part of development for reuse. We should be able to express our reuse guidelines effectively using language mechanisms.

4. Study and formulate language reuse guidelines (rules concerning language support for reuse). This emphasizes the effective use of language features for reuse. This process includes studies of existing techniques and appropriate modifications to them.

5. Study and formulate domain reuse guidelines (rules concerning the domain characteristics for reuse). This emphasizes the reusable domain abstractions that are identified in the application domain. Guidelines should not just be general advice but should be specific and verifiable for creating potentially reusable components. Design/ redesign components based on these guidelines.

6. The next step, known as reuse assessment is a process of assessing components based on the number of guidelines satisfied against the total number of guidelines that are applicable, and then produce an assessment report. This is where we need to automate this process. The outcome of this process is to make sure that the components designed for reuse satisfy some of the key characteristics.

7. The final step, known as reuse improvement is a process of modifying and improving these components for reuse by adding attributes of an abstraction for reuse. This process is based on the assessment report produced during the previous step. The reuse improver must know what attributes of an abstraction must be generalized to make it reusable. Again, an automatic reuse improvement is essential. Finally, produce potentially reusable components.

8. Automate, where possible, these two processes of assessing and improving components for reuse.

It is unrealistic to expect reusable components to be produced as a side-effect of normal systems development. The reasons for this are partly technical and partly managerial. Technically, the notion of what constitutes a reusable component is not well-understood and engineers working on a project cannot be expected to wrestle with this problem while developing to a given set of requirements. Furthermore, the requirements for a particular project may be such that components have to be very specific in order to satisfy them.

Furthermore, a project manager’s principal responsibility is to deliver the required software system on time and within budget. Creating reusable components requires additional effort to be expended which is of no immediate benefit to that project. The project manager cannot reasonably be expected to give reusable component production a high priority.

Thus, we believe that the normal mode of production of reusable components should be to take existing components and to add reusability to them. This extra cost for reuse must be an organizational rather than a project responsibility. Reusability is an attribute which can be added at any level from the specification through to the implementation. In our work, we are principally concerned with the reusability of compilable components. However, we believe that the approach discussed is equally applicable to formal specifications and software designs.

Reusability is a complex component attribute and it is dependent on the effective use of the programming language used to implement the component and application domain knowledge. Application domain knowledge allows the abstractions in a domain to be identified and encoded as a set of reusable components. The objective of our work is to use language and domain knowledge to assess, with automatic assistance, the reusability of a component and to suggest to the software engineer how that component may be made more reusable.

Finally we can say that re-usable components can be produced and re-engineered in a large scale if we can formulate objectives, plan according to some considerations and apply them systematically. Domain analysis can play a major role in supporting development for reuse in the near future.





ACM Code Of Ethics and Professional Conduct

When you talk about the term ’ethics’ in generalized fashion, it’s simple meaning is principles or moral beliefs. So Code of Ethics is the principles or beliefs but which can differ from individual to individual. Even then certain ethics are applicable to every person, organization, state and nation and which have to be strictly followed to maintain the balance of right and wrong in the society.

What is the need for code of ethics?

These principles or moral values have to be introduced as the avarice of human nature has no limitations. Money is the most tempting Lollypop which attracts everyone. In the pursuit of green pastures all the moral values and decency level are broken. Moreover expectations from life are always on the high. These too are instrumental in making people bend the general ethics.  And hence a check in the form of Code of Ethics or moral rules in an organization or for a profession is essential.

Although, the criminal minds still find courage to go against the rules, all the practices and working in the world are going on mostly peacefully owing to these small sets of ethical principles.

There is a long tradition of binding members of professions like medicine and law to a code of professional conduct. Our own profession is in comparison to such classical professions extremely young and immature, and the basic conditions for working as a computer professional are somewhat different from those of doctors and lawyers. Despite these differences, there have been several attempts to establish codes of ethics and professional conduct within computing.

In the United States, ACM has had its official code of professional conduct since 1972; IEEE has adopted a code of ethics; and the Data Processing Management Association also has a code of ethics. The British Computer society agreed upon codes of practice and conduct in 1983, while the Australian Computer Society adopted a code of ethics in 1987. ACM’s recently adopted Code of Ethics and Professional Conduct, quoted below from Anderson et al. (1993) are as following:

  • It has four sections …

– Section 1: General moral imperatives.

-Section 2: More specific professional responsibilities.

-Section 3: Organizational Leadership Imperatives.

-Section 4: Compilance with the code

1.     General moral imperatives:

As an ACM member I will….

1.1  Contribute to society and human well-being.

  •   Obligation to protect fundamental human rights and to respect the diversity of all cultures.
  •   Minimize negative consequences of computing systems
  •   Must attempt to ensure that the products of their efforts will be used in socially responsible ways
  •   Avoid harmful effects to health and welfare.
  •   Avoid potential damage to the local or global environment.

1.2  Avoid harm to others.

  • Harm means injury or negative consequences
  • Example: loss of information, property, property/environmental damage, etc.  Strive to include features which discourage abuse in the investment  world.
  • Design systems so that time & effort is not wasted on overhead items such as the time it takes to purge viruses.
  • Sometimes well intended actions may lead to harmful results.

1.3  Be honest and trustworthy.

  • Honesty is an essential component of trust. Without trust an organization cannot function effectively.
  • Do not make deceptive or false claims about the system.
  • Full discloser limitation and problems with the system!… no sins of omission!
  • Sometimes following this one could get you not promoted or even fired , but you must be able to live with yourself.
  • A computer professional has a duty to be honest about his or her own qualifications, and about any circumstances that might lead to conflicts of interest.

1.4  Be fair and take action not to discriminate.

  • No discrimination based on race, sex, religion, disability, etc.
  • Although this seems obvious, violations may be inadvertent, and there may be tradeoffs with cost and performance aspects of the system.
  • Inequities between different groups of people may result from the use or misuse of information and technology.

1.5  Honor property rights including copyrights and patent.

  • Violation of copyrights, patents, trade secrets and the terms of license agreements is prohibited by law in most circumstances. Even when software is not so protected, such violations are contrary to professional behavior. Copies of software should be made only with proper authorization. Unauthorized duplication of materials must not be condoned.
  • Also protect intellectual property and “secrets” owned by your company even if you came up with them and they are not patented or copyrighted as yet – your ideas could end up in a competitor’s system.

1.6  Give proper credit for intellectual property.

  • Computing professionals are obligated to protect the integrity of intellectual property.
  • One must not take credit for other’s ideas or work, even in cases where the work has not been explicitly protected by copyright, patent, etc.    

1.7  Respect the privacy of others.

  • Because of the awesome power computers have in gathering, storing, and processing data – including personal data, this principle has immense social consequences.
  • Professionals must ensure:
  1. integrity and accuracy of personal data
  2. take precautions to prevent unauthorized access – even accidental disclosures
  3. Allow individuals whose information is stored to access and check records or correctness.
  • Example: Someone was once issued a credit card from a local bank with another person’s account number encoded on the magnetic strip.  A technical slip up, but it made that guy nervous!

1.8  Honor confidentiality.

  • A client may reveal confidential information to you that you may need in designing some aspect of a system
  • A bit of “lawyer/client”, “doctor/patient”, or “confessor/penitent” constraints are needed.
  • The only exceptions may be when something like a court order is issued.

 2.     More Specific Professional Responsibilities:

               As an ACM computing professional I will ….

2.1  Strive to achieve the highest quality, effectiveness and dignity in both the process and products of professional work.

  • Excellence is perhaps the most important obligation of a professional. The computing professional must strive to achieve quality and to be cognizant of the serious negative consequences that may result from poor quality in a system.

2.2  Acquire and maintain professional competence.

  • Excellence depends on individuals who take responsibility for acquiring and maintaining professional competence.
  • Upgrading technical knowledge and competence can be achieved in several ways:doing independent study; attending seminars, conferences, or courses; and being involved in professional organizations.

2.3 Know and respect existing laws pertaining to professional work.

  • ACM members must obey existing local, state,province, national, and international laws unless there is a compelling ethical basis not to do so. Policies and procedures of the organizations in which one participates must also be obeyed.
  • If one decides to violate a law or rule because it is viewed as unethical, or for any other reason, one must fully accept responsibility for one’s actions and for the consequences.

2.4 Accept and provide appropriate professional review.

  • Quality professional work, especially in the computing profession, depends on professional reviewing and critiquing. Whenever appropriate, individual members should seek and utilize peer review as well as provide critical review of the work of others.

2.5  Give comprehensive and thorough evaluations of computer systems and their impacts, including analysis of possible risks.

  • Computer professionals must strive to be perceptive, thorough, and objective when evaluating, recommending, and presenting system descriptions and alternatives.
  • Computer professionals are in a position of special trust, and therefore have a special responsibility to provide objective, credible evaluations to employers, clients, users, and the public. When providing evaluations the professional must also identify any relevant conflicts of interest, as stated in imperative 1.3.

2.6  Honor contracts, agreements, and assigned responsibilities.

  • Honoring one’s commitments is a matter of integrity and honesty. When one contracts for work with another party, one has an obligation to keep that party properly informed about progress toward completing that work.
  • A computing professional has a responsibility to request a change in any assignment that he or she feels cannot be completed as defined.
  • The major underlying principle here is the obligation to accept personal accountability for professional work.
  • However, performing assignments “against one’s own judgment” does not relieve the professional of responsibility for any negative consequences.

2.7  Improve public understanding of computing and its consequences.

  • If professionals are having technical knowledge then they have responsibility to share with public by encouraging understanding of computations.
  • This imperative implies an obligation to counter any false views related to computing.

2.8  Access computing and communication resources only when authorized to do so.

  • Trespassing and unauthorized use of a computer or communication system is addressed by this imperative.
  • Individuals and organizations have the right to restrict access to their systems so long as they do not violate the discrimination principle (see 1.4)

 3.     Organizational Leadership Imperatives:

                  As an ACM member and an organizational leader, I will ….

3.1  Articulate social responsibilities of members of an organizational unit and encourage full acceptance of those responsibilities.

  • Because organizations of all kinds have impacts on the public, they must accept responsibilities to society.
  • Organizational leaders must encourage full participation in meeting social responsibilities as well as quality performance.

3.2  Manage personnel and resources to design and build information systems that enhance the quality of working life.

  • Organizational leaders are responsible for ensuring that computer systems enhance, not degrade, the quality of working life. When implementing a computer system, organizations must consider the personal and professional development, physical safety, and human dignity of all workers.

3.3  Acknowledge and support proper and authorized uses of an organization’s computing and communication resources.

  • Because computer systems can become tools to harm as well as to benefit an organization, the leadership has the responsibility to clearly define appropriate and inappropriate uses of organizational computing resources

3.4  Ensure that users and those who will be affected by a system have their needs clearly articulated during the assessment and design of requirements; later the system must be validated to meet requirements.

  • Current system users, potential users and other persons whose lives may be affected by a system must have their needs assessed and incorporated in the statement of requirements.
  • System validation should ensure compliance with those requirements.

3.5  Articulate and support policies that protect the dignity of users and others affected by a computing system.

  • Designing or implementing systems that deliberately or inadvertently demean individuals or groups is ethically unacceptable.
  • Computer professionals who are in decision making positions should verify that systems are designed and implemented to protect personal privacy and enhance personal dignity.

3.6  Create opportunities for members of the organization to learn the principles and limitations of computer systems.

  • This complements the imperative on public understanding (2.7). Educational opportunities are essential to facilitate optimal participation of all organizational members.
  • Opportunities must be available to all members to help them improve their knowledge and skills in computing, including courses that familiarize them with the consequences and limitations of particular types of systems.

4.     Compilance with code:

                As an ACM member I will ….

4.1 Uphold and promote the principles of this Code.

  • The future of the computing profession depends on both technical and ethical excellence. Not only is it important for ACM computing professionals to adhere to the principles expressed in this Code, each member should encourage and support adherence by other members.

4.2 Treat violations of this code as inconsistent with membership in the ACM.

  • Adherence of professionals to a code of ethics is largely a voluntary matter. However, if a member does not follow this code by engaging in gross misconduct, membership in ACM may be terminated.

                      According to Anderson et al. (1993) the 1972 ACM code was established together with a review board as instruments to deter ACM members from unethical behavior. The aim was to introduce means to regulate membership and thereby convince the public that the profession deserved to be self regulating. The code emphasized possible violations and threatened sanctions for such violations.


Programming Paradigms: Imperative Programming Paradigm

Great debates ensue about the efficiency of the array declaration in C++ versus the array declaration in JAVA or the value of interpreting versus compiling a program. In truth, however, the array declarations and translation issues have very little to do with distinguishing between the languages. There are often minor syntactic variations that simply reflect the wishes of language designers, which have little concrete effect upon the programs written in those languages. We need to look deeper to understand how languages are constructed???

A Programming Paradigm is a fundamental style of computer programming regarding how solutions to problems are to be formulated in a programming language. It gives some basic idea for performing programming computation. There are many programming paradigms as following:

  • The imperative paradigm
  • The functional paradigm
  • The logical paradigm
  • The Object Oriented paradigm
  • The visual paradigm
  • The applicative paradigm
  • The multi-programming paradigm and many more.

Imperative Programming Paradigm:-

Imperative programming paradigm describes computation in terms of statements that changes a program state. It describes HOW to compute a solution. The basic concept is the machine state, the set of all values for all memory locations in the computer. The basic unit of abstraction is PROCEDURE, whose basic structure is sequence of statements that are executed in succession, abstracting the way that the program counter is incremented so as to proceed through series of machine instructions residing in sequential memory cells. Thus, the execution of imperative program can be viewed as execution of sequence of statements:

Statement 1;

Statement 2;




Statement n;

The sequential flow of an execution can be modified by conditional and looping statements which abstract the conditional and unconditional branch instructions found in the underlying machine instruction set. Variables play a key role & serve as abstractions of hardware memory cells. Typically, a given variable may assume many different values of the course of execution of a program, just as a hardware memory cell has many different values. Thus, the assignment statement is a very important and frequently used statement

Imperative Language Characteristics:

  • Variable and storage
  • Commands:
    • Procedure calls
    • Assignments
    • Sequential commands
    • Collateral commands
    • Conditional commands
    • Iterative commands
    • Block commands

Examples of Imperative Languages:

  • FORTRAN The IBM Mathematical FORmula TRANslating system.
  • ALGOL 60 ALGOrithmic Language 1960.
  • COBOL COmmon Business Oriented Language.
  • Pascal, C language, BASIC, Ada and many more.

Example Program: Finding a Factorial

Public int factorial (int n)


int ans=1;

for( int i=2; i<=n;  i++)


ans= ans * i;


return ans;


As shown in the program, it gives step by step process to find the solution for the problem i.e. finding factorial for any given number. Imperative programming language is also called as Procedural language.


LAB EVALUATION-3–Online-book-store



The C# language specification does not define a coding standard. However, the guidelines in this topic are used by Microsoft to develop samples and documentation.

Naming convention:

If you know that a namespace is imported by default in a project, you do not have to fully qualify the names from that namespace.


Commenting convention:

// The following declaration creates a query. It does not run 

// the query.

C# follows multi-programming paradigm