Trends in Mobile Application Development - Part 1

Over the past few years, we have observed that the relatively stable market has evolved in three distinct directions. First, there seems to be a strong trend towards portal centralization. Second, there is increased number of actors providing open source technology. Third, platforms are moving towards a higher level of integration. It is important for custom application development companies to be aware of the trends in mobile application development. Following explains the same :

1. Towards portal centralization

Prior to the introduction of Apple’s AppStore and more recently Google’s Android Market, platforms did not have a central portal. With the introduction of its AppStore, Apple has proven that a mobile application market should not be underestimated and can represent an important revenue stream. According to CEO Steve Jobs, the AppStore has generated revenue of a million dollars a day in its first month of existence. There are currently 15000 applications on the portal, which have been downloaded a total of 500 million times. Note that these figures grew by 50% in the last month. Following Apple’s lead; traditional platforms like Nokia, RIM and Microsoft seem to be moving in this direction. Nokia is pushing its OVI portal and RIM has developed its own Application Center. Microsoft is also planning to launch its own version of the AppStore called Sky Market with the next version of Windows Mobile (WM7)

2. Towards technological openness

Among the major mobile platforms, LiMo used to be the only player in the open source field. Nokia has moved in this direction after acquiring Symbian OS. Google has also followed this trend. The transition phase from a closed to an open architecture will be critical for the future success of the platform. The shift, depicted in Figure 4, of this major player towards openness means that from a situation with mostly closed systems, we have moved to a situation with a small majority of devices running an open source system. Nevertheless, this shift does not indicate that other platforms will follow. Among the closed platforms, RIM is probably the only one that might go open source, since Microsoft and Apple are strong advocates of proprietary software. So far, it is still hard to evaluate what impact open-source software might have on the current mobile application developments. The successful model that Apple established does not suffer from the proprietary software clauses. The other platforms hope that the open-source option could help them to better compete in the platform war.

3. Towards full integration

Another trend is the emergence of more integrated platforms. Before the introduction of Apple’s platform, there was no fully integrated mobile platform. Moreover, there was no platform with portal integration before the introduction of Google’s platform. Symbian OS is an example of the trend towards integration since it started as a platform with no integration, before it was integrated by Nokia to become a device integrated platform and finally by launching OVI, it became fully integrated. RIM is also expected to soon become fully integrated with the introduction of its Application Center. Furthermore, with Microsoft moving towards portal integration there will be no major platform left without integration. Some leading software application development companies have also hinted that an intermediary could play an integrating role in the mobile development industry. The more surprising observation is the fact that mainly phone manufacturer companies and software development companies have played this integration role and not so much MNOs as was the intuition of most of these scholars.

Author Signature: Shreyans Agrawal (ifour.shreyans.agrawal@gmail.com)

Empowering People in Safety - Part 2

Principle 4.  Focus on Positive Consequences to Motivate Behavior. 

Control by negative consequences reduces perceptions of personal freedom and responsibility. Think about it.  Do you feel freer or empowered when you are working to avoid an unpleasant consequence or working to achieve a pleasant consequence? Unfortunately, the common metric used to rank companies on their safety performance is “total recordable injury rate” (or an analogous count of losses) which puts people in a reactive mindset of “avoiding failure” rather than “achieving success.” PBS provides proactive measures employees can achieve in order to prevent occupational injury. These days, Software development companies are focusing on People-Based Safety (PBS) as well.

We can often intervene to increase people’s perceptions that they are working to achieve success rather than working to avoid failure.  Even our verbal behavior directed toward another person, perhaps as a statement of genuine approval or appreciation for a task well done, can influence motivation in ways that increase perceptions of personal freedom and empowerment.  Of course, we can’t be sure our intervention will have the effect we intended unless we measure the impact of our intervention procedures.  Hence, the next basic premise of PBS. 

Principle 5.  Apply the Scientific Method to Improve Intervention. 

People’s actions can be objectively observed and measured before and after an intervention process is implemented.  This application of the scientific method provides critical feedback upon which to build improvement.   The acronym “DO IT” says it all:  D = Define the target action to increase or decrease; O = Observe the target action during a pre-intervention baseline period to identify natural environmental and interpersonal factors influencing it (see Principle 1), and to set improvement goals; I = Intervene to change the target action in desired directions; and T = Test the impact of the intervention procedure by continuing to observe and record the target action during and after the intervention program. 

The systematic evaluation of a number of DO IT processes can lead to a body of knowledge worthy of integration into a theory.  This is reflected in the next principle. 

Principle 6.  Use Theory to Integrate Information. 

After applying the DO IT process a number of times, you will see distinct consistencies. Certain intervention techniques will work better in some situations than others, by some individuals than others, or with some work practices than others.  You should summarize relationships between intervention impact and specific interpersonal or contextual characteristics.  The outcome will be a research-based theory of what is most cost-effective under given circumstances.  By doing this you are using theory to integrate information gained from systematic behavioral observation.   

Principle 7.  Consider the Internal Feelings and Attitudes of Others. 

Feelings and attitudes are influenced by the type of intervention procedure implemented, and such relationships require careful consideration by those who develop and deliver the intervention.  This is the essence of empathic leadership taught by PBS.   

The rationale for using more positive than negative consequences to motivate behavior (Principle 4) is based on the different feeling states resulting from using positive versus negative consequences to motivate behavior. Likewise, the way an intervention process is introduced and delivered can increase or decrease perceptions of empowerment, build or destroy interpersonal trust, and facilitate or inhibit an interdependent teamwork. 

Conclusion:

The PBS principles reviewed here provide a perspective that improves how people view injury prevention and talk about this challenge to themselves and to others.  Besides providing a paradigm that improves the quality and increases the quantity of safety conversations, PBS provides specific tools and methods, which software development companies are using extensively, for increasing safe behaviors, decreasing at-risk behaviors, and motivating participation in safety-related activities.   

