Perpetua Knowledge Services-Students Centre

BASEL II

arun9895929393 — Thu, 31 Jan 2008 09:54:26 +0000

Anti-money Laundering Anti-money laundering (“AML”) is a term mainly used in the financial and legal industries to describe the legal controls that require financial institutions and other regulated entities to prevent or report money laundering activities. Anti-money laundering guidelines came into prominence globally after the attacks and the subsequent enactment of the USA PATRIOT Act. Today, all financial institutions globally are required to monitor, investigate and report transactions of a suspicious nature to the financial intelligence unit of the central bank in the respective country. For example, a bank must perform due diligence by having proof of a customer’s identity and that the use, source and destination of funds do not involve money laundering. United States federal law related to money laundering is implemented under the Bank Secrecy Act of 1970 as amended by anti-money laundering acts up to the present. Many people have confused Anti-Money Laundering (“AML”) with Anti-Terrorist Financing (“ATF”). Under the Bank Secrecy Act of USA, Money Laundering and Terrorist Financing are classified into two different categories when financial institutions file Suspicious Activities Reports (“SAR”) to Financial Crimes Enforcement Network (“FinCEN”) which is a US government agency. To effectively implement AML and ATF measures, The US government encourages financial institutions to work together for AML and ATF purposes in accordance with Section 314(b) of the USA PATRIOT Act. An entire industry has developed around providing software to analyze transactions in an attempt to identify transactions or patterns of transactions that may constitute illegal financial activity. Financial institutions face penalties for failing to properly file CTR (Cash Transaction Report) and SAR (Suspicious Activity Report) reports, including heavy fines and regulatory restrictions, even to the point of charter revocation. These software applications effectively monitor bank customer transactions on a daily basis and, using customer historical information and account profile, provide a “whole picture” to the bank management. Transaction monitoring can include cash deposits and withdrawals, wire transfers, credit card activity, cheques (checks), share (securities) dealing and ACH activity. In the bank circles, these applications are known as “BSA software” or “AML software“.

Steps in Money Laundering

Money laundering involves three independent steps that often occur simultaneously.They are: 1. Placement – Physically placing bulk cash proceeds. 2. Layering – Separating the proceeds from criminal activity from their origins through layers of complex financial transactions.3. Integration. – Providing an apparently legitimate explanation for the illicit proceeds

Rapid Testing

Dominick — Thu, 31 Jan 2008 09:53:43 +0000

Rapid testing means testing software faster than you do now, while maintaining or improving your standards of quality. Unfortunately, there is no simple way to achieve rapid testing. Figure 1.1 shows a somewhat simplistic sketch that represents rapid testing as a structure that is built on a foundation of four components. If any of these components is weak, the effectiveness of testing will be greatly impaired. As illustrated in the figure, the four components that must be optimized for rapid testing are people, integrated test process, static testing, and dynamic testing. We’ll briefly examine each of the four components.Figure 1.1 Essential components of rapid testing.

People

As every test manager knows, the right people are an essential ingredient to rapid testing. There are several studies that show productivity differences of 10:1 or more in software developers. The same is true with test engineers—not everyone has the skills, experience, or temperament to be a good test engineer. Rapid testing particularly needs people who are disciplined, flexible, who can handle the pressure of an aggressive schedule, and who are able to be productive contributors through the early phases of the development life cycle. While the main focus of this book is on test process and technique, some ideas about the “people side” of testing will be included in Chapter 6.

Integrated Test Process

No matter how good your people may be, if they do not have a systematic, disciplined process for testing, they will not operate at maximum efficiency. The test process needs to be based on sound, fundamental principles, and must be well integrated with the overall software development process. We will spend a good portion of Part I of this book describing ways to improve the test process, with a more detailed discussion of practical techniques and implementation tips presented in Part II. The focus of our discussion will be to explore ways of better integrating the development and test activities.

Static Testing

In the previous section we defined static testing as test activities associated with analyzing the products of software development. Static testing is done for the purpose of validating that a work product such as a design specification properly implements all the system requirements, and verifying the quality of the design. Static testing is one of the most effective means of catching bugs at an early stage of development, thereby saving substantial time and cost to the development. It involves inspections, walkthroughs, and peer reviews of designs, code, and other work products, as well as static analysis to uncover defects in syntax, data structure, and other code components. Static testing is basically anything that can be done to uncover defects without running the code. In the experience of the authors, it is an often-neglected tool. Static testing will be discussed throughout Parts I and II of this book.

Dynamic Testing

Often when engineers think of testing, they are thinking of dynamic testing, which involves operating the system with the purpose of finding bugs. Whereas static testing does not involve running the software, dynamic testing does. Generally speaking, dynamic testing consists of running a program and comparing its actual behavior to what is expected. If the actual behavior differs from the expected behavior, a defect has been found. As we’ll see in later chapters, dynamic testing will be used to perform a variety of types of tests such as functional tests, performance tests, and stress tests. Dynamic testing lies at the heart of the software testing process, and if the planning, design, development, and execution of dynamic tests are not performed well, the testing process will be very inefficient. Dynamic testing is not only performed by the test team; it should be a part of the development team’s unit and integration testing as well. For Completer Article CLICK HERE.ByDOMINICK

Rational Unified Process (RUP)

rajalekshmi — Mon, 21 Jan 2008 11:09:09 +0000

History of RUP

The roots of Rational Process go back to the original spiral model of Barry Boehm. The Rational Approach was developed at Rational Software in the 1980s and 1990s.The Rational Unified Process was the result of the merger of the Rational Approach and the Objectory process developed by Objectory founder Ivar Jacobson. The first result of that merger was the Rational Objectory Process, designed to an Objectory-like process, but suitable to wean Objectory users to the Rational Rose tool. When that goal was accomplished, the name was changed. The first version of the Rational Unified Process, version 5.0, was released in 1998. The chief architect was Philippe Kruchten. The latest version of RUP (7.0) was released with the announcement [1]of the IBM Rational Method Composer in November 2005.The RUP lifecycle is an implementation of the spiral model. It has been created by assembling the content elements into semi-ordered sequences. Consequently the RUP lifecycle is available as a work breakdown structure, which could be customized to address the specific needs of a project. The RUP lifecycle organizes the tasks into phases and iterations.A project has four phases:

