Tuesday, December 22, 2009

Assignment 4 (SAD1)

Identify and discuss at least 3 systems development models .. discuss each phases ..

What is a system development model?

System development model specifies how the activities of development process are organized in the total system development effort.

Sample System Models

WATERFALL MODEL

The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back. The advantage of waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps. The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), synch and stabilize, build and fix, and the spiral model.

Advantages
Easy to understand, easy to use
Provides structure to inexperienced staff
Sets requirements stability
Good for management control (plan, staff, track

Limitations
All requirements must be known upfront
System can be frozen before the design begins
Little opportunity for customer to preview the system (until itmay be too late)

PROTOTYPING MODEL
The Prototyping Model is a systems development method (SDM) in which a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed. This model works best in scenarios where not all of the project requirements are known in detail ahead of time. It is an iterative, trial-and-error process that takes place between the developers and the users. There are several steps in the

Prototyping Model:
1.The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the departments or aspects of the existing system.
2.A preliminary design is created for the new system
. 3.A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
4.The users thoroughly evaluate the first prototype, noting its strengths and weaknesses, what needs to be added, and what should to be removed. The developer collects and analyzes the remarks from the users.
5.The first prototype is modified, based on the comments supplied by the users, and a second prototype of the new system is constructed.
6.The second prototype is evaluated in the same manner as was the first prototype.
7.The preceding steps are iterated as many times as necessary, until the users are satisfied that the prototype represents the final product desired.
8.The final system is constructed, based on the final prototype.
9.The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

Advantages
Customers can "see" the system requirements as they are being gathered
A more accurate end product
Unexpected requirements accommodated
Allows for flexible design and development
Lower overall development costs when requirements change frequently

Limitations
Prototyping can lead to false expectations.
Prototyping can lead to poorly designed systems

ITERATIVE ENHANCEMENT MODEL
The basic idea is that the software should be developed in increment. Each increment adding some functional capability to the system until the full system is implemented. At each step extension and design modification can be made. 1) Project control list: - All the tasks needed to complete final implementation of the project.2) Each step in Iterative Enhancement Model consist of removing next task from the project control list, designing the implementation for selected task, coding and testing the implementation , perform analysis of partial system that is obtained at this step, update the list as a result of the analysis.

Advantages
It combines benefits of both prototyping and waterfall model.
It can result in better testing because testing each increment is easier than testing entire system as a whole.
It can be used for product development in which developer themselves provide the specification.

Limitations
Provide incomplete system
Time consuming
High cost

Reflection:
I think based on the samples of systems development model, the most used and easily to used was the waterfall model because it is a step by step definition of activities to do by the organization.It can be easily explained to the people.
References:

http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci755441,00.html http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci519580,00.html
http://www.indiastudychannel.com/resources/40544-Iterative-Enhancement-Model.aspx