Author Signature: Shreyans Agrawal (ifour.shreyans.agrawal@gmail.com)

Empowering People in Safety - Part 1

Introduction

Behavior modification… safety management…. attitude adjustment… behavior based safety… culture change… cognitive alignment… person-based safety… human engineering… social influence.  All these terms used to address the human dynamics of injury prevention.  Each of these can be linked to a set of principles, procedures, or a consultant’s service which defines a particular approach to managing the human side of occupational safety. Software development companies in India are implementing these set of principles in order to manage the human side of occupational safety.  

 All of these terms, and most of the accompanying materials, are insufficient.  They are either too narrow and restricting, or too broad and nondirective.  Some focus entirely on behavior change, while others attempt to target vague and unobservable aspects of other people, like attitudes and thoughts.  Still others have the grand notion of directly targeting culture change. 

  

 All of these approaches are well-intentioned and none are entirely wrong.  The human dynamics of an organization include behaviors, attitudes, cognitions, and the context (or culture) in which these aspects of people occur.  However, some of these approaches are too equivocal or ambiguous to be practical, while others may be practical but are not sufficiently comprehensive. 

Systematic evaluations of our implementations have enabled successive refinements of procedures, as well as the discovery of guidelines for increasing effectiveness and the long-term impact of our interventions.  We also developed research based and practical support materials for the behavior-change and culture-enrichment process. 

Today we call this approach “People-Based Safety” (PBS).  It strategically integrates the best of behavior-based and person-based safety in order to enrich the culture in which people work, thereby improving job satisfaction, work quality and production, interpersonal relationships, and occupational safety and health.   

 This article is the first of a five-part series in which I explain the essential principles and procedures of PBS.  Here are the seven underlying principles of PBS.   

Seven Basics of People-Based Safety 

Principle 1: Start with Observable Behavior. 

Like behavior-based safety, PBS focuses on what people do, analyzes why they do it, and then applies a research-supported intervention strategy to improve what people do.  The improvement of others results from acting people into thinking differently rather than targeting internal awareness or attitudes so as to think people into acting differently.   However, unlike behavior-based safety, PBS considers that people can observe their own thoughts and attitudes.  Thus, people can think themselves into safer actions.  In other words, self-management requires self-dialogue or thinking as well as self-directed behavior.  

Principle 2.  Look for External and Internal Factors to Improve Behavior. 

We do what we do because of factors in both our external and internal worlds.  While behavior-based safety deals with only external factors, PBS teaches people how to address their internal thoughts, perceptions, and attitudes related to injury prevention.  A behavioral analysis of work practices can pinpoint many external factors that encourage at-risk behavior and hinder safe behavior.  But, it’s also possible for individuals to conduct a self-evaluation of their own self-talk and selective perception regarding safety related behavior, and choose to make appropriate adjustments. Safety is of utmost importance for all the software development companies and hence they attempt to identify external and internal factors to improve behavior.

Principle 3.  Direct with Activators and Motivate with Consequences. 

Activators (or signals preceding behavior) are only as powerful as the consequences supporting the behavior.  In other words, activators tell us what to do in order to receive a pleasant consequence or avoid an unpleasant consequence.  This reflects the ABC model, with “A” for activator, “B” for behavior, and “C” for consequence.  This principle is used to design interventions for improving behavior at individual, group, and organizational levels. 

Author Signature: Shreyans Agrawal (ifour.shreyans.agrawal@gmail.com)

Moving from ISO/IEC 27001:2005 to ISO/IEC 27001:2013 - Part 2

Clause 4: Context of the organization 

This is a new clause that in part addresses the depreciated concept of preventive action and in part establishes the context for the ISMS. It meets these objectives by drawing together relevant external and internal issues (i.e. those that affect the organization’s ability to achieve the intended outcome(s) of its ISMS) with the requirements of interested parties to determine the scope of the ISMS. 

It should be noted that the term ‘issue’ covers not only problems, which would have been the subject of preventive action in the previous standard, but also important topics for the ISMS to address, such as any market assurance and governance goals that the organization might set for the ISMS. Further guidance is given in Clause 5.3 of  ISO 31000:2009.

Note that the term ‘requirement’ is a ‘need or expectation that is stated, generally implied or obligatory’. Combined with Clause 4.2, this in itself can be thought of as a governance requirement, as strictly speaking an ISMS that did not conform to generally-accepted public expectations could now be ruled nonconforming with the standard.

The final requirement (Clause 4.4) is to establish, implement, maintain and continually improve the ISMS in accordance with the requirements the standard.

Clause 5: Leadership 

This clause places requirements on ‘top management’ which is the person or group of people who directs and controls the organization at the highest level. Note that if the organization that is the subject of the ISMS is part of a larger organization, then the term ‘top management’ refers to the smaller organization. The purpose of these requirements is to demonstrate leadership and commitment by leading from the top. 

A particular responsibility of top management is to establish the information security policy, and the standard defines the characteristics and properties that the policy is to include. This is important for software development companies.

Finally, the clause places requirements on top management to assign information security relevant responsibilities and authorities, highlighting two particular roles concerning ISMS conformance to ISO/IEC 27001 and reporting on ISMS performance.

Clause 6: Planning 

Clause 6.1.1, General: This clause works with Clauses 4.1 and 4.2 to complete the new way of dealing with preventive actions. The first part of this clause (i.e. down to and including 6.1.1 c)) concerns risk assessment whilst Clause 6.1.1 d) concerns risk treatment. As the assessment and treatment of information security risk is dealt with in Clauses 6.1.2 and 6.1.3, then organizations could use this clause to consider ISMS risks and opportunities.