Inception
Elaboration
Construction
Transition

Inception phase

In this phase the business case which includes business context, success factors (expected revenue, market recognition, etc), and financial forecast is established. To complement the business case, a basic use case model, project plan, initial risk assessment and project description (the core project requirements, constraints and key features) are generated. After these are completed, the project is checked against the following criteria:

Stakeholder concurrence on scope definition and cost/schedule estimates.
Requirements understanding as evidenced by the fidelity of the primary use cases.
Credibility of the cost/schedule estimates, priorities, risks, and development process.
Depth and breadth of any architectural prototype that was developed.
Establishing a baseline by which to compare actual expenditures versus planned expenditures.

If the project does not pass this milestone, called the Lifecycle Objective Milestone, it can either be cancelled or it can repeat this phase after being redesigned to better meet the criteria.

Elaboration phase

The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form.This phase must pass the Lifecycle Architecture Milestone by the following criteria:

A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed. The use-case model should be 80% complete.
A description of the software architecture in a software system development process.
An executable architecture that realizes architecturally significant use cases.
Business case and risk list which are revised.
A development plan for the overall project.
Prototypes that demonstrably mitigate each identified technical risk.

If the project cannot pass this milestone, there is still time for it to be canceled or redesigned. After leaving this phase, the project transitions into a high-risk operation where changes are much more difficult and detrimental when made.The key domain analysis for the elaboration is system architecture.

Construction phase

In this phase, the main focus goes to the development of components and other features of the system being designed. This is the phase when the bulk of the coding takes place. In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments that produce demonstrable prototypes.This phase produces the first external release of the software. Its conclusion is marked by the Initial Operational Capability Milestone.

Transition phase

In the transition phase, the product has moved from the development organization to the end user. The activities of this phase include training of the end users and maintainers and beta testing of the system to validate it against the end users’ expectations. The product is also checked against the quality level set in the Inception phase. If it does not meet this level, or the standards of the end users, the entire cycle in this phase begins again.If all objectives are met, the Product Release Milestone is reached and the development cycle ends.RUP is based on a set of six key principles for business-driven development:

Adapt the process
Balance stakeholder priorities
Collaborate across teams
Demonstrate value iteratively
Elevate the level of abstraction
Focus continuously on quality

In short -> [ABCDEF]

Adapt the process

A project or organization must right-size the process to their needs. For example, governance, size of the project, regulations etc, drive the degree of formality that should be used in a project. RUP provides pre-configured process templates for small, medium and large projects, which can be used for easier adoption. The ceremony of the process should reflect the goals of the RUP phases. Adapting a process also encourages the continuous improvement of a process in an organization.

Balance stakeholder priorities

This key principle widens the discussion from a pure software requirements point of view, to a higher discussion. This includes business goals and stakeholder needs. Often, they compete and conflict, which needs to be balanced out between the parties involved.

Collaborate across teams

Software engineering is a team effort. With a broad variety of stakeholders, all voices need to be heard. With the increasing demand of globally distributed development, collaboration is enabled through modern communication tools. The collaboration is not limited to requirements, but includes exchange of metrics, test results, release management and project plans. That is especially true for RUP projects which are executed in an iterative-incremental approach.

Demonstrate value iteratively

Projects are delivered, even though often only internally, in increments in an iterative fashion. The increment, which includes the value of the past iteration, is used to measure the progress of the project. That increment is also used to encourage feedback from stakeholders about the direction of the project. This allows projects to adjust to changed situations based on the feedback. The stakeholders on the other side, can influence the shape of the development effort while the project is executed. The combination of the iterative development and the focus on risks in RUP, allows projects an iterative risk-assessment.

Elevate the level of abstraction

This key principle motivates the use of reusable assets such as software pattern, 4GL or Framework to name a few. This prevents software engineers going directly from the requirements to custom-made software code. A higher level of abstraction also allows discussions on different architectural levels. These can be accompanied by visual representations of the architecture, for example using UML.

Focus continuously on quality

Quality checks are not only at the end of each iteration but a continuous ongoing activity in the software engineering project, often performed in a daily rhythm supported by the entire team. Automating test scenarios (scripts) helps in dealing with the increasing amount of tests due to iterative development.RUP is based on a set of building blocks, or content elements, describing what is to be produced, the necessary skills required and the step-by-step explanation describing how specific development goals are achieved.The main building blocks, or content elements, are the following:

Roles (who) – A Role defines a set of related skills, competences, and responsibilities.
Work Products (what) – A Work Product represents something resulting from a task, including all the documents and models produced while working through the process.
Tasks (how) – A Task describes a unit of work assigned to a Role that provides a meaningful result.

Within each iteration, the tasks are categorized into nine Disciplines:Engineering Disciplines:

Business Modeling
Requirements
Analysis and Design
Implementation
Test
Deployment

Supporting Disciplines:

Configuration and Change Management
Project Management
Environment

LimitationsIf the users of RUP do not understand that RUP is a process framework, they may perceive it as a weighty and expensive process. RUP was not intended, not envisioned and not promoted to be used straight “out of the box.” The IBM Rational Method Composer product has been created to address this limitation and help process engineers and project managers customize the RUP for their project needs. OpenUP/Basic, the lightweight and open source version of RUP, is another attempt to address this limitation.As the RUP must be customized for each project by a RUP process expert, the project’s overall success is highly dependent on the abilities of this one person. — Rajalekshmi.V Reference: http://en.wikipedia.org/wiki/Rational_Unified_Process

BASEL II

rajalekshmi — Mon, 21 Jan 2008 10:51:19 +0000