Assignment 4 (MIS2)

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 our ever increasingly competitive, technologically advanced and profit motivated global economy, all factions of the business community are searching for opportunities to strategically reduce inherent business and operational costs while systematically increasing their profitability and revenues. In the past, businesses reduced costs through devices such as downsizing and corporate re-structuring. Today, however, labor has become an asset that can no longer be cut without creating adverse affects on productivity, quality and efficiency. Because of this, the objective for many organizations today has become to be as efficient as possible through the use of new Information Systems."
Source:http://www.academon.com/Essay-Information-Systems-Proposal/62032
Before we discuss about Information Systems planning for the university, let us first sight some examples of Plans so that we can have an idea how to initiate it. Here is an example of the proposal:
An Information System for Proposal Submission and Handling
A. M. Chavan and M. A. Albrecht
European Southern Observatory, Karl-Schwarzschild-Str. 2, D-85748 Garching, Germany
Abstract:
The Proposal Handling and Reporting System (PHRS) is a software system aimed at supporting ESO's Observing Programme Committee (OPC) during the entire review process of the Observing Time Proposals. Proposals are written in a mark-up language based on LaTeX and are submitted via e-mail. PHRS maintains a database of validated proposals, and operators are enabled to browse it via user-friendly GUI tools, developed using Tcl/Tk. Referees receive PHRS generated printed reports, and submit proposal ratings via e-mail. Panel and OPC meetings are supported by interactive data entry tools and printed documents; in order to obtain high-quality output, all printed reports are processed via LaTeX. The final telescope schedule is published both on-line (World Wide Web) and in printed form.
PHRS was already successfully employed twice (for Periods 54 and 55), handling over 250 (peak) proposal submissions per day.
Introduction
Astronomers who wish to use ESO's facilities in La Silla (Chile) must submit Observing Time Proposals (henceforth simply proposals), indicating which facilities they want to use, when and for how long, and the science they want to perform. All submitted proposals are peer-reviewed and ranked by the Observing Program Committee (OPC) of ESO; the best proposals are finally assigned observing time at one of the telescopes in La Silla. This process takes several weeks, twice each year, and involves tens of people both within and outside ESO; more than one thousand investigators submit a total of over five hundred proposals each observing period.
The Proposal Handling and Reporting System (PHRS) at ESO is a software system aimed at tackling this problem and supporting the OPC. An entirely new version was developed in 1994, drawing on the experience gained during some years' experience with a previous, less comprehensive system. PHRS handles proposals throughout the entire review process: submission, storage, referee evaluation, panel discussion, OPC recommendation, and time assignment (scheduling).
Proposal Submission and Archiving
Proposals need to be both computer-readable and nicely formatted on paper. We achieved both goals by developing a mark-up language based on LaTeX macros: the new commands give the proposal its appropriate look and are easily parsed to extract relevant information. The ESOFORM package, which can be downloaded to each investigator's site, contains all necessary style files, template Observing Time applications, user manuals and period-related technical information. When printed at ESO, a submitted proposal looks identical to the proposal on the investigator's desk---thus eliminating the need for paper copy submission. Investigators write their proposals, print them at their institute for verification, and then send them via e-mail to ESO.
Here, a ``receiver'' program verifies that all mandatory information was provided, then stores valid proposals in a database---the ``proposal archive.'' No manual intervention is necessary: in fact, PHRS can operate unattended around the clock, and it proved able to cope with over 250 e-mail messages per day (usually on the last day before the deadline). Investigators normally get an acknowledgment message back within a minute or so of their submission; errors found in proposals are reported in detail. The authors went to great lengths to avoid data loss, even in the case of hardware failure.
The proposal archive is based on relational data base management technology, the same used in the STARCAT system (Pirenne et al. 1993). Operators interface with the archive with user-friendly, GUI-based tools, developed using Tcl/Tk (Ousterhout 1994). Since most of the data in the archive is classified, at least until schedule publication, we had to insure that only authorized operators could access it.
The system is network oriented, but it is flexible enough to allow for regular (post) mail submission of proposals as well. In some special cases, investigators submit printed proposals, and operators need to type the proposal's main data into the database.
Peer Review
Valid proposals are peer-reviewed. Each referee reviews several proposals of the same category (for instance, category C groups proposals dealing with ``Interstellar and intergalactic mediums''): he/she is required to rate them, by giving a grade---expressing the proposal's scientific merit---and a recommended number of nights (and, often, explanatory remarks). The same proposal is refereed by two or three different people.
Referees receive a printed copy of the proposals they must review and a set of summary reports generated by PHRS; these are printed via LaTeX, with the goal of providing appropriate documents, where scientific symbols and non-English names are correctly printed. Referees are also provided with a pre-initialized, e-mailed form (called a ``report card'') which they must fill in with ratings and comments. In order to eliminate possible errors, completed report cards are then returned via e-mail, and later processed by PHRS to extract and store ratings in the proposal archive.
Discussion and Ranking
The final step in the review process is the ranking of proposals, and it is a two-phase activity. Initially, all referees of the same category meet in a panel; they discuss each proposal belonging to the category, and agree on a final grade and recommended number of nights. The goal of panel discussion is to rank all proposals in one category according to their scientific value: better proposals are more likely to be assigned observing time, and telescopes are often oversubscribed by a factor of four or more.
PHRS supports the panels with more summary reports and interactive tools: since panels can directly update the proposal archive, there is no need to re-type information, thus eliminating possible errors; and panels can explore alternative rankings with respect to the number of available observing nights. Some data summaries are generated in spreadsheet format, for further processing and chart generation.
When the panels have completed their task, it is the OPC's responsibility to harmonize rankings across different categories and telescopes. A ``cutoff line'' separates the best proposals from those that will receive telescope time only if there is any time left, and the OPC ensures that proposals of different categories are evenly distributed around the line. PHRS provides per-telescope and per-category cutoff line reports to support OPC discussion.
Scheduling
Once the OPC has finalized its decisions, it is the ESO's directorate responsibility to distribute observing proposals (which are now called ``observing programmes'') over the range of available nights. This is a very complex and delicate process, and it is currently performed by hand; we plan to integrate telescope scheduling within PHRS as our next project. The final schedule is both stored in the proposal archive and published. ESO distributes the schedule document to all interested investigators, and we also developed a World Wide Web interface to the schedule archive for on-line browsing.
Conclusions and Future Directions
Some recent advances in technology have made PHRS possible: (1) widespread Internet access enables most investigators to use FTP and e-mail for their submission, (2) ``client-server'' software techniques increase the system's modularity, reliability and efficiency, (3) easy to develop, ``point-and-click'' Graphical User Interfaces (GUI's) minimize operator training and reduce errors, and (4) centralized information storage, coupled with appropriate software tools, enable support staff to meet deadlines, providing timely and accurate information to the OPC.
A number of problems have arisen with the use of this new system, the main one being the inability to check the correctness of some user supplied information: for instance, investigators writing a (first) name where a surname (family name) is needed, and vice-versa.
Future projects include support for Observation Preparation (Phase II proposals), and both long- and short-term scheduling (telescope scheduling and observation scheduling). Finally, in order to reduce bulky paper shipments, we are investigating the possibility of having referees download proposals and reports from an FTP account.

