Wednesday, December 30, 2009

MIS2 assignment4

You were invited by the university president to prepare an IS plan for the university, discuss what are the steps in order to expedite the implementation of the IS Plan.
In creating IS plan for the university there are many things to tackled and talked about .Some of these are we should analyze positive and negative effect of the plan , understand the role of ISP , know the risk management of the plan ,how to implement those plan .
Planning for information systems, as for any other system, begins with the identification of needs. In order to be effective, development of any type of computer-based system should be a response to need--whether at the transaction processing level or at the more complex information and support systems levels. Such planning for information systems is much like strategic planning in management. Objectives, priorities, and authorization for information systems projects need to be formalized. The systems development plan should identify specific projects slated for the future, priorities for each project and for resources, general procedures, and constraints for each application area. The plan must be specific enough to enable understanding of each application and to know where it stands in the order of development. Also the plan should be flexible so that priorities can be adjusted if necessary. King (King, 1995) in his recent article has argued that a strategic capability architecture - a flexible and continuously improving infrastructure of organizational capabilities – is the primary basis for a company's sustainable competitive advantage. He has emphasized the need for continuously updating and improving the strategic capabilities architecture. SISP is the analysis of a corporation’s information and processes using business information models together with the evaluation of risk, current needs and requirements. The result is an action plan showing the desired course of events necessary to align information use and needs with the strategic direction of the company (Battaglia, 1991). The same article emphasizes the need to note that SISP is a management function and not a technical one. This is consistent with the earlier distinction between the older data processing views and the modern strategic importance view of Information Systems. SISP thus is used to identify the best targets for purchasing and installing new management information systems and help an organization maximize the return on its information technology investment. A portfolio of computer-based applications is identified that will assist an organization in executing its business plans and realize its business goals. There is a growing realization that the application of information technology (IT) to a firm’s strategic activities has been one of the most common and effective ways to improve business performance.

This paper reviews the existing methodologies for SISP in an attempt to answer the critical question: how to move ahead and further improve the effectiveness of strategic planning for information-based enterprises? In particular, we examine their capacity for driving the development of corporate information systems ensuing the planning, and their potential to support economic evaluations of information systems investments.

The Perspective of Strategic Information Systems Planning
In order to put the planning for strategic information systems in perspective, the evolution of information systems according to the three-era model of John Ward, et al.(1990) is pertinent.According to this model there are three distinct, albeit overlapping, eras of information systems, dating back to the 60’s. The relationship over time of the three eras of information systems isshown in table 1:
business strategy, enable the business -business driven.

Strategic Information Systems Planning Methodologies
The task of strategic information systems planning is difficult and often time organizations do not know how to do it. Strategic information systems planning is a major change for organizations, from planning for information systems based on users’ demands to those based on business strategy. Also strategic information systems planning changes the planning characteristics in major ways. For example, the time horizon for planning changes from 1 year to 3 years or more and development plans are driven by current and future business needs rather than incremental user needs. Increase in the time horizon is a factor which results in poor response from the top management to the strategic information systems planning process as it is difficult to hold their attention for such a long period. Other questions associated with strategic information systems planning are related to the scope of the planning study, the focus of the planning exercise – corporate organization vs. strategic business unit, number of studies and their sequence, choosing a strategic information systems planning methodology or developing one if none is suitable, targets of planning process and deliverables. Because of the complexity of the strategic information systems planning process and uniqueness of each organization, there is no one best way to tackle it. Vitale, et al. (1986) classify SISP methodologies into two categories: impact and alignment. Impact methodologies help create and justify new uses of IT, while the methodologies in the “alignment”
Characteristics of a Quality ISP
A quality ISP must exhibit five distinct characteristics before it is useful. These five are presented in the table that follows.
Characteristic
Description
Timely
The ISP must be timely. An ISP that is created long after it is needed is useless. In almost all cases, it makes no sense to take longer to plan work than to perform the work planned.
Useable
The ISP must be useable. It must be so for all the projects as well as for each project. The ISP should exist in sections that once adopted can be parceled out to project managers and immediately started.
Maintainable
The ISP must be maintainable. New business opportunities, new computers, business mergers, etc. all affect the ISP. The ISP must support quick changes to the estimates, technologies employed, and possibly even to the fundamental project sequences. Once these changes are accomplished, the new ISP should be just a few computer program executions away.
Quality
While the ISP must be a quality product, no ISP is ever perfect on the first try. As the ISP is executed, the metrics employed to derive the individual project estimates become refined as a consequence of new hardware technologies, code generators, techniques, or faster working staff. As these changes occur, their effects should be installable into the data that supports ISP computation. In short, the ISP is a living document. It should be updated with every technology event, and certainly no less often than quarterly.
Reproducible
The ISP must be reproducible. That is, when its development activities are performed by any other staff, the ISP produced should essentially be the same. The ISP should not significantly vary by staff assigned.

