Considering the needs of limited resources of the university there should be assessment regarding the needs of the university.

Goals and purpose of Life Cycle Assessment

The goal of LCA is to compare the full range of environmental and social damages assignable to products and services, to be able to choose the least burdensome one. At present it is a way to account for the effects of the cascade of technologies responsible for goods and services. It is limited to that, though, because the similar cascade of impacts from the commerce responsible for goods and services is unaccountable because what people do with money is unrecorded. As a consequence LCA succeeds in accurately measuring the impacts of the technology used for delivering products, but not the whole impact of making the economic choice of using it.

The term 'life cycle' refers to the notion that a fair, holistic assessment requires the assessment of raw material production, manufacture, distribution, use and disposal including all intervening transportation steps necessary or caused by the product's existence. The sum of all those steps - or phases - is the life cycle of the product. The concept also can be used to optimize the environmental performance of a single product (ecodesign) or to optimize the environmental performance of a company.

Four Main Phases

According to the ISO 14040 and 14044 standards, a Life Cycle Assessment is carried out in four distinct phases.

Goal and scope

In the first phase, the LCA-practitioner formulates and specifies the goal and scope of study in relation to the intended application. The object of study is described in terms of a so-called functional unit. Apart from describing the functional unit, the goal and scope should address the overall approach used to establish the system boundaries. The system boundary determines which unit processes are included in the LCA and must reflect the goal of the study. In recent years, two additional approaches to system delimitation have emerged. These are often referred to as ‘consequential’ modeling and ‘attributional’ modeling. Finally the goal and scope phase includes a description of the method applied for assessing potential environmental impacts and which impact categories that are included.

Life cycle inventory[/b]

This second phase 'Inventory' involves data collection and modeling of the product system, as well as description and verification of data. This encompasses all data related to environmental (e.g., CO2) and technical (e.g., intermediate chemicals) quantities for all relevant unit processes within the study boundaries that compose the product system. Examples of inputs and outputs quantities include inputs of materials, energy, chemicals and 'other' - and outputs of air emissions, water emissions or solid waste. Other types of exchanges or interventions such as radiation or land use can also be included.

Usually Life Cycle Assessments inventories and modeling are carried out using dedicated software packages. Depending on the software package used it is possible to model life cycle costing and life cycle social impacts in parallel with environmental life cycle.

The data must be related to the functional unit defined in the goal and scope definition. Data can be presented in tables and some interpretations can be made already at this stage. The results of the inventory is an LCI which provides information about all inputs and outputs in the form of elementary flow to and from the environment from all the unit processes involved in the study.

Life cycle impact assessment

The third phase 'Life Cycle Impact Assessment' is aimed at evaluating the contribution to impact categories such as global warming, acidification, etc. The first step is termed characterization. Here, impact potentials are calculated based on the LCI results. The next steps are normalization and weighting, but these are both voluntary according the ISO standard. Normalization provides a basis for comparing different types of environmental impact categories (all impacts get the same unit). Weighting implies assigning a weighting factor to each impact category depending on the relative importance. The weighting step is not always necessary to create a so called “single indicator”. See for instance the prevention based model of the Eco-costs.

Importance of Data

A life cycle analysis is only as valid as its data; therefore, it is crucial that data used for the completion of a life cycle analysis is accurate and current. When comparing different life cycle analysis with one another, it is crucial that equivalent data is available for both products or processes in question. If one product has a much higher availability of data, it cannot be justly compared to another product which has less detailed data.

The validity of data should always be a concern with life cycle analyses. Since we are living in a global world and economy, new processes, manufacturing methods, and materials are introduced to various processes and products. Therefore, it is important to have current data when performing a LCA. If data from 5 to 10 years in the past is used, the LCA will not be accurate, because the quantitative analysis will not reflect the current methods utilized in the process or product. Therefore, drawing conclusions from a report using such data will be ineffective, since the data is unavailable. Some products, whose processes have not changed in 5 to 10 years (if there are any) will be exempt from this. When analyzing electronics, such as cell phones or computers, for example, the most current data is necessary. Since new computer and cell phone models are created every few months, the results of a life cycle analysis of a 3-year-old computer system will often not be applicable to current systems.

Variants

Cradle-to-grave

Cradle-to-grave is the full Life Cycle Assessment from manufacture ('cradle') to use phase and disposal phase ('grave'). For example, trees produce paper, which can be recycled into low-energy production cellulose (fiberised paper) insulation, then used as an energy-saving device in the ceiling of a home for 40 years, saving 2,000 times the fossil-fuel energy used in its production. After 40 years the cellulose fibers are replaced and the old fibers are disposed of, possibly incinerated. All inputs and outputs are considered for all the phases of the life cycle.

Cradle-to-gate

Cradle-to-gate is an assessment of a partial product life cycle from manufacture ('cradle') to the factory gate (i.e., before it is transported to the consumer). The use phase and disposal phase of the product are usually omitted. Cradle-to-gate assessments are sometimes the basis for environmental product declarations (EPD).

Cradle to cradle

Cradle-to-cradle is a specific kind of cradle-to-grave assessment, where the end-of-life disposal step for the product is a recycling process. From the recycling process originate new, identical products (e.g., glass bottles from collected glass bottles), or different products (e.g., glass wool insulation from collected glass bottles).

Gate-to-gate

Gate-to-Gate is a partial LCA looking at only one value-added process in the entire production chain.

Well-to-wheel

Well-to-wheel is the specific LCA of the efficiency of fuels used for road transportation. The analysis is often broken down into stages such as "well-to-station" and "station-to-wheel, or "well-to-tank" and "tank-to-wheel".

The factor "Tp = Petroleum refining and distribution efficiency = 0.830" from the DOE regulation accounts for the "well-to-station" portion of the gasoline fuel cycle in the USA. To convert a standard Monroney sticker value to a full cycle energy equivalent, convert with Tp. For example, the Toyota Corolla is rated at 28 mpg station-to-wheel. To get the full cycle value, multiply mpg by Tp=0.83 to account for the refining and transportation energy use - 23.2 mpg full cycle. The same adjustment applies to all vehicles fueled completely with gasoline, therefore, Monroney sticker numbers can be compared to each other with or without the adjustment. A recent study examined well-to-wheels energy and emission effects of various vehicle and fuel systems.
Economic Input-Output Life Cycle Assessment

EIOLCA, or Economic Input-Output LCA involves use of aggregate sector-level data on how much environmental impact can be attributed to each sector of the economy and how much each sector purchases from other sectors. Such analysis can account for long chains (for example, building an automobile requires energy, but producing energy requires vehicles, and building those vehicles requires energy, etc.), which somewhat alleviates the scoping problem of process LCA; however, EIO-LCA relies on sector-level averages that may or may not be representative of the specific subset of the sector relevant to a particular product and therefore is not suitable for evaluating the environmental impacts of products. Additionally the translation of economic quantities into environmental impacts is not validated.

Life cycle energy analysis

Life cycle energy analysis (LCEA) is an approach in which all energy inputs to a product are accounted for, not only direct energy inputs during manufacture, but also all energy inputs needed to produce components, materials and services needed for the manufacturing process. An earlier term for the approach was energy analysis.
With LCEA, the total life cycle energy input is established.

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

Today’s business environment produces change in the workplace more suddenly and frequently than ever before. Mergers, acquisitions, new technology, restructuring and downsizing are all factors that contribute to a growing climate of uncertainty. Jobs, health, even marriages can be placed at risk, jeopardizing productivity and profitability.

People have deep attachments to their organization, work group, and way of working. The ability to adapt to changing work conditions is key for individual and organizational survival. Change will be ever present and learning to manage and lead change includes not only understanding human factors but also skill to manage and lead change effectively.

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.

The Reaction to Change

During the change process, there are common predictable stressors, but how we react to those stressors will differ for each person since we are all unique individuals. The anxiety and confusion that result from not knowing what lies ahead can create stress. People will utilize basic defences when there is a high degree of uncertainty. In this sate of ambiguity, people can easily resort to distrust, withdrawal and self-protection. People are told that the old ways are no longer working and often this message becomes personalized that they are not valued.