Basel II is the second of the Basel Accords, which are recommendations on banking laws and regulations issued by the Basel Committee on Banking Supervision. The purpose of Basel II, which initially was published in June 2004, is to create an international standard that banking regulators can use when creating regulations about how much capital banks need to put aside to guard against the types of financial and operational risks banks face. Advocates of Basel II believe that such an international standard can help protect the international financial system from the types of problems that might arise should a major bank or a series of banks collapse. Generally speaking, these rules mean that the greater risk to which the bank is exposed, the greater the amount of capital the bank needs to hold to safeguard its solvency and overall economic stability.Basel II uses a “three pillars” concept – (1) minimum capital requirements (addressing risk), (2) supervisory review and (3) market discipline – to promote greater stability in the financial system.

The first pillar

The first pillar deals with maintenance of regulatory capital calculated for three major components of risk that a bank faces: credit risk, operational risk and market risk. Other risks are not considered fully quantifiable at this stage. Operational risk is defined by the Basel Capital Accord as: “The risk of direct or indirect loss resulting from inadequate or failed internal processes, people and systems, or from external events.” It is not just about IT, all companies are exposed to operational risk, and the integration of processes, systems and people has to be understood and continually monitored to mitigate these risks.

The second pillar

The second pillar deals with the regulatory response to the first pillar, giving regulators much improved ‘tools’ over those available to them under Basel I. It also provides a framework for dealing with all the other risks a bank may face, such as systemic risk, pension risk, concentration risk, strategic risk, reputation risk, liquidity risk and legal risk, which the accord combines under the title of residual risk.

The third pillar

The third pillar greatly increases the disclosures that the bank must make. This is designed to allow the market to have a better picture of the overall risk position of the bank and to allow the counterparties of the bank to price and deal appropriately.

Criticisms

There are many criticisms that are made of Basel II. These include that the more sophisticated risk measures unfairly advantage the larger banks that are able to implement them and, from the same perspective, that the developing countries generally also do not have these banks and that Basel II will disadvantage the economically marginalized by restricting their access to credit or by making it more expensive.The first of these is a valid point, but it is difficult to see how this can be overcome. More risk sensitive risk measures were required for the larger, more sophisticated banks and, while the less sophisticated measures are simpler to calculate, due to their lower risk sensitivity they need to be more conservative.The second criticism has elements of truth; the better credit risks will be advantaged as banks move towards true pricing for risk. Experience with these systems in the United States and the United Kingdom, however, shows that the improved risk sensitivity means that banks are more willing to lend to higher risk borrowers, just with higher prices. Borrowers previously ‘locked out’ of the banking system have a chance to establish a good credit history.A more serious criticism is that the operation of Basel II will lead to a more pronounced business cycle. This criticism arises because the credit models used for pillar 1 compliance typically use a one year time horizon. This would mean that, during a downturn in the business cycle, banks would need to reduce lending as their models forecast increased losses, increasing the magnitude of the downturn.

reference:http://en.wikipedia.org/wiki/Basel_2

Sarbanes-Oxley Act (SOx)

rajalekshmi — Mon, 21 Jan 2008 10:49:03 +0000

A variety of complex factors created the conditions and culture in which a series of large corporate frauds occurred between 2000-2002. The spectacular, highly-publicized frauds at Enron (see Enron scandal), WorldCom, and Tyco exposed significant problems with conflicts of interest and incentive compensation practices. These frauds and others resulted in over U.S. $500 billion in market value declines. The analysis of their complex and contentious root causes contributed to the passage of SOX in 2002.The Sarbanes-Oxley Act of 2002 also known as the Public Company Accounting Reform and Investor Protection Act of 2002 and commonly called SOx or Sarbox, is a United States federal law enacted on July 30, 2002 in response to a number of major corporate and accounting scandals including those affecting Enron, Tyco International, Adelphia, Peregrine Systems and WorldCom. These scandals, which cost investors billions of dollars when the share prices of the affected companies collapsed, shook public confidence in the nation’s securities markets. This was named after sponsors Senator Paul Sarbanes (D-MD) and Representative Michael G. Oxley (R-OH). President George W. Bush signed it into law, stating it included “the most far-reaching reforms of American business practices since the time of Franklin D. Roosevelt.” The legislation establishes new or enhanced standards for all U.S. public company boards, management, and public accounting firms. It does not apply to privately held companies. The Act contains 11 titles, or sections, ranging from additional Corporate Board responsibilities to criminal penalties, and requires the Securities and Exchange Commission (SEC) to implement rulings on requirements to comply with the new law. Debate continues over the perceived benefits and costs of SOX. Supporters contend that the legislation was necessary and has played a useful role in restoring public confidence in the nation’s capital markets by, among other things, strengthening corporate accounting controls. Detractors contend that SOX was an unnecessary and costly government intrusion into corporate management that places U.S. corporations at a competitive disadvantage vis-a-vis foreign firms.The Act establishes a new quasi-public agency, the Public Company Accounting Oversight Board, or PCAOB, which is charged with overseeing, regulating, inspecting, and disciplining accounting firms in their roles as auditors of public companies. The Act also covers issues such as auditor independence, corporate governance, internal control assessment, and enhanced financial disclosure.

Overview