Clause 6.1.2, Information security risk assessment: This clause specifically concerns the assessment of information security risk. In aligning with the principles and guidance given in ISO 31000, this clause removes the identification of assets, threats and vulnerabilities as a prerequisite to risk identification. This widens the choice of risk assessment methods that an organization may use and still conforms to the standard. The clause also refers to ‘risk assessment acceptance criteria’, which allows criteria other than just a single level of risk. Risk acceptance criteria can now be expressed in terms other than levels, for example, the types of control used to treat risk.

The clause refers to ‘risk owners’ rather than ‘asset owners’ and later (in Clause 6.1.3 f)) requires their approval of the risk treatment plan and residual risks.

In other ways the clause closely resembles its counterpart in ISO/IEC 27001:2005 by requiring organizations to assess consequence, likelihood and levels of risk. Assessment of consequences, likelihood and levels of risk is essential for software development companies.

Clause 6.1.3, Information security risk treatment: This clause concerns the treatment of information security risk. It is similar to its counterpart in ISO/IEC 27001:2005, however, it refers to the ‘determination’ of necessary controls rather than selecting controls from Annex A. Nevertheless, the standard retains the use of Annex A as a cross-check to make sure that no necessary control has been overlooked, and organizations are still required to produce a Statement of Applicability (SOA). The formulation and approval of the risk treatment plan is now part of this clause.

Clause 6.2, Information security objectives and planning to achieve them: This clause concerns information security objectives. It uses the phrase “relevant functions and levels”, where here, the term ‘function’ refers to the functions of the organization, and the term ‘level’, its levels of management, of which ‘top management’ is the highest. The clause defines the properties that an organization’s information security objectives must possess. This lets software application development companies to move from ISO 27001:2005 to ISO 27001:2013.

Author Signature: Shreyans Agrawal (ifour.shreyans.agrawal@gmail.com)

Moving from ISO/IEC 27001:2005 to ISO/IEC 27001:2013 - Part 1

ISO/IEC 27001:2013 is the first revision of ISO/IEC 27001. First and foremost, the revision has taken account of practical experience of using the standard: there are now over 17,000 registrations worldwide. However, there have been two other major influences on the revision. The first is an ISO requirement that all new and revised management system standards must conform to the high level structure and identical core text defined in Annex SL to Part 1 of the ISO/IEC Directives. Conformance to these requirements will have a tendency to make all management system standards look the same, with the intention that management system requirements that are not discipline-specific are identically worded in all management system standards. This is good news for software application development companies that operate integrated management systems, i.e. management systems that conform to several standards, such as ISO 9001 (quality), ISO 22301 (business continuity) as well as ISO/IEC 27001. The second influence was a decision to align ISO/IEC 27001 with the principles and guidance given in ISO 31000 (risk management). Again, this is good news for integrated management systems as now an organization may apply the same risk assessment methodology across several disciplines.

The result is that structurally ISO/IEC 27001:2013 looks very different to ISO/IEC 27001:2005.In addition, there are no duplicate requirements, and the requirements are phrased in a way, which allows greater freedom of choice on how to implement them.  A good example of this is that the identification of assets, threats and vulnerabilities is no longer a prerequisite for the identification of information security risks. The standard now makes it clearer that controls are not to be selected from Annex A, but are determined through the process of risk treatment. Nevertheless, Annex A continues to serve as a cross-check to help ensure that no necessary controls have been overlooked.

Clause 0: Introduction 

This is a much shorter clause than its predecessor. In particular the section on the PDCA model has been removed. The reason for this is that the requirement is for continual improvement (see Clause 10) and PDCA is just one approach to meeting that requirement. There are other approaches, and organizations are now free to use them if they wish. Many software application development companies are adopting such approaches.

The introduction also draws attention to the order in which requirements are presented, stating that the order does not reflect their importance or imply the order in which they are to be implemented. 

Clause 1: Scope 

This, too, is a much shorter clause. In particular there is no reference to the exclusion of controls in Annex A.

Clause 2: Normative references 

The only normative reference is to ISO/IEC 27000, Information technology — Security techniques — Information security management systems — Overview and vocabulary.

Clause 3: Terms and definitions 

There are no longer any terms or definitions in ISO/IEC 27001:2013. Instead, readers are referred to ISO/IEC 27000. However, please ensure that you use a version of ISO/IEC 27000 that was published after ISO/IEC 27001:2013 otherwise it will not contain the correct terms or definitions. This is an important document to read. Many definitions, for example ‘management system’ and ‘control’ have been changed and now conform to the definitions given in the new ISO directives and ISO 31000. If a term is not defined in ISO/IEC 27000, please use the definition given in the Oxford English Dictionary. This is important, otherwise confusion and misunderstanding may be the result.


Author Signature: Shreyans Agrawal (ifour.shreyans.agrawal@gmail.com)

Security System Development Lifecycle

The Systems Development Life Cycle 

Information security must be managed in a manner similar to any other major system implemented in an organization. The one approach for implementing an information security system in an organization with little or no formal security in place is to use a variation of the systems development life cycle (SDLC): the security systems development life cycle (SecSDLC). Many software development companies in India are implementing security systems development life cycle (SecSDLC). Also to understand a security systems development life cycle, we must first understand the basics of the method upon which it is based.

Methodology and Phases 

The systems development life cycle (SDLC) is a methodology for the design and implementation of an information system. A methodology is a formal approach to solving a problem by means of a structured sequence of procedures. Also using a methodology ensures a rigorous process with a clearly defined goal and increases the probability of success. Once a methodology has been adopted, the key milestones are established and a team of individuals is selected and made accountable for accomplishing the project goals. The traditional SDLC consists of six general phases. If you have taken a system analysis and design course, you may have been exposed to a model consisting of a different number of phases. The SDLC models range from having three to twelve phases, all of which have been mapped into the six presented here. At the end of each phase comes a structured review or reality check, during which the team determines if the project should be continued, discontinued, outsourced, postponed, or returned to an earlier phase depending on whether the project is proceeding as expected and on the need for additional expertise, organizational knowledge, or other resources. Once the system is implemented, it is maintained (and modified) over the remainder of its operational life. Any information systems implementation may have multiple iterations as the cycle is repeated over time. Only by means of constant examination and renewal can any system, especially an information security program, perform up to expectations in the constantly changing environment in which it is placed. The following sections describe each phase of the traditional SDLC.20