For the employee, the emotional reactions while going through an organizational change can be similar to the stages of grief associated with personal loss. The employee may initially feel shock or denial when the organizational change is announced. Reactions such as “they can’t do this,” this can’t be happening” are common. At this stage, most employees will want to know exactly how this change will affect them, their benefits, their work hours, their family and will not “hear” much other information. At the next stage the employee may feel anger, resentment or sadness in response to the changes. “This isn’t fair,” “why are they doing this to me?” are normal reactions and productivity on the job is usually lower as employees discuss and process the changes among themselves. Tearfulness is common.

The employee experiencing organizational change at a personal level often feels threatened and is fearful. Managers recognizing this can better intervene with employees by acknowledging feelings, letting the employee vent and ask questions, and by being supportive that change is difficult. The Manager who moves straight into why the change is best for everyone and how business is going to be conducted disregards the human nature element - the emotions that are normal and natural for anyone feeling threatened by change to feel. At every step in the process of implementing an organizational change, a good Manager will ask him/herself “How might I react to this information or these changes if I were in the employee’s shoes?” and try to tailor responses accordingly.

As the organization implements the changes though, the reality of the change becomes present and employees may either resist the changes or start to adjust to the changes depending on the person. The employee who continues to resist, remains angry and is labeled as “difficult” is feeling more threatened and may need some one-to-one time with the Manager to discuss the changes or at some point, may need clarification from the Manager about performance expectations in light of the changes.

Effects Seen at the Workplace

Absenteeism: As individuals see jobs eliminated and friends leaving, they may work longer hours. They feel more concern about their own security and future and put less effort into maintaining balance in their lives. Complaints of burnout increase. Health may deteriorate, and stress related symptoms increase. More workdays are missed for illness.

Reduction In Productivity: Less works gets done even by employees who come to work. In an atmosphere of ambiguity and uncertainty, individuals may withdraw support from one another and become self-protective. Superiors may provide less information and that which is provided may be more inconsistent. Working relationships can deteriorate as competition increases and turf battles are intensified in order to justify and protect departments and jobs.
Loss of Valued Employees: Confident, skilled, and experienced employees in the midst of ambiguity and uncertainty may be looking for or are invited to consider other career opportunities.

Another stress may result from the feeling of being insufficiently skilled as changes are implemented and new ways of conducting business begin. New practices and skills must be intentionally learned and practiced. Consider what you have to offer and what you need to learn.
There is no right or wrong way to react to change. But, there are things you can do to help yourself adjust to change and get involved in positive ways.

Dealing with Organizational Change

Individuals can reduce the impact of change and resulting stress by focusing on the value to be gained. The following are some ways to help approach change with a positive attitude:

• Keep an open mind. Do not assume that the results of change will be negative. Change may be the best thing that ever happened to you.

• Stay flexible. Be ready to let go of the old and try the new. Talking with colleagues can help allay stress and foster a supportive environment.

• Be supportive of colleagues. It is important that people recognize each other’s contributions on a regular basis and show appreciation for one another.

• Take an active role in the change process. Learn new skills, offer suggestions, set goals for yourself.

• Give change a chance to work. Be patient; change takes time.

• Ignore rumors. Instead, focus on gathering as many facts as you can about change. Talk with your supervisor when you have questions.

• Pay attention to yourself. It is important to learn to manage stress. People who feel good mentally and physically are better able to handle change. Eat a nutritious diet, get enough sleep, exercise, limit alcohol use and utilize relaxation/stress management techniques (e.g., deep breathing, progressive muscle relaxation), so your body and mind are able to deal with change.

Automation

Automation is the use of control systems (such as numerical control, programmable logic control, and other industrial control systems), in concert with other applications of information technology (such as computer-aided technologies [CAD, CAM, CAx]), to control industrial machinery and processes, reducing the need for human intervention.In the scope of industrialization, automation is a step beyond mechanization. Whereas mechanization provided human operators with machinery to assist them with the muscular requirements of work, automation greatly reduces the need for human sensory and mental requirements as well. Processes and systems can also be automated.

Automation plays an increasingly important role in the global economy and in daily experience. Engineers strive to combine automated devices with mathematical and organizational tools to create complex systems for a rapidly expanding range of applications and human activities.

Many roles for humans in industrial processes presently lie beyond the scope of automation. Human-level pattern recognition, language recognition, and language production ability are well beyond the capabilities of modern mechanical and computer systems. Tasks requiring subjective assessment or synthesis of complex sensory data, such as scents and sounds, as well as high-level tasks such as strategic planning, currently require human expertise. In many cases, the use of humans is more cost-effective than mechanical approaches even where automation of industrial tasks is possible.

Specialised hardened computers, referred to as programmable logic controllers (PLCs), are frequently used to synchronize the flow of inputs from (physical) sensors and events with the flow of outputs to actuators and events. This leads to precisely controlled actions that permit a tight control of almost any industrial process.

Human-machine interfaces (HMI) or computer human interfaces (CHI), formerly known as man-machine interfaces, are usually employed to communicate with PLCs and other computers, such as entering and monitoring temperatures or pressures for further automated control or emergency response. Service personnel who monitor and control these interfaces are often referred to as stationary engineers.

Impact

Automation has had a notable impact in a wide range of highly visible industries beyond manufacturing. Once-ubiquitous telephone operators have been replaced largely by automated telephone switchboards and answering machines. Medical processes such as primary screening in electrocardiography or radiography and laboratory analysis of human genes, sera, cells, and tissues are carried out at much greater speed and accuracy by automated systems. Automated teller machines have reduced the need for bank visits to obtain cash and carry out transactions. In general, automation has been responsible for the shift in the world economy from agrarian to industrial in the 19th century and from industrial to services in the 20th century.

At first glance, automation might appear to devalue labor through its replacement with less-expensive machines; however, the overall effect of this on the workforce as a whole remains unclear. Today automation of the workforce is quite advanced, and continues to advance increasingly more rapidly throughout the world and is encroaching on ever more skilled jobs, yet during the same period the general well-being and quality of life of most people in the world (where political factors have not muddied the picture) have improved dramatically. What role automation has played in these changes has not been well studied.

Rationalization of Procedures

It is the streamlining of existing operating procedures, eliminating obvious bottlenecks so that automation makes operating procedures more efficient and the second stage of organizational change where the organization uses information technology to streamline a standard operating procedure. A database that holds information of available rooms is an example of this stage.

Business Reengineering

Business reengineering reorganizes work flows, combining steps to cut waste and eliminating repetitive, paper-intensive tasks (sometimes the new design eliminates jobs as well). It is much more ambitious than rationalization of procedures, requiring a new vision of how the process is to be organized.

BPR combines a strategy of promoting business innovation with a strategy of making major improvements to business processes so that a company can become a much stronger and more successful competitor in the marketplace. Re-engineering is the basis for many recent developments in management. The cross-functional team, for example, has become popular because of the desire to re-engineer separate functional tasks into complete cross-functional processes. Also, many recent management information systems developments aim to integrate a wide number of business functions. Enterprise resource planning, supply chain management, knowledge management systems, groupware and collaborative systems, Human Resource Management Systems and customer relationship management systems all owe a debt to re-engineering theory. Business process reengineering (BPR) began as a private sector technique to help organizations fundamentally rethink how they do their work in order to dramatically improve customer service, cut operational costs, and become world-class competitors.

Paradigm Shift

It is a dramatic change in methodology or practice. It often refers to a major change in thinking and planning, which ultimately changes the way projects are implemented. For example, accessing applications and data from the Web instead of from local servers is a paradigm shift. Seeparadigm and buzzword.