Sarbanes-Oxley contains 11 titles that describe specific mandates and requirements for financial reporting. Each title consists of several sections, summarized below:• TITLE I — “Public Company Accounting Oversight Board (PCAOB)” Title I establishes the Public Company Accounting Oversight Board , to provide independent oversight of public accounting firms providing audit services (”auditors”). It also creates a central oversight board tasked with registering auditors, defining the specific processes and procedures for compliance audits, inspecting and policing conduct and quality control, and enforcing compliance with the specific mandates of SOX. Title I consists of nine sections.• TITLE II, which consists of nine sections, establishes standards for external auditor independence, to limit conflicts of interest. It also addresses new auditor approval requirements, audit partner rotation policy, conflict of interest issues and auditor reporting requirements. Section 201 of this title restricts auditing companies from doing other kinds of business apart from auditing with the same clients.• TITLE III — “Corporate Responsibility”Title III mandates that senior executives take individual responsibility for the accuracy and completeness of corporate financial reports. It defines the interaction of external auditors and corporate audit committees, and specifies the responsibility of corporate officers for the accuracy and validity of corporate financial reports. It enumerates specific limits on the behaviors of corporate officers and describes specific forfeitures of benefits and civil penalties for non-compliance. For example, Section 302 implies that the company board (Chief Executive Officer, Chief Financial Officer) should certify and approve the integrity of their company financial reports quarterly. This helps establish accountability. Title III consists of eight sections.• TITLE IV — “Enhanced Financial Disclosures”Title IV consists of nine sections. It describes enhanced reporting requirements for financial transactions, including off-balance sheet transactions, pro-forma figures and stock transactions of corporate officers. It requires internal controls for assuring the accuracy of financial reports and disclosures, and mandates both audits and reports on those controls. It also requires timely reporting of material changes in financial condition and specific enhanced reviews by the SEC or its agents of corporate reports.• TITLE V — “Analyst Conflicts of Interest”Title V consists of only one section, which includes measures designed to help restore investor confidence in the reporting of securities analysts. It defines the codes of conduct for securities analysts and requires disclosure of knowable conflicts of interest.• TITLE VI — “Commission Resources and Authority”Title VI consists of four sections and defines practices to restore investor confidence in securities analysts. It also defines the SEC’s authority to censure or bar securities professionals from practice and defines conditions under which a person can be barred from practicing as a broker, adviser or dealer.• TITLE VII — “Studies and Reports”Title VII consists of five sections. These sections 701 to 705 are concerned with conducting research for enforcing actions against violations by the SEC registrants (companies) and auditors. Studies and reports include the effects of consolidation of public accounting firms, the role of credit rating agencies in the operation of securities markets, securities violations and enforcement actions, and whether investment banks assisted Enron, Global Crossing and others to manipulate earnings and obfuscate true financial conditions.• TITLE VIII — “Corporate and Criminal Fraud Accountability”Title VIII consists of seven sections and it also referred to as the “Corporate and Criminal Fraud Act of 2002.” It describes specific criminal penalties for fraud by manipulation, destruction or alteration of financial records or other interference with investigations, while providing certain protections for whistle-blowers.• TITLE IX — “White Collar Crime Penalty Enhancement”Title IX consists of two sections. This section is also called the “White Collar Crime Penalty Enhancement Act of 2002.” This section increases the criminal penalties associated with white-collar crimes and conspiracies. It recommends stronger sentencing guidelines and specifically adds failure to certify corporate financial reports as a criminal offense.• TITLE X — “Corporate Tax Returns”Title X consists of one section. Section 1001 states that the Chief Executive Officer should sign the company tax return.• TITLE XI — “Corporate Fraud Accountability”Title XI consists of seven sections. Section 1101 recommends a name for this title as “Corporate Fraud Accountability Act of 2002” . It identifies corporate fraud and records tampering as criminal offenses and joins those offenses to specific penalties. It also revises sentencing guidelines and strengthens their penalties. This enables the SEC to temporarily freeze large or unusual payments.

The effect of SOX on non-US companies

Some have asserted that Sarbanes-Oxley legislation has helped displace business from New York to London, where the Financial Services Authority regulates the financial sector with a lighter touch. In U.K. non statutory Combined Code of Corporate Governance play somewhat similar role to SOX. However, a greater amount of resources are dedicated to enforcement of securities laws in the UK than in the US. The Sarbanes-Oxley Act’s effect on Non-US companies cross-listed in the US is different on firms from developed and well regulated countries than on firms from less developed countries . Companies from badly regulated countries benefit from better credit ratings by complying to regulations in a highly regulated country (USA) that is higher than the cost, but companies from developed countries only incur the cost, since transparency is adequate in their home countries as well. On the other hand, the benefit of better credit rating also comes with listing on other stock exchanges such as the London Stock Exchange. However, the administrative cost of SOX is considered a drag on the productivity of capital regardless of the rate at which it is borrowed, and it is ironically the financial catastrophes caused by the 2000 bubble market and subsequent scandals that forced the federal reserve to flood money into the market via lower interest rates. Contrary to logical thinking, it was massive economic irresponsibility that led to improved credit ratings and lower rates.

SOX 404 and information technologyThe financial reporting processes of many companies depend to some extent on IT systems. Therefore, Information technology controls that specifically address financial risks may be within the scope of a SOX 404 assessment. Chief information officers are typically responsible for the IT organization and IT personnel may be directly involved in SOX compliance efforts.

The SOX 404 guidance requires the usage of an internal control framework, such as the COSO framework. The IT Governance Institute’s “COBIT: Control Objectives of Information and Related Technology” is also used by many companies as a framework supporting IT SOX 404 efforts. However, there are certain aspects of COBIT that are outside the boundaries of Sarbanes-Oxley regulation. IT application controls (i.e., transaction processing controls) that address specific material misstatement risks are a critical part of the SOX 404 assessment. However, the extent of SOX testing to perform related to IT General Controls (ITGC) has been a topic of contention.[19] By nature, ITGC have an indirect effect on financial statements. The 2007 SEC guidance states: “…management only needs to evaluate those ITGC that are necessary for the proper and consistent operation of other controls designed to adequately address financial reporting risks.” ITGC efforts will likely be carefully scrutinized in light of the new guidance, which encourages focus on the most critical financial risks.

reference:http://en.wikipedia.org/wiki/Sarbanes-Oxley_Act#SOX_404_and_information_technology

References :http://en.wikipedia.org/wiki/Sarbanes-Oxley_Act

Anti-money laundering (AML)

rajalekshmi — Mon, 21 Jan 2008 10:44:04 +0000

