Need to apply RAD Technique
-Speeding up of development process which is very important in today’s business environment.
-To speedily create and amend info systems in organization in order to support the continuous changing business environment

NB: There is need to harness the characteristics of RAD so that most flexible and quality systems are delivered in the shortest time scale possible.

Characteristics of RAD
-Use of evolutionary prototyping techniques operating in an environment of high delivery time scales.
-To focus upon the identification of important users and involving them in workshops at early stages of development.
-Obtaining commitment from the business users
-The use of CASE integrated development environment

Concepts of RAD
RAD was traditionally viewed as quick fix approach but not a technique to deliver quality systems.
It was seen as a way of setting up a system quickly using a 4GL tools and DBMS products without the quality controls associated with other development projects.

The two common approaches used are:
1) The work of James Martin (1991)
Context of Information Engineering
2) Dynamic System Development Method (DSDM)
Is a framework and standards of RAD formed by a consortium of UK companies in January 1994.

Phases of RAD
a) Requirement Analysis
This concerns the definition of requirements. The techniques used in this phase are:
i. Joint Requirements Planning (JRP)
ii. Joint Application Development (JAD)

Both of these techniques are based on workshops or structured meetings.
i. Joint Requirements Planning (JRP)
The role of JRP is to identify the high level management requirements of the system at a strategic level. The participants are senior managers who have visions and understanding of the overall objective of the system and how it can contribute to the goals and strategies of the organization.
The workshops may be used to help determine those goals when they are not well understood.
JRP is a creative workshop that helps to:
 Identify and create commitment to the goals of the system .
 Identify priorities
 Eliminate unnecessary functions

The difference between JRP & JAD is that different people are involved.
In JRP the participants need to have a contribution of overall business knowledge and specific knowledge about the proposed system with its requirements.
They also need to have the necessary authority and seniority to be able to make decisions and commitments.
It is suggested that if the right people are not available without referring to their seniors negates the RAD objectives which is to get requirements identified agreed in the shortest time possible.
b) User design
The main technique used in this phase is JAD in reality, user design is both analysis and design. Thus the JRP workshops may be combined with JAD in situations where the overall requirements are well established.
Normally, however JAD would follow on from JRP

c) Construction Phase
The construction phase in RAD concerns taking of the user design through detailed design and code generation.This phase is carried out by the IS professionals using CASE tools.
The construction highly depends on the uses of info engineering based case tools and prototyping.

The prototype are reviewed by the key users for approval where they are not approved, the requested changes are effected through series of interaction which are achieved quickly and testing enabled by use of CASE tools and prototyping.

Construction is performed by small teams of 3 to 4 experts in the use of CASE tools. The teams are kept small so as to reduce the number of interfaces and interactions between people in the teams.

They are required to work quickly, making maximum possible use of re-usable designs already in existence.

Large teams of developers would require large communication network and a number of communication resulting in low productivity as in the traditional development.
There should be a developer for each part of the system so as to reduce the number of potential interactions with other developers.
Using this approach the system can be viewed as quickly as 4-6 weeks and progressively refined and integrated with other aspects developed by other team members.

Once the detailed designs are agreed upon the code generated using the CASE tool and then the system is tested and approved.

All associated documentation is then produced and database optimization is then performed.

d) Cut-over:

This is the final phase that involves testing and the use of realistic data in operational situations. The users are trained on the system. The organization changes.
Implied by the system is implemented. The cut-over is finally effected by running the old and the new system in particular until the new system has proved itself. The old system is then phased out.

Related Topics

• No Related Post

It was initially defined by a consortium of UK RAD users and suppliers. The consortium consisted of many large organizations that had used the concept of RAD and now wanted to develop a generic framework that could be used.

The initial framework was approved and version one was published in Feb 95. Version 1 of DSDM consisted of

1) 13 Principles
2) Project Management
3) Team Structures
4) Prototyping