A scientific revolution occurs, according to Kuhn, when scientists encounter anomalies which cannot be explained by the universally accepted paradigm within which scientific progress has thereto been made. The paradigm, in Kuhn's view, is not simply the current theory, but the entire worldview in which it exists, and all of the implications which come with it. There are anomalies for all paradigms, Kuhn maintained, that are brushed away as acceptable levels of error, or simply ignored and not dealt with (a principle argument Kuhn uses to reject Karl Popper's model of falsifiability as the key force involved in scientific change). Rather, according to Kuhn, anomalies have various levels of significance to the practitioners of science at the time. To put it in the context of early 20th century physics, some scientists found the problems with calculating Mercury's perihelion more troubling than the Michelson-Morley experiment results -- and some, the other way around. Kuhn's model of scientific change differs here, and in many places, from that of the logical positivists in that it puts an enhanced emphasis on the individual humans involved as scientists, rather than abstracting science into a purely logical or philosophical venture.

Change is the Present and Future

People tend to blame the organization or top management for the changes occurring within the organization. Top management’s actions are usually reactions to some outside force, such as stiffer competition, shifts in the marketplace or new technology. It is important to realize that change is a key to surviving and growing in today’s global economy.

Change is inevitable and we will be surfing on this wave of transition. Without change we would run the risk of becoming stale and unresponsive. The challenge we face is to learn to move through this wave of transition as easily and creatively as possible.

References:

http://www.healthsystem.virginia.edu/internet/feap/newsletters/managing-org.-change.pdf
http://www.wordiq.com/definition/Paradigm_shift
http://en.wikipedia.org/wiki/Automation
http://managementhelp.org/org_chng/org_chng.htm

A Process Model refers to a description of business flow (order of task group).In many cases, a diagram is drawn "from left to right" or "from top to bottom" on the basis of execution procedure of each task. As a concept, not only Flow Models but also Data Models, etc. are included. An example of element resolution of Process Models is as follows.

• Flow models (definition of diagram)
• Divergence conditions (definition of condition that cannot be written in diagram)
• Allocation models (definition of person in charge of each task)
• Data models (definition of input/output, visibility)

According to this article found in the internet it says that a Process Model is a sequence of activities, objects, transformations, and events that embody strategies for accomplishing a certain task.
The model generally starts with a context diagram showing the system as a single process connected to external entities outside of the system boundary. This process explodes to a lower level DFD that divides the system into smaller parts and balances the flow of information between parent and child diagrams. Many diagram levels may be needed to express a complex system. Primitive processes, those that don't explode to a child diagram, are usually described in a connected textual specification.

What is a software process model?

In contrast to software life cycle models, software process models often represent a networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities. Their power emerges from their utilization of a sufficiently rich notation, syntax, or semantics, often suitable for computational processing.

Software process networks can be viewed as representing multiple interconnected task chains (Kling 1982, Garg 1989). Task chains represent a non-linear sequence of actions that structure and transform available computational objects (resources) into intermediate or finished products. Non-linearity implies that the sequence of actions may be non-deterministic, iterative, accommodate multiple/parallel alternatives, as well as partially ordered to account for incremental progress. Task actions in turn can be viewed a non-linear sequences of primitive actions which denote atomic units of computing work, such as a user's selection of a command or menu entry using a mouse or keyboard. Winograd and others have referred to these units of cooperative work between people and computers as "structured discourses of work" (Winograd 1986), while task chains have become popularized under the name of "workflow" (Bolcer 1998).

Task chains can be employed to characterize either prescriptive or descriptive action sequences. Prescriptive task chains are idealized plans of what actions should be accomplished, and in what order. For example, a task chain for the activity of object-oriented software design might include
the following task actions:

1. Develop an informal narrative specification of the system.
2. Identify the objects and their attributes.
3. Identify the operations on the objects.
4. Identify the interfaces between objects, attributes, or operations.
5. Implement the operations.

Clearly, this sequence of actions could entail multiple iterations and non-procedural primitive action invocations in the course of incrementally progressing toward an object-oriented software design.

Task chains join or split into other task chains resulting in an overall production network or web (Kling 1982). The production web represents the "organizational production system" that transforms raw computational, cognitive, and other organizational resources into assembled, integrated and usable software systems. The production lattice therefore structures how a software system is developed, used, and maintained. However, prescriptive task chains and actions cannot be formally guaranteed to anticipate all possible circumstances or idiosyncratic 5 foul-ups that can emerge in the real world of software development (Bendifallah 1989, Mi 1990).Thus, any software production web will in some way realize only an approximate or incomplete description of software development.

Traditional Process Model

Traditional models of software evolution have been with us since the earliest days of software engineering. The traditional process models of software development are as follows:

•Stepwise Refinement

In this approach, software systems are developed through the progressive refinement and enhancement of high-level system specifications into source code components (Wirth 1971, Mili 1986).

However, the choice and order of which steps to choose and which refinements to apply remain unstated. Instead, formalization is expected to emerge within the heuristics and skills that are acquired and applied through increasingly competent practice.

This model has been most effective and widely applied in helping to teach individual programmers how to organize their software development work. Many interpretations of the classic software life cycle thus subsume this approach within their design and implementations.

In a nutshell, the concept of "stepwise refinement" is to take an object and move it from a general perspective to a precise level of detail. Architects have used such an approach for years, as have engineers building products. But to do so, they realized they cannot simply go from the general to the specific in one felled swoop, but instead, in increments (steps). The number of steps needed to decompose an object into sufficient detail is ultimately based on the inherent nature of the object. To illustrate, for architects designing a building, the typical steps include:

1. Develop artist rendering (to consider viability).
2. Design foundation and superstructure.
3. Design Floor plans.
4. Design electrical and plumbing diagrams.

In other words, before the first shovel of dirt is dug on the project, the architect knows precisely what the building will look like and how it will work. All of the guess work has been eliminated.

•Incremental Development and Release Model

Developing systems through incremental release requires first providing essential operating functions, then providing system users with improved and more capable versions of a system at regular intervals (Basili 1975).