Anti-money laundering (”AML”) is a term mainly used in the financial and legal industries to describe the legal controls that require financial institutions and other regulated entities to prevent or report money laundering activities. Anti-money laundering guidelines came into prominence globally after the September 11, 2001 attacks and the subsequent enactment of the USA PATRIOT Act.Today, all financial institutions globally are required to monitor, investigate and report transactions of a suspicious nature to the financial intelligence unit of the central bank in the respective country. For example, a bank must perform due diligence by having proof of a customer’s identity and that the use, source and destination of funds do not involve money laundering. United States federal law related to money laundering is implemented under the Bank Secrecy Act of 1970 as amended by anti-money laundering acts up to the present. Many people have confused Anti-Money Laundering (”AML”) with Anti-Terrorist Financing (”ATF”). Under the Bank Secrecy Act of USA, Money Laundering and Terrorist Financing are classified into two different categories when financial institutions file Suspicious Activities Reports (”SAR”) to Financial Crimes Enforcement Network (”FinCEN”) which is a US government agency. To effectively implement AML and ATF measures, The US government encourages financial institutions to work together for AML and ATF purposes in accordance with Section 314(b) of the USA PATRIOT Act. However, since financial institutions are required by law to protect the privacy of their clients, section 314(b) cooperation has not been generally adopted by financial institutions. To overcome this obstacle, the United Crimes Elimination Network (UCEN) has been established by AML and ATF professionals to achieve this global cooperation goal in compliance with the privacy laws of most countries.

Steps in Money Laundering

Money laundering involves three independent steps that often occur simultaneously. They are:1. Placement – Physically placing bulk cash proceeds. 2. Layering – Separating the proceeds from criminal activity from their origins through layers of complex financial transactions. 3. Integration. – Providing an apparently legitimate explanation for the illicit proceeds.

Additional information

An entire industry has developed around providing software to analyze transactions in an attempt to identify transactions or patterns of transactions ,that may constitute illegal financial activity. Financial institutions face penalties for failing to properly file CTR (Cash Transaction Report) and SAR (Suspicious Activity Report) reports, including heavy fines and regulatory restrictions, even to the point of charter revocation. These software applications effectively monitor bank customer transactions on a daily basis and, using customer historical information and account profile, provide a “whole picture” to the bank management. Transaction monitoring can include cash deposits and withdrawals, wire transfers, credit card activity, cheques (checks), share (securities) dealing and ACH activity. In the bank circles, these applications are known as “BSA software” or “AML software.

Reference : http://en.wikipedia.org/wiki/Anti_Money_Laundering

Requirements Elicitation

rajalekshmi — Mon, 21 Jan 2008 10:37:49 +0000