Whenever a proposal for the development of an ISP is created it must be assessed against these five characteristics. If any fail or not addressed in an optimum way, the entire set of funds for the development of an ISP is risked.

Risk management
Risk management can therefore be considered the identification, assessment, and prioritization of risks followed by coordinated and economical application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events[1] or to maximize the realization of opportunities. Risks can come from uncertainty in financial markets, project failures, legal liabilities, credit risk, accidents, natural causes and disasters as well as deliberate attacks from an adversary. Several risk management standards have been developed including the Project Management Institute, the National Institute of Science and Technology, actuarial societies, and ISO standards.[2][3] Methods, definitions and goals vary widely according to whether the risk management method is in the context of project management, security, engineering, industrial processes, financial portfolios, actuarial assessments, or public health and safety.
The strategies to manage risk include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk.
Certain aspects of many of the risk management standards have come under criticism for having no measurable improvement on risk even though the confidence in estimates and decisions increase.

Create a risk-management plan
Select appropriate controls or countermeasures to measure each risk. Risk mitigation needs to be approved by the appropriate level of management. For example, a risk concerning the image of the organization should have top management decision behind it whereas IT management would have the authority to decide on computer virus risks.
The risk management plan should propose applicable and effective security controls for managing the risks. For example, an observed high risk of computer viruses could be mitigated by acquiring and implementing antivirus software. A good risk management plan should contain a schedule for control implementation and responsible persons for those actions.
According to ISO/IEC 27001, the stage immediately after completion of the Risk Assessment phase consists of preparing a Risk Treatment Plan, which should document the decisions about how each of the identified risks should be handled. Mitigation of risks often means selection of security controls, which should be documented in a Statement of Applicability, which identifies which particular control objectives and controls from the standard have been selected, and why.


Method
For the most part, these methods consist of the following elements, performed, more or less, in the following order.
identify, characterize, and assess threats
assess the vulnerability of critical assets to specific threats
determine the risk (i.e. the expected consequences of specific types of attacks on specific assets)
identify ways to reduce those risks
prioritize risk reduction measures based on a strategy
Principles of risk management
The International Organization for Standardization identifies the following principles of risk management:[4]
Risk management should...
create value.
be an integral part of organizational processes.
be part of decision making.
explicitly address uncertainty.
be systematic and structured.
be based on the best available information.
be tailored.
take into account human factors.
be transparent and inclusive.
be dynamic, iterative and responsive to change.
be capable of continual improvement and enhancement
Risk management and business continuity
Risk management is simply a practice of systematically selecting cost effective approaches for minimising the effect of threat realization to the organization. All risks can never be fully avoided or mitigated simply because of financial and practical limitations. Therefore all organizations have to accept some level of residual risks.
Whereas risk management tends to be preemptive, business continuity planning (BCP) was invented to deal with the consequences of realised residual risks. The necessity to have BCP in place arises because even very unlikely events will occur if given enough time. Risk management and BCP are often mistakenly seen as rivals or overlapping practices. In fact these processes are so tightly tied together that such separation seems artificial. For example, the risk management process creates important inputs for the BCP (assets, impact assessments, cost estimates etc). Risk management also proposes applicable controls for the observed risks. Therefore, risk management covers several areas that are vital for the BCP process. However, the BCP process goes beyond risk management's preemptive approach and moves on from the assumption that the disaster will realize at some point.
What are the phases and steps in information system development?
· Planning,
· Analysis
· Design
· Development
· Testing
· Deployment
· Maintenance