This model combines the classic software life cycle ("waterfall chart”) with iterative enhancement at the level of system development organization. It also supports a strategy to 7 periodically distribute software maintenance updates and services to dispersed user communities. This in turn accommodates the provision of standard software maintenance contracts. It is therefore a popular model of software evolution used by many commercial software firms and system vendors. This approach has also been extended through the use of software prototyping tools and techniques (described later), which more directly provide support for incremental development and iterative release for early and ongoing user feedback and evaluation (Graham 1989).

•Industrial and Military Standards, and Capability Models

Industrial firms often adopt some variation of the classic model as the basis for standardizing their software development practices (Royce 1970, Boehm 1976, Distaso 1980, Humphrey 1985, Scacchi 1984, Somerville 1999).

Military software systems are often constrained in ways not found in industrial or academic practice, including:

(1) Required use of military standard computing equipment (which is often technologically dated and possesses limited processing capabilities);
(2) Embedded in larger systems (e.g., airplanes, submarines, missiles, command and control systems) which are mission-critical (i.e., those whose untimely failure could result in military disadvantage and/or life-threatening risks);
(3) Developed under contract to private firms through cumbersome procurement and acquisition procedures that can be subject to public scrutiny and legislative intervention; and ;
(4) Many embedded software systems for the military are among the largest and most complex systems in the world (Moore1997).

In industrial settings, standard software development models represent often provide explicit detailed guidelines for how to deploy, install, customize or tune a new software system release in its operating application environment. In addition, these standards are intended to be compatible with provision of software quality assurance, configuration management, and independent verification and validation services in a multi-contractor development project. Early efforts in monitoring and measuring software process performance found in industrial practice appear in (Humphrey 1985, Radice 1985, Basili 1988). These efforts in turn help pave the way for what many software development organizations now practice, or have been certified to practice, software process capability assessments, following the Capability Maturity Model developed by the Software Engineering Institute (Paulk 1995) (see Capability Maturity Model for Software).


All these models are independent of any organizational development setting, choice of programming language, software application domain, etc. In short, the traditional models are context-free rather than context-sensitive. But as all of these life cycle models have been in use for some time, we refer to them as the traditional models, and characterize each in turn.

Recent Process Model

Collectively, these process models are finer-grained, often detailed to the point of computational formalization, more often empirically grounded, and in some cases address the role of new automated technologies in facilitating software development. The recent process models of software development are as follows:

•Software Product Development Models

Software products represent the information-intensive artifacts that are incrementally constructed and iteratively revised through a software development effort. Such efforts can be modeled using software product life cycle models. These product development models represent an evolutionary revision to the traditional software life cycle models (MacCormack 2001).

The revisions arose due to the availability of new software development technologies such as software prototyping languages and environments, reusable software, application generators, and documentation support environments. Each of these technologies seeks to enable the creation of executable software implementations either earlier in the software development effort or more rapidly.

Therefore in this regard, the models of software development may be implicit in the use of the technology, rather than explicitly articulated. This is possible because such models become increasingly intuitive to those developers whose favorable experiences with these technologies substantiate their use. Thus, detailed examination of these models is most appropriate when such technologies are available for use or experimentation.

•Rapid Prototyping

Prototyping is a technique for providing a reduced functionality or a limited performance version of a software system early in its development (Balzer 1983, Budde 1984, Hekmatpour 1987).

Software prototypes come in different forms including throwaway prototypes, mock-ups,demonstration systems, quick-and-dirty prototypes, and incremental evolutionary prototypes (Hekmatpour 1987). Increasing functionality and subsequent evolvability is what distinguishes the prototype forms on this list.

Prototyping technologies usually take some form of software functional specifications as their starting point or input, which in turn is simulated, analyzed, or directly executed. These technologies can allow developers to rapidly construct early or primitive versions of software systems that users can evaluate. User evaluations can then be incorporated as feedback to refine the emerging system specifications and designs. Further, depending on the prototyping technology, the complete working system can be developed through a continual revising/refining the input specifications. This has the advantage of always providing a working version of the emerging system, while redefining software design and testing activities to input specification refinement and execution. Alternatively, other prototyping approaches are best suited for developing throwaway or demonstration systems, or for building prototypes by reusing part/all of some existing software systems. Subsequently, it becomes clear why modern models of software development like the Spiral Model (described later) and the ISO 12207 expect that prototyping will be a common activity that facilitates the capture and refinement of software requirements, as well an overall software development.

• Joint Application Development (JAD)

JAD is a technique for engaging a group or team of software developers, testers, customers, and prospective end-users in a collaborative requirements elicitation and prototyping effort (Wood and Silver 1995).

It is quintessentially a technique for facilitating group interaction and collaboration. Consultants often employ JAD or external software system vendors who have been engaged to build a custom software system for use in a particular organizational setting.

The JAD process is based on four ideas:

1. People who actually work at a job have the best understanding of that job.

2. People who are trained in software development have the best understanding of the possibilities of that technology.

3. Software-based information systems and business processes rarely exist in isolation -- they transcend the confines of any single system or office and effect work in related departments. People working in these related areas have valuable insight on the role of a system within a larger community.

4. The best information systems are designed when all of these groups work together on a project as equal partners.

For large-scale projects, it is recommended that the project be organized as an incremental development effort, and that separate JAD's be used for each increment (Wood and Silver 1995). Given this formulation, it is possible to view open source software development projects that rely on group email discussions among globally distributed users and developers, together with Internet-based synchronized version updates (Fogel 1999, Mockus 2000), as an informal variant of JAD.

References:

Alan Cline, “Joint Application Development (JAD) for Requirements Collection and Management”, www. Carolla.com
http://en.q-bpm.org/mediawiki/index.php/Process_Model#Use_of_Process_Models
http://www.excelsoftware.com/processmodel.html
http://it.toolbox.com/blogs/irm-blog/stepwise-refinement-25007

A system analyst is the person who selects and configures computer systems for an organization or business. His or her job typically begins with determining the intended purpose of the computers. This means the analyst must understand the general objectives of the business, as well as what each individual user's job requires. Once the system analyst has determined the general and specific needs of the business, he can choose appropriate systems that will help accomplish the goals of the business.

When configuring computer systems for a business, the analyst must select both hardware and software. The hardware aspect includes customizing each computer's configuration, such as the processor speed, amount of RAM, hard drive space, video card, and monitor size. It may also involve choosing networking equipment that will link the computers together. The software side includes the operating system and applications that are installed on each system. The software programs each person requires may differ greatly between users, which is why it is important that the system analyst knows the specific needs of each user.

To summarize, the system analyst's job is to choose the most efficient computer solutions for a business, while making sure the systems meet all the company's needs. Therefore, the system analyst must have a solid understanding of computer hardware and software and should keep up-to-date on all the latest technologies. He must also be willing to listen to the constant needs and complaints of the users he builds systems for.

Project management is a carefully planned and organized effort to accomplish a specific (and usually) one-time objective, for example, construct a building or implement a major new computer system. Project management includes developing a project plan, which includes defining and confirming the project goals and objectives, identifying tasks and how goals will be achieved, quantifying the resources needed, and determining budgets and timelines for completion. It also includes managing the implementation of the project plan, along with operating regular 'controls' to ensure that there is accurate and objective information on 'performance' relative to the plan, and the mechanisms to implement recovery actions where necessary. Projects usually follow major phases or stages (with various titles for these), including feasibility, definition, project planning, implementation, evaluation and support/maintenance.

The system analyst is the person (or persons) who guides through the development of an information system. In performing these tasks the analyst must always match the information system objectives with the goals of the organization.

Role of System Analyst differs from organization to organization. Most common responsibilities of System Analyst are following

1) System analysis
It includes system's study in order to get facts about business activity. It is about getting information and determining requirements. Here the responsibility includes only requirement determination, not the design of the system.

2) System analysis and design:
Here apart from the analysis work, Analyst is also responsible for the designing of the new system/application.
3) Systems analysis, design, and programming:

Here Analyst is also required to perform as a programmer, where he actually writes the code to implement the design of the proposed application.

Due to the various responsibilities that a system analyst requires to handle, he has to be multifaceted person with varied skills required at various stages of the life cycle. In addition to the technical know-how of the information system development a system analyst should also have the following knowledge.

• Business knowledge: As the analyst might have to develop any kind of a business system, he should be familiar with the general functioning of all kind of businesses.

• Interpersonal skills: Such skills are required at various stages of development process for interacting with the users and extracting the requirements out of them

• Problem solving skills: A system analyst should have enough problem solving skills for defining the alternate solutions to the system and also for the problems occurring at the various stages of the development process.

Activities of a System Analyst

1. Assists current or potential application users in identifying and describing problems or opportunities that might be addressed either:

a) by implementing a new (automated or manual) system, or
b) by changing an existing application system.

2. Investigates such problems and opportunities to determine the feasibility of a system solution and to identify the general kinds of system solution that appear appropriate.

3. Analyzes users’ business requirements in detail and, where appropriate, prepares functional specifications1 for a proposed new (or changed) system.

4. Assists and guides prospective users of a proposed new or changed system in:

a) quantifying the benefits of having the system (or the penalties for not having it), and
b) assessing the impact of the system on their organization and on the operation of their
business.

5. Obtains rough estimates of the cost of operating and maintaining a proposed new or changed system, assuming use of appropriate technology, tools, and methods.

6. Assists the project manager3 in identifying the skills and resources needed to implement a new system or to modify an existing system, and in preparing rough estimates of:

a) the cost of developing or changing the system,
b) the duration of a project to do so.

7. Assists the sponsoring users in:

a)analyzing the costs, benefits, risks, and return-on-investment of the proposed new system,
b) understanding the exact nature of the proposed system,
c) deciding whether to proceed with the implementation.

8. Designs and develops users' manuals4 and corresponding training programs for a system being developed.

9. Prepares, in consultation with users, implementers, and operations representatives, the acceptance (or parallel) test plan for any new or changed system.

10. Assists the users in preparing for the installation and start-up of any new system being implemented.


Reference:
http://www.freetutes.com/systemanalysis/role-of-system-analyst.html
http://www.techterms.com/definition/systemanalyst
http://managementhelp.org/plan_dec/project/project.htm