The first phase, investigation, is the most important. What problem is the system being developed to solve? The investigation phase begins with an examination of the event or plan that initiates the process. During the investigation phase, the objectives, constraints, and scope of the project are specified. A preliminary cost-benefit analysis evaluates the perceived benefits and the appropriate levels of cost for those benefits. At the conclusion of this phase, and at every phase following, a feasibility analysis assesses the economic, technical, and behavioral feasibility of the process and ensures that implementation is worth the organization’s time and effort.

Analysis 

The analysis phase begins with the information gained during the investigation phase. This phase consists primarily of assessments of the organization, its current systems, and its capability to support the proposed systems. Analysts begin by determining what the new system is expected to do and how it will interact with existing systems. This phase ends with the documentation of the findings and an update of the feasibility analysis.

Logical Design 

In the logical design phase, the information gained from the analysis phase is used to begin creating a systems solution for a business problem. In any systems solution implemented at any software development company, it is imperative that the first and driving factor is the business need. Based on the business need, applications are selected to provide needed services, and then data support and structures capable of providing the needed inputs are chosen. Finally, based on all of the above, specific technologies to implement the physical solution are delineated. The logical design is, therefore, the blueprint for the desired solution. The logical design is implementation independent, meaning that it contains no reference to specific technologies, vendors, or products. It addresses, instead, how the proposed system will solve the problem at hand. In this stage, analysts generate a number of alternative solutions, each with corresponding strengths and weaknesses, and costs and benefits, allowing for a general comparison of available options. At the end of this phase, another feasibility analysis is performed.

Physical Design 

During the physical design phase, specific technologies are selected to support the alternatives identified and evaluated in the logical design. The selected components are evaluated based on a make-or-buy decision (develop the components in-house or purchase them from a vendor). Final designs integrate various components and technologies. After yet another feasibility analysis, the entire solution is presented to the organizational management for approval.

Implementation 

In the implementation phase, any needed software is created. Components are ordered, received, and tested. Afterward, users are trained and supporting documentation created. Once all components are tested individually, they are installed and tested as a system. Again a feasibility analysis is prepared, and the sponsors are then presented with the system for a performance review and acceptance test.

Maintenance and Change 

The maintenance and change phase is the longest and most expensive phase of the process. This phase consists of the tasks necessary to support and modify the system for the remainder of its useful life cycle. Even though formal development may conclude during this phase, the life cycle of the project continues until it is determined that the process should begin again from the investigation phase. At periodic points, the system is tested for compliance, and the feasibility of continuance versus discontinuance is evaluated. Upgrades, updates, and patches are managed. As the needs of the organization change, the systems that support the organization must also change. It is imperative that those who manage the systems, as well as those who support them, continually monitor the effectiveness of the systems in relation to the organization’s environment. When a current system can no longer support the evolving mission of the organization, the project is terminated and a new project is implemented.

Securing the SDLC 

Each of the phases of the SDLC should include consideration of the security of the system being assembled as well as the information it uses. Whether the system is custom and built from scratch, is purchased and then customized, or is commercial off-the-shelf software (COTS), the implementing organization such as software development company is responsible for ensuring it is used securely. This means that each implementation of a system is secure and does not risk compromising the confidentiality, integrity, and availability of the organization’s information assets. The following section, adapted from NIST Special Publication 800-64, rev. 1, provides an overview of the security considerations for each phase of the SDLC.

Author Signature: Shreyans Agrawal (ifour.shreyans.agrawal@gmail.com)

Implementing ISO 27001 - Part 2

Implementation Phases

An organization needs to have the detailed understanding of PDCA implementation phases to manage the costs of the project. Software development companies adopt PDCA cycle to implement international standards. Cycle of the PDCA is consistent with all auditable international standards: ISO 18001, 9001 and 14001. ISO/IEC 27001:2005 gives the following PDCA steps for an organization to follow:

• Define an ISMS policy.
• Define the scope of the ISMS.
• Perform a security risk assessment.
• Manage the identified risk.
• Select the controls to be implemented and applied.
• Prepare an SOA.

Phase 5—Prepare an Inventory of Information Assets to Protect, and the Rank Assets According to the Risk Classification Based on Risk Assessment

The various companies, such as software development companies, needs to create a list of information assets to be protected. The following are suggested steps:

• For the assets classify the key CIA impact levels: high, medium and low.
• Identify the risks, and also classify them according to their severity and vulnerability.
• After complete identification of the risks and the levels of CIA, do assign the values to the risks.

Phase 6—Manage the Risks, and Create a Risk Treatment Plan

To control the impact associated with risk, the organization must accept and avoid and transfer or reduce the risk to an acceptable level using risk mitigating controls. Then the next stage is performing the gap analysis with the controls provided in the standard to create an RTP and an SOA and it is also important to obtain management approval of the proposed residual risks.

The RTP also provides:

• Acceptable risk treatment (accept, transfer, reduce, avoid)
• Identification of operational controls and additional proposed controls with the help of gap analysis

Phase 7—Set Up the Policies and Procedures to Control Risks

For the controls adopted, shown in the SOA the organization will require the statements of policy or a detailed procedure and responsibility document to identify user roles for consistent and effective implementation of policies and procedures. And the documentation of policies and procedures is a requirement of ISO/IEC 27001. Also the list of applicable policies and procedures depends on the organization’s structure, the locations and the assets.

Phase 8—Allocate Resources, and Train the Staff

The ISMS process highlights one of the important commitments for the management: sufficient resources to manage, develop, maintain and implement the ISMS. And also it is very essential to document the training for audit.