Assignment 6 (MIS2)

Identify and discuss the steps for "critical success factors" approach?
Critical Success Factor (CSF) is the term for an element that is necessary for an organization or project to achieve its mission. It is a critical factor or activity required for ensuring the success of your business. The term was initially used in the world of data analysis, and business analysis. For example, a CSF for a successful Information Technology (IT) project is user involvement.
A plan should be implemented that considers a platform for growth and profits as well as takes into consideration the following critical success factors:
•Money: positive cash flow, revenue growth, and profit margins.
•Your future: Acquiring new customers and/or distributors.
• Customer satisfaction: How happy they are.
• Quality: How good is your product and service?
• Product or service development: What's new that will increase business with existing customers and attract new ones?
• Intellectual capital: Increasing what you know is profitable.
• Strategic relationships: New sources of business, products and outside revenue.
• Employee attraction and retention: Your ability to extend your reach.
• Sustainability: Your personal ability to keep it all going.
Critical Success Factors (CSF’s) are the critical factors or activities required for ensuring the success your business. The term was initially used in the world of data analysis, and business analysis.
Most smaller and more pragmatic businesses can still use CSF’s but we need to take a different, more pragmatic approach.Critical Success Factors have been used significantly to present or identify a few key factors that organizations should focus on to be successful. As a definition, critical success factors refer to "the limited number of areas in which satisfactory results will ensure successful competitive performance for the individual, department, or organization”.
Being Practical
As you read this and many other resources on the internet you will discover that there are potentially a confusing variety of definitions and uses of Critical Success Factors.Before you start the journey looking at CSFs it is important to realise that the specific factors relevant for you will vary from business to business and industry to industry. The key to using CSFs effectively is to ensure that your definition of a factor of your organizations activity which is central to its future will always apply. Therefore success in determining the CSFs for your organization is to determine what is central to its future and achievement of that future.This page is primarily written for students of management and business, to keep things simple for application in smaller organizations remember to only have 5-7 critical factors for YOUR organization, and I am sure one of those will be cashflow!
How are they important to your business?
Identifying CSF's is important as it allows firms to focus their efforts on building their capabilities to meet the CSF's, or even allow firms to decide if they have the capability to build the requirements necessary to meet Critical Success Factors (CSF's).
Types of Critical Success FactorThere are four basic types of CSF'sThey are:
1. Industry CSF's resulting from specific industry characteristics;
2. Strategy CSF's resulting from the chosen competitive strategy of the business;
3. Environmental CSF's resulting from economic or technological changes; and
4. Temporal CSF's resulting from internal organizational needs and changes. Things that are measured get done more often than things that are not measured. Each CSF should be measurable and associated with a target goal. You don't need exact measures to manage. Primary measures that should be listed include critical success levels (such as number of transactions per month) or, in cases where specific measurements are more difficult, general goals should be specified (such as moving up in an industry customer service survey).
Definitions
Critical Success Factor an element of organizational activity which is central to its future success. Critical success factors may change over time, and may include items such as product quality, employee attitudes, manufacturing flexibility, and brand awareness. This can enable analysis.
Critical Success Factor any of the aspects of a business that are identified as vital for successful targets to be reached and maintained. Critical success factors are normally identified in such areas as production processes, employee and organization skills, functions, techniques, and technologies. The identification and strengthening of such factors may be similar. ..
Critical Success Factor (CSF) or Critical Success Factors is a business term for an element which is necessary for an organization or project to achieve its mission. For example, a CSF for a successful Information Technology (IT) project is user involvement.
Five key sources of Critical Success Factors
MAIN ASPECTS OF Critical Success Factors and their use in analysis CSF's are tailored to a firm's or manager's particular situation as different situations (e.g. industry, division, individual) lead to different critical success factors. Rockart and Bullen presented five key sources of CSF's:
1.The industry, Industry: There are some CSF's common to all companies operating within the same industry. Different industries will have unique, industry-specific CSF'sAn industry's set of characteristics define its own CSF's Different industries will thus have different CSF's, for example research into the CSF's for the Call centre, manufacturing, retail, business services, health care and education sectors showed each to be different after starting with a hypothesis of all sectors having their CSF's as market orientation, learning orientation, entrepreneurial management style and organizational flexibility.In reality each organization has its own unique goals so while thee may be some industry standard - not all firms in one industry will have identical CSF's.Some trade associations offer benchmarking across possible common CSF's.
2.Competitive strategy and industry position, Competitive position or strategy: The nature of position in the marketplace or the adopted strategy to gain market share gives rise to CSF's Differing strategies and positions have different CSF'sNot all firms in an industry will have the same CSF's in a particular industry. A firm's current position in the industry (where it is relative to other competitors in the industry and also the market leader), its strategy, and its resources and capabilities will define its CSF'sThe values of an organization, its target market etc will all impact the CSF's that are appropriate for it at a given point in time.
3. Environmental factors, Environmental changes: Economic, regulatory, political, and demographic changes create CSF's for an organization.These relate to environmental factors that are not in the control of the organization but which an organization must consider in developing CSF's Examples for these are the industry regulation, political development and economic performance of a country, and population trends. An example of environmental factors affecting an organization could be a de-merger
4. Temporal factorsTemporal factors: These relate to short-term situations, often crises. These CSF's may be important, but are usually short-lived.Temporal factors are temporary or one-off CSF's resulting from a specific event necessitating their inclusion. Theoretically these would include a firm which "lost executives as a result of a plane crash requiring a critical success factor of rebuilding the executive group". Practically, with the evolution and integration of markets globally, one could argue that temporal factors are not temporal anymore as they could exist regularly in organizations.For example, a firm aggressively building its business internationally would have a need for a core group of executives in its new markets. Thus, it would have the CSF of "building the executive group in a specific market" and it could have this every year for different markets.
5. Managerial position (if considered from an individual's point of view). Each of these factors is explained in greater detail below. Managerial role: An individual role may generate CSF's as performance in a specific manager's area of responsibility may be deemed critical to the success of an organization.Managerial position. This is important if CSF's are considered from an individual's point of view. For example, manufacturing managers who would typically have the following CSF's: product quality, inventory control and cash control. In organizations with departments focused on customer relationships, a CSF for managers in these departments may be customer relationship management.
CSF as a requirement:
After having developed a hierarchy of goals and their success factors, further analysis will lead to concrete requirements at the lowest level of detail
CSF as a key influence factor:Some CSFs might influence other CSFs or factors such as markets, technologies, etc.Such CSFs could be rephrased into “key influence factors” For example: “physical size” or “trained staff”
A Critical Success Factor Method
Start with a vision:
• Mission statement
• Develop 5-6 high level goals
• Develop hierarchy of goals and their success factors
• Lists of requirements, problems, and assumptions
• Leads to concrete requirements at the lowest level of decomposition (a single, implementable idea) Along the way, identify the problems being solved and the assumptions being made Cross-reference usage scenarios and problems with requirements
• Analysis matrices
• Problems vs. Requirements matrix
• Usage scenarios vs. Requirements matrix
• Solid usage scenarios
• Relationship to Usage Scenarios
• Usage scenarios or "use cases"; provide a means of determining: o Are the requirements aligned and self-consistent? o Are the needs of the user being met as well as those of the enterprise? o Are the requirements complete
• Results of the Analysis
Using Critical Success Factors for Strategic and Business Planning
Examples of Critical Success factorsStatistical research into CSF’s on organizations has shown there to be seven key areas. These CSF's are:
1. Training and education
2. Quality data and reporting
3. Management commitment, customer satisfaction
4. Staff Orientation
5. Role of the quality department
6. Communication to improve quality, and
7. Continuous improvementThese were identified when Total Quality was at its peak, so as you can see have a bias towards quality matters. You may or may not feel that these are right or indeed critical for your organization.The Critical Success Factors we have identified and us in the BIR process are captured in the mnemonic PRIMO-F
1. People - availability, skills and attitude
2. Resources - People, equipment, etc
3. Innovation - ideas and development
4. Marketing - supplier relation, customer satisfaction, etc
5. Operations - continuous improvement, quality, 6. Finance- cash flow, available investment etc

References:http://rapidbi.com/created/criticalsuccessfactors.html

Assignment 5 (MIS2)

In the spectrum of organizational change, which is the most radical type of change: automation, rationalization of procedures, business reengineering, or paradigm shifts?
“Change is an absolutely critical part of business. And yes, your company does need to change—preferably now and not later, when you have no other choice.”
By:Jack Welch & Suzy Welch

The problem is that people hate it when their bosses announce a “transformation initiative.” They run back to their cubicles and start frantically e-mailing one another, complaining that the changes are going to ruin everything
People love familiarity and patterns. They cling to them. The phenomenon is so entrenched it can only be chalked up to human nature. But while managing change can sometimes feel like moving a mountain, it can also be incredibly rewarding, particularly when you start seeing results.
Ultimately, implementing change comes down to embracing the following four practices:
1. Attach every change initiative to a clear purpose or goal. Change for change’s sake is stupid and enervating. Change should be a relatively orderly process, but for that to occur, people have to understand why change is necessary and how changes will affect them. This is easier, of course, when the problems are obvious—earnings are collapsing or a competitor has dropped prices 20 percent. But sometimes the need for change isn’t immediately apparent. Competitive threats seem to be emerging, but you don’t know for certain, and still, you have to respond. In those cases, relentless communication about the business rationale for change, reinforced with lots of data, is the best ammunition you have.The larger your company, the more challenging it will be to communicate the need for change. In big companies, calls for change are often greeted noncommittally. After all, if the company has been through enough change programs, employees will assume you’ll go away if they just wait long enough. Stick to your guns—your solid, persuasive business case. Over time, logic will win out.
2. Hire and promote only true believers and get-on-with-it types. Everyone in business claims to like change. To say otherwise would be career suicide. But by my estimate, less than 10 percent of all businesspeople are true change agents. Once the next group—about 70 to 80 percent of people working in business—is convinced that change is necessary, they’ll say, “OK already, get on with it.” The rest are resisters.To make change happen, companies must actively hire and promote only true believers and get-on-with-its. But with everyone claiming to like change, how can you tell who is for real?
Luckily, change agents usually make themselves known. They’re typically brash, high-energy and more than a little paranoid about the future. They often invent change initiatives on their own or ask to lead them. Invariably, they are curious and forward-looking. These people have a certain fearlessness about the unknown. If they fail, they know they can pick themselves up, dust themselves off and move on. They’re thick-skinned about risk, which allows them to make bold decisions without a lot of data.
3. Ferret out and remove the resisters, even if their performance is satisfactory. This is the hardest of the four practices to implement. It’s tough to let anyone go, but it’s particularly difficult to fire people who are not actually screwing up and may in fact be doing quite well.But in any organization, there are people who will not accept change, no matter how sound your case is. They are so invested—emotionally, intellectually, or politically—in the status quo that they cannot see a way to improve anything. These people usually have to go.That may sound harsh, but you’re not doing anyone a favor by keeping resisters in your organization. They foster an underground resistance and lower the morale of the people who support change. They’re wasting their own time: They’re working at a company where they don’t agree with or share in the vision, and they should be encouraged to find one where they do.
4. Look at car wrecks. Most companies capitalize on obvious opportunities. When a competitor fails, they move in on their customers. When a new technology emerges, they invest in it and create product line extensions.But to be a real change organization, you also have to have to look at bolder, scarier, more unpredictable events, assess the opportunities they present and make the most of them. Fostering this capability takes a certain determination, but the rewards can be huge.Take the 1997 Asian financial crisis. Currency traders certainly capitalized on this awful event; they live on exploiting change. But they’re not the only ones who should do this. GE had real success buying undervalued Thai auto loans in this period. Others prospered by buying real estate at fire sale prices.Bankruptcies are another type of calamity that reveals all kinds of opportunities. Of course, they’re tragic to the employees. Jobs are lost, and pensions disappear into thin air. But jobs and futures can also be created from the cinders. With all the noise out there about change, it’s easy to get overwhelmed and confused. But these are the only four practices that matter. That’s it. There’s nothing to be afraid of.
TERMINOLOGIES
Organizational change
This phrase refers to the overall nature of activities, for example, their extent and rate, that occurs during a project that aims to enhance the overall performance of the organization. The activities are often led by a change agent, or person currently responsible to guide the overall change effort. The activities are often project-oriented (a one-time project) and geared to address a current overall problem or goal in the organization. (A relatively new phrase, capacity building, refers to these types of activities, as well.)

Automation
Automation is the use of control systems (such as numerical control, programmable logic control, and other industrial control systems), in concert with other applications of information technology (such as computer-aided technologies [CAD, CAM, CAx]), to control industrial machinery and processes, reducing the need for human intervention.[1] In the scope of industrialization, automation is a step beyond mechanization. Whereas mechanization provided human operators with machinery to assist them with the muscular requirements of work, automation greatly reduces the need for human sensory and mental requirements as well. Processes and systems can also be automated.Automation plays an increasingly important role in the global economy and in daily experience. Engineers strive to combine automated devices with mathematical and organizational tools to create complex systems for a rapidly expanding range of applications and human activities.

Paradigm shift
Paradigm shift (or revolutionary science) is the term first used by Thomas Kuhn in his influential book The Structure of Scientific Revolutions (1962) to describe a change in basic assumptions within the ruling theory of science. It is in contrast to his idea of normal science.The term paradigm shift, as a change in a fundamental model of events, has since become widely applied to many other realms of human experience as well, even though Kuhn himself restricted the use of the term to the hard sciences. According to Kuhn, "A paradigm is what members of a scientific community, and they alone, share." (The Essential Tension, 1977). Unlike a normal scientist, Kuhn held, "a student in the humanities has constantly before him a number of competing and incommensurable solutions to these problems, solutions that he must ultimately examine for himself." (The Structure of Scientific Revolutions). Once a paradigm shift is complete, a scientist cannot, for example, posit the possibility that miasma causes disease or that ether carries light. In contrast, a critic in the Humanities can choose to adopt a 19th-century theory of poetics, for instance.Since the 1960s, the term has been found useful to thinkers in numerous non-scientific contexts. Compare as a structured form of Zeitgeist.

Business Process Reengineering Cycle.
Business process reengineering (BPR) is, in computer science and management, an approach aiming at improvements by means of elevating efficiency and effectiveness of the business process that exist within and across organizations. The key to BPR is for organizations to look at their business processes from a "clean slate" perspective and determine how they can best construct these processes to improve how they conduct business.
Business process reengineering is also known as BPR, Business Process Redesign, Business Transformation, or Business Process Change Management. Reengineering is a fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in cost, quality, speed, and service. BPR combines a strategy of promoting business innovation with a strategy of making major improvements to business processes so that a company can become a much stronger and more successful competitor in the marketplace.
The Article
Clearing Up the Language About Organizational Change and Development
Written by Carter McNamara, MBA, PhD, Authenticity Consulting, LLC. Copyright 1997-2008.Adapted from the Field Guide to Consulting and Organizational Development and Field Guide to Consulting and Organizational Development with Nonprofits.
When a topic (for example, organizational change and development) becomes very prominent, it often takes on many different interpretations and meanings. The advantage is that that topic becomes very accessible, interesting and enlightening to many. The disadvantage is that it's also increasingly vague and difficult for many to make practical. To make this topic of organizational change and development useful, we should reference some common definitions. Even if not all people agree with the definitions, we at least have some definitions in common to disagree about -- that alone can enhance the communications about the topic. Having some understanding and discernment about the following phrases will help readers to benefit even more from literature about organizational change.
Organizational performance management
We're used to thinking of ongoing performance management for employees, for example, setting goals, monitoring the employee's achievement of those goals, sharing feedback with the employee, evaluating the employee's performance, rewarding performance or firing the employee. Performance management applies to organizations, too, and includes recurring activities to establish organizational goals, monitor progress toward the goals, and make adjustments to achieve those goals more effectively and efficiently.Note that, in contrast to organizational change projects, organizational performance management activities are recurring in nature. Those recurring activities are much of what leaders and managers inherently do in their organizations -- some do them far better than others. An organizational change project is not likely to be successful if it is not within the context of the recurring activities of organizational performance management.
Organizational change
This phrase refers to the overall nature of activities, for example, their extent and rate, that occurs during a project that aims to enhance the overall performance of the organization. The activities are often led by a change agent, or person currently responsible to guide the overall change effort. The activities are often project-oriented (a one-time project) and geared to address a current overall problem or goal in the organization. (A relatively new phrase, capacity building, refers to these types of activities, as well.)
Organizational development
This phrase refers to the evolution of the organization during the overall organizational change activities, for example, evolution of its members to be able to resolve a major problem, achieve an overall project goal and/or achieve overall organizational goals. Organizational development is an outcome of organizational change activities.
Change management
This phrase refers to the implementation of a certain approach or methodology to ensure the organizational change effort is successful, including to ensure a clear vision and/or goals for the project, and to modify systems in the organization to more effectively achieve the goals. Change management activities can range from a planned, structured and explicit approach (successful change efforts usually are) to unplanned and implicit.
Change agent
A change agent is the person who's currently responsible for the overall change effort. The role can be performed by different people at different times. For example, an effective consultant (internal or external) might first perform the role, but work in such a way during the project that the role ultimately is adopted by someone else inside the organization.
Organization Development (OD)
OD is a field of research, theory and practice dedicated to expanding the knowledge and effectiveness of people to accomplish more successful organizational change and performance. Different people often have different perspectives on the field, depending on their particular values and skills. Many people assert that, for OD projects to be highly effective, they must be systems-based in design and highly humanistic in implementation. (Occasionally, someone refers to the field as "organizational development," but for the sake of clarity in this topic, that definition will not be used in the Free Management Library.)Reflection: For me the most radical type of chenge in the spectrum of organization is the business reengineering because in this case we should be careful in analying our steps and ways in redesigning our organization.
References:
http://www.businessmirror.com.ph/home/pf/17334-principles-of-organizational-change.htmlhttp://managementhelp.org/org_chng/keyt-terms.htmhttp://en.wikipedia.org/wiki/Automationhttp://en.wikipedia.org/wiki/Paradigm_shifthttp://en.wikipedia.org/wiki/Business_process_reengineering

Tuesday, December 15, 2009

Assignment1(SAD)

Based on your learnings of chapter 1, identify and discuss some characteristics you have as a good Systems Analyst.

                                                                                                                            

Our first topic for our reporting in SAD1 was all about The World of the Information Systems Analyst. To expand its thought, we will first discuss the main topic, Information Systems Analyst. What does it really mean?

Well, according to my research and to what I have understand from the reporters, A systems analyst designs new IT solutions to improve business efficiency and productivity. The work might be for an external client or an internal client. When an analyst works closely with the client, they can examine existing business models and flows of data, discuss their findings with the client, and design an appropriate improved IT solution. They produce outline designs and costing of new IT systems, specifying the operations the system will perform, and the way data will be viewed by the user, present their design to the client and, once it is approved, work closely with the client team to implement the solution.

Why do you think the world needs a good systems analyst?

            I think the world needs a Systems analyst because it has a big role for us. In the world of technology, it helps a lot it is responsible for the operating system and associated subsystems. Provide system-level support of multi-user operating systems, hardware and software tools, including installation, configuration, maintenance, and support of these systems. Identify alternatives for optimizing computer resources.

Who can be an analyst?

            Our facilitator asked us, who can be a systems analyst? The Accountant or the IT professional? The directly replied the IT professional. We first think that IT professionals have an edge because of their edge in computing and technological skills, but he explained that its not the course or profession your taking to.

KNOWLEDGE AND SKILL REQUIREMENTS

  1. Basic reading, writing, and arithmetic skills required. This is normally acquired through a high school diploma or equivalent.
  2. Knowledge of company supported hardware, software and operating systems to include configuration and connectivity. Ability to investigate and analyze information and to draw conclusions. Ability to plan, implement, test, and troubleshoot system software. Ability to develop systems solutions for operational problems. Knowledge of computer flow charts and of programming logic and codes. Ability to determine computer problems and to coordinate hardware and/or software solutions. Ability to communicate technical guidance and instruction to users on the use of PC and/or mainframe applications and systems. Ability to write technical instructions in the use of programs and/or program modifications. Records maintenance skills. Knowledge of computer security procedures and protocol. Knowledge of federal copyright laws as they pertain to the use of computer software. Ability to determine the nature of computer hardware and systems software problems, and to communicate technical guidance and information to users. Ability to learn and support new hardware, software and operating systems. Work with users requires interpersonal skills. This is normally acquired through a combination of a Bachelor's Degree and three to five years of programming and/or system analysis experience.

Responsibilities may require evening and weekend work in response to needs of the systems being supported.

Here are some attributes for an analyst:(by: H M Winning)

An analyst is looking for ways to improve the business through technology yet cautioning against letting technology lead the business by the nose.

An analyst is looking to accomplish specific tasks or meet specific measurable goals within a reasonable time frame.

An analyst is as comfortable in a technology driven meeting as in a business planning session. The analyst listens to business problems and goals and translates that information into potential solutions - sometimes using technology and sometimes not - technology is not always the answer.

An analyst can also serve as project manager, test coordinator, "keeper of the budget" or data analyst.

Analysts are not "yes" people - if the idea sucks we'll tell you. Analysts hate waste and are usually budget bears.

An analyst is always conducting research - either for their business or for their own personal education. An analyst understands that business and technology are forever changing therefore, an open view of the world must be maintained in order to see the potential in any situation.

An analyst understands that no one vendor or software is the solution to all evils. The newest rage today will fade into the distance next week.

We'd always rather build than buy but understand that buying - for the most part - is usually the way to get more of what the business really needs in a more reasonable time frame (at lease in my world).

An analyst is not and cannot be political. An analyst is a cynic and optimist at the same time.

An analyst knows "bodies" don't get a project done - people do. An analyst gets to know the developers on a project and finds the unique talent that each one has - and uses it to run a better project.

 

Analysts believe that they are pretty smart - if we don't no one else will. We chuckle softly at people who don't understand that we really do have a grand vision and believe that anything can be accomplished if you knock all the crap out of your processes.

Analysts are always looking at least 5 years out.

An analyst thinks becoming management is a step down. Analysts aspire to be highly paid experts.

 

In my side:

Do I have the characteristics of a good systems analyst?

What are those?

As what I have read in the internet, here are some characteristics of good Systems Analyst:

-The system analyst must be able to communicate in writing and orally.

-The analyst must easily get along with people.

-The analyst must be a good listener and be able to react to what people say.

-The analyst must be knowledgeable of technology. The analyst is not expected to know the intricacies of programming, but a decent general knowledge of concepts and terms is essential.

-The analyst must be knowledgeable of business. The analyst is not expected to be an expert in business but a decent understanding of the client's world is required.

The Skills

Analytical Skills ability to see things as systems, identify, analyze, and solve problems in an optimal way for a specific organization.

Technical Skills ability to understand how computers, data networks, databases, operating systems, etc. work together, as well as their potentials and limitations.

Management Skills include organization’s recourse management, project management (people and money), risk management, and change management.

Communication Skills include effective interpersonal communication (written, verbal, visual, electronic, face-to-face conversations, presentations in front of groups), listening, group facilitation skills

 

Can I take the responsibility?

I know to my self that some day I can be what I want to be… I think I can communicate through written and orally terms.

I can also develop my Analytical and Technical skills…

When it comes to Management and Communication Skills I think I can manage … (char lang)…

I can easily get along with people too… it can be a good start for an employee to have a good relationship with their office mates so that they can learn more…

 

 

References:

http://it.toolbox.com/blogs/business-analyst/analyst-qualifications-9881

http://www.interlabs.bradley.edu/NSF_CCLI/Demo/class6/module6/Skills_Pretest_Posttest_Answers.pdf

 

Blog blog blog…

http://shecapacillo.blogspot.com

 

wew..... here we go again..

harroiiii.... start na pud tag blog2...pwede makapoie??

hahaha...

gogogo...cheer up she..kayang kaya....

labyu lord.... 

^-^