Planning for information systems, as for any other system, begins with the identification of needs. In order to be effective, development of any type of computer-based system should be a response to need--whether at the transaction processing level or at the more complex information and support systems levels. Such planning for information systems is much like strategic planning in management. Objectives, priorities, and authorization for information systems projects need to be formalized. The systems development plan should identify specific projects slated for the future, priorities for each project and for resources, general procedures, and constraints for each application area. The plan must be specific enough to enable understanding of each application and to know where it stands in the order of development. Also the plan should be flexible so that priorities can be adjusted if necessary. King (King, 1995) in his recent article has argued that a strategic capability architecture - a flexible and continuously improving infrastructure of organizational capabilities – is the primary basis for a company's sustainable competitive advantage. He has emphasized the need for continuously updating and improving the strategic capabilities architecture.

SISP is the analysis of a corporation’s information and processes using business information models together with the evaluation of risk, current needs and requirements. The result is an action plan showing the desired course of events necessary to align information use and needs with the strategic direction of the company (Battaglia, 1991). The same article emphasizes the need to notethat SISP is a management function and not a technical one. This is consistent with the earlier distinction between the older data processing views and the modern strategic importance view of Information Systems. SISP thus is used to identify the best targets for purchasing and installing new management information systems and help an organization maximize the return on its information technology investment. A portfolio of computer-based applications is identified that will assist an organization in executing its business plans and realize its business goals. There is a growing realization that the application of information technology (IT) to a firm’s strategic activities has been one of the most common and effective ways to improve business performance.

Review of information systems planning models

Existing planning models can be broadly classified into impact and alignment models (Vitale et al., 1986). Impact models focus on the potential impact of information technology on organizational tasks and processes and use this as the basis to identify opportunities for deploying information systems. Alignment models, on the other hand, focus on aligning the information system’s plans and priorities with organizational strategy and business goals.
Michael Porter’s value chain analysis is by far the most widely used impact model.

According to Porter, ‘‘every firm is a collection of activities that are performed to design, produce, market, deliver, and support its product’’. These activities can be represented using a value chain. Value chain analysis helps in identifying key value-adding processes that could be made more effective using information technology. As a planning methodology, value chain analysis is too abstract as it does not provide specific guidelines for designing an information architecture, nor does it provide guidelines for systems development and implementation (Porter and Millar, 1985).Moreover, over the past year, there has been a strategic shift from thinking about value chains to value hubs where the ‘‘linear’’ value chain perspective has evolved to a ‘‘hub-centric’’ model, i.e. emarketplaces. This shift in thinking has been largely driven by two factors: the competitive pressures to respond to a direct selling strategy initiated by companies like Dell, and the maturation of the Internet and related technologies. These changes limit the applicability of the original value chain model for information systems planning for e-business.

Popular alignment methodologies include critical success factors, business systems planning (BSP) from IBM, strategic systems planning, information engineering (Martin, 1989) and method/1. Critical success factors (Rockart, 1979) methodology focuses on identifying key information needs of senior executives and building information systems around those key needs. The emphasis on senior management’s information requirements is based on an organizational control model of critical decisions being made by informed executives. However, the control in e-business is more diffused, autonomous and often occurs outside the organization. This reduces the usefulness of this methodology for EBIS architecture planning.

BSP combines top-down planning with bottom-up implementation and focuses on a firm’s business processes to derive data needs and classes. Similarly, strategic systems planning methodology stresses functional area analysis to identify the data architecture, which is then used to design information systems. Information engineering provides techniques for building enterprise, data, and process models. These models are combined to form a comprehensive knowledge base that is used to create and maintain information systems.

Experience of organizations suggests that these methodologies tend to be too detailed, time-consuming, and expensive. The roots of these methodologies can be traced to systems development practices of the 1980s. Since then new paradigms such as component based development have come into use. These paradigms place less emphasis on building applications from scratch and stress a factory approach of assembling pre-packaged components to create application systems. Hence, organizations often find methodologies such as BSP too rigid and unsuitable for the highly compressed development cycle times that prevail in e-business applications development. Moreover, EBIS planning requires addressing how diverse systems and platforms will be integrated to meet organizational requirements. The alignment methodologies fail to explicitly address such integration issues because they are from an era when organizations created their own information systems and cross-platform integration was not a primary need.

The ISP Steps

The information systems plan project determines the sequence for implementing specific information systems. The goal of the strategy is to deliver the most valuable business information at the earliest time possible in the most cost-effective manner.
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.

Information Systems Plan Development Steps

1.) Create the mission model

2.) Develop a high-level data model- The high-level data model is an Entity Relationship diagram created to meet the data needs of the mission descriptions.

3.) Create the resource life cycles (RLC) and their nodes- Resources are drawn from both the mission descriptions and the high level data model. 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 aspect of the missions.

4.) Allocate precedence vectors among RLC nodes- Tied together into a enablement network, the resulting resource life cycle network forms a framework of enterprises assets that represent an order and set of inter-resource relationships.

5.) Allocate existing information systems and databases to the RLC nodes.

6.) Allocate standard work break down structures (WBS) to each RLC node- Employing WBS and metrics from a comprehensive methodology supports project management standardization, repeatability, and self-learning.

7.) Load resources into each WBS node- Once the resources are determined, these are loaded into the project management meta entities of the meta data repository, that is, metrics, project, work plan and deliverables.

8.) Schedule the RLC nodes through a project management- The entire suite of projects is then scheduled on an enterprise-wide basis.

9.) Produce and review of the ISP- The scheduled result is predicable: Too long, too costly, and too ambitious. At that point, the real work starts: paring down the suite of projects to a realistic set within time and budget.

10.) Execute and adjust the ISP through time- As the ISP is set into execution, technology changes occur that affect resource loadings. In this case, only steps 6-9 need to be repeated.

FOUR STEPS TO IMPLEMENTATION

The adoption and implementation of the proposed approach to complying with regulation requirements consists of four steps. Activities in these four steps can be easily incorporated into the Software Development Life Cycle (SDLC) currently in use by the organization. “Information System Life Cycle Phases” is a model that demonstrates integrating regulation requirements into a popular SDLC.

1. Discovery and Identification Specific regulation requirements relevant to information systems should be documented. A current risk survey report may be used if available.

Identification and classification of binding enterprise regulations, standards, and frameworks should be included in a dictionary of terms and definitions. This dictionary should be the basis for a common language among all the organizational units in the enterprise that are involved in implementing and sustaining regulatory compliance measures. Existing and planned information systems and the identification of gaps between regulation requirements and their implementation should also be surveyed.

It is possible to have regulation requirements from multiple regulatory agents. Conversely, IT controls that were developed in response to a particular regulation requirement may be applicable to several information systems. One byproduct of this exercise is the identification of duplicate controls that were implemented to remedy regulatory requirements. A list of information systems, their risk classification, and associated controls presents an excellent opportunity to streamline and consolidate the number of IT controls in the organization.

Once IT controls are documented, a logical next step would be to expand the knowledge base by linking relevant policies, procedures, work instructions, forms, process owner information, and system managers. A repository of such information could help reduce the burden and high demand on IT professionals and make the audit process more efficient.

2. Classification Information systems should be classified to facilitate prioritization according to criteria such as:

• The importance of a system to a business process. An existing risk survey report can be used as a source for information system classification and serve as a starting point. Control self-assessment is a popular tool that can be used for establishing information systems classification.
• The impact of the information system on one or more business processes and the risk factors associated with information systems.
• The interdependency with other internal and external information systems.

Once prioritized, a viable work plan for implementing regulation requirements can be developed for the information systems managed by the IT department.

3. Mapping To establish ownership and direct responsibility for each information system in the organization, it is necessary to map information systems. Mapping should identify the following relationships:
• Information system to business process.
• Regulation requirements to organizational unit(s).
• Information system ownership.
• Identification or discovery of “orphan” information systems.
• Identification of multi-owner information systems.

Any identified gaps must be investigated and resolved. Additionally, the mapping information collected in this effort should be well-documented and maintained as an ongoing regulation compliance activity.

4. Development, Testing, Implementation, and Maintenance The development, testing, implementation, and maintenance of regulation requirements include:

• Development of code necessary to satisfy regulation requirements.
• Testing and validation of regulation compliance of information systems developed in-house.
• Validation that all vendor-supplied information systems comply with regulation requirements.
• Testing, validation, and approval of external information systems services compliance with regulation requirements (including software as a service-based (SaaS) systems).