Requirements elicitation is the first of the four steps in software requirements engineering (the others being analysis, specification, and validation). Software engineers use several elicitation techniques. Requirements elicitation is recognized as one of the most critical, knowledge-intensive activities of softwaredevelopment [1]; poor execution of elicitation will almost guarantee that the final project is a complete failure. Since project failures are so rampant [2], it is quite likely that improving how the industry performs elicitation couldhave a dramatic effect on the success record of the industry [3]. Improving requirements elicitation requires us to first understand it. A requirement is a “function or characteristic of a system that is necessary…the quantifiable and verifiable behaviors that a system must possess and constraints that a system must work within to satisfy an organization’s objectives and solve a set of problems” [STEP 91]. Similarly,“requirement” has the following definitions [IEEE 90]:(1) a condition or capability needed by a user to solve a problem or achieve anobjective; (2) a condition or capability that must be met or possessed by asystem or system component to satisfy a contract, standard, specification, orother formally imposed documents; (3) a documented representation of acondition or capability as in (1) or (2). Requirements do not only consist of functions, a misconception introduced in part because the currently popular structured analysis techniques focus on articulating functional requirements. Different authors will present different definitions, but there are clearly nonfunctional requirements as well as functional requirements. In one source, requirements are classified as follows :1. functional requirements2. nonfunctional requirementsa. performance/reliabilityb. interfacesc. design constraints Requirements elicitation was defined in a recent workshop as “the process of identifying needs and bridging the disparities among the involved communities for the purpose of defining and distilling requirements to meet the constraints of these communities”. Requirements elicitation serves as a front end to systems development. Requirements analysts, sponsors/funders, developers, and end users are involved with requirements elicitation to differing degrees, and thus requirements elicitation involves social, communicative issues as well astechnical issues . Requirements elicitation technique selection Requirements elicitation is generally performed using an elicitation methodology or a series of techniques. Many such methodologies and techniques exist, all with the common aim to assist analysts in understanding needs . Although some analysts think that just one methodology or just one technique is applicable to all situations, one methodology or technique cannot possiblybe sufficient for all conditions . Figure 5. Communication channels in elicitationAnalysts select a particular elicitation technique for any combination of four reasons: (1) It is the only technique that the analyst knows, (2) It is the analyst’s favorite technique for all situations, (3) The analyst is following some explicit methodology, and that methodology prescribes a particular technique at the current time, and (4) The analyst understands intuitively that the technique is effective in the current circumstance. Requirements Elicitation ProblemsProblems of requirements elicitation can be grouped into three categories:• problems of scope, in which the requirements may address too little or toomuch information;• problems of understanding, within groups as well as between groups such asusers and developers; and• problems of volatility, i.e., the changing nature of requirements.The list of ten elicitation problems given in one source could be classified according to this framework as follows:• problems of scope• the boundary of the system is ill-defined• unnecessary design information may be given• problems of understanding• users have incomplete understanding of their needs• users have poor understanding of computer capabilities and limitations• analysts have poor knowledge of problem domain• user and analyst speak different languages• ease of omitting “obvious” information• conflicting views of different users• requirements are often vague and untestable, e.g., “user friendly” and“robust”• problems of volatility• requirements evolve over timeThe remainder of this section will discuss these three problem areas in further detail. Current Elicitation TechniquesRequirements elicitation has received little attention in the past from the software engineering research community.From the survey, it was learned that requirements analysis, in particular requirements elicitation, is a hard task, and that it is carefully avoided by most of the software engineering researchers. We believe that most researchers avoid dealing with elicitation of requirements, because it is an area where one has to deal with informality, incompleteness and inconsistency. Instead, research labeled as dealing with requirements, usually deals with specification, and that is the main reason for the lack of agreement on the definitions of requirements analysis and specification.Despite this lack of research activity, there have been some efforts toward the development of methods and techniques to address the requirements elicitation problems discussed in the previous section. These approaches will be introduced here, along with a brief description of their proposed solutions to the problem areas of scope, understanding, and volatility. A few elicitation techniques receive more detailed treatment in the appendices. The elicitation issues discussed in the previous section were categorized as follows:• scope• organizational and contextual factors, including the identification ofsystem goals, the problem context, and boundaries and interfaces• avoidance of premature design activities• understanding• contribution of many varied stakeholder communities to elicitation• contribution of more than one person to requirements elicitation• large size of requirements and associated data resulting from elicitation• utility of multiple expressions (models) of the requirements• requirements volatility Information GatheringInterviews are perhaps the most common technique used for gathering information during requirementselicitation. There are many social aspects of dealing with users in interviews . Berlin notes that “even a few hours of interviews can be very valuable, even when conducted by engineers who have had only brief training in interviewing and userneeds analysis” The information collected through interviews can address organizational and contextual factors provided that the right questions are asked. Likewise, if the right people are interviewed the information will represent multiple stakeholders’ opinions across a number of different communities affected by the development of the proposed system being elicited.There is a lack of standardized procedures for structuring information received via interviews. Other limitations with eliciting requirements primarily or exclusively through interviews result from the tremendous responsibility placed on the requirements analyst. Assuming that interview data was collected from the different communities affected by the system being elicited,the analyst must integrate these different interpretations, goals, objectives, communication styles, and use of terminology into a single set of requirements. This integration is a difficult task unless the interviews are structured in some way. Requirements Expression and AnalysisElicitation is concerned with gathering information from various stakeholders in order to derive the requirements for a system. This collected information needs to be represented in some way, and ideally the gathered statements are expressed “in a notation which elucidates their implications, prompts further questions, correlates different aspects, and facilitates detailed analysis”. Many current elicitation approaches represent the requirements from different viewpoints, inorder to promote understanding and the gathering of information from the many communities involved in elicitation. This viewpoint approach is exemplified by CORE. • CORE provides a framework for analysis• it expresses requirements in a structured diagrammatic notation• the notation fosters communication• it is less ambiguous than natural language• CORE identifies design constraints at an early stage• CORE supports early verification because both the target system and itsenvironment are modeledThe limited tool support for CORE is noted as an inhibitor for its use on medium and large developmentprojects. GPT summarizes their assessment as “CORE is a powerful method forgathering requirements but it lacks a standard notation and effective tool support” . ValidationOne often cited technique for dealing with requirements volatility is to validate early and often that the information gathered so far and the representation of that information is consistent with the elicitation communities’ needs and expectations. This repeated validation is part of an incremental approach to elicitation. Requirements elicitation should also be interleaved with subsequent activities such as the design and early prototyping of critical components. Quality Function Deployment (QFD) is another useful technique for validation. QFD allows the “Voice of the Customer” to be captured, and then the proposed requirements of the system to be validated based on whether or not they reflect these expressed customer needs. QFD helps to identify user requirements that have not been addressed by the developer, as well as developer-proposed features that do not support any requirements. In addition to highlighting such omissions, QFD also documents requirements that are highly rated by the user and receive little attention by the developer-proposed features. Issues in Requirements ElicitationThere are many problems associated with requirements engineering, including problems in defining the system scope, problems in fostering understanding among the different communities affected by the development of a given system, and problems in dealing with the volatile nature of requirements. These problems may lead to poor requirements and the cancellation of system development, or else the development of a system that is later judged unsatisfactory or unacceptable, has high maintenance costs, or undergoes frequent changes. By improving requirements elicitation, the requirements engineering process can be improved, resulting in enhanced system requirements and potentially a much better system. Requirements engineering can be decomposed into the activities of requirements elicitation, specification, and validation. Most of the requirements techniques and tools today focus on specification, i.e., the representation of the requirements. This report concentrates instead on elicitation concerns, those problems with requirements engineering that are not adequately addressed by specification techniques. An elicitation methodology is proposed to handle these concerns.This new elicitation methodology strives to incorporate the advantages of existing elicitation techniques while comprehensively addressing the activities performed during requirements elicitation. These activities include fact-finding, requirements gathering, evaluation and rationalization, prioritization, and integration. Taken by themselves, existing elicitation techniques are lacking in one or more of these areas.Issues involved in this problem area include:• achieving requirements completeness without unnecessarily constrainingsystem design• analysis and validation difficulty• changing requirements over time Many requirements errors are passed undetected to the later phases of the life cycle, and correcting these errors during or after implementation has been found to be extremely costly . The DoD Software Technology Plan [DoD 91] states that “early defect fixes are typically two orders of magnitude cheaper than late defect fixes, and the early requirements and design defects typically leave more serious operational consequences.” One way to reduce requirements errors is by improving requirements elicitation, an activity often overlooked or only partially addressed by current requirements engineering techniques.After the role of elicitation in the requirements engineering process is defined, an outline of the remainder of the report will be presented. references :http://csdl2.computer.org/comp/proceedings/hicss/2003/1874/03/187430096a.pdf
http://csdl2.computer.org/comp/proceedings/hicss/2003/1874/03/187430096a.pdf
http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf

Https

Dominick — Fri, 28 Dec 2007 07:01:18 +0000

https is a URI scheme used to indicate a secure HTTP connection. It is syntactically identical to the http:// scheme normally used for accessing resources using HTTP. Using an https: URL indicates that HTTP is to be used, but with a different default TCP port (443) and an additional encryption/authentication layer between the HTTP and TCP. This system was designed by Netscape Communications Corporation to provide authentication and encrypted communication and is widely used on the World Wide Web for security-sensitive communication such as payment transactions and corporate logons.How it works

For more details on this topic, see Transport Layer Security#How it works.