Phase 9—Monitoring the Implementation of the ISMS

The periodic internal audit is a must for monitoring and review. The internal audit review consists of testing of controls and identifying corrective/preventive actions. In order to complete the PDCA cycle all the gaps identified in the internal audit must be addressed by identifying the corrective and preventive controls needed and the company’s compliance based on a gap analysis.

Also to be effective, the ISMS need to be reviewed by management at periodic and planned intervals. This review follows the changes and improvements to the policies, procedures, the controls and staffing decisions. It is a very important step in the process is project management review. Thus the results of audits and periodic reviews are documented and maintained.

Phase 10—Preparation for the Certification Audit

In order for the organizations, such as software development companies, to be certified it is very essential that it conduct a full cycle of internal audits and management reviews and activities in the PDCA process and that it retains evidence of the responses taken as a result of those reviews and audits. The ISMS management should review risk assessments, the RTP, the SOA, and the policies and procedures at least annually.

An external auditor will first examine the ISMS documents to determine the scope and content of the ISMS and the objective of the review and audit is to have sufficient evidence and review/audit documents sent to an auditor for review. Thus the evidence and documents will demonstrate the efficiency and effectiveness of the implemented ISMS in the organization and its business units.

Phase 11—Conducting Periodic Reassessment Audits

The follow-up reviews or periodic audits confirm that the organization remains in compliance with the standard.

The certification maintenance requires periodic reassessment audits to confirm that the ISMS continue to operate as specified and intended. Thus with any other ISO standard the ISO 27001 follows the PDCA cycle and assists ISMS management in knowing how far and how well the enterprise has progressed along this cycle. It directly influences the time and cost estimates related to achieving compliance.

Conclusion

The true success of ISO 27001 is its alignment with the business objectives and effectiveness in realizing those objectives. For software development companies the IT and other departments play an important role in implementing ISO 27001. Implementing ISO 27001 is an exercise toward better understanding an existing inventory of IT initiatives, information availability and ISMS implementation phases. An organization also needs to have the detailed understanding of PDCA implementation phases. 

Without a well-defined and well-developed ISO 27001 project plan, implementing ISO 27001 would be a time- and cost-consuming exercise. To achieve the planned return on investment (ROI), the implementation plan has to be developed with an end goal in mind. Training and internal audit are major parts of ISO 27001 implementation. ISO 27001 certification should help assure most business partners of an organization’s status with respect to information security without the necessity of conducting their own security reviews. 

Author Signature: Shreyans Agrawal (ifour.shreyans.agrawal@gmail.com)

Implementing ISO 27001 - Part 1

Implementation Phases

An organization needs to have the detailed understanding of PDCA implementation phases to manage the costs of the project. Software development companies adopt PDCA cycle to implement international standards. Cycle of the PDCA is consistent with all auditable international standards: ISO 18001, 9001 and 14001. ISO/IEC 27001:2005 gives the following PDCA steps for an organization to follow:

• Define an ISMS policy
• Define the scope of the ISMS
• Perform a security risk assessment
• Manage the identified risk
• Select the controls to be implemented and applied
• Prepare an SOA

Phase 1—Identify Business Objectives

Stakeholders must buy in; identifying and prioritizing objectives is the step that will gain management support. The primary objectives can be derived from the company’s mission, the strategic plan and IT goals. The objectives are:

• Increased marketing potential
• Complete assurance to the business partners of the organization’s status with respect to information security
• Both Increased revenue and profitability by providing the highest level of security for customers’ sensitive data
• Identification of the information assets & effective risk assessments
• Compliance with industry regulations

Phase 2—Obtain Management Support

Management must make a commitment to the establishment, planning, the implementation, the operation, monitoring, review, improvement and maintenance of the ISMS. The commitment must also include activities such as ensuring that the proper resources are available to work on the ISMS and that all employees affected by the ISMS have the proper training, competency and also awareness. The following activities/initiatives show management support:

• An information security policy
• The information security objectives & the plans
• The roles & responsibilities for the information security or a segregation of duties (SoD) matrix that shows the list of the roles related to information security
• Sufficient resources for managing, developing, maintaining and implementing the ISMS
• The determination of acceptable level of risk
• The management reviews of the ISMS at planned intervals
• Assurance that personnel affected is also affected by the ISMS are provided with training
• Appointment of the competent people for the roles and responsibilities that they are assigned to fulfill

Phase 3—Select Proper Scope of Implementation

ISO 27001 states that any scope of implementation may cover all or part of an organization. According to it for the software company or any other company the scope of the ISMS, the processes, business units, external vendors or contractors falling within the scope of implementation must be specified for certification to occur.

The standard also thus requires companies to list any scope exclusions and the reasons why they were excluded.

Identifying the scope of implementation can save the organization time, money. The following points should be considered:

• Selected scope helps to achieve all the identified business objectives.
• The organization’s over all scale of operations is an integral parameter needed to determine the compliance process’s complexity level.
• To find out appropriate scale of operations, organizations need to consider the number of employees, business processes, work locations, and products or services offered.

Phase 4—Define the appropriate Method of Risk Assessment

To meet the requirements of ISO/IEC 27001, the companies need to define & document the method of risk assessment. The ISO/IEC 27001 standards do not specify the risk assessment method that can be used. The following all points should be considered:

• The method that can be used that can assess the risk to identified information assets
• Which risks are intolerable therefore, that need to be mitigated
• Managing the residual risks through carefully considered policies, the procedures and controls
• Choosing a risk assessment method is one of the most important parts of establishing the ISMS and use of the following will be helpful:
• NIST Special Publication (SP) 800-30 Risk Management Guide for Information Technology Systems
• Sarbanes-Oxley IT risk assessment
• Asset classification, data classification documents (determined by the organization)
• ISO 27001 needs risk evaluations based on levels of confidentiality, integrity and availability (CIA):
• Confidentiality—Clause 3.3: Ensuring that information is accessible only to those authorized to have access
• Integrity—Clause 3.8: Safeguarding the accuracy and completeness of information and processing methods
• Availability—Clause 3.9: Ensuring that authorized users have access to information and associated assets when required