Feedback from the early users of DSDM led to the release of subsequent versions. In December 1995 version 2 was published. In version 2 the 13 principles were reduced to 9 principles.
In October 1997 version 3 was published.
These developments reflected the increasing use of DSDM in business process change projects.
Since then DSDM has been used successfully by organizations in public and private sectors.
Applications built using DSDM approach address the current and imminent needs for the business rather than the traditional approach of attacking all the perceived possibilities.
The resulting computer system is, therefore, expected to be a better fit in the true business needs, easier to test and more likely to be accepted to the users working practices.

DSDM provides a holistic approach to software development in a RAD project environment.
Many software development methods focus purely on one activity even as analysis and design or project management.
DSDM provides a development life cycle supported by all the necessary controls.

Overview
There are 4 philosophies behind the development of DSDM namely:

a) Mode of Development:

Development should be a team effort consisting of the users and IT professionals with the following roles
Users: Provide the good understanding of the business requirements
IT professionals: Provide the technical know-how

b) Quality Demands

High development quality is demanded in order for it to suit the users needs as well as technical competence and robustness.

c) Deadline for Delivery

Development can be delivered in incremental stages. It is better to deliver part of the development in time rather than everything way past the acceptable deadline.

In deed, a fundamental assumption of DSDM is that noting is built perfectly for the first time, but that a usable and useful 80% of the proposed system can be produced in 20% of the time it would take to produce the total system.

d) Resources Requirement:

It has to be accepted that resources will be spent if development of IS of value to the organization is to be realized in time.

It should be noted that DSDM is viewed as a framework of controls for the development of IT systems to tight time scales and a guidance of how to apply the controls and concepts of RAD rather than the view of method/methodology.

DSDM is independent of any particular set of tools and techniques and could be used by object oriented and structured analysis and design approaches in environment ranging from the individual PC to global distributed system.
DSDM defines set of process and products at a high level to give flexibility to the approach.
Developers may choose any technique, but conform to the DSDM guidelines and controls.
In a RAD environment DSDM addresses the following. These factors are:

- Project management - Testing
- Estimation - Quality Assurance
- Time boxing - Team structures
- Prototyping - Tools
- Configuration Management - Risk management

SUMMARY:
DSDM: Note:
Tools and techniques: The tools and techniques of DSDM should enable:

- Rapid development
- Users to be involved
- Support of interactive development
- The building of acceptable user interface
- Support of …… and provide good documentations.

People and Teams:

- Involve users all through
- Empower teams
- Establish key roles

Management:
- Plan for interactive delivery ie. Deliver things in bits
- Plant for continuous testing
- Plan for constant review of prototypes and progress.

Time-boxing:
- is a technique to make RAD more measurable and controllable.

Related Topics

• No Related Post

Certification and accreditation documentation
According to Howard the approving authority needs to see only documentation describing the system, its environment, identified controls that protect the system and the status of those controls. So the approving authority needs to see a certification package that includes a system security plan, risk assessment, certification test plan and result, remediation plan and a certification statement.

A certification statement is a document prepared by a certifying agent showing the system has been properly certified. It shows tasks carried out during the certification process, findings, remediation recommendations and residual risk for which acceptance is recommended. The certification package is given to the approving authority for review and approval.

Documenting the accreditation decision
An accreditation decision allows the system to operate in its current security posture. This is done by signing the accreditation letter done by the approving authority indicating that they have considered all the risks and have decided to let the system operate.

The approving authority must receive the certification package with a signature from the certifying agent and also a review done by system owners and their staff. The package should then be reviewed and comments posted by interested parties such as the CISO, CFO, legal consul etc. the system owner develops an accreditation letter for the approving authority to sign.
The system owner must then indicate the next schedule for re-certification and should keep track of any corrective actions that are taken, any changes to the system environment and their impact on the controls should be assessed periodically.

Related Topics

• No Related Post

The scope of the test plan is driven by the range of control requirements applicable to the system. test requirements focuses on the type of controls to be tested. Testing approach defines in general how testing will be done i.e. the methodology to be used. Test plan also describes the specific tests to be used to test each control, the schedule when the testing will begin and end and also describes the test team.

The test plan must be approved and carried out and the results should indicate each control and rank it as either pass or fail and if there were any deviation from the test plan it must be documented.

Related Topics

• No Related Post