Certification demonstrating regulatory compliance of information systems by all stakeholders is required to authorize systems for production use. During tough economic times and budget cuts, improving business processes is a good way to prepare for the up-turn cycle and for the inevitable wave of new regulations that are sure to hit our shores.

The prevailing best practice of doing more with less applies to internal and IT auditors just as it does to other stakeholders in business enterprises. Internal and IT auditors can add value to their audited parties, in particular, and to business organizations in general, by playing the role of trusted advisor. The primary role of an auditor is to verify compliance; identify risks, control deficiencies, and the effectiveness of existing controls; and produce an audit report for management.
Executive and Adjusting the ISP Through Time

IT projects are accomplished within distinct development environments. The two most common are: discrete project and release. The discrete project environment is typified by completely encapsulated projects accomplished through a water-fall methodology.

In release environments, there are a number of different projects underway by different organizations and staff of varying skill levels. Once a large number of projects are underway, the ability of the enterprise to know about and manage all the different projects degrades rapidly. That is because the project management environment has been transformed from discrete encapsulated projects into a continuous flow process of product or functionality improvements that are released on a set time schedule. The continuous flow process environment is characterized by:

• Multiple, concurrent, but differently scheduled projects against the same enterprise resource

• Single projects that affect multiple enterprise resources

• Projects that develop completely new capabilities, or changes to existing capabilities within enterprise resources

It is precisely because enterprises have transformed themselves from a project to a release environment that information systems plans that can be created, evolved, and maintained on an enterprise-wide basis are essential.

There are four major sets of activities within the continuous flow process environment. The user/client is represented at the top in the small rectangular box. Each of the ellipses represents an activity targeted to a specific need. The four basic needs are:

• Need Identification

• Need Assessment- is a process for determining and addressing needs, or "gaps" between current conditions and desired conditions, often used for improvement projects in education/training, organizations, or communities. In the context of community improvement, it is known as community needs analysis. It involves identifying material problems/deficits/weaknesses and advantages/opportunities/strengths, and evaluating possible solutions that take those qualities into consideration

• Design- is the planning that lays the basis for the making of every object or system. It is also the process or art of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements. One could see it as the application of systems theory to product development. There is some overlap with the disciplines of systems analysis, systems architecture and systems engineering.

• Deployment- The general deployment process consists of several interrelated activities with possible transitions between them. These activities can occur at the producer site or at the consumer site or both. Because every software system is unique, the precise processes or procedures within each activity can hardly be defined. Therefore, "deployment" should be interpreted as a general process that has to be customized according to specific requirements or characteristics.

The box in the center is the meta data repository. Specification and impact analysis is represented through the left two processes. Implementation design and accomplishment is represented by the right two processes. Two key characteristics should be immediately apparent. First, unlike the water-fall approach, the activities do not flow one to the other. They are disjoint. In fact, they may be done by different teams, on different time schedules, and involve different quantities of products under management. In short, these four activities are independent one from the other. Their only interdependence is through the meta data repository.

The second characteristic flows from the first. Because these four activities are independent one from the other, the enterprise evolves by means of releases rather than through whole systems. If it evolved through whole systems, then the four activities would be connected either in a waterfall or a spiral approach, and the enterprise would be evolving through major upgrades to encapsulated functionality within specific business resources. In contrast, the release approach causes coordinated sets of changes to multiple business resources to be placed into production. This causes simultaneous, enterprise-wide capability upgrades across multiple business resources.

Through this continuous-flow process, several unique features are present:

• All four processes are concurrently executing.
• Changes to enterprise resources occur in unison, periodically, and in a very controlled manner.
• The meta data repository is always contains all the enterprise resource specifications: current or planned. Simply put, if an enterprise resource semantic is not within the meta data repository, it is not enterprise policy.
• All changes are planned, scheduled, measured, and subject to auditing, accounting, and traceability.
• All documentation of all types is generated from the meta data repository.

ISP Summary
In summary, any technique employed to achieve an ISP must be accomplishable with less than 3% of the IT budget. Additionally, it must be timely, useable, maintainable, able to be iterated into a quality product, and reproducible. IT organizations, once they have completed their initial set of databases and business information systems will find themselves transformed from a project to a release environment.

The continuous flow environment then becomes the only viable alternative for moving the enterprise forward. It is precisely because of the release environment that enterprise-wide information systems plans that can be created, evolved, and maintained are essential.


References:
http://www.wiscorp.com/ISP_the_bet_your_business_project.pdf
http://web.njit.edu/~jerry/MIS-625/Articles/Pant-Ravichandran-2001.pdf
http://viu.eng.rpi.edu/publications/strpaper.pdf
http://www.theiia.org/intAuditor/itaudit/2009-articles/the-impact-of-regulation-on-information-system-planning/

http://h10025.www1.hp.com/ewfrf/wc/softwareList?os=2093&lc=en&dlc=en&cc=us&lang=en&product=458978

ddddd

On our second assignment our task is to interview a Systems Analyst and ask what skills and characteristics must a systems analyst develop in order to be more effective in any design modeling process.

AMS Group of Companies

AMS Group of Companies is our adopted company in our group discussion in SAD 1 which is on “System Analyst as a Project Manager”. We interview the MIS Head/System Analyst of the Andres M. Soriano (AMS) Group of Companies, Mr. Gemrald Glibara.

System Analyst, in a narrow sense, analysis of the current and future roles of proposed computer system in an organization, The system analyst (usually a software engineer or programmer) examines the flow of documents, information, and material to design a system that best meets the cost, performance, and scheduling objectives.
System characteristics

A component - an irreducible part or aggregation of parts that make up a system, also called a subsystem

Interrelated components- Dependence of one subsystem on one or more subsystems

Boundary- The line that marks the inside and outside of a system and that sets off the system form its environment

Purpose-The overall goal or function of a system

Environment- Everything external to a system that interacts with the system

Interface- it is a point of contact where a system meets its environment or where subsystems meet each other.

Constraint- A limit to what a system can accomplish

Input- Whatever a system takes from its environment in order to fulfill its purpose

Output- Whatever a system returns from its environment in order to fulfill its purpose

Four main skills of a System Analyst

1.) Analytical Skills
It is the ability to see things as systems, identify, analyze, and solve problems in an optimal way for a specific organization.
To test for analytical skills one might be asked to look for inconsistencies in an advertisement, put a series of events in the proper order, or critically read an essay. Usually standardized tests and interviews include an analytical section that requires the examiner to use their logic to pick apart a problem and come up with a solution.
Although there is no question that analytical skills are essential, other skills are equally required as well. For instance in systems analysis the systems analyst should focus on four sets of analytical skills: systems thinking, organizational knowledge, problem
identification, and problem analyzing and solving.
It also includes the way we describe a problem and subsequently finding out the solutions.
2.) Technical Skills
It is the ability to understand how computers, data networks, databases, operating systems, etc. work together, as well as their potentials and limitations.

He has the knowledge and proficiencies required in the accomplishment of engineering, scientific, or any specific task.

Many aspects of your job as a system analyst are technically oriented.
• The following activities will help you stay up-to-date:
– Read trade publications
– Join professional societies
– Attend classes or teach at a local college
– Attend many courses or training sessions offered by your organizations
– Attend professional conferences, seminars, or trade shows
– Participate in electronic bulletin, new groups

You should be familiar as possible with information technology:
• Microcomputer, micro station, workstation, mainframe computers
• Programming languages
• Operating systems
• Database and file management systems
• Data communication standards
• Software for local and wide networks
• Web developing tools
• Decision support system generators
• Data analysis tools
• Data design tools


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

Also it is the practice of understanding, developing and deploying people and their skills. Well-implemented skills management should identify the skills that job roles require, the skills of individual employees, and any gap between the two.

To be most useful, skills management needs to be conducted as an ongoing process, with individuals assessing and updating their recorded skill sets regularly. These updates should occur at least as frequently as employees' regular line manager reviews, and certainly when their skill sets have changed.
There are four classes of management skills:

1- Resources
2- Project
3- Risk
4- Change management


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