Planning
Planning is a process for accomplishing purpose. It is blue print of business growth and a road map of development. It helps in deciding objectives both in quantitative and qualitative terms. It is setting of goals on the basis of objectives and keeping in view the resources.
What should a plan be?
A plan should be a realistic view of the expectations. Depending upon the activities, a plan can be long range, intermediate range or short range. It is the framework within which it must operate. For management seeking external support, the plan is the most important document and key to growth. Preparation of a comprehensive plan will not guarantee success, but lack of a sound plan will almost certainly ensure failure.
Purpose of Plan
Just as no two organizations are alike, so also their plans. It is therefore important to prepare a plan keeping in view the necessities of the enterprise. A plan is an important aspect of business. It serves the following three critical functions:
Helps management to clarify, focus, and research their business's or project's development and prospects.
Provides a considered and logical framework within which a business can develop and pursue business strategies over the next three to five years.
Offers a benchmark against which actual performance can be measured and reviewed.
Importance of the planning Process
A plan can play a vital role in helping to avoid mistakes or recognize hidden opportunities. Preparing a satisfactory plan of the organization is essential. The planning process enables management to understand more clearly what they want to achieve, and how and when they can do it.
A well-prepared business plan demonstrates that the managers know the business and that they have thought through its development in terms of products, management, finances, and most importantly, markets and competition.
Planning helps in forecasting the future, makes the future visible to some extent. It bridges between where we are and where we want to go. Planning is looking ahead.

Analysis
Business analysis as a discipline has a heavy overlap with requirements analysis sometimes also called requirements engineering, but focuses on identifying the changes to an organization that are required for it to achieve strategic goals. These changes include changes to strategies, structures, policies, processes, and information systems.
Examples of business analysis include:
Enterprise analysis or company analysis
focuses on understanding the needs of the business as a whole, its strategic direction, and identifying initiatives that will allow a business to meet those strategic goals.
Requirements planning and management
involves planning the requirements development process, determining which requirements are the highest priority for implementation, and managing change.
Requirements elicitation
describes techniques for collecting requirements from stakeholders in a project.
Requirements analysis
describes how to develop and specify requirements in enough detail to allow them to be successfully implemented by a project team.
Requirements communication
describes techniques for ensuring that stakeholders have a shared understanding of the requirements and how they will be implemented.
Solution assessment and validation
describes how the business analyst can verify the correctness of a proposed solution, how to support the implementation of a solution, and how to assess possible shortcomings in the implementation.
Design
The design concepts provide the software designer with a foundation from which more sophisticated methods can be applied. A set of fundamental design concepts has evolved. They are:
1.Abstraction - Abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose.
2.Refinement - It is the process of elaboration. A hierarchy is developed by decomposing a macroscopic statement of function in a stepwise fashion until programming language statements are reached. In each step, one or several instructions of a given program are decomposed into more detailed instructions. Abstraction and Refinement are complementary concepts.
3.Modularity - Software architecture is divided into components called modules.
4.Software Architecture - It refers to the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. A software architecture is the development work product that gives the highest return on investment with respect to quality, schedule and cost.
5.Control Hierarchy - A program structure that represent the organization of a program components and implies a hierarchy of control.
6.Structural Partitioning - The program structure can be divided both horizontally and vertically. Horizontal partitions define separate branches of modular hierarchy for each major program function. Vertical partitioning suggests that control and work should be distributed top down in the program structure.
7.Data Structure - It is a representation of the logical relationship among individual elements of data.
8.Software Procedure - It focuses on the processing of each modules individually
9.Information Hiding - Modules should be specified and designed so that information contained within a module is inaccessible to other modules that have no need for such information.
Design considerations
There are many aspects to consider in the design of a piece of software. The importance of each should reflect the goals the software is trying to achieve. Some of these aspects are:
Compatibility - The software is able to operate with other products that are designed for interoperability with another product. For example, a piece of software may be backward-compatible with an older version of itself.
Extensibility - New capabilities can be added to the software without major changes to the underlying architecture.
Fault-tolerance - The software is resistant to and able to recover from component failure.
Maintainability - The software can be restored to a specified condition within a specified period of time. For example, antivirus software may include the ability to periodically receive virus definition updates in order to maintain the software's effectiveness.
Modularity - the resulting software comprises well defined, independent components. That leads to better maintainability. The components could be then implemented and tested in isolation before being integrated to form a desired software system. This allows division of work in a software development project.
Packaging - Printed material such as the box and manuals should match the style designated for the target market and should enhance usability. All compatibility information should be visible on the outside of the package. All components required for use should be included in the package or specified as a requirement on the outside of the package.
Reliability - The software is able to perform a required function under stated conditions for a specified period of time.
Reusability - the modular components designed should capture the essence of the functionality expected out of them and no more or less. This single-minded purpose renders the components reusable wherever there are similar needs in other designs.
Robustness - The software is able to operate under stress or tolerate unpredictable or invalid input. For example, it can be designed with a resilience to low memory conditions.
Security - The software is able to withstand hostile acts and influences.
Usability - The software user interface must be intuitive (and often aesthetically pleasing) to its target user/audience. Default values for the parameters must be chosen so that they are a good choice for the majority of the users. In many cases,
online help should be included and also carefully designed.