Strictly speaking, https is not a separate protocol, but refers to the combination of a normal HTTP interaction over an encrypted Secure Sockets Layer (SSL) or Transport Layer Security (TLS) connection. This ensures reasonable protection from eavesdroppers and man-in-the-middle attacks.An https: URL may specify a TCP port; if it does not, the connection uses port 443 (unsecured HTTP typically uses port 80).To prepare a web-server for accepting https connections the administrator must create a public key certificate for the web-server. These certificates can be created for Unix based servers with tool(s) such as OpenSSL‘s ssl-ca ^[1] or SuSE‘s gensslcert. This certificate must be signed by a certificate authority of one form or another, which certifies that the certificate holder is indeed the entity it claims to be. Web browsers are generally distributed with the signing certificates of major certificate authorities, so that they can verify certificates signed by them.Organizations may also run their own certificate authority, particularly if they are responsible for setting up browsers to access their own sites (for example, sites on a company intranet), as they can trivially add their own signing certificate to those shipped with the browser.Some sites, especially those operated by hobbyists, use self-signed certificates on public sites. Using these provides protection against simple eavesdropping, but unlike a well-known certificate, preventing a man-in-the-middle attack with a self-signed certificate requires the site to make available some other secure method of verifying the certificate.The system can also be used for client authentication, in order to restrict access to a Web server to only authorized users. For this, typically the site administrator creates certificates for each user which are loaded into their browser. These normally contain the name and e-mail address of the authorized user, and are automatically checked by the server on each reconnect to verify the user’s identity, potentially without ever entering a password.

Limitaions:The level of protection depends on the correctness of the implementation by the web browser and the server software and the actual cryptographic algorithms supported.HTTPS only protects data in transit from eavesdropping and man in the middle attacks. Once data arrive at their destination, they are only as safe as the computer they are on. Gene Spafford states that it is like “using an armored truck to transport rolls of pennies between someone on a park bench and someone doing business from a cardboard box.”^[2]Because SSL operates below http and has no knowledge of higher level protocols, SSL servers can only present one certificate

Extreme Programming

pkramya — Fri, 28 Dec 2007 07:00:12 +0000

Extreme Programming (or XP) is a software engineering methodology, one of several agile software development methodologies, prescribing a set of daily stakeholder practices that embody and encourage particular XP values. Proponents believe that exercising these practices—traditional software engineering practices taken to so-called “extreme” levels—leads to a development process that is more responsive to customer needs (“agile”) than traditional methods, while creating software of better quality.Proponents of XP and agile methodologies in general regard ongoing changes to requirements as a natural, inescapable and desirable aspect of software development projects; they believe that adaptability to changing requirements at any point during the project life is a more realistic and better approach than attempting to define all requirements at the beginning of a project and then expending effort to control changes to the requirements.Goal of XPExtreme Programming Explained describes Extreme Programming as being:

An attempt to reconcile humanity and productivity
A mechanism for social change
A path to improvement
A style of development
A software development discipline

The main aim of XP is to reduce the cost of change. In traditional system development methods (such as SSADM) the requirements for the system are determined at the beginning of the development project and often fixed from that point on. This means that the cost of changing the requirements at a later stage (a common feature of software engineering projects) will be high.XP sets out to reduce the cost of change by introducing basic values, principles and practices. By applying XP, a system development project should be more flexible with respect to changes.

XP values

Extreme Programming initially recognized four values in 1999. A new value was added in the second edition of Extreme Programming Explained. The five values are:

Building software systems requires communicating system requirements to the developers of the system. In formal software development methodologies, this task is accomplished through documentation. Extreme Programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team. The goal is to give all developers a shared view of the system which matches the view held by the users of the system. To this end, Extreme Programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback.Extreme Programming encourages starting with the simplest solution. Extra functionality can then be added later. The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow, next week, or next month. Proponents of XP acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system; their claim is that this is more than compensated for by the advantage of not investing in possible future requirements that might change before they become relevant. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed. Related to the “communication” value, simplicity in design and coding should improve the (quality of) communication. A simple design with very simple code could be easily understood by most programmers in the team.Within Extreme Programming, feedback relates to different dimensions of the system development:

Feedback from the system: by writing unit tests, or running periodic integration tests, the programmers have direct feedback from the state of the system after implementing changes.
Feedback from the customer: The functional tests (aka acceptance tests) are written by the customer and the testers. They will get concrete feedback about the current state of their system. This review is planned once in every two or three weeks so the customer can easily steer the development.
Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement.

Feedback is closely related to communication and simplicity. Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break. The direct feedback from the system tells programmers to recode this part. A customer is able to test the system periodically according to the functional requirements (aka user stories). To quote Kent Beck, “Optimism is an occupational hazard of programming, feedback is the treatment.”Several practices embody courage. One is the commandment to always design and code for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else. Courage enables developers to feel comfortable with refactoring their code when necessary. This means reviewing the existing system and modifying it so that future changes can be implemented more easily. Another example of courage is knowing when to throw code away: courage to remove source code that is obsolete, no matter how much effort was used to create that source code. Also, courage means persistence: A programmer might be stuck on a complex problem for an entire day, then solve the problem quickly the next day, if only they are persistent.The respect value manifests in several ways. In Extreme Programming, team members respect each other because programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers. Members respect their work by always striving for high quality and seeking for the best design for the solution at hand through refactoring.Adopting four earlier values led to respect gained from others in team. Nobody on the team should feel unappreciated or ignored. This ensures high level of motivation and encourages loyalty toward the team, and the goal of the project. This value is very dependent upon the other values, and is very much oriented toward people in a team.

Principles

The principles that form the basis of XP are based on the values just described and are intended to foster decisions in a system development project. The principles are intended to be more concrete than the values and more easily translated to guidance in a practical situation.Feedback is most useful if it is done rapidly. The time between an action and its feedback is critical to learning and making changes. In Extreme Programming, unlike traditional system development methods, contact with the customer occurs in small iterations. The customer has clear insight into the system that is being developed. He or she can give feedback and steer the development as needed.Unit tests also contribute to the rapid feedback principle. When writing code, the unit test provides direct feedback as to how the system reacts to the changes one has made. If, for instance, the changes affect a part of the system that is not in the scope of the programmer who made them, that programmer will not notice the flaw. There is a large chance that this bug will appear when the system is in production.Assuming simplicity is about treating every problem as if its solution were “extremely simple”. Traditional system development methods say to plan for the future and to code for reusability. Extreme programming rejects these ideas.The advocates of Extreme Programming say that making big changes all at once does not work. Extreme Programming applies incremental changes: for example, a system might have small releases every three weeks. By making many little steps the customer has more control over the development process and the system that is being developed.The principle of embracing change is about not working against changes but embracing them. For instance, if at one of the iterative meetings it appears that the customer’s requirements have changed dramatically, programmers are to embrace this and plan the new requirements for the next iteration.ReferencewikipediaBy P.K.Ramya

