The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems engineering and software engineering, is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. The concept generally refers to computer or information systems. In software engineering the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the creation of an information system: the software development process.
Developers worldwide will agree that building software takes more than just writing complex codes and implementing them in an environment. Developers usually start out their career in programming by developing programs or software according to their own plan and hope that someone will appreciate it. But once the developer is associated with a business or another software company, the creativity is limited to business and consumer needs. The pressure in creating accurate and efficient software is even bigger in the entrepreneurial stage.
To ensure developers have come up with the right software for the specific need, programmers have created steps on how a program could specifically created. This will ensure everything is built according to plan and tested extensively before it could be implemented for public or formal use in business. Under these circumstances the term “Systems Development Life Cycle” was born. The need to create accurate and efficient software has led to the formalization on certain stages and phases on how a program should be built.
Simply put, SDLC or Systems Development Life Cycle is a series of steps observed by developers on building specific software. Developers follow certain steps to ensure they have the right software for the right demand.
The history of the term “Systems Development Life Cycle” is very vague but it naturally came into being since the 1960s when developers started to create programs specific to a certain need. Slowly, the term has been observed by different software development companies. From a simple format of planning, building, testing and implementing, software companies have developed their own version of developing specific products for their clients. Each version of software development is called “Model”. As of this writing, there are 18 known software development models observed by differentsoftware development companies . These development models could be applied in a certain situation to ensure the product created is a success, since not all models could be used in a certain application. Skills and experience in software development will also dictate which model will work for software development.
There is a great temptation to just resign to the fact of creating software based on the problem. For example, the business needs a simple computing software embedded in their website. That is a simple problem that could be done by programmer, anytime. It is just a matter of using code to efficiently implement the software in a website.
But if you take a look at it deeply, there are steps that should be done before you can actually create the software. First you have to know what type of computing software and the components that should be added. Then they have to plan the actual codes that will be used and test it extensively before implementation. Without any of these steps, something will definitely go wrong once the program is implemented. With SDLC, software development companies or in-house developers will ensure the software released will have the following behaviors:
1. Software created are of high standard. Building a software is different from building a well built software. Anyone could create a software as there are available tools that does not even require a knowledge in extensive programming. But with SDLC, programmers have to look further than tapping in shortcuts to create a specific tool that the customer wants.
2. Project implementation and control will be easier. The role of developers does not end when the program is implemented. Even though a specific software is highly efficient when implemented, anything found wrong or a bug in the system should be worked on especially when the software did not go through beta testing. In this account, SDLC will ensure that controls of the software are stable. This is usually done be creating better documentation to guide the developers in controlling the specific function of a software.
3. Answer the need of the users or even exceeding their expectations. Every software that is created should answer the specific needs of their clients. Having a highly stable software will be nothing if the intended users cannot use the software. SDLC will make sure the needs are answered and could even provide more than they need. The steps they will be using are geared towards creating a software that is highly efficient as well as problem solving for better time management.
Although SDLC has different models, most of the models observe the following stages to ensure their software is a success.
1. Project planning, feasibility study. Developers have to study the market and know their needs. The theoretical plan of the software is created in this stage. Developers will conduct a study on how will this software affect the users and if there is an actual need for this software.
2. Systems analysis, requirements definition. After creating the theoretical plan and mapping out the need of the users, developers will have to sit down and determine the technical requirements in building the software. In this stage, developers will create a workflow that will be the basis of the actual design.
3. Systems design. Developers will now build the software based on the needs and the architectural plan of the software. Developers will either use a specific language to create a software or they could use an available component. This stage usually differentiates different models wherein some will actually use a specific language, some will use tools without the use of a specific language while other models will use the available components to create a software.
4. Implementation. As the software progresses, developers will need to test the software for proper implementation. Slowly the program is built from the scratch and each component is tested if the code or language used actually works.
5. Integration and testing. Once the software is completed, it will go through serious testing before integration to the actual working environment. The software will be placed on beta version. Usually the software will be available for selected users (closed beta) and gradually the software is opened for public use but will still be in beta version (open beta). Going from “closed beta” to “open beta” will test the software capability for simultaneous and multiple users. Bugs will be detected and developers can work on them before they are completely integrated on to the system.
6. Acceptance, installation, deployment. After a rigorous testing in beta version, the program is now ready to be used publicly. Complete installation of the program is offered with all the components applied.
7. Maintenance. Although the software is now stable it does not guarantee it will work properly at all times. But instead of looking out for bugs, developers will be reactive to the problem. The developers will only monitor the performance of the software and create the necessary adjustments to maintain the software.
8. Disposal phase. In course of time a software can no longer be required. A better software may take its place in the market, the software may no longer answer the concerns of its users or the project could not live according to the expectations, these are some of the reasons why a software should be disposed. Before actually disposing a software, Developers will have to inform its users in advance the discontinuation of support to the said product. Users, then will have the option to uninstall or disregard the software completely. In a software development environment, the disposal phase usually means another system is in the works to replace the software said to be disposed.
SDLC models can be described along a spectrum of agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on light-weight processes which allow for rapid changes along the development cycle. Iterative methodologies, such as Rational Unified Process and Dynamic Systems Development Method, focus on limited project scopes and expanding or improving products by multiple iterations. Sequential or big-design-upfront (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results.
THE WATERFALL MODEL. The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.
The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995), although Royce did not use the term "waterfall" in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development—as a way to criticize a commonly used software practice.
To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes requirements specification, which are set in stone. When the requirements are fully completed, one proceeds to design. The software in question is designed and a blueprint is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, separate software components produced are combined to introduce new functionality and reduced risk through the removal of errors.
Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. However, there are various modified waterfall models (including Royce's final model) that may include slight or major variations upon this process.
The waterfall model is argued by many to be a bad idea in practice. This is mainly because of their belief that it is impossible for any non-trivial project to get one phase of a software product's lifecycle perfected, before moving on to the next phases and learning from them.
For example, clients may not be aware of exactly what requirements they need before reviewing a working prototype and commenting on it; they may change their requirements constantly. Designers and programmers may have little control over this. If clients change their requirements after the design is finalized, the design must be modified to accommodate the new requirements. This effectively means invalidating a good deal of working hours, which means increased cost, especially if a large amount of the projects resources has already been invested in Big Design Up Front.
Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product. That is, it may become clear in the implementation phase that a particular area of program functionality is extraordinarily difficult to implement. If this is the case, it is better to revise the design than to persist in using a design that was made based on faulty predictions and that does not account for the newly discovered problem areas.
The idea behind the waterfall model may be "measure twice; cut once", and those opposed to the waterfall model argue that this idea tends to fall apart when the problem being measured is constantly changing due to requirement modifications and new realizations about the problem itself. As a solution can serve some "investment of man-time", ordering some experienced developer to spend time on refactoring, to consolidate the SW back together. Another approach is to prevent these needs by a predicting design, targeting modularity with interfaces.
THE SPIRAL MODEL. The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects.
The spiral model was defined by Barry Boehm in his 1988 article "A Spiral Model of Software Development and Enhancement". This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters.
As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project. Game development is a main area where the spiral model is used and needed, that is because of the size and the constantly shifting goals of those large projects.
THE AGILE SOFTWARE DEVELOPMENT. Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.
Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Conceptual foundations of this framework are found in modern approaches to operations management and analysis, such as lean manufacturing, soft systems methodology, speech act theory (network of conversations approach), and Six Sigma.
Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("timeboxes") that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration. Multiple iterations may be required to release a product or new features.
Team composition in an agile project is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration's requirements.
Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc.
Most agile teams work in a single open office (called bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. Larger development efforts may be delivered by multiple teams working toward a common goal or different parts of an effort. This may also require a coordination of priorities across teams.
Most agile implementations use a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative and any interested stakeholders as observers. In a brief session, team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. This standing face-to-face communication prevents problems being hidden.
Agile emphasizes working software as the primary measure of progress. This, combined with the preference for face-to-face communication, produces less written documentation than other methods—though, in an agile project, documentation and other artifacts rank equally with a working product. The agile method encourages stakeholders to prioritize wants with other iteration outcomes based exclusively on business value perceived at the beginning of the iteration.
Tuesday, December 22, 2009
MIS2- Assign6 :)
CSFs (Critical Success Factor) are the essential areas of activity that must be performed well if you are to achieve the mission, objectives or goals for your business or project. By identifying your Critical Success Factors, you can create a common point of reference to help you direct and measure the success of your business or project.
Critical Success Factor 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 critical success factor is not a key performance indicator (KPI). Critical success factors are elements that are vital for a strategy to be successful. KPIs are measures that quantify management objectives and enable the measurement of strategic performance. A critical success factor is what drives the company forward, it is what makes the company or breaks the company. As staff must ask themselves everyday 'Why would customers choose us?' and they will find the answer is the critical success factors.
As a common point of reference, CSFs help everyone in the team to know exactly what's most important. And this helps people perform their own work in the right context and so pull together towards the same overall aims.
The idea of CSFs was first presented by D. Ronald Daniel in the 1960s. It was then built on and popularized a decade later by John F. Rockart, of MIT's Sloan School of Management, and has since been used extensively to help businesses implement their strategies and projects. Inevitably, the CSF concept has evolved, and you may have seen it implemented in different ways. This article provides a simple definition and approach based on Rockart's original ideas.
Rockart defined CSFs as:
"The limited number of areas in which results, if they are satisfactory, will ensure successful competitive performance for the organization. They are the few key areas where things must go right for the business to flourish. If results in these areas are not adequate, the organization's efforts for the period will be less than desired."
He also concluded that CSFs are "areas of activity that should receive constant and careful attention from management." Critical Success Factors are strongly related to the mission and strategic goals of your business or project. Whereas the mission and goals focus on the aims and what is to be achieved, Critical Success Factors focus on the most important areas and get to the very heart of both what is to be achieved and how you will achieve it.
The CSFs approach was applied in case studies carried out in the UK universities (Pellow & Wilson, 1993; Greene et al. 1996; Loughridge 1996). It was applied also as a component of a strategic information management (SIM) methodology put forward by Wilson (1992, 1994b). The CSFs approach was combined with the value chain concept by Porter (1985) in order to form an information audit (e.g. Ellis et al. 1993; Dimond, 1996; Buchanan & Gibb, 1998; see also Goldsmith, 1991). The methodology was tested in two case studies carried out in very knowledge-intensive sectors of Finnish industry. The process was funded by the Academy of Finland.
CRTICICAL SUCCESS FACTORS for Strategic Planning, Thinking, and Doing
1. Paradigm Shift. Shift your paradigm about organizations to one that is
the largest and most inclusive by beginning with societal good in
mind. Move out of your comfort zone and consider two bottom lines:
• Positive impact on society through improved quality of life.
• Profit over long term.
2. Results vs. Methods and Means. Distinguish between ends and means.
Define and plan results at the Mega, Macro, and Micro levels you
desire before choosing how to achieve them.
3. Link Mega, Macro, and Micro. Use all three levels of planning and
results, Mega, Macro, and Micro.
4. Measurable Objectives. Develop measurable objectives at the Mega,
Macro, and Micro levels of results that are linked systemically as a
value added chain. Don’t include methods and means in objectives.
5. Ideal Vision. Use an Ideal Vision as the foundation for strategic thinking
and planning. Don’t be limited to your immediate organization or
current paradigms.
6. Needs Are Gaps in Results. Define “needs” as a gaps in results, not as
insufficient resources, means, or methods.
These critical success factors are now explained in more detail.
Paradigm Shift. Paradigms, like mental models, are the ways
in which we perceive and filter reality. When the demands and pressures for
change within the organization intensify beyond just incremental changes,
then it’s one indicator that a paradigm shift is imminent.We can and should shift
paradigms, even when previous paradigms are not yet failing us. Thinking
about the future is not about “more of the same.” After all, the ways of thinking
that led to success yesterday can become a major barrier to creating future
success.
Distinguishing between ends and means. Distinguishing between ends and means is another characteristic of a strategic thinker. Results are ends that define in measurable terms the future we want to create. Means are the methods and tactics we choose to
achieve the results. It is also good sense, good logic, and good economics to define
the future desired state before selecting how you will get there. When methods,
means, resources, and tactics are chosen before the problem, opportunity, and result
are defined, then we are likely to end up somewhere other than where we desire.
Link Mega, Macro and Micro. Use and link all three levels of planning and
results. Each level of results focuses on a different, but related, client category.
The starting point for strategic planning—unless you aren’t concerned with the
health, safety, and well-being of your clients and community—is to define the desired results at the Mega level. Planning then proceeds down the chain of results to the Macro and Micro levels. In this way the three levels of results make up a value added chain of high payoff results. After all, we want to plan for useful results before selecting any methods or means for accomplishing those results.
Measurable Objectives. We create the future twice. We achieve it the first
time in our mind through imagining and dreaming, and then again through our
external accomplishments. For any useful results to be accomplished in tangible, measurable forms, first someone has to dream them. Since there are three levels of planning and associated results (Mega/Outcomes, Macro/Outputs, Micro/Products), strategic thinkers develop linked objectives for each of these in measurable terms. To
ensure we move out of our present paradigms and break the status quo, we must
be bold and audacious when we set and commit to our objectives. These objectives are called Smarter objectives. These are objectives that are not based on past processes; they specify the desired future in terms of results that ought to be accomplished, irrespective of the hindrances of today. They invent in the mind’s eye and commit to action results that have not yet been achieved (nor perhaps even conceived). As such, they don’t include methods and means— the methods and means describe the options for achieving the results, not the results themselves.
Ideal Vision. It is critical that strategic thinking and planning begin by stepping outside the limits of your organization. This step involves representative stakeholders in answering some fundamental questions about the sort of world you would like to create for tomorrow’s child. The Ideal Vision expresses in measurable terms what we wish to accomplish and commit to design and create.3 It describes ends and not means, processes, procedures, resources, or methods. In Chapter Four, Preparing to Plan, the Ideal Vision as the starting place for strategic thinking is described in greater detail.
Needs are gaps in results. Define “needs” as a gap between present results and desired results, not as perceived gaps in inputs and/or processes (which are really wants). By defining needs as gaps in results, we are thinking strategically, because we are designing the long-term future to be accomplished before deciding what methods and means might create it. Terminology should be precise when describing the world to which we will expect to commit many resources.
Critical Success Factors are the areas of your business or project that are absolutely essential to its success. By identifying and communicating these CSFs, you can help ensure your business or project is well-focused and avoid wasting effort and resources on less important areas. By making CSFs explicit, and communicating them with everyone involved, you can help keep the business and project on track towards common aims and goals.
LINKS used:
http://en.wikipedia.org/wiki/Critical_success_factor
http://www.mindtools.com/pages/article/newLDR_80.htm
http://media.wiley.com/product_data/excerpt/30/07879650/0787965030.pdf
Critical Success Factor 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 critical success factor is not a key performance indicator (KPI). Critical success factors are elements that are vital for a strategy to be successful. KPIs are measures that quantify management objectives and enable the measurement of strategic performance. A critical success factor is what drives the company forward, it is what makes the company or breaks the company. As staff must ask themselves everyday 'Why would customers choose us?' and they will find the answer is the critical success factors.
As a common point of reference, CSFs help everyone in the team to know exactly what's most important. And this helps people perform their own work in the right context and so pull together towards the same overall aims.
The idea of CSFs was first presented by D. Ronald Daniel in the 1960s. It was then built on and popularized a decade later by John F. Rockart, of MIT's Sloan School of Management, and has since been used extensively to help businesses implement their strategies and projects. Inevitably, the CSF concept has evolved, and you may have seen it implemented in different ways. This article provides a simple definition and approach based on Rockart's original ideas.
Rockart defined CSFs as:
"The limited number of areas in which results, if they are satisfactory, will ensure successful competitive performance for the organization. They are the few key areas where things must go right for the business to flourish. If results in these areas are not adequate, the organization's efforts for the period will be less than desired."
He also concluded that CSFs are "areas of activity that should receive constant and careful attention from management." Critical Success Factors are strongly related to the mission and strategic goals of your business or project. Whereas the mission and goals focus on the aims and what is to be achieved, Critical Success Factors focus on the most important areas and get to the very heart of both what is to be achieved and how you will achieve it.
The CSFs approach was applied in case studies carried out in the UK universities (Pellow & Wilson, 1993; Greene et al. 1996; Loughridge 1996). It was applied also as a component of a strategic information management (SIM) methodology put forward by Wilson (1992, 1994b). The CSFs approach was combined with the value chain concept by Porter (1985) in order to form an information audit (e.g. Ellis et al. 1993; Dimond, 1996; Buchanan & Gibb, 1998; see also Goldsmith, 1991). The methodology was tested in two case studies carried out in very knowledge-intensive sectors of Finnish industry. The process was funded by the Academy of Finland.
CRTICICAL SUCCESS FACTORS for Strategic Planning, Thinking, and Doing
1. Paradigm Shift. Shift your paradigm about organizations to one that is
the largest and most inclusive by beginning with societal good in
mind. Move out of your comfort zone and consider two bottom lines:
• Positive impact on society through improved quality of life.
• Profit over long term.
2. Results vs. Methods and Means. Distinguish between ends and means.
Define and plan results at the Mega, Macro, and Micro levels you
desire before choosing how to achieve them.
3. Link Mega, Macro, and Micro. Use all three levels of planning and
results, Mega, Macro, and Micro.
4. Measurable Objectives. Develop measurable objectives at the Mega,
Macro, and Micro levels of results that are linked systemically as a
value added chain. Don’t include methods and means in objectives.
5. Ideal Vision. Use an Ideal Vision as the foundation for strategic thinking
and planning. Don’t be limited to your immediate organization or
current paradigms.
6. Needs Are Gaps in Results. Define “needs” as a gaps in results, not as
insufficient resources, means, or methods.
These critical success factors are now explained in more detail.
Paradigm Shift. Paradigms, like mental models, are the ways
in which we perceive and filter reality. When the demands and pressures for
change within the organization intensify beyond just incremental changes,
then it’s one indicator that a paradigm shift is imminent.We can and should shift
paradigms, even when previous paradigms are not yet failing us. Thinking
about the future is not about “more of the same.” After all, the ways of thinking
that led to success yesterday can become a major barrier to creating future
success.
Distinguishing between ends and means. Distinguishing between ends and means is another characteristic of a strategic thinker. Results are ends that define in measurable terms the future we want to create. Means are the methods and tactics we choose to
achieve the results. It is also good sense, good logic, and good economics to define
the future desired state before selecting how you will get there. When methods,
means, resources, and tactics are chosen before the problem, opportunity, and result
are defined, then we are likely to end up somewhere other than where we desire.
Link Mega, Macro and Micro. Use and link all three levels of planning and
results. Each level of results focuses on a different, but related, client category.
The starting point for strategic planning—unless you aren’t concerned with the
health, safety, and well-being of your clients and community—is to define the desired results at the Mega level. Planning then proceeds down the chain of results to the Macro and Micro levels. In this way the three levels of results make up a value added chain of high payoff results. After all, we want to plan for useful results before selecting any methods or means for accomplishing those results.
Measurable Objectives. We create the future twice. We achieve it the first
time in our mind through imagining and dreaming, and then again through our
external accomplishments. For any useful results to be accomplished in tangible, measurable forms, first someone has to dream them. Since there are three levels of planning and associated results (Mega/Outcomes, Macro/Outputs, Micro/Products), strategic thinkers develop linked objectives for each of these in measurable terms. To
ensure we move out of our present paradigms and break the status quo, we must
be bold and audacious when we set and commit to our objectives. These objectives are called Smarter objectives. These are objectives that are not based on past processes; they specify the desired future in terms of results that ought to be accomplished, irrespective of the hindrances of today. They invent in the mind’s eye and commit to action results that have not yet been achieved (nor perhaps even conceived). As such, they don’t include methods and means— the methods and means describe the options for achieving the results, not the results themselves.
Ideal Vision. It is critical that strategic thinking and planning begin by stepping outside the limits of your organization. This step involves representative stakeholders in answering some fundamental questions about the sort of world you would like to create for tomorrow’s child. The Ideal Vision expresses in measurable terms what we wish to accomplish and commit to design and create.3 It describes ends and not means, processes, procedures, resources, or methods. In Chapter Four, Preparing to Plan, the Ideal Vision as the starting place for strategic thinking is described in greater detail.
Needs are gaps in results. Define “needs” as a gap between present results and desired results, not as perceived gaps in inputs and/or processes (which are really wants). By defining needs as gaps in results, we are thinking strategically, because we are designing the long-term future to be accomplished before deciding what methods and means might create it. Terminology should be precise when describing the world to which we will expect to commit many resources.
Critical Success Factors are the areas of your business or project that are absolutely essential to its success. By identifying and communicating these CSFs, you can help ensure your business or project is well-focused and avoid wasting effort and resources on less important areas. By making CSFs explicit, and communicating them with everyone involved, you can help keep the business and project on track towards common aims and goals.
LINKS used:
http://en.wikipedia.org/wiki/Critical_success_factor
http://www.mindtools.com/pages/article/newLDR_80.htm
http://media.wiley.com/product_data/excerpt/30/07879650/0787965030.pdf
SAD Assign3 :)
We actually had the same interview we had during our previous assignments. I still have DLPC’s (Davao Light and Power Corporation) system analyst as my interviewee.
Project Manager and System Analyst has analytical work in the administration or operation of computer(s) or groups of computers, troubleshooting and improving operation systems, and monitoring the usage and workload of the computer systems and auxiliary equipment. Operational procedures of computer applications are analyzed to determine potential for automation to improve efficiency or correct recurring errors. Problems with operational functions and application performance are analyzed to determine when situations require changes or enhancements to be designed, tested and implemented. Updates to operational software or new utilities to optimize system performance are installed requiring analysis of impact to existing computer systems and languages and other applications.
COMPETENCIES:
Planning and Organizing. Ability to work independently to complete tasks, and able to stay on task.
Project Management. Ability to interact as a productive team member on a project team or manages a project task.
Technical Knowledge. Ability to apply basic programming concepts to JCL. Understands software installation concepts.
Technical Solution Development. Knowledge of available technologies to recommend solutions for work that is characterized by a limited number of user objectives and relatively stable work functions.
Technical Support. Ability to resolve routine operational problems referred from technicians. Able to solicit relevant information from client in order to sufficiently describe non-routine problems to technical expert, and effectively communicate solution to client.
Consultancy Skills. Understands user needs through discussion with customer.
Since that a Project manager have the responsibility of the planning, execution, and closing of any project, typically relating to construction industry, architecture, computer networking, telecommunications or software development.
The person accountable for accomplishing the stated project objectives. Key project management responsibilities include creating clear and attainable project objectives, building the project requirements, and managing the triple constraint for projects, which are; cost, time, and quality (also known as scope).
A project manager is often a client representative and has to determine and implement the exact needs of the client, based on knowledge of the firm they are representing. The ability to adapt to the various internal procedures of the contracting party, and to form close links with the nominated representatives, is essential in ensuring that the key issues of cost, time, quality and above all, client satisfaction, can be realized.
The specific responsibilities of the Project Manager vary depending on the industry, the company size, the company maturity, and the company culture. However, there are some responsibilities that are common to all Project Managers, noting:
• Developing the project plan
• Managing the project stakeholders
• Managing the project team
• Managing the project risk
• Managing the project schedule
• Managing the project budget
• Managing the project conflicts
In the modern workplace, it is imperative that Information Technology (IT) works both effectively and reliably. Computer and information systems managers play a vital role in the implementation and administration of technology within their organizations. They plan, coordinate, and direct research on the computer-related activities of firms. In consultation with other managers, they help determine the goals of an organization and then implement technology to meet those goals. They oversee all technical aspect of an organization, such as software development, network security, and Internet operations.
Computer and information systems managers direct the work of other IT professionals, such as computer software engineers and computer programmers, computer systems analysts, and computer support specialists (information on these occupations can be found elsewhere in the Handbook). They plan and coordinate activities such as installing and upgrading hardware and software, programming and systems design, the implementation of computer networks, and the development of Internet and intranet sites. They are increasingly involved with the upkeep, maintenance, and security of networks. They analyze the computer and information needs of their organizations from an operational and strategic perspective and determine immediate and long-range personnel and equipment requirements. They assign and review the work of their subordinates and stay abreast of the latest technology to ensure that the organization remains competitive.
Computer and information systems managers can have additional duties, depending on their role within an organization. Chief technology officers (CTOs),for example, evaluate the newest and most innovative technologies and determine how these can help their organizations. They develop technical standards, deploy technology, and supervise workers who deal with the daily information technology issues of the firm. When a useful new tool has been identified, the CTO determines one or more possible implementation strategies, including cost-benefit and return on investment analyses, and presents those strategies to top management, such as the chief information officer (CIO).
Computer and information systems managers generally work in clean, comfortable offices. Long hours are common, and some may have to work evenings and weekends to meet deadlines or solve unexpected problems; in 2008, about 25 percent worked more than 50 hours per week. Some computer and information systems managers may experience considerable pressure in meeting technical goals with short deadlines or tight budgets. As networks continue to expand and more work is done remotely, computer and information systems managers have to communicate with and oversee offsite employees using laptops, e-mail, and the Internet.
Injuries in this occupation are uncommon, but like other workers who spend considerable time using computers, computer and information systems managers are susceptible to eyestrain, back discomfort, and hand and wrist problems such as carpal tunnel syndrome.
Computer and information systems managers generally have technical expertise from working in a computer occupation, as well as an understanding of business and management principles. A strong educational background and experience in a variety of technical fields is needed.
LINKS:
http://www.osp.state.nc.us/CareerBanding/Specs/Operations%20&%20Systems%20Analyst.pdf
http://en.wikipedia.org/wiki/Project_manager
Project Manager and System Analyst has analytical work in the administration or operation of computer(s) or groups of computers, troubleshooting and improving operation systems, and monitoring the usage and workload of the computer systems and auxiliary equipment. Operational procedures of computer applications are analyzed to determine potential for automation to improve efficiency or correct recurring errors. Problems with operational functions and application performance are analyzed to determine when situations require changes or enhancements to be designed, tested and implemented. Updates to operational software or new utilities to optimize system performance are installed requiring analysis of impact to existing computer systems and languages and other applications.
COMPETENCIES:
Planning and Organizing. Ability to work independently to complete tasks, and able to stay on task.
Project Management. Ability to interact as a productive team member on a project team or manages a project task.
Technical Knowledge. Ability to apply basic programming concepts to JCL. Understands software installation concepts.
Technical Solution Development. Knowledge of available technologies to recommend solutions for work that is characterized by a limited number of user objectives and relatively stable work functions.
Technical Support. Ability to resolve routine operational problems referred from technicians. Able to solicit relevant information from client in order to sufficiently describe non-routine problems to technical expert, and effectively communicate solution to client.
Consultancy Skills. Understands user needs through discussion with customer.
Since that a Project manager have the responsibility of the planning, execution, and closing of any project, typically relating to construction industry, architecture, computer networking, telecommunications or software development.
The person accountable for accomplishing the stated project objectives. Key project management responsibilities include creating clear and attainable project objectives, building the project requirements, and managing the triple constraint for projects, which are; cost, time, and quality (also known as scope).
A project manager is often a client representative and has to determine and implement the exact needs of the client, based on knowledge of the firm they are representing. The ability to adapt to the various internal procedures of the contracting party, and to form close links with the nominated representatives, is essential in ensuring that the key issues of cost, time, quality and above all, client satisfaction, can be realized.
The specific responsibilities of the Project Manager vary depending on the industry, the company size, the company maturity, and the company culture. However, there are some responsibilities that are common to all Project Managers, noting:
• Developing the project plan
• Managing the project stakeholders
• Managing the project team
• Managing the project risk
• Managing the project schedule
• Managing the project budget
• Managing the project conflicts
In the modern workplace, it is imperative that Information Technology (IT) works both effectively and reliably. Computer and information systems managers play a vital role in the implementation and administration of technology within their organizations. They plan, coordinate, and direct research on the computer-related activities of firms. In consultation with other managers, they help determine the goals of an organization and then implement technology to meet those goals. They oversee all technical aspect of an organization, such as software development, network security, and Internet operations.
Computer and information systems managers direct the work of other IT professionals, such as computer software engineers and computer programmers, computer systems analysts, and computer support specialists (information on these occupations can be found elsewhere in the Handbook). They plan and coordinate activities such as installing and upgrading hardware and software, programming and systems design, the implementation of computer networks, and the development of Internet and intranet sites. They are increasingly involved with the upkeep, maintenance, and security of networks. They analyze the computer and information needs of their organizations from an operational and strategic perspective and determine immediate and long-range personnel and equipment requirements. They assign and review the work of their subordinates and stay abreast of the latest technology to ensure that the organization remains competitive.
Computer and information systems managers can have additional duties, depending on their role within an organization. Chief technology officers (CTOs),for example, evaluate the newest and most innovative technologies and determine how these can help their organizations. They develop technical standards, deploy technology, and supervise workers who deal with the daily information technology issues of the firm. When a useful new tool has been identified, the CTO determines one or more possible implementation strategies, including cost-benefit and return on investment analyses, and presents those strategies to top management, such as the chief information officer (CIO).
Computer and information systems managers generally work in clean, comfortable offices. Long hours are common, and some may have to work evenings and weekends to meet deadlines or solve unexpected problems; in 2008, about 25 percent worked more than 50 hours per week. Some computer and information systems managers may experience considerable pressure in meeting technical goals with short deadlines or tight budgets. As networks continue to expand and more work is done remotely, computer and information systems managers have to communicate with and oversee offsite employees using laptops, e-mail, and the Internet.
Injuries in this occupation are uncommon, but like other workers who spend considerable time using computers, computer and information systems managers are susceptible to eyestrain, back discomfort, and hand and wrist problems such as carpal tunnel syndrome.
Computer and information systems managers generally have technical expertise from working in a computer occupation, as well as an understanding of business and management principles. A strong educational background and experience in a variety of technical fields is needed.
LINKS:
http://www.osp.state.nc.us/CareerBanding/Specs/Operations%20&%20Systems%20Analyst.pdf
http://en.wikipedia.org/wiki/Project_manager
Thursday, December 17, 2009
MIS2- Assign5 :)
The rate of organizational change has not slowed in recent years, and may even be increasing. The rapid and continual innovation in technology is driving changes to organizational systems and processes. Witness the startling growth of the internet, which is enabling much faster and easier access to knowledge. Add to this the increased expectations of employees as they move more freely between organizations. And, of course, globalization has seen the tearing down of previous international market barriers. It is no wonder that relentless change has become a fact of organizational life.
In spite of the importance and permanence of organizational change, most change initiatives fail to deliver the expected organizational benefits. This failure occurs for a number of reasons. You might recognize one or more of these in your organization.
absence of a change champion or one who is too junior in the organization
poor executive sponsorship or senior management support
poor project management skills
hope rested on a one-dimensional solution
political infighting and turf wars
poorly defined organizational objectives
change team diverted to other projects
Failed organizational change initiatives leave in their wake cynical and burned out employees, making the next change objective even more difficult to accomplish. It should come as no surprise that the fear of managing change and its impacts is a leading cause of anxiety in managers.
Understanding your organization and matching the initiative to your organization’s real needs (instead of adopting the latest fad) is the first step in making your change program successful. Beyond that, recognize that bringing about organizational change is fundamentally about changing people’s behavior in certain desired ways. As is apparent from the above list of reasons for failure, lack of technical expertise is not the main impediment to successful change. Leadership and management skills, such as visioning, prioritizing, planning, providing feedback and rewarding success, are key factors in any successful change initiative.
Change Management Principles
Adopting a principled approach that displays integrity and engenders openness and trust will see your change program through the hard times. Our consultancy promotes five key principles of successful change management. Adopting these principles in both spirit and practice will enhance significantly your chances of success. These principles are:
1.Sponsorship
The change program has the visible support of key decision-makers throughout the organization and resources are committed to the program.
2.Planning
Planning is conducted methodically before program implementation and committed to writing. Plans are agreed with major stakeholders and objectives, resources, roles and risks are clarified.
3.Measurement
Program objectives are stated in measurable terms and program progress is monitored and communicated to major stakeholders.
4.Engagement
Stakeholders are engaged in genuine two-way dialogue in an atmosphere of openness, mutual respect and trust.
5.Support structures
Program implementers and change recipients are given the resources and supporting systems they require during and after change implementation.
Significant organizational change occurs, for example, when an organization changes its overall strategy for success, adds or removes a major section or practice, and/or wants to change the very nature by which it operates. It also occurs when an organization evolves through various life cycles, just like people must successfully evolve through life cycles. For organizations to develop, they often must undergo significant change at various points in their development. That's why the topic of organizational change and development has become widespread in communications about business, organizations, leadership and management.
Leaders and managers continually make efforts to accomplish successful and significant change -- it's inherent in their jobs. Some are very good at this effort (probably more than we realize), while others continually struggle and fail. That's often the difference between people who thrive in their roles and those that get shuttled around from job to job, ultimately settling into a role where they're frustrated and ineffective. There are many schools with educational programs about organizations, business, leadership and management. Unfortunately, there still are not enough schools with programs about how to analyze organizations, identify critically important priorities to address (such as systemic problems or exciting visions for change) and then undertake successful and significant change to address those priorities. This Library topic aims to improve that situation.
As I continuously browse the net for further articles, I had found some of the Major roles during and
Capacity Building, The process of organizational change can include a variety of key roles. These roles can be filled by various individuals or groups at various times during the change process. Sometimes, individuals or
groups can fill more than one role.
Change Initiator
It is conventional wisdom among organizational development consultants that successful change is often provoked by a deep “hurt” or crisis in the organization, for example, dramatic reduction in sales, loss of a key leader in the organization, warnings from a major investor, or even actions of a key competitor. It is not uncommon then that someone inside the organization reacts to that deep hurt and suggests the need for a major change effort. Often the person who initiates the change is not the person who becomes the primary change agent.
Change Agent
The change agent is the person responsible for organizing and coordinating the overall change effort. The change agent role can be filled by different people at different times during the project. For example, an outside consultant might be the first change agent. After the project plan has been developed and begins implementation, the change agent might be an implementation team comprised of people from the organization. If the change effort stalls out, the change agent might be a top leader in the organization who intercedes to ensure the change process continues in a timely fashion.
Champion for Change
Change efforts often require a person or group who continues to build and sustain strong enthusiasm about the change. This includes reminding everyone of why the change is occurring in the first place, the many benefits that have come and will come from the change process. The champion might be the same person as the change agent at various times in the project.
Sponsor of Change
Usually, there is a one key internal person or department that is officially the “sponsor,” or official role responsible for coordinating the change process. In large organizations, that sponsor often is a department, such as Human Resources, Strategic Planning or Information Technology. In smaller organizations, the sponsor might be a team of senior leaders working to ensure that the change effort stays on schedule and is sustained by ongoing provision of resources and training.
Leadership, Supervision, and Delegation
In this Field Guide, leadership is defined as setting direction and influencing people to follow that direction. A person can lead themselves, other individuals, other groups or an entire organization. Supervision is guiding the development and productivity of people in the organization. Effective supervisors are able to achieve goals by guiding the work of other people – by delegating.
Organizations can't change without people changing first. It is the collective action of individual change that emerges as organizational change. One approach to understanding how individuals change is the Transtheoretical Model (TTM), which is also known as Stages of Change (SOC). Change cannot be commanded, yet it is possible to influence individual change.
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.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.
The widespread impact of industrial automation raises social issues, among them its impact on employment. Historical concerns about the effects of automation date back to the beginning of the industrial revolution, when a social movement of English textile machine operators in the early 1800s known as the Luddites protested against Jacquard's automated weaving looms[4] — often by destroying such textile machines— that they felt threatened their jobs. One author made the following case. When automation was first introduced, it caused widespread fear. It was thought that the displacement of human operators by computerized systems would lead to severe unemployment.
Rationalization of Procedures is the application of efficiency or effectiveness measures to an organization. Rationalization can occur at the onset of a downturn in an organization's performance or results. It usually takes the form of cutbacks intended to bring the organization back to profitability and may involve layoffs, plant closures, and cutbacks in supplies and resources. It often involves changes in organization structure, particularly in the form of downsizing. The term is also used in a cynical way as a euphemism for mass layoffs.
Business process reengineering (often referred to by the acronym BPR) is the main way in which organizations become more efficient and modernize. Business process reengineering transforms an organization in ways that directly affect performance.
The two cornerstones of any organization are the people and the processes. If individuals are motivated and working hard, yet the business processes are cumbersome and non-essential activities remain, organizational performance will be poor. Business Process Reengineering is the key to transforming how people work. What appear to be minor changes in processes can have dramatic effects on cash flow, service delivery and customer satisfaction. Even the act of documenting business processes alone will typically improve organizational efficiency by 10%.
The best way to map and improve the organization's procedures is to take a top down approach, and not undertake a project in isolation. That means:
Starting with mission statements that define the purpose of the organization and describe what sets it apart from others in its sector or industry.
Producing vision statements which define where the organization is going, to provide a clear picture of the desired future position.
Build these into a clear business strategy thereby deriving the project objectives.
Defining behaviours that will enable the organization to achieve its' aims.
Producing key performance measures to track progress.
Relating efficiency improvements to the culture of the organization
Identifying initiatives that will improve performance.
To be successful, business process reengineering projects need to be top down, taking in the complete organization, and the full end to end processes. It needs to be supported by tools that make processes easy to track and analyze.
Paradigm Shifts (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.
Think of a Paradigm Shift as a change from one way of thinking to another. It's a revolution, a transformation, a sort of metamorphosis. It just does not happen, but rather it is driven by agents of change.
Agents of change helped create a paradigm-shift moving scientific theory from the Plolemaic system (the earth at the center of the universe) to the Copernican system (the sun at the center of the universe), and moving from Newtonian physics to Relativity and Quantum Physics. Both movements eventually changed the world view. These transformations were gradual as old beliefs were replaced by the new paradigms creating "a new gestalt".
In initiating organizational change, the first step is raising awareness that some change is needed. An Organizational Assessment can be used as a point for initiating the dialogue that is necessary for organizational change to gain grassroots acceptance (the 1st step towards commitment). -”Rose A. Wirth, Ph D”
*References used in this assignment are posted at our forum:
http://usep-ic.forumsmotions.com/mis-2-f20/assignment-5-due-december-23-2009-before-0100p-t159.htm#2936
In spite of the importance and permanence of organizational change, most change initiatives fail to deliver the expected organizational benefits. This failure occurs for a number of reasons. You might recognize one or more of these in your organization.
absence of a change champion or one who is too junior in the organization
poor executive sponsorship or senior management support
poor project management skills
hope rested on a one-dimensional solution
political infighting and turf wars
poorly defined organizational objectives
change team diverted to other projects
Failed organizational change initiatives leave in their wake cynical and burned out employees, making the next change objective even more difficult to accomplish. It should come as no surprise that the fear of managing change and its impacts is a leading cause of anxiety in managers.
Understanding your organization and matching the initiative to your organization’s real needs (instead of adopting the latest fad) is the first step in making your change program successful. Beyond that, recognize that bringing about organizational change is fundamentally about changing people’s behavior in certain desired ways. As is apparent from the above list of reasons for failure, lack of technical expertise is not the main impediment to successful change. Leadership and management skills, such as visioning, prioritizing, planning, providing feedback and rewarding success, are key factors in any successful change initiative.
Change Management Principles
Adopting a principled approach that displays integrity and engenders openness and trust will see your change program through the hard times. Our consultancy promotes five key principles of successful change management. Adopting these principles in both spirit and practice will enhance significantly your chances of success. These principles are:
1.Sponsorship
The change program has the visible support of key decision-makers throughout the organization and resources are committed to the program.
2.Planning
Planning is conducted methodically before program implementation and committed to writing. Plans are agreed with major stakeholders and objectives, resources, roles and risks are clarified.
3.Measurement
Program objectives are stated in measurable terms and program progress is monitored and communicated to major stakeholders.
4.Engagement
Stakeholders are engaged in genuine two-way dialogue in an atmosphere of openness, mutual respect and trust.
5.Support structures
Program implementers and change recipients are given the resources and supporting systems they require during and after change implementation.
Significant organizational change occurs, for example, when an organization changes its overall strategy for success, adds or removes a major section or practice, and/or wants to change the very nature by which it operates. It also occurs when an organization evolves through various life cycles, just like people must successfully evolve through life cycles. For organizations to develop, they often must undergo significant change at various points in their development. That's why the topic of organizational change and development has become widespread in communications about business, organizations, leadership and management.
Leaders and managers continually make efforts to accomplish successful and significant change -- it's inherent in their jobs. Some are very good at this effort (probably more than we realize), while others continually struggle and fail. That's often the difference between people who thrive in their roles and those that get shuttled around from job to job, ultimately settling into a role where they're frustrated and ineffective. There are many schools with educational programs about organizations, business, leadership and management. Unfortunately, there still are not enough schools with programs about how to analyze organizations, identify critically important priorities to address (such as systemic problems or exciting visions for change) and then undertake successful and significant change to address those priorities. This Library topic aims to improve that situation.
As I continuously browse the net for further articles, I had found some of the Major roles during and
Capacity Building, The process of organizational change can include a variety of key roles. These roles can be filled by various individuals or groups at various times during the change process. Sometimes, individuals or
groups can fill more than one role.
Change Initiator
It is conventional wisdom among organizational development consultants that successful change is often provoked by a deep “hurt” or crisis in the organization, for example, dramatic reduction in sales, loss of a key leader in the organization, warnings from a major investor, or even actions of a key competitor. It is not uncommon then that someone inside the organization reacts to that deep hurt and suggests the need for a major change effort. Often the person who initiates the change is not the person who becomes the primary change agent.
Change Agent
The change agent is the person responsible for organizing and coordinating the overall change effort. The change agent role can be filled by different people at different times during the project. For example, an outside consultant might be the first change agent. After the project plan has been developed and begins implementation, the change agent might be an implementation team comprised of people from the organization. If the change effort stalls out, the change agent might be a top leader in the organization who intercedes to ensure the change process continues in a timely fashion.
Champion for Change
Change efforts often require a person or group who continues to build and sustain strong enthusiasm about the change. This includes reminding everyone of why the change is occurring in the first place, the many benefits that have come and will come from the change process. The champion might be the same person as the change agent at various times in the project.
Sponsor of Change
Usually, there is a one key internal person or department that is officially the “sponsor,” or official role responsible for coordinating the change process. In large organizations, that sponsor often is a department, such as Human Resources, Strategic Planning or Information Technology. In smaller organizations, the sponsor might be a team of senior leaders working to ensure that the change effort stays on schedule and is sustained by ongoing provision of resources and training.
Leadership, Supervision, and Delegation
In this Field Guide, leadership is defined as setting direction and influencing people to follow that direction. A person can lead themselves, other individuals, other groups or an entire organization. Supervision is guiding the development and productivity of people in the organization. Effective supervisors are able to achieve goals by guiding the work of other people – by delegating.
Organizations can't change without people changing first. It is the collective action of individual change that emerges as organizational change. One approach to understanding how individuals change is the Transtheoretical Model (TTM), which is also known as Stages of Change (SOC). Change cannot be commanded, yet it is possible to influence individual change.
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.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.
The widespread impact of industrial automation raises social issues, among them its impact on employment. Historical concerns about the effects of automation date back to the beginning of the industrial revolution, when a social movement of English textile machine operators in the early 1800s known as the Luddites protested against Jacquard's automated weaving looms[4] — often by destroying such textile machines— that they felt threatened their jobs. One author made the following case. When automation was first introduced, it caused widespread fear. It was thought that the displacement of human operators by computerized systems would lead to severe unemployment.
Rationalization of Procedures is the application of efficiency or effectiveness measures to an organization. Rationalization can occur at the onset of a downturn in an organization's performance or results. It usually takes the form of cutbacks intended to bring the organization back to profitability and may involve layoffs, plant closures, and cutbacks in supplies and resources. It often involves changes in organization structure, particularly in the form of downsizing. The term is also used in a cynical way as a euphemism for mass layoffs.
Business process reengineering (often referred to by the acronym BPR) is the main way in which organizations become more efficient and modernize. Business process reengineering transforms an organization in ways that directly affect performance.
The two cornerstones of any organization are the people and the processes. If individuals are motivated and working hard, yet the business processes are cumbersome and non-essential activities remain, organizational performance will be poor. Business Process Reengineering is the key to transforming how people work. What appear to be minor changes in processes can have dramatic effects on cash flow, service delivery and customer satisfaction. Even the act of documenting business processes alone will typically improve organizational efficiency by 10%.
The best way to map and improve the organization's procedures is to take a top down approach, and not undertake a project in isolation. That means:
Starting with mission statements that define the purpose of the organization and describe what sets it apart from others in its sector or industry.
Producing vision statements which define where the organization is going, to provide a clear picture of the desired future position.
Build these into a clear business strategy thereby deriving the project objectives.
Defining behaviours that will enable the organization to achieve its' aims.
Producing key performance measures to track progress.
Relating efficiency improvements to the culture of the organization
Identifying initiatives that will improve performance.
To be successful, business process reengineering projects need to be top down, taking in the complete organization, and the full end to end processes. It needs to be supported by tools that make processes easy to track and analyze.
Paradigm Shifts (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.
Think of a Paradigm Shift as a change from one way of thinking to another. It's a revolution, a transformation, a sort of metamorphosis. It just does not happen, but rather it is driven by agents of change.
Agents of change helped create a paradigm-shift moving scientific theory from the Plolemaic system (the earth at the center of the universe) to the Copernican system (the sun at the center of the universe), and moving from Newtonian physics to Relativity and Quantum Physics. Both movements eventually changed the world view. These transformations were gradual as old beliefs were replaced by the new paradigms creating "a new gestalt".
In initiating organizational change, the first step is raising awareness that some change is needed. An Organizational Assessment can be used as a point for initiating the dialogue that is necessary for organizational change to gain grassroots acceptance (the 1st step towards commitment). -”Rose A. Wirth, Ph D”
*References used in this assignment are posted at our forum:
http://usep-ic.forumsmotions.com/mis-2-f20/assignment-5-due-december-23-2009-before-0100p-t159.htm#2936
SAD1- Assign2 :)
Question was interview a System Analyst and ask what skills and characteristics must a systems analyst develop in order to be more effective in any design modeling process, in this interview, evidences such as letters and pictures must be included. In our previous assignment I had already defined what is a System Analyst and their different characteristics. We actually had an interview with the Systems Analyst of Davao Light whose name I cant recall. (I'm sorry) Actually, during the interview I was late, yet I was able to catch up some of the important details needed for this assignment.
We already knew what a System Analyst is based on our previous discussions and repetitive mentioning of it every time we make assessments. Well, to recall, a System Analyst, is responsible for researching, planning, coordinating and recommending software and system choices to meet an organization's business requirements. The systems analyst plays a vital role in the systems development process. A successful systems analyst must acquire four skills: analytical, technical, managerial, and interpersonal.
The information systems analyst assists a senior analyst or consultant in determining the feasibility of
implementing new computer applications or upgrades. The information systems analyst meets with users to determine and assess user needs, and designs and tests applications and enhancements. The information systems analyst is also responsible for debugging applications and providing technical support and training to users. The information systems analyst will prepare technical documentation and procedural instructions for implementing systems software. Working relationships are established with state courts personnel. Work is performed under the general supervision of the Information Systems Analyst Manager.
Since a System Analyst has a known major skills, I think it would be appropriate to elaborate those. Analytical skills enable systems analysts to understand the organization and its functions, which helps him/her to identify opportunities and to analyze and solve problems. Technical skills help systems analysts understand the potential and the limitations of information technology. The systems analyst must be able to work with various programming languages, operating systems, and computer hardware platforms. Management skills help systems analysts manage projects, resources, risk, and change. Interpersonal skills help systems analysts work with end users as well as with analysts, programmers, and other systems professionals.
Systems analysts, as motivated and talented IT professionals, solve computer problems and apply computer technology, to meet the individual needs of an organization, realize the maximum benefit from investment in equipment, personnel, and business processes, plan and develop new computer systems, or devise ways to apply existing systems’ resources to additional operations.
As a systems analyst, one may design new systems, including both hardware and software, or add a new software application, to harness more of the computer’s power. Most system analysts work with specific types of systems-for example, business, accounting, or financial systems, or scientific and engineering systems-that vary within the organization and industry. Some system analysts are known as systems developers or systems architects.
As according to the interviewee, a System Analyst must have Communication Skills that is really needed for an organization like:
1. clear and effective interpersonal communication, whether written, verbal, or visual,
from writing reports to face–to–face conversations, to presentations in front of groups;
2. listening (accepting opinions and ideas from other project team members),
3. group facilitation or formal technical reviews (FTR) skills:
- setting an agenda,
- leading discussions,
- involving all parties in the discussion,
- summarizing ideas,
- keeping discussions on the agenda, etc.
If a System Analyst have those Communication Skills, he / she must also have Technical Skills but not they are not limited to, such as:
1. Computers (PCs, mini, mainframes, etc.)
2. Computer networks (LAN, WAN, VPNs, administration, security, etc.)
3. Operating systems (Unix, Mac/OS, Windows)
4. Data Exchange Protocols (ftp, http, etc.)
5. Programming languages (C++, Java, XML, etc.)
6. Software applications (Office, project managements, etc.)
7. Information systems (databases, MISs, decision support systems)
8. System development tools and environments (such as report generators, office automation
tools, etc.)
In Addition, a System Analyst has the ability to conduct a feasibility analysis of systems and programs requirements. Ability to prepare clear, detailed programs of instruction for users of the State Courts System management information system. Ability to detect errors on detailed charts, diagrams, and code sheets. Ability to interpret diagrammatic presentations of work flow, and prepare computer block diagrams and flow charts. Ability to act as a project leader. Ability to operate an on-line date entry terminal.
Most importantly, a System Analyst must have a good Managerial Skills as follows:
1. resource management
effectively managing the project’s resources, including time, equipment, hardware, software, people, money, etc.,
2. project management
determining the tasks and resources needed for a project and how they are related to each other,
3. risk management
identifying and minimizing risks,
4. change management
managing the system’s (organization's) transition from one state to another
Required technical skills can include knowledge of PL/SQL, Oracle, SQL Server 2000, MS-Access – Crystal Reports, Windows Server 2000/2003, Windows 2000/XP, Visual Basic, Microsoft.net MS -Office; Experience with enterprise finance and/or HR software systems; combined with demonstrable proficiency in producing appropriate, effective documentation are considered prerequisites for success in this field. Preferably, a BS in Computer Science, MIS or related area supplemented by a minimum of 5 yrs previous experience and/or training, that includes computer programming, systems analysis, computer operations and hardware/software troubleshooting, can enable you to find challenging opportunities in this field.
As highly trained skilled knowledge workers and information technology experts, they will be in demand. Some of the main duties and tasks include: design and development of new hardware and software systems, incorporating new technologies, new areas of specialization or changes in technology is prevalent. Typically seeking to work in offices or laboratories, in comfortable surroundings and even pursuing tele-commuting or self-employment, contract and project-work, working independently as contractors or consultants, are all viable options. A 40-hour work week is typical, but more and more weekend, evening and deadline-related, project-work, characterize the modern technology-driven environment. Other risks specifically to watch for, would be susceptibility to eyestrain, back discomfort, as well as hand and wrist problems such as carpal tunnel syndrome or cumulative trauma disorder.
To enhance your professional knowledge and broaden your opportunities, consider:
Keeping constantly updated in your specialty
Improving interpersonal skills
Setting standards and guidelines for safety/operations
Learning business management
Finding out about international networks
For systems analyst, programmer-analyst, and database administrator positions, many employers seek applicants who have a bachelor’s degree in computer science, information science, or management information systems (MIS). MIS programs usually are part of the business school or college and differ considerably from computer science programs, emphasizing business and management-oriented course work and business computing courses. Employers are increasingly seeking individuals with a master’s degree in business administration (MBA), with a concentration in information systems, as more firms move their business to the Internet.
References:
Skills_Pretest_Posttest_Answers.pdf
infosysanalyst.pdf
http://www.systemsanalyst.com/systems-analyst-solvers-of-computer-problems-and-master-craft-applicants-of-computer-technology/
Pictures taken as evidences:
We already knew what a System Analyst is based on our previous discussions and repetitive mentioning of it every time we make assessments. Well, to recall, a System Analyst, is responsible for researching, planning, coordinating and recommending software and system choices to meet an organization's business requirements. The systems analyst plays a vital role in the systems development process. A successful systems analyst must acquire four skills: analytical, technical, managerial, and interpersonal.
The information systems analyst assists a senior analyst or consultant in determining the feasibility of
implementing new computer applications or upgrades. The information systems analyst meets with users to determine and assess user needs, and designs and tests applications and enhancements. The information systems analyst is also responsible for debugging applications and providing technical support and training to users. The information systems analyst will prepare technical documentation and procedural instructions for implementing systems software. Working relationships are established with state courts personnel. Work is performed under the general supervision of the Information Systems Analyst Manager.
Since a System Analyst has a known major skills, I think it would be appropriate to elaborate those. Analytical skills enable systems analysts to understand the organization and its functions, which helps him/her to identify opportunities and to analyze and solve problems. Technical skills help systems analysts understand the potential and the limitations of information technology. The systems analyst must be able to work with various programming languages, operating systems, and computer hardware platforms. Management skills help systems analysts manage projects, resources, risk, and change. Interpersonal skills help systems analysts work with end users as well as with analysts, programmers, and other systems professionals.
Systems analysts, as motivated and talented IT professionals, solve computer problems and apply computer technology, to meet the individual needs of an organization, realize the maximum benefit from investment in equipment, personnel, and business processes, plan and develop new computer systems, or devise ways to apply existing systems’ resources to additional operations.
As a systems analyst, one may design new systems, including both hardware and software, or add a new software application, to harness more of the computer’s power. Most system analysts work with specific types of systems-for example, business, accounting, or financial systems, or scientific and engineering systems-that vary within the organization and industry. Some system analysts are known as systems developers or systems architects.
As according to the interviewee, a System Analyst must have Communication Skills that is really needed for an organization like:
1. clear and effective interpersonal communication, whether written, verbal, or visual,
from writing reports to face–to–face conversations, to presentations in front of groups;
2. listening (accepting opinions and ideas from other project team members),
3. group facilitation or formal technical reviews (FTR) skills:
- setting an agenda,
- leading discussions,
- involving all parties in the discussion,
- summarizing ideas,
- keeping discussions on the agenda, etc.
If a System Analyst have those Communication Skills, he / she must also have Technical Skills but not they are not limited to, such as:
1. Computers (PCs, mini, mainframes, etc.)
2. Computer networks (LAN, WAN, VPNs, administration, security, etc.)
3. Operating systems (Unix, Mac/OS, Windows)
4. Data Exchange Protocols (ftp, http, etc.)
5. Programming languages (C++, Java, XML, etc.)
6. Software applications (Office, project managements, etc.)
7. Information systems (databases, MISs, decision support systems)
8. System development tools and environments (such as report generators, office automation
tools, etc.)
In Addition, a System Analyst has the ability to conduct a feasibility analysis of systems and programs requirements. Ability to prepare clear, detailed programs of instruction for users of the State Courts System management information system. Ability to detect errors on detailed charts, diagrams, and code sheets. Ability to interpret diagrammatic presentations of work flow, and prepare computer block diagrams and flow charts. Ability to act as a project leader. Ability to operate an on-line date entry terminal.
Most importantly, a System Analyst must have a good Managerial Skills as follows:
1. resource management
effectively managing the project’s resources, including time, equipment, hardware, software, people, money, etc.,
2. project management
determining the tasks and resources needed for a project and how they are related to each other,
3. risk management
identifying and minimizing risks,
4. change management
managing the system’s (organization's) transition from one state to another
Required technical skills can include knowledge of PL/SQL, Oracle, SQL Server 2000, MS-Access – Crystal Reports, Windows Server 2000/2003, Windows 2000/XP, Visual Basic, Microsoft.net MS -Office; Experience with enterprise finance and/or HR software systems; combined with demonstrable proficiency in producing appropriate, effective documentation are considered prerequisites for success in this field. Preferably, a BS in Computer Science, MIS or related area supplemented by a minimum of 5 yrs previous experience and/or training, that includes computer programming, systems analysis, computer operations and hardware/software troubleshooting, can enable you to find challenging opportunities in this field.
As highly trained skilled knowledge workers and information technology experts, they will be in demand. Some of the main duties and tasks include: design and development of new hardware and software systems, incorporating new technologies, new areas of specialization or changes in technology is prevalent. Typically seeking to work in offices or laboratories, in comfortable surroundings and even pursuing tele-commuting or self-employment, contract and project-work, working independently as contractors or consultants, are all viable options. A 40-hour work week is typical, but more and more weekend, evening and deadline-related, project-work, characterize the modern technology-driven environment. Other risks specifically to watch for, would be susceptibility to eyestrain, back discomfort, as well as hand and wrist problems such as carpal tunnel syndrome or cumulative trauma disorder.
To enhance your professional knowledge and broaden your opportunities, consider:
Keeping constantly updated in your specialty
Improving interpersonal skills
Setting standards and guidelines for safety/operations
Learning business management
Finding out about international networks
For systems analyst, programmer-analyst, and database administrator positions, many employers seek applicants who have a bachelor’s degree in computer science, information science, or management information systems (MIS). MIS programs usually are part of the business school or college and differ considerably from computer science programs, emphasizing business and management-oriented course work and business computing courses. Employers are increasingly seeking individuals with a master’s degree in business administration (MBA), with a concentration in information systems, as more firms move their business to the Internet.
References:
Skills_Pretest_Posttest_Answers.pdf
infosysanalyst.pdf
http://www.systemsanalyst.com/systems-analyst-solvers-of-computer-problems-and-master-craft-applicants-of-computer-technology/
Pictures taken as evidences:
Tuesday, December 15, 2009
MIS2 - Assignment 4 :)
If I were invited by the university president to present my IS (Information System) Plan for the university in which I would really feel flattered for, and to discuss what are the steps to expedite or accelerate the implementation of my said IS (Information System) plan, I would first explain the foundation and grounds of an Information Systems Plan.
Any organization especially the university must be aware of the rationale of an Information System. In almost all the organizations in the world, they spend 5% of their gross income on information systems and their supports. If the corporation has $300-700 million dollar every year, $15,000,000 to $35,000,000 will be spent for the IS support which makes us think how on earth will our university have this lots of money just for an IS support, excluding of course the planning stage but then even planning costs a lot especially in a government organization.
Even though an information system costs from $1,000,000 to $10,000,000, and even through most chief information
officers (CIOs) can specify exactly how much money is being spent for hardware, software, and staff, CIOs cannot however state with any degree of certainty why one system is being done this year versus next, why it is being done ahead of another, or finally, why it is being done at all. I am referring to a million dollar company. But in case of USEP, I still find it hard to propose or much especially to have IS plan because of this one factor, BUDGET. I am sure that the university won’t spend lots and lots of millions just for an innovation. Well, it’s just what I think though.
Too many half-billion dollar organizations have only a vague notion of the names and interactions of the existing and under development information systems. Whenever they need to know, a meeting is held among the critical few, an inventory is taken, interactions confirmed, and accomplishment schedules are updated.
Rather than having centralized, long-range planning and management activities that address these problems, today's business units are using readily available tools to design and build ad hoc stop-gap solutions. These ad hoc systems not only do not interconnect, support common semantics, or provide synchronized views of critical corporate policy, they are soon to form the almost impossible to comprehend confusion of systems and data from which systems order and semantic harmony must spring. Not only has the computing landscape become profoundly different and more difficult to comprehend, the need for just the right--and correct--information at just the right time is escalating. Late or wrong information is worse than no information. Information systems managers need a model of their information systems environment. A model that is malleable. As new requirements are discovered, budgets modified, new hardware/software introduced, this model must be such that it can reconstitute the information systems plan in a timely and efficient manner.
There are five distinct characteristics of a QUALITY ISP (information Systems Plan) as according to Whitemarsh. A quality ISP must exhibit five distinct characteristics before it is useful. These five are presented in the table that follows.
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 should 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 (Information systems Plan) 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 (Information systems Plan) is risked.
It is very difficult to obtain consensus on a functional decomposition for any one application, much less across all the information systems within the entire corporation. That is because functional analysis requires identification and codification of how activities are performed. In short, the codification of style. This type of analysis leads to conflicts, power struggles, and endless nit-picking. In the end, nobody likes the results. Once, or if ever completed, both IBM and Martin use the resulting ISP as a foundation for identifying information systems. Building the ISP on top of such a foundation of discord cannot possibly result in stable, enduring information systems.
Finklestein's methodology requires the development of a fifth-normal form data model for the entire enterprise. Such an extraordinarily detailed effort certainly embraces three to five thousand entities, all the appropriate attributes, full definitions for entities and attributes, and a full exposition of every relationship among all entities. While development of such a edifice is a valuable final shrine once all the identified information systems have been implemented, it is totally unnecessary for the ISP.
Whitemarsh’s ISP: A Difference in Kind
Whitemarsh’s ISP approach was built directly on the strengths and designed-out the weaknesses of the three traditional approaches. The Whitemarsh approach employs:
! A mission based foundation for the ISP rather than the extremely politically charged function modeling.
! A data driven approach for the formulation of all databases, but only at a high level. That is, database objects.
! The Whitemarsh metabase to store, evolve, report and analyze all collected analysis products.
! Project, deliverable, and metric templates to make project estimation accurate and reproducible.
! Ron Ross’s interrelated resource life-cycles as a lattice upon which all ISP proposed projects are cast.
As a consequence of this difference in kind, the Whitemarsh ISP (Information Systems Plan) exhibits these characteristics:
Timely - Creation of the Whitemarsh ISP is timely because it can be created in less than three staff years. This is an order of magnitude less than IBM’s BSP, Martin’s SDP, or Finkelstein’s SMP. The time is even less if components already exist.
Useable - The Whitemarsh ISP enables its users to make both strategic and tactical decisions regarding business information system and database project sequencing based squarely on business fundamentals.
Maintainable - The Whitemarsh ISP is maintainable because it mainly uses metadata
already essential for enterprise database. Metadata that should be readily
available in the metabase.
High Quality – The Whitemarsh ISP is a quality product because it is accomplished through common-sense-based techniques that have been proven over 20+ years.
Reproducible - The Whitemarsh ISP is reproducible because at each review, the resources can be re-examined, new technology set into place, basic RLC precedence vectors re-cast, and then the whole plan regenerated.
The end product of the information systems project is an information systems plan (ISP).
Once deployed, the information systems department can implement the plan with confidence that
they are doing the correct information systems project at the right time and in the right sequence.
The focus of the ISP is not one information system but the entire suite of information systems for
the enterprise. Once developed, each identified information system is seen in context with all other information systems within the enterprise.
The following steps are involved in ISP development (Whitemarsh):
1.Create the mission model
2.Develop a high-level data model
3.Create the resource life cycles (RLC) and their nodes
4.Allocate precedence vectors among RLC nodes
5.Allocate existing information systems and databases to the RLC nodes
6.Allocate standard work break down structures (WBS) to each RLC node
7.Load resources into each WBS node
8.Schedule the RLC nodes through a project management package.
9.Produce and review of the ISP
10.Execute and adjust the ISP through time.
CREATE MISSION MODEL. Missions and mission descriptions are represented through hierarchically composed text. They are natural and are devoid of the effects from organizational structure stylistic effects. Missions from enterprises from the same “line of business” are very similar. In contrast, their
function models may be quite different because of effects imposed by management styles and
organizational structures. Simply stated, mission descriptions are goal and objective oriented and
are best seen as characterizations of the idealized end-results, without any regard for “who and
how.”
For many organizations, the mission description document often represents the first
overall statement of their raison d’etre. The table that follows contains the overall mission
description of the mythical Systems Engineering Corporation, and then the subordinate mission
description for its human resources mission.
It is important to distinguish between missions and functions. At first, missions and
functions look very much alike. However they are not. The following table illustrates their key
differences.
-----------------------------------------------------------------------------------------------------------------
Missions are descriptions of the characteristics of the end result. Missions are noun-based
sentences
Functions are descriptions of how to accomplish an end result. Functions are verb-based
Sentences
-----------------------------------------------------------------------------------------------------------------
Missions are a-political. They are devoid of “who and how.” There should only be ONE
mission description for a mission.
Function hierarchies are commonly tainted by organizations and styles. There can be any
number of equivalent versions of a given function.
-----------------------------------------------------------------------------------------------------------------
Databases and Business Information Systems are based on missions
“Human” activities and organizations are based on business functions
When you “Business Process Re-engineering (BPR)” functions you still have the same
business.
When you “BPR” missions you have a different business.
-----------------------------------------------------------------------------------------------------------------
Mission descriptions are strategic and long range
Functions are tactical to operational, and medium to short range, and are organizationally
Sensitive
-----------------------------------------------------------------------------------------------------------------
BUILD THE HIGH LEVEL DATA. The high level data model is created in two steps: building database domains, and creating database objects.
It is critical to state that the objective of this step is the high-level data model. The goal is
NOT to create a low level or fully attributed data model. The reasons that only a high-level data
model is needed is straight forward:
- No database projects are being accomplished, hence no detailed data modeling is required
- The goal of the ISP is to identify and resource allocate projects including database
projects and for that goal, entity identification, naming and brief definitions is all that is
required for estimating.
The message is simple: any money or resources expended in developing a detailed data model is
wasted.
CREATE DATABASE DOMAINS. Database domains are created from the “bottom” leaves of the mission description texts. There are two cases to consider. First, if the mission description’s bottom leaves are very detailed, they can be considered as having being transformed into database domains. That is they will consist of lists of nouns within simple sentences. The other case is that the mission descriptions have been defined to only a few levels, and the lists of nouns that would result from the development of
database domains have yet to be uncovered.
Whenever a database domain describes complex sets of data, multiple levels of the database domain description may be required. These subdomains are expressed as additional paragraphs. A review of these paragraphs clearly show that the text is “noun-intensive.” The “who and how” is clearly missing. That is the way it should be. If the “who and how” were contained in the database domains then they would not be independent of either process or organization.
A series of diagraming techniques created especially for data and the relationships among data is called entity-relationship (ER) diagraming. Within one style of this technique, the entities are drawn as rectangles and the relationships are drawn as diamonds. The name of the relationship is inside the diamond. Another style of ER modeling is to just have named lines between the entities. In this methodology, since the domain of the diagram is data, it is called the database domain diagram.
The purpose of the database domain diagram is not to be precise and exacting but to be comprehensive. The goal is to have the reviewer say, “that's just the right kind of data needed to satisfy the required mission description.”
When all the database domain diagrams are created, siblings are combined. Entities that are named the same are not presumed to be the same. Analysis must show that to be true. If not, one or both of the entities must have their name and definition changed. As the sets of sibling diagrams are merged from lower to higher levels, the quantity of commonly named entities on different diagrams diminishes. Diagram merger becomes optional when the use analysis of a common entity is subject to update (add, delete, or modify) in one diagram and is only referenced (read) in another diagram.
CREATE RESOURCES AND THE RESOURCE LIFE CYCLES (RCL). Missions are the idealized characterizations of end results of the visionary state of the operating enterprise. Database objects, founded squarely on missions are the highlevel declarations of the data required to reflect the achievement of the mission’s vision. Resources and their life cycles are the names, descriptions, and life cycles of the critical assets of the enterprise, which when exercised achieve one or more aspects of the missions. Each life cycle is composed of RLC nodes.
A mission might be human resource management, where in, the best and most cost effective staff is determined, acquired and managed. A database object squarely based on human resources would be employee. Within the database object, employee, are all the data structures, procedures, integrity constraints, table and database object procedures necessary to “move” the employee database object through its many policy-determined states. A resource might also be named employee, and would set out for the employee resource the life cycle stages that reflect the employee resource’s “journey” through the enterprise. While an enterprise may have 50 to 150 database objects, there are seldom more than 20 resources.
Enterprises build databases and business information systems around the achievement of the life cycle states of its resources. Business information systems execute in support of a particular life cycle stage of a resource (e.g., employee promotion). These information systems cause the databases to change value-state of contained database objects to correctly reflect the resource’s changed state. The state of one or more database objects in the database is the proof that the resource’s state has been achieved. Resources become the lattice work against which database and business information systems are allocated.
ALLOCATE INFORMATION SYSTEMS AND DATABASES TO THE RLC NODES. Once the resource life cycle network has been created, it is stored into the metabase. Once there, its lattice can be employed to attach the databases and business information systems. Databases and their business information systems exist within a data architecture framework.
Most resource life cycle nodes contain at least one original data capture database application. The data from these ODC databases should be pushed to their respective TDSA databases. Once there, various subject area databases pull the data to build the longitudinal and broad subject area databases. It is likely that there is one subject area database for one or more resources. Data from the subject area databases, also called operational data stores by Bill Inmon, is again pulled to create one or more data warehouse databases. Most databases employ one or more reference data tables as standard semantics for selection, control-breaks and printing.
ALLOCATE STANDARD WORK BREAK DOWN (WBD) STRUCTURES TO EACH INFORMATION SYSTEMS AND DATABASE PROJECTS. The key reason for having a well engineered check list for identifying the types of work involved in either a database or business information system project is the ability to then used canned work breakdown structures (WBS). When these WBSs are coupled with experience-honed metrics that are embedded in a project management system that “self-learns” from on-going projects,
accurate, reliable and repeatable project plans result.
The figure below presents a very high level view of how project management and the projects associated with RLC nodes are interrelated. In actuality, there are many more tables within the Whitemarsh project management software. But, from this perspective, when the assessment checklist is compiled, the specific WBSs that are applicable are selected from the project template table.
The five distinct classes of projects are:
! Administration and management
! Specification
! Implementation
! Operation and maintenance
! Multiple category
LOAD RESOURCES INTO EACH PROJECT. Once the WBS is selected, the WBS list and associated deliverables and metrics are automatically brought into the project. When the quantities for each deliverable type is computed, then the overall gross hours estimate for the project is created.
The gross hours estimate is then finalized (either upwards or downwards) by the selection of work environment factors (e.g., nobody even knows who the users are (that’s a bad work environment factor)), and also by the specific persons assigned who have varying levels of capabilities in certain experience levels (e.g., someone is assigned to create the data model who doesn’t yet even know the meaning of the term, “ER diagram”). That’s a bad staffing factor.
The value in having highly engineered work environment and staffing experience factors that adjust the gross hours is that project managers can then relay back to management the exact reasons why a project will cost more or less than another project of even the same construct and size.
The resources are then exported to a text file that is able to loaded into a project management system such as Microsoft Project. This is necessary because the purpose of the Whitemarsh project management system is to support the planning of projects on an enterprise wide basis rather than the scheduling of individual projects.
SCHEDULE THROUGH A PROJECT MANAGEMENT PACKAGE. Project management systems like Microsoft Project, Welcom’s Open Plan Professional, or Primavera’s P3e all require PERT (activity network charts) to effectively schedule an entire RLC network of RLC node assigned projects. When WBSs are brought into a project management system, they are treated as selfcontained subprojects within the overall set of RLC node network of projects. The resource life cycles are depicted from their first to last node in a topdown fashion. The precedence vectors are shows from one node of a RLC to another node of a adifferent RLC. Multiple precedence vectors do not exist between resource life cycles.
PRODUCE AND REVIEW THE ISP. When the resource loaded network of projects is scheduled through a project management system, normal results are produced. That is, the enterprise is faced with the requirement for:
! Infinite resources
! Infinite time
! Infinite computer capacity and speed, and
! Zero time allocated by “management” to accomplish all the work.
The ISP produced by this technique is thus no more able to be accomplished on the first pass
than is any other information systems plan. Now, where the Whitemarsh starts to become very
different from other ISPs is that the Whitemarsh ISP is fundamentally data within a database. Because the Whitemarsh ISP is “data,” it can be reported, queried, updated, recalculated, and reprinted any number of times with only reasonable effort.
A second key distinction is that the data that supports the ISP is primarily contributed by and thus supported by management. After all, it is their missions, their database domains, their database objects, their resources, their resource life cycles, and their precedence vectors between the resource life cycles. The only parts that are truly owned by information technology are the proposals for IT projects that transform an “as-is” database or information system to a “to-be” database or information system.
EXECUTE AND ADJUST ISP THROUGH TIME. Enterprises, once they evolve beyond their first round of information systems, find themselves transformed from a project and package mentality to a release mentality. The diagram on the next page illustrates this new continuous flow environment. It is characterized by:
! Multiple, concurrent, but differently scheduled projects against the same subject area
database or warehouse database
! Single-database projects that affect multiple subject area and data warehouse databases
! Projects that develop completely new capabilities, that can assess required changes to
existing capabilities, and that can accommodate a variety of systems generation
alternatives (COTS, package, and custom programming)
The continuous flow environment contains four major sets of activities. The user/client is represented at the top in the small rectangular box. Each of the ellipses represents an activity list to accomplish a specific need. The four basic needs are essentially:
! Need Identification
! Need Assessment
! Design
! Deployment
REFERENCE:
informationsystemsplanning.pdf
Any organization especially the university must be aware of the rationale of an Information System. In almost all the organizations in the world, they spend 5% of their gross income on information systems and their supports. If the corporation has $300-700 million dollar every year, $15,000,000 to $35,000,000 will be spent for the IS support which makes us think how on earth will our university have this lots of money just for an IS support, excluding of course the planning stage but then even planning costs a lot especially in a government organization.
Even though an information system costs from $1,000,000 to $10,000,000, and even through most chief information
officers (CIOs) can specify exactly how much money is being spent for hardware, software, and staff, CIOs cannot however state with any degree of certainty why one system is being done this year versus next, why it is being done ahead of another, or finally, why it is being done at all. I am referring to a million dollar company. But in case of USEP, I still find it hard to propose or much especially to have IS plan because of this one factor, BUDGET. I am sure that the university won’t spend lots and lots of millions just for an innovation. Well, it’s just what I think though.
Too many half-billion dollar organizations have only a vague notion of the names and interactions of the existing and under development information systems. Whenever they need to know, a meeting is held among the critical few, an inventory is taken, interactions confirmed, and accomplishment schedules are updated.
Rather than having centralized, long-range planning and management activities that address these problems, today's business units are using readily available tools to design and build ad hoc stop-gap solutions. These ad hoc systems not only do not interconnect, support common semantics, or provide synchronized views of critical corporate policy, they are soon to form the almost impossible to comprehend confusion of systems and data from which systems order and semantic harmony must spring. Not only has the computing landscape become profoundly different and more difficult to comprehend, the need for just the right--and correct--information at just the right time is escalating. Late or wrong information is worse than no information. Information systems managers need a model of their information systems environment. A model that is malleable. As new requirements are discovered, budgets modified, new hardware/software introduced, this model must be such that it can reconstitute the information systems plan in a timely and efficient manner.
There are five distinct characteristics of a QUALITY ISP (information Systems Plan) as according to Whitemarsh. A quality ISP must exhibit five distinct characteristics before it is useful. These five are presented in the table that follows.
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 should 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 (Information systems Plan) 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 (Information systems Plan) is risked.
It is very difficult to obtain consensus on a functional decomposition for any one application, much less across all the information systems within the entire corporation. That is because functional analysis requires identification and codification of how activities are performed. In short, the codification of style. This type of analysis leads to conflicts, power struggles, and endless nit-picking. In the end, nobody likes the results. Once, or if ever completed, both IBM and Martin use the resulting ISP as a foundation for identifying information systems. Building the ISP on top of such a foundation of discord cannot possibly result in stable, enduring information systems.
Finklestein's methodology requires the development of a fifth-normal form data model for the entire enterprise. Such an extraordinarily detailed effort certainly embraces three to five thousand entities, all the appropriate attributes, full definitions for entities and attributes, and a full exposition of every relationship among all entities. While development of such a edifice is a valuable final shrine once all the identified information systems have been implemented, it is totally unnecessary for the ISP.
Whitemarsh’s ISP: A Difference in Kind
Whitemarsh’s ISP approach was built directly on the strengths and designed-out the weaknesses of the three traditional approaches. The Whitemarsh approach employs:
! A mission based foundation for the ISP rather than the extremely politically charged function modeling.
! A data driven approach for the formulation of all databases, but only at a high level. That is, database objects.
! The Whitemarsh metabase to store, evolve, report and analyze all collected analysis products.
! Project, deliverable, and metric templates to make project estimation accurate and reproducible.
! Ron Ross’s interrelated resource life-cycles as a lattice upon which all ISP proposed projects are cast.
As a consequence of this difference in kind, the Whitemarsh ISP (Information Systems Plan) exhibits these characteristics:
Timely - Creation of the Whitemarsh ISP is timely because it can be created in less than three staff years. This is an order of magnitude less than IBM’s BSP, Martin’s SDP, or Finkelstein’s SMP. The time is even less if components already exist.
Useable - The Whitemarsh ISP enables its users to make both strategic and tactical decisions regarding business information system and database project sequencing based squarely on business fundamentals.
Maintainable - The Whitemarsh ISP is maintainable because it mainly uses metadata
already essential for enterprise database. Metadata that should be readily
available in the metabase.
High Quality – The Whitemarsh ISP is a quality product because it is accomplished through common-sense-based techniques that have been proven over 20+ years.
Reproducible - The Whitemarsh ISP is reproducible because at each review, the resources can be re-examined, new technology set into place, basic RLC precedence vectors re-cast, and then the whole plan regenerated.
The end product of the information systems project is an information systems plan (ISP).
Once deployed, the information systems department can implement the plan with confidence that
they are doing the correct information systems project at the right time and in the right sequence.
The focus of the ISP is not one information system but the entire suite of information systems for
the enterprise. Once developed, each identified information system is seen in context with all other information systems within the enterprise.
The following steps are involved in ISP development (Whitemarsh):
1.Create the mission model
2.Develop a high-level data model
3.Create the resource life cycles (RLC) and their nodes
4.Allocate precedence vectors among RLC nodes
5.Allocate existing information systems and databases to the RLC nodes
6.Allocate standard work break down structures (WBS) to each RLC node
7.Load resources into each WBS node
8.Schedule the RLC nodes through a project management package.
9.Produce and review of the ISP
10.Execute and adjust the ISP through time.
CREATE MISSION MODEL. Missions and mission descriptions are represented through hierarchically composed text. They are natural and are devoid of the effects from organizational structure stylistic effects. Missions from enterprises from the same “line of business” are very similar. In contrast, their
function models may be quite different because of effects imposed by management styles and
organizational structures. Simply stated, mission descriptions are goal and objective oriented and
are best seen as characterizations of the idealized end-results, without any regard for “who and
how.”
For many organizations, the mission description document often represents the first
overall statement of their raison d’etre. The table that follows contains the overall mission
description of the mythical Systems Engineering Corporation, and then the subordinate mission
description for its human resources mission.
It is important to distinguish between missions and functions. At first, missions and
functions look very much alike. However they are not. The following table illustrates their key
differences.
-----------------------------------------------------------------------------------------------------------------
Missions are descriptions of the characteristics of the end result. Missions are noun-based
sentences
Functions are descriptions of how to accomplish an end result. Functions are verb-based
Sentences
-----------------------------------------------------------------------------------------------------------------
Missions are a-political. They are devoid of “who and how.” There should only be ONE
mission description for a mission.
Function hierarchies are commonly tainted by organizations and styles. There can be any
number of equivalent versions of a given function.
-----------------------------------------------------------------------------------------------------------------
Databases and Business Information Systems are based on missions
“Human” activities and organizations are based on business functions
When you “Business Process Re-engineering (BPR)” functions you still have the same
business.
When you “BPR” missions you have a different business.
-----------------------------------------------------------------------------------------------------------------
Mission descriptions are strategic and long range
Functions are tactical to operational, and medium to short range, and are organizationally
Sensitive
-----------------------------------------------------------------------------------------------------------------
BUILD THE HIGH LEVEL DATA. The high level data model is created in two steps: building database domains, and creating database objects.
It is critical to state that the objective of this step is the high-level data model. The goal is
NOT to create a low level or fully attributed data model. The reasons that only a high-level data
model is needed is straight forward:
- No database projects are being accomplished, hence no detailed data modeling is required
- The goal of the ISP is to identify and resource allocate projects including database
projects and for that goal, entity identification, naming and brief definitions is all that is
required for estimating.
The message is simple: any money or resources expended in developing a detailed data model is
wasted.
CREATE DATABASE DOMAINS. Database domains are created from the “bottom” leaves of the mission description texts. There are two cases to consider. First, if the mission description’s bottom leaves are very detailed, they can be considered as having being transformed into database domains. That is they will consist of lists of nouns within simple sentences. The other case is that the mission descriptions have been defined to only a few levels, and the lists of nouns that would result from the development of
database domains have yet to be uncovered.
Whenever a database domain describes complex sets of data, multiple levels of the database domain description may be required. These subdomains are expressed as additional paragraphs. A review of these paragraphs clearly show that the text is “noun-intensive.” The “who and how” is clearly missing. That is the way it should be. If the “who and how” were contained in the database domains then they would not be independent of either process or organization.
A series of diagraming techniques created especially for data and the relationships among data is called entity-relationship (ER) diagraming. Within one style of this technique, the entities are drawn as rectangles and the relationships are drawn as diamonds. The name of the relationship is inside the diamond. Another style of ER modeling is to just have named lines between the entities. In this methodology, since the domain of the diagram is data, it is called the database domain diagram.
The purpose of the database domain diagram is not to be precise and exacting but to be comprehensive. The goal is to have the reviewer say, “that's just the right kind of data needed to satisfy the required mission description.”
When all the database domain diagrams are created, siblings are combined. Entities that are named the same are not presumed to be the same. Analysis must show that to be true. If not, one or both of the entities must have their name and definition changed. As the sets of sibling diagrams are merged from lower to higher levels, the quantity of commonly named entities on different diagrams diminishes. Diagram merger becomes optional when the use analysis of a common entity is subject to update (add, delete, or modify) in one diagram and is only referenced (read) in another diagram.
CREATE RESOURCES AND THE RESOURCE LIFE CYCLES (RCL). Missions are the idealized characterizations of end results of the visionary state of the operating enterprise. Database objects, founded squarely on missions are the highlevel declarations of the data required to reflect the achievement of the mission’s vision. Resources and their life cycles are the names, descriptions, and life cycles of the critical assets of the enterprise, which when exercised achieve one or more aspects of the missions. Each life cycle is composed of RLC nodes.
A mission might be human resource management, where in, the best and most cost effective staff is determined, acquired and managed. A database object squarely based on human resources would be employee. Within the database object, employee, are all the data structures, procedures, integrity constraints, table and database object procedures necessary to “move” the employee database object through its many policy-determined states. A resource might also be named employee, and would set out for the employee resource the life cycle stages that reflect the employee resource’s “journey” through the enterprise. While an enterprise may have 50 to 150 database objects, there are seldom more than 20 resources.
Enterprises build databases and business information systems around the achievement of the life cycle states of its resources. Business information systems execute in support of a particular life cycle stage of a resource (e.g., employee promotion). These information systems cause the databases to change value-state of contained database objects to correctly reflect the resource’s changed state. The state of one or more database objects in the database is the proof that the resource’s state has been achieved. Resources become the lattice work against which database and business information systems are allocated.
ALLOCATE INFORMATION SYSTEMS AND DATABASES TO THE RLC NODES. Once the resource life cycle network has been created, it is stored into the metabase. Once there, its lattice can be employed to attach the databases and business information systems. Databases and their business information systems exist within a data architecture framework.
Most resource life cycle nodes contain at least one original data capture database application. The data from these ODC databases should be pushed to their respective TDSA databases. Once there, various subject area databases pull the data to build the longitudinal and broad subject area databases. It is likely that there is one subject area database for one or more resources. Data from the subject area databases, also called operational data stores by Bill Inmon, is again pulled to create one or more data warehouse databases. Most databases employ one or more reference data tables as standard semantics for selection, control-breaks and printing.
ALLOCATE STANDARD WORK BREAK DOWN (WBD) STRUCTURES TO EACH INFORMATION SYSTEMS AND DATABASE PROJECTS. The key reason for having a well engineered check list for identifying the types of work involved in either a database or business information system project is the ability to then used canned work breakdown structures (WBS). When these WBSs are coupled with experience-honed metrics that are embedded in a project management system that “self-learns” from on-going projects,
accurate, reliable and repeatable project plans result.
The figure below presents a very high level view of how project management and the projects associated with RLC nodes are interrelated. In actuality, there are many more tables within the Whitemarsh project management software. But, from this perspective, when the assessment checklist is compiled, the specific WBSs that are applicable are selected from the project template table.
The five distinct classes of projects are:
! Administration and management
! Specification
! Implementation
! Operation and maintenance
! Multiple category
LOAD RESOURCES INTO EACH PROJECT. Once the WBS is selected, the WBS list and associated deliverables and metrics are automatically brought into the project. When the quantities for each deliverable type is computed, then the overall gross hours estimate for the project is created.
The gross hours estimate is then finalized (either upwards or downwards) by the selection of work environment factors (e.g., nobody even knows who the users are (that’s a bad work environment factor)), and also by the specific persons assigned who have varying levels of capabilities in certain experience levels (e.g., someone is assigned to create the data model who doesn’t yet even know the meaning of the term, “ER diagram”). That’s a bad staffing factor.
The value in having highly engineered work environment and staffing experience factors that adjust the gross hours is that project managers can then relay back to management the exact reasons why a project will cost more or less than another project of even the same construct and size.
The resources are then exported to a text file that is able to loaded into a project management system such as Microsoft Project. This is necessary because the purpose of the Whitemarsh project management system is to support the planning of projects on an enterprise wide basis rather than the scheduling of individual projects.
SCHEDULE THROUGH A PROJECT MANAGEMENT PACKAGE. Project management systems like Microsoft Project, Welcom’s Open Plan Professional, or Primavera’s P3e all require PERT (activity network charts) to effectively schedule an entire RLC network of RLC node assigned projects. When WBSs are brought into a project management system, they are treated as selfcontained subprojects within the overall set of RLC node network of projects. The resource life cycles are depicted from their first to last node in a topdown fashion. The precedence vectors are shows from one node of a RLC to another node of a adifferent RLC. Multiple precedence vectors do not exist between resource life cycles.
PRODUCE AND REVIEW THE ISP. When the resource loaded network of projects is scheduled through a project management system, normal results are produced. That is, the enterprise is faced with the requirement for:
! Infinite resources
! Infinite time
! Infinite computer capacity and speed, and
! Zero time allocated by “management” to accomplish all the work.
The ISP produced by this technique is thus no more able to be accomplished on the first pass
than is any other information systems plan. Now, where the Whitemarsh starts to become very
different from other ISPs is that the Whitemarsh ISP is fundamentally data within a database. Because the Whitemarsh ISP is “data,” it can be reported, queried, updated, recalculated, and reprinted any number of times with only reasonable effort.
A second key distinction is that the data that supports the ISP is primarily contributed by and thus supported by management. After all, it is their missions, their database domains, their database objects, their resources, their resource life cycles, and their precedence vectors between the resource life cycles. The only parts that are truly owned by information technology are the proposals for IT projects that transform an “as-is” database or information system to a “to-be” database or information system.
EXECUTE AND ADJUST ISP THROUGH TIME. Enterprises, once they evolve beyond their first round of information systems, find themselves transformed from a project and package mentality to a release mentality. The diagram on the next page illustrates this new continuous flow environment. It is characterized by:
! Multiple, concurrent, but differently scheduled projects against the same subject area
database or warehouse database
! Single-database projects that affect multiple subject area and data warehouse databases
! Projects that develop completely new capabilities, that can assess required changes to
existing capabilities, and that can accommodate a variety of systems generation
alternatives (COTS, package, and custom programming)
The continuous flow environment contains four major sets of activities. The user/client is represented at the top in the small rectangular box. Each of the ellipses represents an activity list to accomplish a specific need. The four basic needs are essentially:
! Need Identification
! Need Assessment
! Design
! Deployment
REFERENCE:
informationsystemsplanning.pdf
SAD (Systems Analysis & Design 1) AssignONE
Based on my learning on the previous chapter (chapter one), I should be able to identify and discuss some characteristics I may have as a system analyst. As I can recall, a System Analyst is responsible for researching, planning, coordinating and recommending software and system choices to meet an organization's business requirements. A System Analyst plays a vital role in the systems development process. As according to the reporter, a successful System Analyst must require these skills namely, ANALYTICAL skill, TECHNICAL skill, MANAGERIAL skill, and INTERPERSONAL skills.
The information systems analyst is also responsible for debugging applications and providing technical support and training to users. The information systems analyst will prepare technical documentation and procedural instructions for implementing systems software. Working relationships are established with state courts personnel. Work is performed under the general supervision of the Information Systems Analyst Manager.
As I have mentioned above the different skills that a successful System Analyst must acquire, as I make this assignment, I am able to evaluate myself if I have those skills. But then this one thing I am sure about, I may not have those skills NOW, but I know eventually, I can acquire those. For the meantime, I will explain further what those characteristics based on the reporters’ report previously.
To enable System Analyst to understand the organization and its functions, He or She must have an Analytical Skill, which helps him or her to identify opportunities and to analyze and solve problems. Technical skills help systems analysts understand the potential and the limitations of information technology. The systems analyst must be able to work with various programming languages, operating systems, and computer hardware platforms. Management skills help systems analysts manage projects, resources, risk, and change. Interpersonal skills help systems analysts work with end users as well as with analysts, programmers, and other systems professionals.
Because they must write user requests into technical specifications, the systems analysts are the liaisons between vendors and the IT professionals of the organization they represent[1] They may be responsible for developing cost analysis, design considerations, and implementation time-lines. They may also be responsible for feasibility studies of a computer system before making recommendations to senior management as according to Wikipedia.
Being a System Analyst is not just learning how to become one, or dealing with the business tycoons at the same time cooperating with the techie guys, but rather it comes from within. Its not just what you can gain in school but rather on how would you love being a System Analyst. Based on my readings, when it comes to AREAS of PERSONAL INTEREST, being a Mental – Problem Solver comes first, Following Instructions as second and third on rank is Hands-On physical Works which comprises only ¼ of the votes.
It is also important as a System Analyst, your WORK VALUES, you must have Pleasant Working Conditions, Achievement of work, Recognition, though you are working as a group one must also learn the value of his Independence, and most importantly, the Organizational support. A System Analyst also have this WORK STYLE CHARACTERISTICS as follows:
Attention to Detail
Analytical Thinking
Dependability
Integrity
Adaptability / flexibility
Innovation
Cooperation
Initiative
Stress tolerance
Persistence
Independence
Self-Control
Achievement / effort
Concern for Others
Social Orientation
Leadership
As a System Analyst, you must also possess IMPORTANT NATURAL ABILITIES, which we know that just comes from within. The ability that cannot be taught at school but rather acquire through experience and lessons in life. These important natural abilities are as follows (based on my readings):
Oral Comprehension
Using Rules To Organize Things Into Patterns
Anticipating Problems
Written Comprehension
Speech Clarity
Applying Rules Flexibly
Fluency Of Ideas
Near Vision
Deductive Reasoning
Oral Expression
Inductive Reasoning
Written Expression
Speech Recognition
Doing Math Quickly
Mathematical Reasoning
Recognizing Patterns In Complex Situations
Ability To Concentrate
Originality
Finger Dexterity
Recognizing Patterns Quickly
Perceptual Speed
Visualization
As I browsed the net early ago, I found this topic interesting. What are characteristics of a high-performance system analysis and design team? The characteristics of a high-performance team are the following:
1. shared vision or goal
2. sense of team identity
3. result-driven structure
4. competent team members
5. commitment to the team
6. mutual trust
7. interdependence among team members
8. effective communication
9. sense of autonomy
10. small team size
11. high level of enjoyment
Based on the different characteristics I mentioned above, I have a little characteristic but as I see the most important one of being a System Analyst and it is the COMMITMENT TO THE TEAM, I can say this because on the previous semesters even now, I or even we (including the classmates) engage in several group activities. I can say that having you committed to the team is very essential. Even on your down times especially when your group mates seems so wrong, everything seem isn’t right, you tend to lose everything. But if you have the sense of commitment, it seem like you have a pledge, an obligation that must be done not just to the work or the project but to the team members itself. And surely I know, I have this characteristic of a System Analyst, being committed to the group. It’s all I can think of as of now.
The information systems analyst is also responsible for debugging applications and providing technical support and training to users. The information systems analyst will prepare technical documentation and procedural instructions for implementing systems software. Working relationships are established with state courts personnel. Work is performed under the general supervision of the Information Systems Analyst Manager.
As I have mentioned above the different skills that a successful System Analyst must acquire, as I make this assignment, I am able to evaluate myself if I have those skills. But then this one thing I am sure about, I may not have those skills NOW, but I know eventually, I can acquire those. For the meantime, I will explain further what those characteristics based on the reporters’ report previously.
To enable System Analyst to understand the organization and its functions, He or She must have an Analytical Skill, which helps him or her to identify opportunities and to analyze and solve problems. Technical skills help systems analysts understand the potential and the limitations of information technology. The systems analyst must be able to work with various programming languages, operating systems, and computer hardware platforms. Management skills help systems analysts manage projects, resources, risk, and change. Interpersonal skills help systems analysts work with end users as well as with analysts, programmers, and other systems professionals.
Because they must write user requests into technical specifications, the systems analysts are the liaisons between vendors and the IT professionals of the organization they represent[1] They may be responsible for developing cost analysis, design considerations, and implementation time-lines. They may also be responsible for feasibility studies of a computer system before making recommendations to senior management as according to Wikipedia.
Being a System Analyst is not just learning how to become one, or dealing with the business tycoons at the same time cooperating with the techie guys, but rather it comes from within. Its not just what you can gain in school but rather on how would you love being a System Analyst. Based on my readings, when it comes to AREAS of PERSONAL INTEREST, being a Mental – Problem Solver comes first, Following Instructions as second and third on rank is Hands-On physical Works which comprises only ¼ of the votes.
It is also important as a System Analyst, your WORK VALUES, you must have Pleasant Working Conditions, Achievement of work, Recognition, though you are working as a group one must also learn the value of his Independence, and most importantly, the Organizational support. A System Analyst also have this WORK STYLE CHARACTERISTICS as follows:
Attention to Detail
Analytical Thinking
Dependability
Integrity
Adaptability / flexibility
Innovation
Cooperation
Initiative
Stress tolerance
Persistence
Independence
Self-Control
Achievement / effort
Concern for Others
Social Orientation
Leadership
As a System Analyst, you must also possess IMPORTANT NATURAL ABILITIES, which we know that just comes from within. The ability that cannot be taught at school but rather acquire through experience and lessons in life. These important natural abilities are as follows (based on my readings):
Oral Comprehension
Using Rules To Organize Things Into Patterns
Anticipating Problems
Written Comprehension
Speech Clarity
Applying Rules Flexibly
Fluency Of Ideas
Near Vision
Deductive Reasoning
Oral Expression
Inductive Reasoning
Written Expression
Speech Recognition
Doing Math Quickly
Mathematical Reasoning
Recognizing Patterns In Complex Situations
Ability To Concentrate
Originality
Finger Dexterity
Recognizing Patterns Quickly
Perceptual Speed
Visualization
As I browsed the net early ago, I found this topic interesting. What are characteristics of a high-performance system analysis and design team? The characteristics of a high-performance team are the following:
1. shared vision or goal
2. sense of team identity
3. result-driven structure
4. competent team members
5. commitment to the team
6. mutual trust
7. interdependence among team members
8. effective communication
9. sense of autonomy
10. small team size
11. high level of enjoyment
Based on the different characteristics I mentioned above, I have a little characteristic but as I see the most important one of being a System Analyst and it is the COMMITMENT TO THE TEAM, I can say this because on the previous semesters even now, I or even we (including the classmates) engage in several group activities. I can say that having you committed to the team is very essential. Even on your down times especially when your group mates seems so wrong, everything seem isn’t right, you tend to lose everything. But if you have the sense of commitment, it seem like you have a pledge, an obligation that must be done not just to the work or the project but to the team members itself. And surely I know, I have this characteristic of a System Analyst, being committed to the group. It’s all I can think of as of now.
Tuesday, December 1, 2009
MIS2 - assign 2 =)
What should be the nature of the relationship between the business plan and the IS (information system) plan?
To be real honest, without the aid of our technology, I won't be able to know what a Business Plan and an IS plan is. Thanks to the Internet. But then in order to find the relationship of the two, knowing what PLAN (PLANNING) means would give a little help.
As Time-Management.com said, planning is one of the most important project management and time management techniques. Planning is preparing a sequence of action steps to achieve some specific goal. If you do it effectively, you can reduce much the necessary time and effort of achieving the goal.
A plan is like a map. When following a plan, you can always see how much you have progressed towards your project goal and how far you are from your destination. Knowing where you are is essential for making good decisions on where to go or what to do next.
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.
Now that I am able to give what planning is and its importance. I think what Business Plan is would be the next.
A Business Plan is a formal statement of a set of business goals, the reasons why they are believed attainable, and the plan for reaching those goals. It may also contain background information about the organization or team attempting to reach those goals.
The business goals may be defined for for-profit or for non-profit organizations. For-profit business plans typically focus on financial goals, such as profit or creation of wealth. Non-profit and government agency business plans tend to focus on organizational mission which is the basis for their governmental status or their non-profit, tax-exempt status, respectively—although non-profits may also focus on optimizing revenue. In non-profit organizations, creative tensions may develop in the effort to balance mission with "margin" (or revenue). Business plans may also target changes in perception and branding by the customer, client, tax-payer, or larger community. A business plan having changes in perception and branding as its primary goals is called a MARKETING PLAN.
Business plans may be internally or externally focused. Externally focused plans target goals that are important to external stakeholders, particularly financial stakeholders. They typically have detailed information about the organization or team attempting to reach the goals. With for-profit entities, external stakeholders include investors and customers. External stake-holders of non-profits include donors and the clients of the non-profit's services. For government agencies, external stakeholders include tax-payers, higher-level government agencies, and international lending bodies such as the IMF, the World Bank, various economic agencies of the UN, and development banks.
Business plans are decision-making tools. There is no fixed content for a business plan. Rather the content and format of the business plan is determined by the goals and audience. A business plan should contain whatever information is needed to decide whether or not to pursue a goal.
For example, a business plan for a non-profit might discuss the fit between the business plan and the organization’s mission. Banks are quite concerned about defaults, so a business plan for a bank loan will build a convincing case for the organization’s ability to repay the loan. Venture capitalists are primarily concerned about initial investment, feasibility, and exit valuation. A business plan for a project requiring equity financing will need to explain why current resources, upcoming growth opportunities, and sustainable competitive advantage will lead to a high exit valuation.
Preparing a business plan draws on a wide range of knowledge from many different business disciplines: finance, human resource management, intellectual property management, supply chain management, operations management, and marketing, among others. It can be helpful to view the business plan as a collection of sub-plans, one for each of the main business disciplines.
Meanwhile, Information Systems Planning, or 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.” - Somendra Pant and Cheng Hsu.
From the definitions declared above, since that Information System Planning is a process for developing a strategy and plans for aligning information systems with the business strategies of an organization, and that business plan is formal statement of a set of business goals, the reasons why they are believed attainable, and the plan for reaching those goals. Both are essential to the development of an organization. It can make or break an organization. And as during our lectures, with proper business planning in lined with proper strategic IS plan, an organization may bloom. And as to what the both are naturally related with, well, both deals with proper Time Management and Planning for the betterment of an organization. Well, I hope I said it well and right.
References:
http://en.wikipedia.org/wiki/Business_plan
http://wiki.answers.com/Q/What_is_information_system_plan
http://viu.eng.rpi.edu/publications/strpaper.pdf
http://en.wikipedia.org/wiki/Planning
http://www.time-management-guide.com/planning.html
To be real honest, without the aid of our technology, I won't be able to know what a Business Plan and an IS plan is. Thanks to the Internet. But then in order to find the relationship of the two, knowing what PLAN (PLANNING) means would give a little help.
As Time-Management.com said, planning is one of the most important project management and time management techniques. Planning is preparing a sequence of action steps to achieve some specific goal. If you do it effectively, you can reduce much the necessary time and effort of achieving the goal.
A plan is like a map. When following a plan, you can always see how much you have progressed towards your project goal and how far you are from your destination. Knowing where you are is essential for making good decisions on where to go or what to do next.
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.
Now that I am able to give what planning is and its importance. I think what Business Plan is would be the next.
A Business Plan is a formal statement of a set of business goals, the reasons why they are believed attainable, and the plan for reaching those goals. It may also contain background information about the organization or team attempting to reach those goals.
The business goals may be defined for for-profit or for non-profit organizations. For-profit business plans typically focus on financial goals, such as profit or creation of wealth. Non-profit and government agency business plans tend to focus on organizational mission which is the basis for their governmental status or their non-profit, tax-exempt status, respectively—although non-profits may also focus on optimizing revenue. In non-profit organizations, creative tensions may develop in the effort to balance mission with "margin" (or revenue). Business plans may also target changes in perception and branding by the customer, client, tax-payer, or larger community. A business plan having changes in perception and branding as its primary goals is called a MARKETING PLAN.
Business plans may be internally or externally focused. Externally focused plans target goals that are important to external stakeholders, particularly financial stakeholders. They typically have detailed information about the organization or team attempting to reach the goals. With for-profit entities, external stakeholders include investors and customers. External stake-holders of non-profits include donors and the clients of the non-profit's services. For government agencies, external stakeholders include tax-payers, higher-level government agencies, and international lending bodies such as the IMF, the World Bank, various economic agencies of the UN, and development banks.
Business plans are decision-making tools. There is no fixed content for a business plan. Rather the content and format of the business plan is determined by the goals and audience. A business plan should contain whatever information is needed to decide whether or not to pursue a goal.
For example, a business plan for a non-profit might discuss the fit between the business plan and the organization’s mission. Banks are quite concerned about defaults, so a business plan for a bank loan will build a convincing case for the organization’s ability to repay the loan. Venture capitalists are primarily concerned about initial investment, feasibility, and exit valuation. A business plan for a project requiring equity financing will need to explain why current resources, upcoming growth opportunities, and sustainable competitive advantage will lead to a high exit valuation.
Preparing a business plan draws on a wide range of knowledge from many different business disciplines: finance, human resource management, intellectual property management, supply chain management, operations management, and marketing, among others. It can be helpful to view the business plan as a collection of sub-plans, one for each of the main business disciplines.
Meanwhile, Information Systems Planning, or 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.” - Somendra Pant and Cheng Hsu.
From the definitions declared above, since that Information System Planning is a process for developing a strategy and plans for aligning information systems with the business strategies of an organization, and that business plan is formal statement of a set of business goals, the reasons why they are believed attainable, and the plan for reaching those goals. Both are essential to the development of an organization. It can make or break an organization. And as during our lectures, with proper business planning in lined with proper strategic IS plan, an organization may bloom. And as to what the both are naturally related with, well, both deals with proper Time Management and Planning for the betterment of an organization. Well, I hope I said it well and right.
References:
http://en.wikipedia.org/wiki/Business_plan
http://wiki.answers.com/Q/What_is_information_system_plan
http://viu.eng.rpi.edu/publications/strpaper.pdf
http://en.wikipedia.org/wiki/Planning
http://www.time-management-guide.com/planning.html
Subscribe to:
Posts (Atom)