Risk assessment involves identification of assets and begins with defining the system i.e. what kind of system it is? The scope of the risk assessment defines whether risk assessment will be done on general support system (GSS), major applications, business unit process etc. after defining the scope of risk assessment, the assets such as hardware, software, data facilities and people are identified and documented.

Threat identification follows and it involves identifying and categorizing the threats. It also involves identifying the likelihood of occurrence of the threat and its impact. Vulnerability assessment is done and it involves identifying actual vulnerabilities to the assets. It’s done by assessing the available security controls against minimum security baseline and then against existing controls plus identified threats. Any control that doesn’t adequately protect against the identified threats is classified as vulnerability. The results of the risk assessment are classified are documented and put in a report. Management should use the report to select controls.

Related Topics

• No Related Post

Minimum security baselines need to be created in a way that they reflect actual business needs based on risk assessment to an organization. Initial enterprise wide risk assessment can be used to determine the basis for selecting industry accepted minimum security baseline set. Organizations can pick minimum security baseline from international bodies such as ISO, NIST, GASSP etc. these minimum security baseline should include the organization’s policies, management statements, operational rules, laws and regulations. Organizations should adopt a security baseline set which they know they can implement.

Related Topics

• No Related Post

A security plan can be initiated at any point in the certification and accreditation process but concluded before accreditation decision is made. A security plan document should bring together various information gathered from other areas like risk assessment, control data from security test and evaluation etc.

System security plan is a document that needs to be constantly updated. Procedures indicating who is responsible for reviewing the document should be put in place. The certification agent is the one responsible for confirming that the controls documented in the security plan conform to FIPs 199 while the information system owner together with the Information system security officer (ISSO) and the senior agency information security officer (SAISO) are responsible for developing the security plan, maintaining the plan and ensuring users get the necessary training to implement the controls.

The certification agent at the behest of the system owner approves the security plan and then the system owner reviews the document and approves it and forwards it to the system owner to be packaged as part of the certification and accreditation process.

A security plan contents consist of
System description i.e. the business function the system supports, purpose of the system, the environment in which the system operates in terms of hardware, software, system configuration, data flows, interconnection with other systems, user community supported by the system, access to the system, status of the system, whose is responsible for the system and its protection, security levels within the user community interacting with the system etc.

Description of controls i.e. description of all the controls in the system, the control requirements and the implementation status of each control and justification of those controls not implemented.
System security roles and responsibilities indicates the title, name, office, address, phone number, email, of the people responsible for the security of the system i.e. the system owner, security officer, system administrator, security manager, database administrator, approving authority, users community and developer of the system.

Security related business driver i.e. external requirements that drive security controls such as legal operational, contractual, regulatory etc.

Information categories indicate all the kinds of information processed by the system, the sensitivity of the information and the impact to the organization on the confidentiality, integrity and availability of the information is breached.

Interconnectivity is another aspect of the security plan. It deals with how the system is interconnected to other systems, its dependencies, the data input and output flow. If possible they should graphically be depicted. (Howard, 2006)

System certification level indicates what effort needs to be put in place so as to provide the necessary security controls.

Rules of behavior: acts as a basis of user awareness and training and as a way of users accepting their role and responsibility in securing the system. It also indicates the disciplinary actions that might be taken and the proper use of the system. Users sign documents indicating their acceptance of the rules (OMB A-130)

Plan development information: this section talks about the plan, how it was developed, what methodology was used, who developed it, source documentation, authority for developing the plan etc. (Howard, 2006)

Related Topics

• No Related Post

In terms of confidentiality, data should be assessed on the basis of its need for protection against disclosure. the organization needs to assess the nature of information or data being processed, assess the impact of unauthorized disclosure of that information on the organization and that would enable the organization to assess the level of confidentiality that the information requires.

Integrity means that the data must be protected from unauthorized modification. The level of protection placed on data integrity depends on the loss incurred if the data was modified or altered by an unauthorized individual. Also it depends on other security objectives put on that data such as authenticity, accountability and non repudiation e.g. electronic transactions rely a lot on integrity and non repudiation.