Conclusion

The true success of ISO 27001 is its alignment with the business objectives and effectiveness in realizing those objectives. For any software development company, IT & the other departments play an important role in implementing the ISO 27001. Implementation of ISO 27001 is an exercise toward better understanding an existing inventory of IT initiatives & the information availability and ISMS implementation phases. The organization also needs to have the detailed understanding of PDCA implementation phases. 

Without a well-defined and well-developed ISO 27001 project plan & implementing ISO 27001 would be a time- and cost-consuming exercise & to achieve the planned return on investment (ROI), the implementation plan has to be developed with an end goal in mind. Training and internal audit are major parts of ISO 27001 implementation. ISO 27001 certification should help assure most business partners of an organization’s status with respect to information security without the necessity of conducting their own security reviews. 

Author Signature: Shreyans Agrawal (ifour.shreyans.agrawal@gmail.com)

Legal Infrastructure on Industrial Safety - Part 3

EMERGING ISSUES

General Legislation on Occupational Safety and Health

At present, separate statutes are enacted covering safety and health aspects of workers employed in some sectors such as factories, mines, ports and docks and construction. Many branches of economic activities are out of coverage of OSH Legislation. There is a need for enactment of a general legislation to secure safety and health of persons at work as well as other persons, against the risks arising out of or in connection with the activities at all places of work(software development firm in ahmedabad).

National Board for Accreditation in Occupational Safety and Health

The existing statutes on safety and health require regulation, recognition, certification, approvals etc. in respect of many of the requirements. Since there are multiple agencies namely, CIFs of various States/UTs, it is felt that there should be a single agency.

Self-Certification and Third Party Certification

In order to reduce the burden of inspection, a system of self-certification regarding compliance with OSH standards can be introduced. The factories employing less than 50 workers could be required to furnish the Annual Return on the compliance with the certain provisions of the Factories Act, 1948. These Returns can be accepted as a self-certification and no inspection may be undertaken in respect of such factories. However, inspections can be carried out in case of complaints, accidents, etc. Any non-compliance detected during such inspection should be taken very seriously and the occupier and manager of such factories can be severely punished. A system of self-certification in respect of compliance with labour laws has been introduced by certain States such as Gujarat, Punjab, Uttar Pradesh, etc.

Protection of Women Workers vis-à-vis Equal Opportunities

In the era of globalization and liberalization, equal opportunities to male and female workers have become essential feature of any business enterprise. At international level also women employees are contributing significantly in the growth of business. Therefore, the restrictive provisions under the statutes seem to be discriminating and many women organizations(Empowring Woman worker in Software development company in india) have taken up the issue at social, political and judicial levels.

Conclusion

In India, a national system on Occupational Safety and Health in the form of policy, statutes and regulatory mechanism exists in respect of certain branches of economic activities namely, factories, mines, ports and docks and construction. However, there is a need to extend the OSH coverage to all other sectors, through appropriate means. Further, with the phenomenal growth in the industrial sector, a system of self-certification and third party certification in the field of OSH is essential in order to reduce the burden of inspection.

References

1. Constitution of India

2. The Factories Act, 1948

3. The Model Rules under the Factories Act, 1948;

DGFASLI 1998

4. Annual Report 2007-2008; Ministry of Labour &

Employment

5. DGFASLI Standard Reference Note 2006; DGFASLI

April 2007

6. www.ilo.org

7. www.labour.nic.in

8. www.dgfasli.nic.in

Legal Infrastructure on Industrial Safety - Part 2

LEGAL FRAMEWORK

As per the allocation of business rules under the Constitution, labour is in the concurrent list of subjects. It is dealt with by the MOLE at the Central and Departments of Labour under State Governments in respective States / UTs. The MOLE has enacted workplace safety and health statutes concerning workers in the manufacturing sector, mines, ports and docks and in construction sectors. Many software development companies have also adopted the legal framework. Further, other Ministries of the Government of India have also enacted certain statutes relating to safety aspects of substances, equipment, operations etc. Some of the statutes applicable in the manufacturing sector are discussed below :-

The Static and Mobile Pressure Vessels (Unfired) Rules, 1981

These (SMPV) Rules are notified under the Explosives Act, 1884. These rules regulate storage, handling and transport of compressed gases. These rules stipulate requirements regarding construction and fitments, periodic testing, location, fire protection, loading and unloading facilities, transfer operations etc. in respect of pressure vessels whose water capacity exceeds one thousand liters.

The Manufacture, Storage and Import of Hazardous Chemicals Rules (MSIHC), 1989

These MSIHC Rules are notified under the Environment (Protection) Act, 1986. These rules are aimed at regulating and handling of certain specified hazardous chemicals. The rules stipulate requirements regarding notification of site, identification of major hazards, taking necessary steps to control major accident, notification of major accident, preparation of safety report and on-site emergency plan; prevention and control of major accident, dissemination of information etc by the custom software development company in india. These rules are notified by the Ministry of Environment and Forests (MOEF) but enforced by the Inspectorates of Factories of respective States / UTs in the manufacturing sector.

REGULATION OF SAFETY AND HEALTH IN FACTORIES

The Factories Act, 1948 is applicable to the premises where(i) manufacturing process is carried on with the aid of power employing 10 or more persons; (ii) manufacturing process is carried on without the aid of power employing 20 or more persons;(iii) notified under Section 85 of the Factories Act, 1948. The State Governments are empowered to make rules under the enabling provisions as well as general provision. The State Governments are also empowered to appoint inspectors and the Chief Inspector. Thus, the State Inspectorates of Factories enforce the provisions under the Act and Rules. The uniformity in States Rules notified by different States / UTs is sought through framing of Model.