Data mining

pkramya — Fri, 28 Dec 2007 06:59:24 +0000

Data mining is the principle of sorting through large amounts of data and picking out relevant information. It is usually used by business intelligence organizations, and financial analysts, but it is increasingly used in the sciences to extract information from the enormous data sets generated by modern experimental and observational methods. It has been described as “the nontrivial extraction of implicit, previously unknown, and potentially useful information from data” and “the science of extracting useful information from large data sets or databases”.Data mining parameters include:

Association – looking for patterns where one event is connected to another event
Sequence or path analysis – looking for patterns where one event leads to another later event
Classification – looking for new patterns (May result in a change in the way the data is organized but that’s ok)
Clustering – finding and visually documenting groups of facts not previously known
Forecasting – discovering patterns in data that can lead to reasonable predictions about the future (This area of data mining is known as predictive analytics.)

BackgroundTraditionally, analysts have performed the task of extracting useful information from recorded data. But, the increasing volume of data in modern business and science calls for computer-based approaches. As data sets have grown in size and complexity, there has been an inevitable shift away from direct hands-on data analysis toward indirect, automatic data analysis using more complex and sophisticated tools. The modern technologies of computers, networks, and sensors have made data collection and organization an almost effortless task. However, the captured data needs to be converted into information and knowledge to become useful. Data mining is the entire process of applying computer-based methodology, including new techniques for knowledg discovery, from data.Data mining identifies trends within data that go beyond simple analysis. Through the use of sophisticated algorithms, users have the ability to identify key attributes of business processes and target opportunities.Although data mining is a relatively new term, the technology is not. Companies for a long time have used powerful computers to sift through volumes of data such as supermarket scanner data to produce market research reports. Continuous innovations in computer processing power, disk storage, and statistical software are dramatically increasing the accuracy and usefulness of analysis.The term data mining is often used to apply to the two separate processes of knowledge discovery and prediction. Knowledge discovery provides explicit information that has a readable form and can be understood by a user. Forecasting, or predictive modeling provides predictions of future events and may be transparent and readable in some approaches (e.g. rule based systems) and opaque in others such as neural networks. Moreover, some data mining systems such as neural networks are inherently geared towards prediction and pattern recognition, rather than knowledge discovery.Metadata, or data about a given data set, are often expressed in a condensed data mine-able format, or one that facilitates the practice of data mining. Common examples include executive summaries and scientific abstracts.OverviewData mining, the extraction of hidden predictive information from large databases, is a powerful new technology with great potential to help companies focus on the most important information in their data warehouses. Data mining tools predict future trends and behaviors, allowing businesses to make proactive, knowledge-driven decisions. The automated, prospective analyses offered by data mining move beyond the analyses of past events provided by retrospective tools typical of decision support systems. Data mining tools can answer business questions that traditionally were too time consuming to resolve. They scour databases for hidden patterns, finding predictive information that experts may miss because it lies outside their expectations.Most companies already collect and refine massive quantities of data. Data mining techniques can be implemented rapidly on existing software and hardware platforms to enhance the value of existing information resources, and can be integrated with new products and systems as they are brought on-line. When implemented on high performance client/server or parallel processing computers, data mining tools can analyze massive databases to deliver answers to questions such as, “Which clients are most likely to respond to my next promotional mailing, and why?”This white paper provides an introduction to the basic technologies of data mining. Examples of profitable applications illustrate its relevance to today’s business environment as well as a basic description of how data warehouse architectures can evolve to deliver the value of data mining to end users.The Foundations of Data MiningData mining techniques are the result of a long process of research and product development. This evolution began when business data was first stored on computers, continued with improvements in data access, and more recently, generated technologies that allow users to navigate through their data in real time. Data mining takes this evolutionary process beyond retrospective data access and navigation to prospective and proactive information delivery. Data mining is ready for application in the business community because it is supported by three technologies that are now sufficiently mature:

Massive data collection
Powerful multiprocessor computers
Data mining algorithms

The Scope of Data MiningData mining derives its name from the similarities between searching for valuable business information in a large database — for example, finding linked products in gigabytes of store scanner data — and mining a mountain for a vein of valuable ore. Both processes require either sifting through an immense amount of material, or intelligently probing it to find exactly where the value resides. Given databases of sufficient size and quality, data mining technology can generate new business opportunities by providing these capabilities:

Automated prediction of trends and behaviors. Data mining automates the process of finding predictive information in large databases. Questions that traditionally required extensive hands-on analysis can now be answered directly from the data — quickly. A typical example of a predictive problem is targeted marketing. Data mining uses data on past promotional mailings to identify the targets most likely to maximize return on investment in future mailings. Other predictive problems include forecasting bankruptcy and other forms of default, and identifying segments of a population likely to respond similarly to given events.

Automated discovery of previously unknown patterns. Data mining tools sweep through databases and identify previously hidden patterns in one step. An example of pattern discovery is the analysis of retail sales data to identify seemingly unrelated products that are often purchased together. Other pattern discovery problems include detecting fraudulent credit card transactions and identifying anomalous data that could represent data entry keying errors.

Data mining techniques can yield the benefits of automation on existing software and hardware platforms, and can be implemented on new systems as existing platforms are upgraded and new products developed. When data mining tools are implemented on high performance parallel processing systems, they can analyze massive databases in minutes. Faster processing means that users can automatically experiment with more models to understand complex data. High speed makes it practical for users to analyze huge quantities of data. Larger databases, in turn, yield improved predictions.Databases can be larger in both depth and breadth:

More columns. Analysts must often limit the number of variables they examine when doing hands-on analysis due to time constraints. Yet variables that are discarded because they seem unimportant may carry information about unknown patterns. High performance data mining allows users to explore the full depth of a database, without preselecting a subset of variables.

More rows. Larger samples yield lower estimation errors and variance, and allow users to make inferences about small but important segments of a population.

Referencesreference1 reference2By P.K.Ramya