The ability or the skill to transfer one’s thoughts, ideas and information from the sender to the receiver with the latter being understood the same effectively and efficiently is known as communication skills. It is one of the greatest skills of the soft skills and its importance is growing rapidly due to the rising complexities as a result of technological inventions.

In corporate terminology, communication is the process of exchange of information from the sender to the receiver and vice versa. There are different types of communication such as downward communication, upward communication, horizontal communication, crosswise communication, verbal communication; written communication etc., In downward communication, the flow of information is from the people at the superior level to the people at the subordinate level. On the other hand, in upward communication, the flow of information is from the subordinate level to the superior level. In horizontal information, the flow of information is from the people of same level to that of their counterparts at the same level. In crosswise communication, the flow of information is from one level to any other level which is either diagonal or crosswise without any reporting relationship. In verbal communication, the flow of communication, which is transferred orally to any level and it, is the most effective one as one can communicate effectively with one’s body language so as to have profound impact on the receiver. Whenever, there is a need to record the information in black and white, and then people go for written communication in which the communication is through mass mailing in written form.



Most important system concepts

1. Open system: a system that interacts freely with its environment, taking input and returning output.

An open system is a system that regularly exchanges feedback with its external environment. Open systems are systems, of course, so inputs, processes,
outputs, goals, assessment and evaluation, and learning are all important. Aspects that are critically important to open systems include the boundaries, external environment and equifinality.

Healthy open systems continuously exchange feedback with their environments, analyze that feedback, adjust internal systems as needed to achieve the system’s goals, and then transmit necessary information back out to the environment.

2. Closed system: a system that is cut off from its environment and does not interact with it.

It is a "state of being isolated from its surrounding environment."The term often refers to an idealized system in which closure is perfect. In reality no system can be completely closed; there are only varying degrees of closure.

3. Modularity is dividing a system into parts/chunks/modules of relatively uniform size.

4. Decomposition is the process of breaking down a system into its component parts.

The purpose of decomposition is to allow the system analysts to:
• Break a system into small, manageable subsystem
• Focus on one are at a time

5. Coupling is the extent to which subsystems are dependent on each other.
Subsystem should be independent as possible. If one subsystem fails and other subsystem are highly dependent on it, then the other will either fail themselves or have problems functioning.

One of the important approaches in the modeling of the design process is the axiomatic approach (Suh et al., 1978). This approach is based on developing a set of global principles, or axioms, which can be applied in making decisions during the design process. These axioms are considered as general truths such that no violations or counter-examples can be observed. However, the
y can not be proven, therefore development of axioms is mainly a heuristic approach. The creative processes in 4 different design steps based on the axiomatic design theory are discussed in (Sekimoto and Ukai, 1994). These design steps are the definition of functional requirements, the identification of design parameters, the analysis of the proposed solutions in order to choose the best solution and check the final solution. The mapping from functional domain to physical domain is explained and the properties of design matrix, which is responsible for this mapping, are given. The axiomatic theory is also discussed by Dimarogonas (Dimarogonas, 1993) and implication of these rules on the design and manufacturing methodology is presented.

Systems analysts will need to continually upgrade their technical expertise and improve their ability to interact with users as the sophistication and complexity of technology advances. As more computing power is made available to the individual user and users develop more sophisticated knowledge of computers, they become more aware of the machine's potential and better able to suggest how computers could be used to increase their own productivity and that of the organization. Increasingly, users are able to design and implement more of their own applications and programs. The result is a growing demand for computer support specialists, help desk personnel, and technical consultants.

References:
http://en.wikipedia.org/wiki/Analytical_skill
http://www.articlesbase.com/training-articles/communication-skills-218336.html
http://managementhelp.org/misc/orgs-open-systems.pdf
www.cba.edu.kw/abo/pdf/chapter-2.ppt
http://www.interlabs.bradley.edu/NSF_CCLI/Demo/class6/module6/Skills_Pretest_Posttest_Answers.pdf
http://mecha
tronics.atilim.edu.tr/courses/mece401/reading/Chapter%2004%20Design%20Process%20Models.pdf

Evidence:

Information is an organizational resource which must be managed as carefully as other resources. Costs are associated with information processing. It must be managed to take full advantage of its potential.

A system is a combination of resources working together to transform inputs into usable outputs.

An information system is an arrangement of people, data, processes, interfaces, networks, and technology that interact to support and improve both day-to-day operations (data processing, transaction processing), as well as support the problem-solving and decision-making needs of management (information services, management information systems, executive support).

A computer application is a computer-based solution to one or more business problems or needs. One or more computer applications are typically contained within an information system.

Systems analysts study business, scientific, or engineering data processing problems and design new solutions using computers. They work to help an organization realize the maximum benefit from its investment in equipment, personnel, and business processes.

Analysts begin an assignment by discussing the systems problem with managers and users to determine its exact nature. Much time is devoted to clearly defining the goals of the system and understanding the individual steps used to achieve them so that the problem can be broken down into separate programmable procedures. Analysts then use techniques such as structured analysis, data modeling, information engineering, mathematical model building, sampling, and cost accounting to plan the system. Analysts must specify the inputs to be accessed by the system, design the processing steps, and format the output to meet the users' needs. Once the design has been developed, systems analysts prepare charts and diagrams that describe it in terms that managers and other users can understand. They may prepare cost-benefit and return-on-investment analyses to help management decide whether implementing the proposed system will be financially feasible.

When a system is accepted, analysts determine what computer hardware and software will be needed to set it up. They coordinate tests and observe initial use of the system to ensure it performs as planned. They prepare specifications, work diagrams, and structure charts for computer programmers to follow and then work with them to "debug," or eliminate errors from the system.

What do systems analysts do?

The rapid spread of computers has generated a need for highly trained workers to design and develop new hardware and software systems and to incorporate technological advances into new or existing systems. Job titles used to describe the broad category of computer-related occupations evolve rapidly, reflecting new areas of specialization or changes in technology as well as the preferences and practices of employers. Although many narrow specializations exist, this professional specialty group is commonly categorized into computer scientists, computer engineers, and systems analysts.

Far more numerous than do computer scientists and computer engineers, systems analysts use their knowledge and skills to solve computer problems and enable computer technology to meet the individual needs of an organization. They study business, scientific, or engineering data processing problems and design new solutions using computers. This process may include planning and developing new computer systems or devising ways to apply existing systems' resources to additional operations. Systems analysts may design entirely new systems, including both hardware and software, or add a single new software application to harness more of the computer's power. They work to help an organization realize the maximum benefit from its investment in equipment, personnel, and business processes. Most systems analysts generally work with a specific type of system depending on the type of organization they work for for example, business, accounting or financial systems, or scientific and engineering systems. Companies generally seek business systems analysts who specialize in the type of systems they use.

Analysts begin an assignment by discussing the systems problem with managers and users to determine its exact nature. Much time is devoted to clearly defining the goals of the system and understanding the individual steps used to achieve them so that the problem can be broken down into separate programmable procedures. Analysts then use techniques such as structured analysis, data modeling, information engineering, mathematical model building, sampling, and cost accounting to plan the system. Analysts must specify the inputs to be accessed by the system, design the processing steps, and format the output to meet the users' needs. Once the design has been developed, systems analysts prepare charts and diagrams that describe it in terms that managers and other users can understand. They may prepare cost-benefit and return-on-investment analyses to help management decide whether implementing the proposed system will be financially feasible.

When a system is accepted, analysts determine what computer hardware and software will be needed to set it up. They coordinate tests and observe initial use of the system to ensure it performs as planned. They prepare specifications, work diagrams, and structure charts for computer programmers to follow and then work with them to "debug," or eliminate errors from the system.

In some organizations a single worker called a programmer-analyst is responsible for both systems analysis and programming. (The work of computer programmers is described elsewhere in the Handbook.) As this becomes more commonplace, these analysts will increasingly work with Computer Aided Software Engineering (CASE) tools and object-oriented programming languages, as well as client/server applications development, and multimedia and Internet technology.