References

1. Constitution of India

2. The Factories Act, 1948

3. The Model Rules under the Factories Act, 1948;

DGFASLI 1998

4. Annual Report 2007-2008; Ministry of Labour &

Employment

5. DGFASLI Standard Reference Note 2006; DGFASLI

April 2007

6. www.ilo.org

7. www.labour.nic.in

8. www.dgfasli.nic.in

Legal Infrastructure on Industrial Safety - Part 1

INTRODUCTION

At the global level, industrial safety has been drawing attention of international agencies such as ILO, WHO, UNDP, UNEP, etc. In fact, efforts are being made to consider and recognize occupational safety and health as one of the human rights.


POLICY FRAMEWORK

Constitutional Provisions

The Constitution of India under the Directive Principles of State Policy provides for certain safeguards to workers. The State policies should be directed to ensure that health and strengths of workers are not abused and just and humane conditions of work and maternity relief that are provided. The Constitution prohibits employment of child below 14 years of age for work in any factory, or mine or any hazardous occupation. The constitution also provides for the State to make any special provision for women and children.

ILO Conventions

The International Labour Organization (ILO) is the standard making body in the area of labor and social issues. The ILO was established in the year 1919. Since then, they have formulated 188 Conventions relating to conditions of labor. In addition, they have also formulated several recommendations, codes of practices and guidelines for the benefit of member countries. As one of the founder members, India has so far ratified 41 Conventions.

As a step towards facilitating the ratification, a national policy on occupational safety, health and environment at workplace is already prepared by the Ministry of Labour and Employment (MOLE). The policy is under advanced stage of declaration.

National Policy On Occupational Safety, Health And Environment At Work

The national policy aims at improvement in the safety, health and environment at workplace (especially at Manufacturing sites, Chemical industries, software development companies) through:- (i) statutory framework on OSH in respect of all sectors of economic activities (ii) facilitation of technical support services (iii) providing incentives to employees and employers (iv) establishment and maintaining of R & D capabilities in the area of risk management (v) focusing on prevention strategies; and (vi) competence enhancement of technical manpower.

The policy sets its objective to achieve continuous reduction in work related injuries, diseases and associated costs; and continuous enhancement of awareness regarding safety, health and environment. The policy also outlines an Action Programme for achieving these objectives and goals. It identifies 9 key strategies :-
1. Enforcement
2. Development of national standards
3. Compliance
4. Awareness
5. Research and development
6. Skills development
7. Data collection
8. Practical guidance
9. Incentives

National Policies On Other Subjects

The Government of India have also formulated National Environment Policy, National Policy on Petroleum, Chemicals and Petro-chemical Investment Regions (PCPIR), Policy on Information Technology Investment Regions, National Fertilizer Policy, etc. These policies also contain reference to the occupational safety and health aspects of working population. Apart from these, at the instance of National Human Rights Commission (NHRC), a national programme on ‘Elimination of Silicosis’ is being formulated.

Further, a separate legislation concerning safety, health, social security and welfare of workers employed in unorganized sectors is also being contemplated by software development company in india.


Tripartite Consultations

The MOLE has put in place a tripartite consultative mechanism in the form of Indian Labour Conference (ILC), to discuss the issues relating to labour including occupational safety and health. The ILC is assisted by another tripartite forum, Standing Labour Committee (SLC) which frames the agenda for the ILC. Further, MOLE has also constituted Tripartite Committee on ILO Conventions which addresses the issue of ratification of ILO Conventions. In addition, Tripartite Committees are also constituted as per the enabling provisions under various statutes concerning safety and health.


References

1. Constitution of India
2. The Factories Act, 1948
3. The Model Rules under the Factories Act, 1948;
DGFASLI 1998
4. Annual Report 2007-2008; Ministry of Labour &
Employment
5. DGFASLI Standard Reference Note 2006; DGFASLI
April 2007
6. www.ilo.org
7. www.labour.nic.in
8. www.dgfasli.nic.in

Types of Software Quality Models

1. McCall Model 

McCall’s model was developed by the Rome air development center (RADC), the US air-force electronic system decision (ESD), general electric, in order to improve the quality of software products at software development companies. The model was developed to assess the relationships between external factors and product quality criteria. The quality characteristics were classified in three major types, eleven such factors which describe the external view of the software (user view), 23 quality criteria which describe the internal view of the software (developer view), and the metrics which define and are used to provide a scale and method for measurement. The total number of factors was reduced to eleven in order to simplify it. Those factors are Correctness, Integrity, Reliability, Efficiency, Usability, Flexibility, Maintainability, Reusability, Testability, Portability, and Interoperability. The major contribution of this model is the relationship between the quality characteristics and metrics. But, this model does not consider directly on the functionality of software products.

2. Boehm Model

Boehm added new factors to McCall’s model with emphasis on the maintainability of software product at software development companies. The main aim of this model is to address the contemporary shortcomings of models that automatically and quantitatively evaluate the quality of software. Thus, Boehm model represents the characteristics of the software product hierarchically in order to get contribute in the total quality. Also, the software product evaluation considered with respect to the utility of the program. But, this model contains only a diagram without any suggestion about measuring the quality characteristics.

3. FURPS Model

FURPS model was proposed by and Hewlett-Packard Co and Robert Grady. The attributes were classified into two main categories according to the user’s requirements, the functional and non-functional requirements. Functional requirements (F): Defined by input and expected output. Non-functional requirements (URPS):

Usability, reliability, performance, supportability. Also, this model was extended by IBM Rational Software – into FURPS+. Thus, this model considered only the user’s requirements and disregards the developer consideration. But, this model fails to take into account the software some of the product characteristics, like maintainability and portability.

4. Dromey Model