Development
Software development is the set of activities that results in software products. Software development may include research, new development, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.[1] Especially the first phase in the software development process may involve many departments, including marketing, engineering, research and development and general management.[2]
The term software development may also refer to computer programming, the process of writing and maintaining the source code.

Testing
Software Testing can also be stated as the process of validating and verifying that a software program/application/product:
meets the business and technical requirements that guided its design and development;
works as expected; and
can be implemented with the same characteristics.
Software Testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the Software Development methodology adopted.

Testing can never completely identify all the defects within software. Instead, it furnishes a criticism or comparison that compares the state and behavior of the product against oracles—principles or mechanisms by which someone might recognize a problem. These oracles may include (but are not limited to) specifications, contracts[2], comparable products, past versions of the same product, inferences about intended or expected purpose, user or customer expectations, relevant standards, applicable laws, or other criteria.
Every software product has a target audience. For example, the audience for video game software is completely different from banking software. Therefore, when an organization develops or otherwise invests in a software product, it can assess whether the software product will be acceptable to its end users, its target audience, its purchasers, and other stakeholders. Software testing is the process of attempting to make this assessment.
A study conducted by NIST in 2002 reports that software bugs cost the U.S. economy $59.5 billion annually. More than a third of this cost could be avoided if better software testing was performed.
Deployment activities
Release
The release activity follows from the completed development process. It includes all the operations to prepare a system for assembly and transfer to the customer site. Therefore, it must determine the resources required to operate at the customer site and collect information for carrying out subsequent activities of deployment process.
Install and activate
Activation is the activity of starting up the executable component of software. For simple system, it involves establishing some form of command for execution. For complex systems, it should make all the supporting systems ready to use.
In larger software deployments, the working copy of the software might be installed on a production server in a production environment. Other versions of the deployed software may be installed in a test environment, development environment and disaster recovery environment.
Deactivate
Deactivation is the inverse of activation, and refers to shutting down any executing components of a system. Deactivation is often required to perform other deployment activities, e.g., a software system may need to be deactivated before an update can be performed. The practice of removing infrequently used or obsolete systems from service is often referred to as application retirement or application decommissioning.
Adapt
The adaptation activity is also a process to modify a software system that has been previously installed. It differs from updating in that adaptations are initiated by local events such as changing the environment of customer site, while updating is mostly started from remote software producer.
Update
The update process replaces an earlier version of all or part of a software system with a newer release.
Built-In
Mechanisms for installing updates are built into some software systems. Automation of these update processes ranges from fully automatic to user initiated and controlled. Norton Internet Security is an example of a system with a semi-automatic method for retrieving and installing updates to both the antivirus definitions and other components of the system. Other software products provide query mechanisms for determining when updates are available.
Version tracking
Version tracking systems help the user find and install updates to software systems installed on PCs and local networks.
· Web based version tracking systems notify the user when updates are available for software systems installed on a local system. For example: VersionTracker Pro checks software versions on a user's computer and then queries its database to see if any updates are available.
· Local version tracking system notifies the user when updates are available for software systems installed on a local system. For example: Software Catalog stores version and other information for each software package installed on a local system. One click of a button launches a browser window to the upgrade web page for the application, including auto-filling of the user name and password for sites that require a login.
· Browser based version tracking systems notify the user when updates are available for software packages installed on a local system. For example: wfx-Versions is a Firefox extension which helps the user find the current version number of any program listed on the web.
Uninstall
Uninstallation is the inverse of installation. It is a remove of a system that is no longer required. It also involves some reconfiguration of other software systems in order to remove the uninstalled system’s files and dependencies. This is not to be confused with the term "deinstall" which is not actually a word.
Retire
Ultimately, a software system is marked as obsolete and support by the producers is withdrawn. It is the end of the life cycle of a software product.