Many others specialize in analysis, application, or design of a particular system or piece of the system. Network or systems administrators, for example, may install, configure, and support an organizations systems or portion of a system. Telecommunications specialists generally are involved with the interfacing of computer and communications equipment. Computer security specialists are responsible for planning, coordinating, and implementing an organizations' information security measures. These and other growing specialty occupations reflect the increasing emphasis on client-server applications, the growth of the Internet, the expansion of World Wide Web applications and Intranets, and the demand for more end-user support. An example of this is the growing number of job titles relating to the Internet and World Wide Web such as Internet and Web developers, or Webmasters.

How do you prepare to become a systems analyst?

Training, Other Qualifications, and Advancement
While there is no universally accepted way to prepare for a job as a systems analyst because employers' preferences depend on the work to be done, a bachelor's degree is virtually a prerequisite for most employers. Relevant work experience also is very important. For some of the more complex jobs, persons with graduate degrees are preferred.

Regardless of college major, employers generally look for people who are familiar with programming languages and have broad knowledge of and experience with computer systems and technologies, strong problem-solving and analysis skills, and good interpersonal skills. Courses in computer programming or systems design offer good preparation for a job in this field. For jobs in a business environment, employers usually want systems analysts to have a background in business management or a closely related field, while a background in the physical sciences, applied mathematics, or engineering is preferred for work in scientifically oriented organizations. Since employers generally look for experience, entry-level employees enhance their employment opportunities by participating in internship or co-op programs offered through their schools.

Systems analysts must be able to think logically and have good communication skills. They often deal with a number of tasks simultaneously; the ability to concentrate and pay close attention to detail is important. Although many computer specialists sometimes work independently, they often work in teams on large projects. They must be able to communicate effectively with computer personnel, such as programmers and managers, as well as with users or other staff who may have no technical computer background.

Systems analysts may be promoted to senior or lead systems analysts with experience. Those who show leadership ability also can advance to management positions, such as manager of information systems or chief information officer.

Many people develop advanced computer skills in other occupations in which they work extensively with computers, and then transfer into computer occupations. For example, an accountant may become a systems analyst or computer support specialist specializing in accounting systems development, or an individual may move into a systems analyst job after working as a computer programmer.

Nature of the Work

All organizations rely on computer and information technology to conduct business and operate efficiently. Computer systems analysts help organizations to use technology effectively and to incorporate rapidly changing technologies into their existing systems. The work of computer systems analysts evolves rapidly, reflecting new areas of specialization and changes in technology.

Computer systems analysts solve computer problems and use computer technology to meet the needs of an organization. They may design and develop new computer systems by choosing and configuring hardware and software. They may also devise ways to apply existing systems’ resources to additional tasks. Most systems analysts work with specific types of computer systems—for example, business, accounting, or financial systems or scientific and engineering systems—that vary with the kind of organization. Analysts who specialize in helping an organization select the proper system software and infrastructure are often called system architects. Analysts who specialize in developing and fine-tuning systems often are known as systems designers.

To begin an assignment, systems analysts consult managers and users to define the goals of the system. Analysts then design a system to meet those goals. They specify the inputs that the system will access, decide how the inputs will be processed, and format the output to meet users’ needs. Analysts use techniques such as structured analysis, data modeling, information engineering, mathematical model building, sampling, and cost accounting to make sure their plans are efficient and complete. They also may prepare cost-benefit and return-on-investment analyses to help management decide whether implementing the proposed technology would be financially feasible.

When a system is approved, systems analysts determine what computer hardware and software will be needed to set it up. They coordinate tests and observe the initial use of the system to ensure that it performs as planned. They prepare specifications, flow charts, and process diagrams for computer programmers to follow; then they work with programmers to “debug,” or eliminate errors, from the system. Systems analysts who do more in-depth testing may be called software quality assurance analysts. In addition to running tests, these workers diagnose problems, recommend solutions, and determine whether program requirements have been met.

In some organizations, programmer-analysts design and update the software that runs a computer. They also create custom applications tailored to their organization’s tasks. Because they are responsible for both programming and systems analysis, these workers must be proficient in both areas. (A separate section on computer programmers appears elsewhere in the Handbook.) As this dual proficiency becomes more common, analysts are increasingly working with databases, object-oriented programming languages, client–server applications, and multimedia and Internet technology.

One challenge created by expanding computer use is the need for different computer systems to communicate with each other. Systems analysts work to make the computer systems within an organization, or across organizations, compatible so that information can be shared. Many systems analysts are involved with these “networking” tasks, connecting all the computers internally, in an individual office, department, or establishment, or externally, as when setting up e-commerce networks to facilitate business among companies.

Work environment. Computer systems analysts work in offices or laboratories in comfortable surroundings. They usually work about 40 hours a week—about the same as many other professional or office workers. Evening or weekend work may be necessary, however, to meet deadlines or solve specific problems. Many analysts telecommute, using computers to work from remote locations.

Like other workers who spend long periods typing on a computer, computer systems analysts are susceptible to eyestrain, back discomfort, and hand and wrist problems such as carpal tunnel syndrome or cumulative trauma disorder.

One obstacle associated with expanding computer use is the inability of different computer systems to communicate with each other. Because maintaining up-to-date information—accounting records, sales figures, or budget projections, for example—is important in modern organizations, systems analysts may be instructed to make the computer systems in each department compatible so that information can be shared. Many systems analysts are involved with "networking" or connecting all the computers in an individual office, department, or establishment. A primary goal of networking is to allow users to retrieve data from a mainframe computer or a server and use it on their machine. This connection also allows data to be entered into the mainframe from a personal computer. Analysts must design the hardware and software to allow free exchange of data, custom applications, and the computer power to process it all. They study the seemingly incompatible pieces and create ways to link them so users can access information from any part of the system. Networks come in many variations and network systems and data communications analysts design, test, and evaluate systems such as Local Area Networks (LAN), Wide Area Networks (WAN), Internet, and Intranet and other data communications systems. These analysts perform network modeling, analysis and planning, and even research and recommend necessary hardware and software.
A problem is an undesirable situation that prevents the organization from fully achieving its purpose, goals, and objectives. An opportunity is the chance to improve the organization even in the absence of specific problems. (Some might argue that any unexploited opportunity is, in reality, a problem.) A directive is a new requirement imposed by management, government, or some external influence. (Some might argue that a directive until it is fully complied with is, in reality, a problem.)

A systems analyst facilitates the development of information systems and computer applications. The systems analyst performs systems analysis and design. Systems analysis is the study of a business problem or need in order to recommend improvements and specify the requirements for the solution. System design is the specification or construction of a technical, computer-based solution as specified by the requirements identified in a systems analysis.

Personal qualities helpful to systems analysts include:
• problem-solving abilities
• communication skills
• computer/IT experience
• self-discipline and self-motivation
• Project management capabilities

SPECIALIZED SKILLS OF SYSTEM ANALYSTS

Systems analysts must be able to think logically and have good communication skills. They often deal with a number of tasks simultaneously; the ability to concentrate and pay close attention to detail is important. Although many computer specialists sometimes work independently, they often work in teams on large projects. They must be able to communicate effectively with computer personnel, such as programmers and managers, as well as with users or other staff who may have no technical computer background.

Employers generally look for analysts who are familiar with programming languages and have broad knowledge of and experience with computer systems and technologies, strong problem-solving and analysis skills, and good interpersonal skills. Courses in computer programming or systems design offer good preparation for a job in this field. For jobs in a business environment, employers usually want systems analysts to have a background in business management or a closely related field, while a background in the physical sciences, applied mathematics, or engineering is preferred for work in scientifically oriented organizations. Since employers generally look for experience, entry-level employees enhance their employment opportunities by participating in internship or co-op programs offered through their schools. A related background in the industry in which the job is located, such as financial services, banking, or accounting, can also give an applicant an edge.

References:
http://www.math.utep.edu/mathmajor/system/home.html
http://www.careersprep.com/html/it_anlst.html
http://faculty.sxu.edu/~rogers/sys/sa.html

Followers

AbOuT Me ;)

My photo
HeLLo...just CaLL me jusip for short, 18 yrs of age 3rd Year sTudent Of USEP(Obrero Campus)

ChatBoX