Dromey (1995) states that the evaluation is different for each product, thus a dynamic idea for process modeling is required. Thus, the main idea of the proposed model was to obtain a model broad enough to work for different systems. Also the model seeks to increase understanding of the relationship between the attributes (characteristics) and the sub-attributes (sub-characteristics) of quality. Also this model defined two layers, the high-level attributes and subordinate attributes. Therefore, this model suffers from lack of criteria for measurement of software quality.

5. ISO IEC 9126 Model

As, many software quality models were proposed, the confusion happened and new standard model was required. Thus, ISO/IEC JTC1 began to develop the required consensus and encourage standardization world-wide. The ISO 9126 is part of the ISO 9000 standard, and it is the most important standard for quality assurance. The first considerations originated in 1978, and in the year 1985 the development of ISO/IEC 9126 was started.

In this model, for software development companies, the totality of software product quality attributes was classified in a hierarchical tree structure of characteristics and sub characteristics. And the highest level of this structure consists of the quality characteristics and the lowest level consists of the software quality criteria. This model specified six characteristics including Functionality, the Reliability, Usability, Efficiency, Maintainability and the Portability; all of which are further divided into 21 sub characteristics. All these sub characteristics are manifested externally when the software is used as part of a computer system, and thus are the result of internal software attributes. All the defined characteristics are applicable to every kind of software, including computer programs and data contained in firmware and provide consistent terminology for software product quality. And they also provide a framework for making trade-offs between software product capabilities.

Author Signature: Shreyans Agrawal (ifour.shreyans.agrawal@gmail.com)

Users’ perspective in Software Quality - Part 2

4. User’s Perspective Quality Factors

Here, different characteristics of software product developed at software development companies are considered and checked; a number of such characteristics are taken into consideration by the end users. In it, the list of the software characteristics, considered by the end users and which affect their emotions are taken into consideration.

4.1 Functionality

The main idea of any software product is to perform specific business functionality. Thus, the performance of the software product is considered as crucial factor in the software quality, which identifies whether the software is really usable or not, by not considering the values of other software quality factors and functions. The critical role of the software presents whether the software product is apt, the result is correct, and whether some standard is followed in order to perform the required functions. The adaptability of the software presents how the system fit the developer’s requirements. Therefore, the suitability evaluates the ability of the software product to produce desired result and appropriate for a specified environment.

Software accuracy is defined as the ability of the software products to achieve its requirements, by bringing accurate output as per requirement of the system core developer. The software accuracy also affects the process continuity, system safety, total cost and maintainability. The compliance represents whether the system has followed any standard or certificates to achieve the user requirements.

4.2 Reliability

The reliability of the software represents the ability to perform the intended function properly without any failures. That is maintaining a level of services under specific condition within specific period of time during systems operation. Thus, the reliability measures the failures occurred in the software product within defined period of time.

Moreover, the reliability considered in the information and the system function safety harms that may be caused by the unauthorized people. Therefore, the reliability of the software product consists of several characteristics: the integrity, the maturity and the fault recovery.

4.3 Performance

Software performance is the most affected software characteristic, which gets affected by everything in the system product, from software characteristics to the system environment such as the operating system, the middleware, the hardware and the communication networks. System performance is a make-or break quality for software, which is an important nonfunctional attribute of software systems for producing quality software, that considers the run time property.

System performance is characterized by the amount of useful work accomplished by a system compared to the time and resources used. The performance factor is thus destined to evaluate whether the software application is running efficiently on the computing resources available or not.

The performance factor represents the degree of the system efficiency to produce desired result during system operation time. This degree is thus represented by combination of software and hardware attributes which influence on the time of answer and the range of the software services coverage.

4.4 Usability

As per the ACM the usability engineering (called human-computer interaction engineering) is defined as “a discipline concerned with the design, evaluation and implementation of interactive computing systems for human use and the study of major phenomena surrounding them”.

As per the software life cycle phases, usability characteristics were classified into three main categories: Interface characteristics, training, and operation supportability.

4.5 Transferability/Portability

Software transferability expresses the ability of the software to work properly in different type of platforms. It deals with the effort required to transfer a program from one hardware configuration and/or software system environment to another with slight modification. Thus this characteristic refers to how the software can be adopted to change its environment or with its requirements in software development companies.

Author: Shreyans Agrawal (ifour.shreyans.agrawal@gmail.com)

Users’ perspective in Software Quality - Part 1

1. Introduction

In the last decade, the cost of software products has reduced, which leads to growth in the software application development companies in India and software products are being used by individuals in addition to the corporations. Thus, research in software engineering increasingly grows and focuses on software quality evaluation and growth, yet most of all these research focuses on the internal/ development perspective.

Since the market of software development companies interest is on the user’s satisfaction with more attention to the perspective of users in software quality is needed, the software users from different education background and culture are considered in developing software products and services. Therefore, by not considering these factors, the software will be less used, which means the software product failed in the market.

According to ISO9126, the main consideration of the users is the software usability, its effects and its performance without knowing what is inside it, how it works, or how was it developed. 

Since, the software users do not care about all of software characteristics that are required to identify the quality of the software product, but it seems to be not accurate to show them the quality that they are searching for. Thus, the quality of the software as users need is very important in the market.

2. Software Quality Models

Since 1978, when McCall proposed first software quality model and also several other models were proposed to check the characteristics of the software products. These models combined the different point of views of the Manager, the Developer, and the user. Thus, there is no clear image of the software quality shows to the users. For e.g., if such a software product has a high maintainability and low usability might be equal to software has a high usability low maintainability.

3. User’s Emotion Quality Models

On the other side, the effect of the software products on the user were considered and several emotions models were proposed. The aim of these models is to evaluate the software product from what the users feels when they use it. It either proposed a B2C model that calculates the emotions of the end users instead of software characteristics. The cognitive emotions were adopted in this model. 

Author: Shreyans Agrawal (ifour.shreyans.agrawal@gmail.com)