Maintenance
This international standard[1] describes the 6 software maintenance processes as:
The implementation processes contains software preparation and transition activities, such as the conception and creation of the maintenance plan, the preparation for handling problems identified during development, and the follow-up on product configuration management.
The problem and modification analysis process, which is executed once the application has become the responsibility of the maintenance group. The maintenance programmer must analyze each request, confirm it (by reproducing the situation) and check its validity, investigate it and propose a solution, document the request and the solution proposal, and, finally, obtain all the required authorizations to apply the modifications.
The process considering the implementation of the modification itself.
The process acceptance of the modification, by checking it with the individual who submitted the request in order to make sure the modification provided a solution.
The migration process (platform migration, for example) is exceptional, and is not part of daily maintenance tasks. If the software must be ported to another platform without any change in functionality, this process will be used and a maintenance project team is likely to be assigned to this task.
Finally, the last maintenance process, also an event which does not occur on a daily basis, is the retirement of a piece of software.
There are a number of processes, activities and practices that are unique to maintainers, for example:
Transition: a controlled and coordinated sequence of activities during which a system is transferred progressively from the developer to the maintainer;
Service Level Agreements (SLAs) and specialized (domain-specific) maintenance contracts negotiated by maintainers;
Modification Request and Problem Report Help Desk: a problem-handling process used by maintainers to prioritize, documents and route the requests they receive;
Modification Request acceptance/rejection: modification request work over a certain size/effort/complexity may be rejected by maintainers and rerouted to a developer.

Some steps in successful implementing IS
Step 1. Define what should be IS be implemented, what it should accomplish, and how to accomplish this goal, including an explanation of the terms” and “functional status.”
Step 2. Evaluate the IS and their limitations.
Step 3. Identify the communications operating issues.
Step 4. Define data requirements.
Step 5. Identify promising emerging technologies.
Step 6. Decide what data should be shared, with whom, and when.
Step 7. Decide who should operate, use, and maintain the system.
Steps 8. Identify potential participants involved
Step 9. Consider cost and funding issues.


This would help to expedite the implementation of the IS Plan. It shows the analazation the effect of implamented plan .What is its function,limitation,requirement and the people who handle the plan implamented.

References :
http://en.wikipedia.org/wiki/Software_maintenance
http://en.wikipedia.org/wiki/Software_deployment
http://en.wikipedia.org/wiki/Software_planning
http://en.wikipedia.org/wiki/Software_analysis
http://en.wikipedia.org/wiki/Software_design
http://en.wikipedia.org/wiki/Software_testing
http://en.wikipedia.org/wiki/Software_debvelopment
http://en.wikipedia.org/wiki/Risk_management


My blog:
http://gleizelle.blogspot.com/

No comments:

Post a Comment