Availability means how long an organization will accept the non availability of its data. to determine the appropriate level of security placed on availability of data, one needs to consider issues like timeliness i.e. the need for data to be available to users on a timely basis, period of operation i.e. protection of data needs to be high during the period of operation when systems are most critical to the business function it supports.

Data sensitivity assessment should be done by the system owner. The system owner is responsible for basically defining the sensitivity of data, their system processes and in some cases they might need the assistance of data owners who tend to have a better understanding of what the data means and how it’s applied in combination with other systems. The organization needs to come up with a certain criteria for ranking data sensitivity. It can be ranked according to type of information processed e.g. public, financial, personal etc or according to regulatory requirements e.g. contractual, operational, legal requirements. Data sensitivity can also be ranked using terms such as low, moderate, high or using numeric such as 1, 2, and 3 or color schemes such as red, amber, and green.

Data criticality is used in relation to the system. It defines the importance of the system to the organization i.e. how long can the organization accept the non availability of a system. When assessing the criticality of the system, one needs to define which business activity is considered critical to the overall mission of the organization. The assessment of the system should always be categorized as mission-critical or non mission-critical.

A system can be ranked on its criticality based on the following aspects: financial impact that an organization has to achieve due to the system being at risk, harmed or unavailable, operational importance of the system to the mission of the organization and breadth/scope of impact of the system and also the importance of the system based on health, life and safety consideration.

An organization can use business impact analysis as a tool to quantify or measure the criticality of the system based on the time i.e. how long an organization can tolerate the non availability of the system. It also considers disaster recovery/contingency planning as part of the measure. Critical systems are often expressed as critical or non critical and sometimes in terms of high, moderate and low.

Related Topics

• No Related Post

General support systems (GSS) are defined as “interconnected set of information resources under the same direct management control that shares common functionality. This includes hardware, software, information, data, applications and people.” (OMB A-130, 2000)

After identification a determination is then made as to the sensitivity of information they process. Sensitivity of data relates to its integrity, confidentiality and availability (CIA). After determining information sensitivity, the next thing is to determine importance of the mission of the system and this relates to the availability aspect of CIA i.e. how long can an organization accept the non availability of the system? (Howard, 2006)

After determining information sensitivity and critical mission, major applications are identified by looking at all applications and determining which qualifying as major applications and non major applications. Non major applications are then mapped to general support systems.

Major applications are defined as “an application that requires special attention to its security due to the risk and magnitude of harm resulting from loss, misuse or unauthorized access to or modification of the information in the application.” (OMB A-130, 2000)

All this information is documented and presented to the chief information officer for review by the business unit executive and the chief information officer .after which the inventory is then published.

Major applications and general support systems are identified and categorized into separate assets so as not to place security emphasis where it’s not needed e.g. investing in expensive controls for general support systems like Ms Word, Spreadsheets etc. it is important when collecting system inventory to minimize the amount of information collected. Emphasis should be placed on name of system, description of the system, status of the system (operation or in development), list of systems its connected to , data sensitivity impacts, mission criticality ranking and identification of the system’s point of contact (owner, approving authority, ISSO) and name of individual authorizing submission.

Three tools are used in managing the system inventory program. These are inventory form, an inventory change form and an organization inventory summary. These three tools can be combined into one through an automation tool. Inventory form is used to collect system inventory information while inventory change form indicates updates to the inventory and the organization inventory summary indicates the current accurate assessment of what is the organization’s system inventory i.e. general support system and major applications.

Related Topics

• No Related Post

The project manager needs to develop a work plan that will be used to develop a schedule, project activities, milestones and deliverables. The project manager must also make assumptions in situations where some issues are not well defined. These assumptions should be included in the work plan and sorted out by management to turn them into known planning factors. Assumptions can include sufficient manpower, time, scope changes, money etc.

The project manager also needs to draft a project agreement that outlines expectations of the project team, their mission, scope, team composition, deliverables, approach, project activities and schedule. He also needs to develop a standard reporting format and procedures so as to improve communication between team members and also between the project manager and management.

Accurate and constant reporting helps improve support and cooperation from management because they feel as part of the process and they are in the loop about what is going on, what is required and problems encountered.

Related Topics

• No Related Post