♥ReGeneration♥

Future Technology - Case Study 3

2011-01-06T23:02:00.003+08:00

I have chosen to watch the movies Equilibrium and The Fifth Element and below are the reactions that I have on watching those movies.

Equilibrium

If you would try to watch this movie, I think you would think that this is kinda boring because when I watched it, I feel like I wanted to click stop on the video player and try another movie. But when I started to concentrate on it, I have realized that this movie is worth watching for especially that it talks about how would the future be or how would we live in the near future. I felt very excited during the middle part of the movie since it was when the main actor had stopped taking his Prozium, a liquid drug that could stop feeling emotions, and later felt the feelings a normal human being has. It was so pitiful for those people who were executed just because they have felt emotions. In the movie, the people in place call Libria believes that human emotion is responsible for man's inhumanity to man, and made the new leaders ban all materials deemed likely to stimulate strong emotions, including art, music, and literature. Those materials are rated "EC-10" for "emotional content" and are typically destroyed by immediate incineration. It was very overwhelming to watch the part where the main actor had decided to continue not taking the Prozium and be with those people who are resistant to the policies existing in Libria, which they are called “The Underground” since they were living under the grounds of Libria. Since the main actor is Libria’s highest ranking cleric, it is exected that he is well-trained on a deadly martial art of Gun Kata, an art which teaches users to predict the actions of opponents during firearm combat. And by that, he killed those people behind the Tetragrammaton Council who were governing the city of Libria and all became well.

The Fifth Element

When I started to watch this movie, I remembered that I have already seen this a very long time ago and I think I was not able to understand the details of the movie since I was just a kid on that time. I can say that during the first part of the movie, I already felt excited and interested on watching this since I love watching movies involving the universe, astronomy and the like. The main goal of the main actor and actress in this movie is to save the world. At first, Dallas did not want to believe that his mission is to save the world. When he won a ticket on a contest which has a price of having a vacation on Fhloston Paradise, he never expected that aliens would be there interrupting the show. Speaking of the show, it was the most amazing part for me, a Diva that was singing in a high-pitched tone of voice. Oh, I wish I had that wonderful voice also. So much for that, I felt like I was inlove watching Dallas and Leeloo kissing and embracing each other that made Leeloo realized that the human beings are worth saving for and had released the weapon’s “Divine Light which caused the Great Evil (Black Hole) to stop hitting the Earth and become a new moon in Earth’s orbit. After watching this movie, I remembered how the Earth had been destroyed on the movie entitled “2012”. I think they have similar story also with the movie entitled “Deep Impact”. All in all, this movie is really amazing.

COMPARATIVE ANALYSIS

Both movies are of course categorized as a Science Fiction Movie. Both are also nice and worth watching for. The movie Equilibrium is more engaged to political views since it talks about how society would become in the near future if war would be existing. Meanwhile the movie The Fifth Element talks about saving the world through having the five elements combined to stop the evil going through Earth. Both talked about love. In the movie Equilibrium, the actor and his children realized that it is not right to take the liquid drug and that they have started to stop taking it when the actor’s wife has been executed after being revealed to be a sense offender. And in the movie The Fifth Element, it was saying the word “I need you because I love you”, the embrace and the kiss that made Leeloo strong enough to perform her role as the fifth element that could save the world.

Future Technology - Case Study 2

2011-01-05T16:37:00.001+08:00

Since I have started to learn what my profession really is, and if I would think of what would be my contributions for the development of technology on what I have learned from college, the first thing that would come on my mind is I would like to work with the security issues in systems. According to Wikipedia, Computer security is a branch of computer technology known as information security as applied to computers and networks. The objective of computer security includes protection of information and property from theft, corruption, or natural disaster, while allowing the information and property to remain accessible and productive to its intended users. We all know the fact that information security is not yet as perfect as we wanted it to be. There would still be ways to hack systems nowadays and that’s why I would really want to contribute ways for the data and systems security to be perfect like no one could really get through the systems without permission.

Future Technology - Case Study 1

2010-12-24T11:29:00.001+08:00

Enumerate reasons why we use technology today. What are some points that have influenced us? What are the factors involved in technology change?

Technology is the set of tools both hardware (physical) and software (algorithms, philosophical systems, or procedures) that help us act and think better. Technology includes all the objects from a basic pencil and paper to the latest electronic gadget. Electronic and computer technology help, use and share information and knowledge quickly and efficiently. What was previously slow and tedious is now easier and more realistic. Any tool has the potential to remove the tedium and repetition that will allow us to perform that which is most human-- thinking, dreaming, and planning.

We use technology for the following reasons: (1) help us act and think better; (2) quick and efficient information dissemination; (3) ease of work; (4) profit; (5) faster transactions; etc

The points that have influenced us in using technology are: (1) curiosity; (2) today’s trend; (3) making life easier and better; etc

There are also factors that are involved in the change of technology and some of those are the following: (1) new ideas; (2) creativity; (3) uncontentment ; (4) people’s demands and needs; etc.

SAD 2 - Assignment 4

2010-09-02T22:34:00.002+08:00

Contrast and discuss the enrollment input form (PRF) with the enrollment university interface.

When you try to look the Pre- Registration Form (PRF), it seems that it has many differences with the interface of the university's enrollment system. There are entries or fields on the system that is not present on the PRF that a student must fill-up. And some of those entries are the following:

Civil Status
Birthdate
Contact Number
E-mail Address
Religion
Desired Career
Year
Parents

If the entries above are not present on the PRF, then what would be the values to be inputted on that fields? If a student is an old type of student, then maybe those fields have already values but what if he/she is a new type of student? What should be those fields have?

Aside from those missing fields that I have observed, there is also a big difference on the positions of the different fields that the PRF and the enrollment system interface have. If I would be the encoder, and assuming that it would be my first time to operate the system, it would be difficult for me to input the values found on the PRF to the system since I have to look to the PRF and then find the correct field on the system where I have to enter the values. It would be time-consuming and there is a possibility of wrong inputs for those fields.

I also found out that the PRF has something to do with the scholarship a student has but in the system, there is no field for the scholarship. Aside from that, the employment information is also not present on the enrollment system interface.

My suggestions would be: (a) the look and feel of the PRF should be close to the look and feel of the university's enrollment system interface so that it would just be easy for the encoder to encode the necessary information found in the PRF into the system; (b) some entries that are present on the system and are not on the PRF should be removed.

SAD 2 - Assignment 3

2010-07-30T04:28:00.001+08:00

Interview your university network specialist. Ask how various parts of the system communicates with each other throughout the university. (Q) Given the chance to redesign the existing setup, enumerate and discuss your keypoints for an effective and efficient network environment ideal for the university.

1. What are the components involved in the system(s) in the university? (hardware, software, technology, etc.)

I am not in the right position to discuss the details of the software components used as there are other assigned personnel for such job. However, talking about hardware component and technology used, basically I, assigned as the network administrator, is entrusted to maintain our different servers to run 24/7. Currently, we have our Web Server hosted here in our University in our HP ProLiant ML350 Server. Its an old but stable server set-up here in our Networks Office and has been active since Engr. Val A. Quimno , not yet a dean, was appointed as the Network Administrator. The said server has the following specification:

* Intel Xeon 3.0 GHz, 3.2 GHz, or 3.4 GHz processors (dual processor capability) with 1MB level 2 cache standard. Processors include support for Hyper-Threading and Extended Memory 64 Technology (EM64T)

* Intel® E7520 chipset

* 800-MHz Front Side Bus

* Integrated Dual Channel Ultra320 SCSI Adapter

* Smart Array 641 Controller (standard in Array Models only)

* NC7761 PCI Gigabit NIC (embedded)

* Up to 1 GB of PC2700 DDR SDRAM with Advanced ECC capabilities (Expandable to 8 GB)

* Six expansion slots: one 64-bit/133-MHz PCI-X, two 64-bit/100-MHz PCI-X, one 64-bit/66-MHz PCI-X, one x4 PCI-Express, and one x8 PCI-Express

* New HP Power Regulator for ProLiant delivering server level, policy based power management with industry leading energy efficiency and savings on system power and cooling costs

* Three USB ports: 1 front, 1 internal, 1 rear

* Support for Ultra320 SCSI hard drives (six hot plug or four non-hot plug drives supported standard, model dependent)

* Internal storage capacity of up to 1.8TB; 2.4TB with optional 2-bay hot plug SCSI drive

* 725W Hot-Plug Power Supply (standard, most models); optional 725W Hot-Pluggable Redundant Power Supply (1+1) available. Non hot plug SCSI models include a 460W non-hot plug power supply.

* Tool-free chassis entry and component access

* Support for ROM based setup utility (RBSU) and redundant ROM

* Systems Insight Manager, SmartStart, and Automatic Server Recovery 2 (ASR-2) included

* Protected by HP Services and a worldwide network of resellers and service providers. Three-year Next Business Day, on-site limited global warranty. Certain restrictions and exclusions apply. Pre-Failure Notification on processors, memory, and SCSI hard drives.

Aside from it, our mail server running under Compaq Proliant ML330 Server, our oldest server, is also hosted here in our Networks Office. Together with other Servers, such as Proxy and Enrollment Servers, both proxy and our enrollment servers are running in a microcomputer/personal computers but with higher specifications to act as servers.

2. How do these communicate with one another? (topology, network connectivity, protocols, etc.) – may include data flow/ UML diagrams to better explain.

All Servers are connected in a shared medium grouped as one subnetwork. In general, our network follows the extended star topology which is connected to a DUAL WAN Router that serves as the load balancer between our two Internet Service Providers. All other workstations are grouped into different subnetworks as in star topology branching out from our servers subnetwork as in extended star topology. At present, we are making use of class C IP Address for private IP address assignments. Other workstations IP assignments are configured statically (example: laboratories) while others are Dynamic (example: offices). All workstations are connected via our proxy servers that do some basic filtering/firewall to control users access to the internet aside from router filtering/firewall management. So, whenever any workstation has to connect to the internet, it has to pass through software and hardware based firewall.

3. What are the processes involved in the communication (each system to other systems)?

As mentioned above, in item 3, all workstations are connected via a proxy server. It means that whenever a workstation is turned on, it requests for an IP address from the proxy server (for dynamically configured IP address) and connect to the network after IP address is acquired. As connection is established, each system can now communicate and share resources within the same subnetwork and to server following the concepts discuss in your Computer Network Class.

4. How do you go along with the maintenance of the system?

Basically, our servers are expected to be in good condition since it is required to be up 24/7. Daily, during my vacant period, monitoring on the servers are observed that includes checking logs, checking hardware performance such as CPU health, etc. If problems are observed, remedies are then and then applied. Once in a week, regular overall checkup is observed as preventive maintenance to ensure not to experience longer downtime if possible.

5. Does the system follow a specific standard? Explain Please.

As I was appointed as the Network Administrator, everything was already in place except for some minor changes. Basically, different networking standards was already observed such as cabling standards, TIA/EIA 568A-B, different IEEE standards as discussed in your Computer Networks Subject, etc.

6. How is the security of the system? Are there any vulnerabilities? Risks? Corresponding mitigation techniques? Access control?

As I have mentioned, we have implemented both software and hardware based filtering/firewall. Basically, Risks or vulnerabilities and different mitigation techniques were considered to increase security in our network. Aside from filtering/firewall, constant monitoring on networks activity also increases the security of the system.

7. Are there any interference? During what (most) times do these occur? Explain their effects especially with regards to the business of the university?

Major Interferences are normally encountered as an effect of unforeseen and beyond our control events such as black outs, and the like. The said interference would of course affect University’s day-to-day businesses for obviously this will paralyze all our activities that rely on electricity and further this might cause damage on our network devices, etc. that may later be the reason for longer downtime. Problems encountered by our providers such as connection to the National/International Gateway also affect University’s business such as correlating to University’s Business Partners outside and within the country.

SAD 2 - Assignment 2

2010-07-22T00:03:00.000+08:00

Relative to your answer in Assignment 1 .... what's your take on the design of the enrollment system?

All of the observations, comments and suggestions about the new enrollment system implemented this year are already posted in my Assignment 1. And based on it, I would just summarize my take on the design of the newly implemented enrollment system.

The enrollment period plays a big role on a university since it is the time that students would be registering as a part of the institution. As my part as a student, the enrollment procedure of the university should have a process that is easy for us to adopt, understand and follow. It is my fourth year of staying here in the university and I observed that for that past seven enrollment periods (2 times for every year) that I have experienced, it was not that easy to adopt and follow. The process is always changing and I know for the fact that it is for the betterment of the process since lots of students and other people involve in the enrollment process have many complaints about it and by that, we all want change. However, changing the enrollment process can make the people involve confused. Fortunately, diagrams were posted on the different areas on the university every enrollment. Those diagrams show the process for the enrollment and serve as a guide for the students, especially for the freshmen students, since they are new comers to the university.

The following are the necessary changes that should be implemented for the improvement of the new enrollment system of our university.

the first step, which is the students accounts part, can just be removed since the processes involve on it, which are checking students accounts and checking balance, are already involve on the clearance signing part that is usually done weeks before the end of a semester.

on the third step, the payment of the other fees (e.g. local council, OCSC, headlight, insurance) should be done prior to the presenting enrollment requirements for the advising/pre-registration part since receipts for the other fees should be included on the advising part for the adviser to be able to give a pre-registration form to the student.

on the sixth step, which is the last step on the diagram, should not serve as the last step since we all knew that we have to go to the library after having the official Certificate of Registration (COR).

SAD 2 - Assignment 1

2010-07-08T19:37:00.005+08:00

Assuming you were tapped by the university president to evaluate the new enrollment system implemented this semester, enumerate your observations/comments and suggest possible areas and ways where improvements can be made. Your observations/suggestions should be properly validated with facts and literature.

The enrollment period plays a big role on a university since it is the time that students would be registering as a part of the institution. As my part as a student, the enrollment procedure of the university should have a process that is easy for us to adopt, understand and follow. It is my fourth year of staying here in the university and I observed that for that past seven enrollment periods (2 times for every year) that I have experienced, it was not that easy to adopt and follow. The process is always changing and I know for the fact that it is for the betterment of the process since lots of students and other people involve in the enrollment process have many complaints about it and by that, we all want change. However, changing the enrollment process can make the people involve confused. Fortunately, diagrams were posted on the different areas on the university every enrollment. Those diagrams show the process for the enrollment and serve as a guide for the students, especially for the freshmen students, since they are new comers to the university.

As a student, I can really say that posting those diagrams can be a big help for us not to be confused and to know what processes should be taken for the enrollment. And this assignment that we will be answering in this forum is related to that enrollment process that can be found on those diagrams. Some issues were taken on considerations for the improvement of those diagrams. But those issues would only focus on the enrollment process of the freshmen students since the old students were already used to the different processes on the university. And for the shiftees, since they have the same enrollment process with the new students, I have just generalized the enrollment process. There are some observations, comments, and suggestions that I have to share to everyone and those are the following:

In terms of the images:

1. I have observed that the picture of the student on the beginning part of the enrollment process is different on the image of the student when he/she finishes the enrollment or is now officially enrolled. It should be taken into consideration since on the reality; a student who would be enrolling would not become big or will not enlarge his/her body size on the time that he/she has finished the enrollment procedure. Maybe, it was used to emphasize that a student is now officially enrolled but it is really a little bit funny if applied into reality. If that is the case, maybe by now I am already fat (how I wish! LOL ).

2. On the long arrow pointing below that can be found after the step four of the enrollment process. For me, it can really make students confused since that arrow is pointing down and it would make us think that the next step to be followed can be found below the previous step. But as you can see on the diagram, it is not, is it? In terms of the process:

1. The first step, which is the students accounts part, can just be removed since the processes involve on it, which are checking students accounts and checking balance, are already involve on the clearance signing part. As a student, I know that every time we will be having clearance signing, out student accounts and balances were already checked by the bookkeeper. Of course, if the bookkeeper found something incomplete on the accounts, he/she would not be signing the clearance. So, on the enrollment process, the first step can be not included since the clearance should be already completely signed prior to the enrollment period because of the fact that the people involve on the clearance signing (people who will sign the clearance, e.g. registrar, bookkeeper, etc.) are already busy on the enrollment time so they should not be disturbed for them also to concentrate on the enrollment process alone.

2. On the third step, which involves presenting enrollment requirements, advising, paying other fees, encoding, assessment of fees, and temporary COR printing, the payment of the other fees (e.g. local council, OCSC, headlight, insurance) should be done prior to the presenting enrollment requirements for the advising/pre-registration part. I have suggested it so that the process would be shorter and I know that the receipts for the other fees should be included on the advising part for the adviser to be able to give a pre-registration form to the student. On should be checked so that on the registrar part, students are already assured that they have already the receipts for the other fees.

3. On the sixth step, which is the last step on the diagram, should not serve as the last step since we all knew that we have to go to the library after having the official Certificate of Registration (COR). The library part should be included as the last step on the diagram for the enrollment. The library part should include presenting the COR for validating that a student is officially enrolled and presenting a 1x1 ID picture for the library card.

SAD1 - Assignment 12

2010-03-13T10:38:00.003+08:00

Infor ERP (Enterprise Resource Planning)

Flexible, low-cost ERP solutions that match the way your business works.

In today's world of globalization and price pressures, it's imperative that your enterprise resource planning systems offer business-specific solutions with industry experience built in. This is true whether you produce goods made from distinct parts and components such as automobiles, electronics, and machinery or goods made by blending ingredients such as foods, beverages, pharmaceuticals, and chemicals.

As an ERP software vendor, Infor offers a variety of ERP solutions that help companies in a wide spectrum of subsectors automate, plan, collaborate, and execute according to their unique business requirements. Built on an open, flexible, service-oriented architecture (SOA) with modern, web-based user interfaces, our scalable ERP solutions never lock you in to one mode of operating. Instead, they offer a breadth of functionality that enables you to automate key manufacturing and financial processes, meet fluctuating customer demand and compliance requirements, and collaborate internally as well as externally across your supply chain—all at a low total cost of ownership. Lean manufacturing capabilities are built in to our ERP solutions to minimize waste and increase quality and productivity; strong aftermarket service capabilities expedite service management.

With multiple deployment and buying options for Infor ERP, including Software as a Service (SaaS), manufacturers can choose the model that meets their specific requirements.

Infor ERP solutions help companies like yours:

* Reduce
operational costs and improve efficiency
* Gain
better visibility into transactions across the enterprise
* Make
better business decisions
* Deliver
the right product at the right time
* Keep
customer promises
* Adopt
manufacturing best practices, including lean

Infor's ERP solutions meet the diverse needs of today's manufacturers with robust functionality for two broad categories of manufacturing:

Production environments characterized by individual, separate unit manufacture of highly complex products—Infor's
ERP software systems offer a high degree of flexibility for order-driven manufacturing where unit volumes are typically low and lead times variable. We extend the traditional ERP footprint with unrivaled support for a multitude of cross-business and manufacturing operations, integrated business process modeling, change and compliance management, and aftermarket service support. Based on 25+ years of manufacturing excellence.

Process manufacturing production environments where ingredients are blended to formulate a whole—Infor ERP solutions can help minimize the total cost of quality, to service customers and cost of compliance, while meeting ever-increasing demand variability. We offer industry-specific functionality, advanced workflow technology, and flexible business process support with strong lot traceability, packaging, compliance, customer service, regulatory compliance, and financial capabilities. Industry expertise acquired through long-term partnerships with leading global process manufacturers is embedded.

Service Management—Power and control for customer-centric service and maintenance.

Lean Manufacturing—Enabling lean processes across your enterprise and value chain.

Quality Management—Improved quality for increased productivity.

Financials—Single, integrated modern finance solution for manufacturers.

Manufacturing—Flexibility and control for manufacturers of highly complex products.

Process Manufacturing—Proven value optimization capabilities for the process industry.

Wholesale and Distribution—Control and responsiveness for extended supply chains.

REFERENCES:

http://www.infor.com/

SAD1 - Assignment 11

2010-03-13T10:31:00.001+08:00

CHOOSING OR DEFINING DEPLOYMENT ENVIRONMENT

Choosing a deployment strategy requires design tradeoffs; for example, because of protocol or port restrictions, or specific deployment topologies in your target environment. Identify your deployment constraints early in the design phase to avoid surprises later. To help you avoid surprises, involve members of your network and infrastructure teams to help with this process.

When choosing a deployment strategy an analyst should: understand the target physical environment for deployment; understand the architectural and design constraints based on the deployment environment; and understand the security and performance impacts of your deployment environment.

Distributed vs. Non-distributed Deployment

When creating your deployment strategy, first determine if you will use a distributed or a non-distributed deployment model. If you are building a simple application for which you want to minimize the number of required servers, consider a non-distributed deployment. If you are building a more complex application that you will want to optimize for scalability and maintainability, consider a distributed deployment. In a non-distributed deployment, all of the functionality and layers reside on a single server except for data storage functionality. In a distributed deployment, the layers of the application reside on separate physical tiers. Distributed deployment allows you to separate the layers of an application on different physical tiers.

Scale Up vs. Scale Out

Your approach to scaling is a critical design consideration. Whether you plan to scale out your solution through a Web farm, a load-balanced middle tier, or a partitioned database, you need to ensure that your design supports this. When you scale your application, you can choose from and combine two basic choices: Scale up: Get a bigger box and Scale out: Get more boxes. With this Scale Up: Get a Bigger Box, you add hardware such as processors, RAM, and network interface cards (NICs) to your existing servers to support increased capacity. To Scale Out: Get More Boxes, you add more servers and use load-balancing and clustering solutions.

Consider Design Implications and Tradeoffs up Front

You need to consider aspects of scalability that may vary by application layer, tier, or type of data. Know your tradeoffs up front and know where you have flexibility and where you do not. Scaling up and then out with Web or application servers might not be the best approach.

Stateless Components

If you have stateless components (for example, a Web front end with no in-process state and no stateful business components), this aspect of your design supports both scaling up and scaling out. Typically, you optimize the price and performance within the boundaries of the other constraints you may have.

Data

For data, decisions largely depend on the type of data:

* Static, reference, and read-only data. For this type of data, you can easily have many replicas in the right places if this helps your performance and scalability. This has minimal impact on design and can be largely driven by optimization considerations. Consolidating several logically separate and independent databases on one database server may or may not be appropriate even if you can do it in terms of capacity. Spreading replicas closer to the consumers of that data may be an equally valid approach. However, be aware that whenever you replicate, you will have a loosely synchronized system.
* Dynamic (often transient) data that is easily partitioned. This is data that is relevant to a particular user or session (and if subsequent requests can come to different Web or application servers, they all need to access it), but the data for user A is not related in any way to the data for user B.
* Core data. This type of data is well maintained and protected. This is the main case where the “scale up, then out” approach usually applies. Generally, you do not want to hold this type of data in many places because of the complexity of keeping it synchronized. This is the classic case in which you would typically want to scale up as far as you can (ideally, remaining a single logical instance, with proper clustering), and only when this is not enough, consider partitioning and distribution scale-out. Advances in database technology (such as distributed partitioned views) have made partitioning much easier, although you should do so only if you need to. This is rarely because the database is too big, but more often it is driven by other considerations such as who owns the data, geographic distribution, proximity to the consumers, and availability.

Consider Database Partitioning at Design Time

If your application uses a very large database and you anticipate an I/O bottleneck, ensure that you design for database partitioning up front. Moving to a partitioned database later usually results in a significant amount of costly rework and often a complete database redesign. Partitioning provides several benefits: The ability to restrict queries to a single partition, thereby limiting the resource usage to only a fraction of the data; The ability to engage multiple partitions, thereby getting more parallelism and superior performance because you can have more disks working to retrieve your data.

Performance Patterns

Performance deployment patterns represent proven design solutions to common performance problems. When considering a high-performance deployment, you can scale up or scale out. Scaling up entails improvements to the hardware on which you are already running. Scaling out entails distributing your application across multiple physical servers to distribute the load. A layered application lends itself more easily to being scaled out.

Affinity and User Sessions

Web applications often rely on the maintenance of session state between requests from the same user. A Web farm can be configured to route all requests from the same user to the same server—a process known as affinity—in order to maintain state where this is stored in memory on the Web server. However, for maximum performance and reliability, you should use a separate session state store with a Web farm to remove the requirement for affinity.

Reliability Patterns

Reliability deployment patterns represent proven design solutions to common reliability problems. The most common approach to improving the reliability of your deployment is to use a failover cluster to ensure the availability of your application even if a server fails.

Failover Cluster

A failover cluster is a set of servers that are configured in such a way that if one server becomes unavailable, another server automatically takes over for the failed server and continues processing.

Security Patterns

Security patterns represent proven design solutions to common security problems. The impersonation/delegation approach is a good solution when you must flow the context of the original caller to downstream layers or components in your application. The trusted subsystem approach is a good solution when you want to handle authentication and authorization in upstream components and access a downstream resource with a single trusted identity.

Impersonation/Delegation

In the impersonation/delegation authorization model, resources and the types of operations (such as read, write, and delete) permitted for each one are secured using Windows Access Control Lists (ACLs) or the equivalent security features of the targeted resource (such as tables and procedures in SQL Server). Users access the resources using their original identity through impersonation.

Trusted Subsystem

In the trusted subsystem (or trusted server) model, users are partitioned into application-defined, logical roles. Members of a particular role share the same privileges within the application. Access to operations (typically expressed by method calls) is authorized based on the role membership of the caller. With this role-based (or operations-based) approach to security, access to operations (not back-end resources) is authorized based on the role membership of the caller. Roles, analyzed and defined at application design time, are used as logical containers that group together users who share the same security privileges or capabilities within the application. The middle-tier service uses a fixed identity to access downstream services and resources.

Network Infrastructure Security Considerations

Make sure that you understand the network structure provided by your target environment, and understand the baseline security requirements of the network in terms of filtering rules, port restrictions, supported protocols, and so on. Recommendations for maximizing network security include: Identify how firewalls and firewall policies are likely to affect your application’s design and deployment. Firewalls should be used to separate the Internet-facing applications from the internal network, and to protect the database servers. These can limit the available communication ports and, therefore, authentication options from the Web server to remote application and database servers; Consider what protocols, ports, and services are allowed to access internal resources from the Web servers in the perimeter network or from rich client applications. Identify the protocols and ports that the application design requires, and analyze the potential threats that occur from opening new ports or using new protocols; Communicate and record any assumptions made about network and application layer security, and what security functions each component will handle. This prevents security controls from being missed when both development and network teams assume that the other team is addressing the issue; Pay attention to the security defenses that your application relies upon the network to provide, and ensure that these defenses are in place; Consider the implications of a change in network configuration, and how this will affect security.

Manageability Considerations

The choices you make when deploying an application affect the capabilities for managing and monitoring the application. You should take into account the following recommendations:

* Deploy components of the application that are used by multiple consumers in a single central location to avoid duplication.
* Ensure that data is stored in a location where backup and restore facilities can access it.
* Components that rely on existing software or hardware (such as a proprietary network that can only be established from a particular computer) must be physically located on the same computer.
* Some libraries and adaptors cannot be deployed freely without incurring extra cost, or may be charged on a per-CPU basis; therefore, you should centralize these features.
* Groups within an organization may own a particular service, component, or application that they need to manage locally.
* Monitoring tools such as System Center Operations Manager require access to physical machines to obtain management information, and this may impact deployment options.
* The use of management and monitoring technologies such as Windows Management Instrumentation (WMI) may impact deployment options.

REFERENCES:

http://apparchguide.codeplex.com/wikipage?title=Chapter%205%20-%20Deployment%20Patterns&referringTitle=Home

SAD1 - Assignment 10

2010-03-13T10:26:00.004+08:00

Data Flow Diagrams (DFDs) model events and processes (i.e. activities which transform data) within a system. DFDs examine how data flows into, out of, and within the system. The DFD Principles are: a system can be decomposed into subsystems, and subsystems can be decomposed into lower level subsystems, and so on; each subsystem represents a process or activity in which data is processed. At the lowest level, processes can no longer be decomposed; each 'process' (and from now on, by 'process' we mean subsystem and activity) in a DFD has the characteristics of a system; just as a system must have input and output (if it is not dead), so a process must have input and output; data enters the system from the environment; data flows between processes within the system; and data is produced as output from the system. The 'Context Diagram ' is an overall, simplified, view of the target system, which contains only one process box and the primary inputs and outputs. The Top or 1st level DFD, describes the whole of the target system. It 'bounds' the system under consideration. Data Flow Diagrams show: the processes within the system; the data stores (files) supporting the system's operation; the information flows within the system; the system boundary; and interactions with external entities.

DFD Notations

Processes, in other methodologies, may be called 'Activities', 'Actions', 'Procedures', 'Subsystems' etc. They may be shown as a circle, an oval, or (typically) a rectangular box. Data are generally shown as arrows coming to, or going from the edge of a process box.

General Data Flow Rules

1. Entities are either 'sources of' or 'sinks' for data input and outputs - i.e. they are the originators or terminators for data flows.
2. Data flows from Entities must flow into Processes
3. Data flows to Entities must come from Processes
4. Processes and Data Stores must have both inputs and outputs (What goes in must come out!)
5. Inputs to Data Stores only come from Processes.
6. Outputs from Data Stores only go to Processes.

The Process Symbol

Processes transform or manipulate data. Each box has a unique number as identifier (top left) and a unique name (an imperative - e.g. 'do this' - statement in the main box area). The top line is used for the location of, or the people responsible for, the process. Processes are 'black boxes' - we don't know what is in them until they are decomposed. Processes transform or manipulate input data to produce output data. Except in rare cases, you can't have one without the other.

Data Flows

Data Flows depict data/information flowing to or from a process. The arrows must either start and/or end at a process box. It is impossible for data to flow from data store to data store except via a process, and external entities are not allowed to access data stores directly. Arrows must be named. Double ended arrows may be used with care.

External Entities

External Entities, also known as 'External sources/recipients, are things (e.g.: people, machines, organizations etc.) which contribute data or information to the system or which receive data/information from it. The name given to an external entity represents a Type not a specific instance of the type. When modeling complex systems, each external entity in a DFD will be given a unique identifier. It is common practice to have duplicates of external entities in order to avoid crossing lines, or just to make a diagram more readable.

Data Stores

Data Stores are some location where data is held temporarily or permanently. In physical DFDs there can be 4 types.

D = computerised Data
M = Manual, e.g. filing cabinet.
T = Transient data file, e.g. temporary program file
T(M) = Transient Manual, e.g. in-tray, mail box.

As with external entities, it is common practice to have duplicates of data stores to make a diagram less cluttered.

REFERENCES:

http://www.cems.uwe.ac.uk/~tdrewry/dfds.htm

SAD1 - Assignment 9

2010-03-13T10:17:00.001+08:00

A data flow diagram models the system as a network of functional processes and its data. It documents the system’s processes, data stores, flows which carry data, and terminators which are the external entities with which the system communicates.

SAD1 - Assignment 8

2010-03-13T09:59:00.003+08:00

An activity diagram is a UML diagram that is used to model a process. It models the actions (or behaviors) performed by the components of a business process or IT system, the order in which the actions take place, and the conditions that coordinate the actions in a specific order. Activity diagrams use swim lanes to group actions together. Actions can be grouped by the actor performing the action or by the distinct business process or system that is performing the action.

MIS2 - Assignment 9

2010-03-13T09:55:00.001+08:00

The existing models of information technology (IT) acceptance were developed with the concept of the static individual computing environment in mind. As such, in today's rapidly changing IT environment, they do not serve as adequate indicators of an individual's IT usage behavior.

“The rate and magnitude of change are rapidly outpacing the complex of theories -- economic, social, and philosophical - - on which public and private decisions are based. To the extent that we continue to view the world from the perspective of an earlier, vanishing age, we will continue to misunderstand the developments surrounding the transition to an information society, be unable to realize the full economic and social potential of this revolutionary technology, and risk making some very serious mistakes as reality and the theories we use to interpret it continue to diverge." - Cordell (1987)

The three changes that likely to have substantial impact on USEP in the next three years are the following:

1. Electronic Processing of all services

Electronic Data Processing (EDP) can refer to the use of automated methods to process commercial data. Typically, this uses relatively simple, repetitive activities to process large volumes of similar information. For example: stock updates applied to an inventory, banking transactions applied to account and customer master files, booking and ticketing transactions to an airline's reservation system, billing for utility services. Its advantages are: speed, it operates the speed of electric flow which is measured in billions and trillionth of a second. It is faster than any other machine designed to do similar works; accuracy, high speed processing by computer is accompanied by high accuracy results the electronic circuitry of computer is such that, when the machine are programmed correctly and when incoming data is error free, the accuracy of the output is relatively assured; automatic operation, an electronic computer can carry out sequence of many data processing operations without human interaction, the various operations are executed by way of a stored computer program; decision making capability, a computer can perform certain decision instruction automatically; compact storage, electronic data processing system have the ability to store large amounts of data in compact and easily retrievable form; discipline imposes, to solve problem-with computer you must, first understand the problem, second, program the computer to give you right answers. Understand a problem is one thing but understanding it to the depth of detail and insight required to program the computer is a completely different matter.

2. Virtual Learning

A virtual learning environment (VLE) is a set of teaching and learning tools designed to enhance a student's learning experience by including computers and the Internet in the learning process. The principal components of a VLE package include curriculum mapping (breaking curriculum into sections that can be assigned and assessed), student tracking, online support for both teacher and student, electronic communication (e-mail, threaded discussions, chat, Web publishing), and Internet links to outside curriculum resources. Its advantages are: learning without any restriction as to time or space; courses based on modules with flexible time schemes, which take individual learning needs into account; and greater responsibility taken by students in the learning process.

3. RFID

RFID stands for Radio-Frequency IDentification. The acronym refers to small electronic devices that consist of a small chip and an antenna. The chip typically is capable of carrying 2,000 bytes of data or less. The RFID device serves the same purpose as a bar code or a magnetic strip on the back of a credit card or ATM card; it provides a unique identifier for that object. And, just as a bar code or magnetic strip must be scanned to get the information, the RFID device must be scanned to retrieve the identifying information. Its advantages are: RFID tags are very simple to install/inject inside the body of animals, thus helping to keep a track on them. This is useful in animal husbandry and on poultry farms. The installed RFID tags give information about the age, vaccinations and health of the animals; RFID technology is better than bar codes as it cannot be easily replicated and therefore, it increases the security of the product.; Supply chain management forms the major part of retail business and RFID systems play a key role by managing updates of stocks, transportation and logistics of the product; Barcode scanners have repeatedly failed in providing security to gems and jewelries in shops. But nowadays, RFID tags are placed inside jewelry items and an alarm is installed at the exit doors; The RFID tags can store data up to 2 KB whereas, the bar code has the ability to read just 10-12 digits.

REFERENCES:

http://wiki.answers.com/Q/Advantages_of_electronic_data_processing
http://whatis.techtarget.com/definition/0,,sid9_gci866691,00.html
http://www.friends-partners.org/utsumi/Global_University/Global%20University%20System/Tapio%27s_Slides_Virtual_Learning/tsld008.htm
http://www.technovelgy.com/ct/Technology-Article.asp?ArtNum=1

SAD1 - Assignment 7

2010-02-05T08:16:00.006+08:00

Consider USEP's pre-enrollment system, develop a use case diagram and write a brief use case description. A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. It consists of a group of elements (for example, classes and interfaces) that can be used together in a way that will have an effect larger than the sum of the separate elements combined. The use case should contain all system activities that have significance to the users. A use case can be thought of as a collection of possible scenarios related to a particular goal, indeed, the use case and goal are sometimes considered to be synonymous.

MIS2 - Assignment 8

2010-02-05T08:16:00.004+08:00

fast forward ..., you were hired and have been tasked to develop a strategic information systems plan for a company. The company officers have extended an invitation for you to meet with them to discuss the direction of the company. Before this meeting, they have asked that you provide a list of questions with some explanation about the "why" of the question so they can be prepared, thus maximizing the output from this meeting.

Develop a list of questions you would ask the officers of the company and give an explanation and justification for each question.

***Below are the questions that I formulated for the upcoming meeting for the development of the SISP of the company.

1. Why did you have chosen me to develop a strategic information systems plan for your company?

Reasons why they have chosen me to develop the SISP of their company.

2. What would you want the company to achieve?

This means the goals of the company. Goals can be summarized in the phrase "dream with a deadline," a goal is an observable and measurable end result having one or more objectives to be achieved within a more or less fixed timeframe. In comparison, a 'purpose' is an intention (internal motivational state) or mission. The question, "Has the goal been achieved?" can always be answered with either a "Yes" or "No." A purpose, however, is not 'achieved' but instead is pursued everyday.

3. What are the strengths and weaknesses of your company?

SWOT analysis is a strategic planning method used to evaluate the Strengths, Weaknesses, Opportunities, and Threats involved in a project or in a business venture. It involves specifying the objective of the business venture or project and identifying the internal and external factors that are favorable and unfavorable to achieving that objective.

4. What do you think is the reason why we have to develop SISP for your company?

Strategic planning focuses largely on managing interaction with environmental forces, which include competitors, government, suppliers, customers, various interest groups and other factors that affect the business of the company and its prospects.

5. What are your objectives for the company?

Objective is the desired or needed result to be achieved by a specific time. An objective is broader than a goal, and one objective can be broken down into a number of specific goals.

6. Would you implement whatever SISP I would develop?

The answer would depend if they would like whatever SISP I would develop for the company.

7. Can your company afford the budget to be allocated for the SISP to be implemented?

A company would not hire someone to develop SISP for them if they have no budget allocated for it.

8. What are the existing systems in your company?

Legacy systems are important for me to know to be able to include it on the SISP that I would develop.

SAD1 - Assignment 6

2010-01-30T10:25:00.002+08:00

Consider the following dialogue between a systemsprofessional, John Juan, and a manager of a department targeted for a new information system, Peter Pedro:

Juan: The way to go about the analysis is to first examine the old system, such as reviewing key documents and observing the workers perform their tasks. Then we can determine which aspects are working well and which should be preserved.

Pedro: We have been through these types of projects before and what always ends up happening is that we do not get the new system we are promised; we get a modified version of the old system.

Juan: Well, I can assure you that will not happen this time. We just want a thorough understanding of what is working well and what isn’t.

Pedro: I would feel much more comfortable if we first started with a list of our requirements. We should spend some time up-front determining exactly what we want the system to do for my department. Then you systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system.

Required:

a.Obviously these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most.

b.What method would you propose they take? Why?

Well, before I start, let me first define analysis phase and it's categories of analysis.

The analysis phase is the building block of a training program. The basis for who must be trained, what must be trained, when training will occur, and where the training will take place are accomplished in this phase. The product of this phase is the foundation for all subsequent development activities. The analysis phase is often called a Front-End Analysis. That is, although you might perform analysis throughout the ISD process, such as in the design and development phases, this "front end" of the ISD process is where the main problem identification is performed.

When performing an analysis, it is best to take a long term approach to ensure that the performance improvement initiative ties in with the organization's vision, mission, and values. This connects each need with a metric to ensure that it actually does what it is supposed to do. This is best accomplished by linking performance analysis needs with Kirkpatrick's Four Levels of Evaluations, which means their are four catagories of analysis (Phillips, 2002).

Business Needs

Investigate the problem or performance initiative and see how it supports the mission statement, leader's vision, and/or organizational goals, etc. Fixing a problem or making a process better is just as good as an ROI, if not better. Organizations that focus strictly on ROI are normally focusing on cost-cutting. And you can only cut costs so far before you start stripping out the core parts of a business. A much better approach is to improve a performance or process that supports a key organization goal, vision, or mission. When senior executives were asked the most important training initiatives, 77% cited, "aligning learning strategies with business goals"; 75% cited, "ensuring learning content meets workforce requirements"; and 72%, "boosting productivity and agility" (Training Magazine, Oct 2004). Thus, senior leadership is not looking at training to be a profit center (that is what other business units are for), rather they are looking at performance improvement initiatives to help "grow" the organization so that it can reach its goals and perform its mission. The goal is to make an impact or get some sort of result. So once you have identified the gap between present performance and the organization's goals and vision; create a level 4 evaluation (impact) that measures it -- that is, what criteria must be met in order to show that the gap has actually been bridged?

Job Performance Needs

While the first analysis looked at business needs, this analysis looks at the job performance needs and these two needs could slightly differ. The first need, business, often has a slightly more visionary or future look to it, while the job performance need normally looks at what is needed now. Thus, business needs often tend to be more developmental in nature (future orientated), while job performance needs are normally more related towards the present. This is perhaps the most important need to look at as it links the performer with the organization. When analyzing job performance, you want to look at the entire spectrum that surrounds the job: processes, environment, actual performance verses need performance, etc, thus it often helps to divide the analysis into three groups: people, data, and things.

Training Needs

As you assess the performance for any needed interventions, look at the Job/Performer requirements, that is, what the performer needs to know in order for the performance intervention to be successful. In addition, look at how you are going to evaluate any learning requirements (level 2). It is one thing to determine the learning needs (skill, knowledge, & self system [attitude, metacognition, etc.]), but it is quite another thing to ensure that those requirements actually take place.

Individual Needs

It ensures that the performance intervention actually conforms to the individual requirements. For example, in the Training Needs analysis, it might be determined that the job holders need to learn a new process. In this need analysis, the target population is looked at more closely to determine the actual content, context, and delivery method of the performance intervention.

***On the dialogue above, obviously I would prefer to sympathize with Peter Pedro since he is the manager of a department targeted for a new information system. It was stated about the analysis phase that when performing an analysis, it is best to take a long term approach to ensure that the performance improvement initiative ties in with the organization's vision, mission, and values. This connects each need with a metric to ensure that it actually does what it is supposed to do. Since Peter Pedro is the manager of the department, well he obviously knows what is best for the information system that will be implemented on his department. He is the one who surely knows all the transactions being processed in the department which will be appended on the information system that John Juan would be developing.

***I would propose they will take the method that Peter Pedro had suggested for the analysis phase of the system. Since Peter Pedro is the acting client on the proposed system, of course he would be the one to specify the needs of his department that the system would have. Understanding a clients business is central to developing the right solution and the analysis stage allows Tectura to develop this knowledge. It is also the stage where John Juan and the other systems people work with their clients such as Peter Pedro to examine the standard software functionality and whether their specific business requirements will mean modifications or customisation of the standard software.

http://www.nwlink.com/~donclark/hrd/sat2.html
http://www.au.tectura.com/Page/cm95/Analsis_phase_95.asp?d=1

MIS2 - Assignment 7

2010-01-30T10:14:00.001+08:00

Arguably the most popular search engine available today, Google is widely known for its unparalleled search engine technology, embodied in the web page ranking algorithm, Page Ranking and running on an efficient distributed computer system. In fact, the verb “to Google” has ingrained itself in the vernacular as a synonym of “[performing] a web search.” The key to Google’s success has been its strategic use of both software and hardware information technologies. The IT infrastructure behind the search engine includes huge storage databases and numerous server farms to produce significant computational processing power. These critical IT components are distributed across multiple independent computers that provide parallel computing resources. This architecture has allowed Google’s business to reach a market capital over $100 billion and become one of the most respected and admirable companies in the world.

Google is one such name in the Technology arena that is well poised to rule. Talking of past decade, it’s been all the way up for Google and undoubtedly they have been ruling the internet economy. Google have had its impact in the industry with more than 150 products and will continue to grow with its ever increasing portfolio of products.

Google’s Competitors

Google face competition in every aspect of their rapidly evolving business, particularly from other companies that seek to connect people with online information and provide them with relevant advertising. Currently Google consider their primary competitors to be Microsoft and Yahoo.

But in a blog that I’ve read, the author predicted the 10 companies that will become the 10 Toughest Competitors of Google in 2010. And these are:

1. Apple

Being from partners to rivals, Apple is one of the stringent opponents for Google in the year 2010. Today, Apple and Google have been locking their horns in the field of Smartphone, Mobile App Store, OS, Mobile Ad, and Online Music and so on. Likewise, Apple is more than up to the task of battling Google in these areas as well as browsers, where Google Chrome competes against Apple Safari. But battle between will intensify, as the market for the digital music and SmartPhones is all set for growth in 2010. Google’s music search along with its partner MySpace and Pandora are looking to compete with Apple’s iTunes, which was the No 1 music retailer in United States in 2009. Further, Google’s Android will have tough time as Apple’s iPhones continues to grab hold of the market all round the globe.

2. Microsoft

Microsoft is a company that have had one of the most dominant impacts in the IT industry. So without a doubt it is Google’s biggest adversary in 2010 and these two giants will be locking their horns for market supremacy in areas such as search, collaboration tools and browsers. Talking of these two giants, Google has reigned as leaders in search, but with release of BING in May 2009, Microsoft has raised few questions amongst in Google’s management team. With features such as ranking search results based on relevancy to other users, Microsoft has inked Bing-related deals with Twitter, Facebook and Yahoo. Microsoft continued to enhance Bing, adding image search and mapping. But in response Google have unveiled real time search. In December, Google also added a photo search capability, a dictionary and a translator that finds relevant content in 40 languages. Entering 2010, Google still dominates search, with more than 70% of the market. Apart from search, the battle is likely to focus on cloud based collaboration tool. Google Apps is designed to undercut sales of Microsoft products, including Exchange and SharePoint. Microsoft has responded with Office Web Apps, free Web-based versions of Word, Excel, PowerPoint and OneNote that are due out in 2010. Last but not the least; the browser war between these two is giants are likely to heat up in 2010. So 2010 awaits the answer if ever so popular Microsoft’s premier browser’s market share could be brought down by Google’s Chrome.

3. Amazon

In 2009, Google’s effort of scanning millions of out-of-print books and incorporating them in online search did gain up some momentum and helped themselves to publish over 500000 digital books for free to customers of Sony Reader and Barnes & Noble Nook, which is due in January. Further, there claims of opening up Google Editions, an e-book store, has opened up new rivalry with Amazon. Amazon with its Kindle e-book reader is one of the leaders in e-book reader’s market. The other area where Google is taking on Amazon is in cloud computing. Google’s Apps Engine, a newbie cloud computing platform that allows developers to create their own Web applications and run them on Google’s infrastructure will be competing with Amazon’s Elastic Computing Cloud (EC2) which has already grab hold of market with its several upgrade after its release in 2006. So it will be a great battle to watch when these two giants fight for market supremacy on Cloud computing and E-book readership.

4. Facebook

Facebook, probably the most popular stuff in the internet right now, has attracted 350 million active users in just six years and is subject of interest for the guys at Google too. In 2010, Google and Facebook rivalry is likely to heat up based on question that where will people find there information in future in Search or Social Network? With ever increasing use of social networking and the rise of Facebook, Google’s worry seems to a viable one. So, in 2010 Google with its ORKUT will be in battle with Facebook. Orkut offers Google Friend Connect, a tool for Web publishers to add social networking content to their sites, in direct competition with similarly named Facebook Connect. Meanwhile, Facebook has sought out relationships with several arch-enemies of Google, including Microsoft and Yahoo. So its for sure that this battle is worth taking a note off in 2010.

5. Twitter

No doubt if Facebook is in rise, than it’s no difference with Twitter. If social networking is the way to go, then Google will certainly find Twitter in its way. Twitter, a micro-blogging site, has in a way revolutionized the way we communicate these days. So, Google’s Friend Connect will face tough competitions for Twitter’s Connect in 2010 as Twitter looks to move up the rank in the areas of Social Networking. Other areas where these two find themselves competing are Real time search. Google’s real time search and Twitter’s will be trying to outperform each other in 2010. So, this battle will be a good one to watch for in 2010.

6. Mozilla

With release of Google Chrome, Google has stepped into ever so popular browse battle. Mozilla has been in the markets for years and now this step from Google is likely to create the conflict of interest between these two. Of late the war between the two has heated up even more. The battle has now gone to default search. Mozilla now has shown intent to kick Google out from its default search engine status. The latest rumours on the internet show that Mozilla is now eyeing to get a deal with Microsoft to make Bing as its default search engine in Firefox. This may not impact Google immediately but eventually this move, if comes true, is likely to decrease Google’s share of the search market. Hence, Google now has Mozilla on a double war zone; first the obvious browser war and now the war over default searches.

7. Yahoo

When it comes to search, one of Google’s biggest competitors besides Microsoft is Yahoo. Yahoo has been in the market with variety of products in areas of email, Messenger, News, Search and Analytics services. So without doubt it will be a fearsome competitor for Google. In 2009, Yahoo made some improvements in 2009 by integrating search with its rich content. Users can watch videos or stream music straight from the Yahoo search results page. Yahoo also helps users find travel deals and compare product prices. Further, Yahoo has recently added Twitter to its search Page and if a joint search and advertising deal between Yahoo and Microsoft is approved by federal regulators. This could prove costly to Google so the 2010 is the year to watch as other competitor look to outperform Google in the market with different joint forces being formed by their rivals.

8. Cisco

Google definitely has a tough challenge against Cisco. With years of experience on web based collaborative platfomr, WebEx, and superior VOIP service, Cisco poses a threat to Google’s Wave and Voice. In addition to this, Cisco also is looking to enhance its video conferencing quality by focusing on collaboration through intenret video, desktop video and consumer Telepresence. In addition to this, Cisco’s presence in Cloud is another leading edge it has over Google. As Google is looking to take everything to the web, it certainly will face a good competition from Cisco on this front. Moreover, according to Networkworld, Cisco is looking to enter into Smartphone market in the very near future (actually by mid-2010). Its recent acquisition of Pure Digital and Flip shows Cisco’s intent to take video to the mobile phone. Thus, we might see Cisco giving a hard time to Google’s Nexus One in the coming days.

9. IBM

By now it’s quite crystal clear that 2010 will the year where big internet giants will be trying to gain whole lot of market share that will be up for grab in areas of collaboration tools. So, 2010 is likely to reopen Google’s rivalry with IBM with the release of new collaboration tools such as Google Wave. Google has stepped into the battle field with its low cost hosted collaboration tools such as Google Apps. Google will compete against IBM’s Lotus Lives, which has attracted more than 2 million businesses in the last two years.

10. Nokia

Today, Nokia has had grab hold of the mobile phone market with 4 out of 10 mobiles sold. With increase in use of smart phones, means the IT giants Google will be in rivalry with Nokia in periphery of operating systems for Smartphones. Symbian Open source operating system will be competing with Google’s Android. Nokia with recent deals with Microsoft is all set to bring Office Mobile to Symbian devices. With claim of releasing improved version of Symbian in 2010 means Google Android will have to face off tough battle. But, Google’s Android is poised for major developments in 2010 and with commitments from Acer, Sony Ericcson, HTC and Motorola this will be a worthwhile battle to watch in 2010 and years to come. So, at this point one may feel Google has tough battle to fight in 2010. Most of the arch rivals are gearing up to poise serious threats either single handed or with collaboration. So, 10 line ups of interesting battle is all set to keep the 2010 interesting enough for us to watch and keep the Google on their toes.

GOOGLE’S BUSINESS MODEL AND STRATEGY

Business Model

Since its beginning as a research project from two Computer Science doctorate students at Stanford University, Google has continued to follow its mission “to organize the world's information and make it universally accessible and useful.”2 From Google’s founding in 1997 until 2000, the company did not have a well-defined business model to generate revenues. In 2001, Google’s two co-founders hired Eric Schmidt, the chairman and CEO of Novell and former CTO at Sun Microsystems, as the new CEO of Google to help drive the effort in creating a business model for Google. With new management leadership, Google created a core business in online advertising, enabled by the millions of users using its search engine everyday. Revenue generation and profit growth in online advertising came from both Google’s search engine homepage and partner websites that display Google sponsored advertisements. Google created a cost-per-click pricing scheme for sponsored advertisements such that advertisers only pay a base fee, and for the number of referrals to their site.

Business Strategy

Google is generally secretive about its business strategy, but it is evident that Google is building the foundation for all of its products and services under the central theme of leveraging advanced search technology and personalized advertising. To maintain its reputation as a forefront technology leader and innovator, Google has been aggressively acquiring software start-up companies that can be easily integrated into its existing solutions, and can instantaneously gain visibility through Google’s leverage. However, this strategy of growing through small acquisitions is also used by Yahoo, one of Google’s major competitors, although the underlying methodology of the acquisitions is different. Yahoo’s acquisitions have been focused on acquiring search technology companies having specialized search functionalities. Yahoo has a group of search technologies for different products and services, while Google has only one search technology. Over time with greater competition, an online advertising network may be commoditized and Google will need to develop new business models to entice new customers and enhance relationships with existing ones for customer lock-ins (Elgin, 2004). For existing customers, Google has Advanced Tools & Reporting to support sophisticated advertisers, and Google plans to tighten integration with other Google related products in advertising. To reach new markets faster, Google is expanding its advertising business beyond online marketing to other mediums, including radio and print.

http://investor.google.com/faq.html#competitors
http://technology.globalthoughtz.com/index.php/10-toughest-competitors-of-google-in-2010/
http://www.crito.uci.edu/papers/2007/Google.pdf

SAD1 - Assignment 5

2009-12-18T11:49:00.004+08:00

All things have a beginning, a middle and an end. Just so, for an IT system.

At some point in the past a wonderful new system was introduced into the company. Everyone was happy. Management could see their business improve. The workflow for employees was smoother and more productive.

After the first few months of bedding in, the system worked well... and for a few years the system did everything it was meant to do.

Time passed, people moved on, the company changed ... that wonderful system began to show its age... the new manufacturing system had problems exchanging data. Customer invoices no longer flowed effortlessly from their new system into your aging computers.

Workers grew tired of using black screens with green text - even their home computers were more modern than this!

It was time for a change. And so the life cycle of the system was complete. The SYSTEM LIFE CYCLE is a term used to describe the stages in an IT project. It is the process by which an existing system is replaced with another.

Why do companies want to change their systems?

After all, they have spent a fortune on developing their existing one. All the staff knows how to use it. The technicians know how to fix it. Management understands its capabilities.

As you can imagine, changing things is an expensive, risky undertaking. Staff will have to re-trained. Equipment will have to be replaced. Offices may need to be re-wired causing disruption to every-day work.

Some of the reasons for introducing a new system may be:

1. The current system may no longer be suitable for its purpose. Changes in the way work is carried out means the system is no longer suitable

Happily, the business has grown. Starting out with only ten staff a few short years ago, the system could easily cope with the workload. But now there are a thousand staff in many offices around the world. The system just can't cope.

External influences. For example, new regulations have come along which insist that certain records are kept for years. The existing system was never designed for this.

2. Technological developments may have made the current system redundant or outdated.

Competitors are using more advanced systems that perhaps reduce their costs compared to yours, thus placing the company at a disadvantage.

Customers use more modern systems and insist that you upgrade yours to allow for easier data transfer.

The software supplier has warned that the version you are using will no longer be supported after next year. You have to plan for change.

3. The current system may be too inflexible or expensive to maintain.

A company has to to be able to cope with changing circumstances and this includes having the systems in place to deliver what the customer needs at the least internal cost.

For example, the customer has changed the way it sends data to its suppliers - you - and now your employees are having to manually type in invoices because the system cannot cope with the new format. Added costs, less profit, less competitive. Time for a new system.

Change is risky.

IT change is particularly risky!

Consider the sobering results obtained from a survey of over 14,000 organisations (OASIG study):

80-90% of systems fail to meet performance goals

80% of systems are late and over budget

40% of systems fail or are abandoned

Less than 40% of businesses fully address training and skills requirements

Less than 25% properly integrate business and technology objectives

Just 10-20% of businesses meet all their success criteria.

Therefore only between 1 in 5 and 1 in 10 of the IT projects in the survey were successful.

What could have been done better?

What could reduce the chances of failure?

As people have learnt from past mistakes, a model has been developed and refined over the years to try and maximize the chances of a successful project.

This method / model is called the SYSTEMS LIFE CYCLE.

It consists of a series of stages that take a project from its very first stages to the final outcome of a fully working, fully integrated system.

The SYSTEMS LIFE CYCLE is a term used to describe the stages in an IT project. These are:

Definition of the problem

Feasibility Study

Investigation and Analysis

Design

Development (programming)

Testing

Implementation

Evaluation

Maintenance

Notice that the term 'life cycle' is used. This is because the process never really ends. Systems are created, they become mature, they grow old and are replaced by new ones. It is a cycle.

Before a project can begin, there has to be a reason why it should take place. You have to define the problem that the system is meant to be overcome.

This phase is called the 'Problem definition phase'. Some formal effort is made to define exactly what is the problem.

For example the following statements may appear in the Problem Definition.

...The existing system cannot transfer data to the new invoice system ...
...Staff have to spend three hours loading information...
... New legislation insist that financial records are kept for this department ...

And so on.

Methods of defining a problem:

Interview employees about their issues with the current system

Analysing the total costs of the current system

Key external factors that may point towards developing a new system.

Performance of the existing system.

Once the problem definition stage is over, then if the decision is to carry on with the project the next phase is the 'Feasibility Study'.

It is one thing to define the problem with an existing system. The next question is what are the alternatives - what are the broad avenues that may be taken? It is very rare that any company will have just one possible solution open to them.

This is the 'Feasibility Study Phase' of the Systems Life Cycle model.

In this phase, alternative solutions are examined. The costs Vs the benefits are compared in order to see which would best suit the company taking into consideration their requirements and the funds available. In order to arrive at a final decision, sometimes a trade-off has to be accepted e.g. less functionality for less cash.
Consider three imaginary (very brief!) alternatives that a company could choose from:

a) Company does not change anything
Benefit: No disruption to the business. Least cost.
Performance: No change, system remains outdated. Process becomes increasingly less efficient.

b) Company makes alterations to half the system
Benefit: Best parts of the system are retained, whilst the least efficient aspects are redesigned to enhance performance.
Cost: Moderate, training moderate.
Performance improvement: 30%

c) Complete overhaul
Benefit: Reduces company cost base (more profitable).
Cost: High, given that new equipment / software will be required. Training for staff needed.

Performance: 70% improvement over the old system.
As you can see, deciding on the best alternative is often not simple - management have to take many factors into account. There are often complicated relationships between cost, performance and benefit.

So at this point of the system life cycle, you know what the problem is and you are considering options.

The various options are usually presented to management at this stage and it is up to them to make a decision as to how much cash they want to inject into the project.
Once a decision has been made, the next phase is to analyse that option in greater detail.
The management have taken the decision to proceed with the project.

The next phase is called the 'Investigation and Analysis' phase.

First you define how the old system works (investigation) and the problem(s) it is causing.

This is done by a variety of techniques that include:

Questionnaires and interviews

Observing people actually using the existing system

'Paper trail' : Following information from the point it enters the system and observing what outputs are created at each point in the system.

Noting how / why the defined problem happens.

The investigation part confirms that the true cause of the problem has been correctly defined.

It also confirms that the project will overcome the problem.

The next part is to carefully analyse how the existing system works: Not necessarily the hardware or software - but more about how information is handled and how people interact with it.

As all this needs to be communicated efficiently to all concerned, a number of standard diagrams / methods are used.

System diagrams:

These show the relationships between the various systems in the company (or even outside if relevant) - how they interact, what depends on what and so on.

Data Flow Diagrams:

Most systems deal with information in one way or another. What really matters is how the information flows through the system. How does it branch and re-join. What outputs are created and so on.

The 'data flow' diagram seeks to show this movement through the system.
Process diagrams:

People handle information in a specific way - they have a 'process'. For example, an employee makes an expense claim. First of all their manager counter-signs the claim. It then goes to the account manager who authorises payment and so on...This is 'process flow' in action.

Process diagrams try to show how people interact with the system - who and when (and why).
Having undertaken a thorough investigation and analysis phase, the next stage is to create the 'Requirements Document'

This document does not define the hardware or software design but rather seeks to capture the essence of what needs to be done.
Some fairly standard headings within the document are:

1) An introduction.
Example:
The project has been developed in order to create a new invoicing system to replace the AIX400 computer system...
The introduction gives a broad description of the project and its aspirations.

2) Context
This section provides the background to the project.
Example:
The project was developed in light of the up-coming new regulations and also the increasing awareness that the existing system could no longer meet customer expectations ....

3) Specific Details required
Having provided a broad description and some context to the project, this section deals with specific things that need to be included in the system.
Example:
The system will be able to use a query to create a mail merged personalised letter.
The system must create an invoice in less than 3 seconds
The system will be able to print a management report onto A4 paper, portrait layout.
These specific requirements are all measurable. You should not have vague statements such as "The computer will run as fast as possible..." because you cannot know if 'as fast as possible' has been met when the system finally gets switched on.

Sometimes in a complicated project this section can be sub-divided into smaller sections such as:

Its functions

Its expected performance

How it connects to other systems

How it is going to be maintained, kept secure. Its expected reliability.

And so on.

The Requirements Specification is the 'contract' between project managers and the client. It will be used at the testing stage to confirm that the system performs as the client expects.

Now that the project manager and the client have agreed on the requirements (Requirements Specification), it is time to define how the project is going to be carried out.

This is the Design phase of the project.
In this phase the exact details are defined, for example :-

The data inputs

The data outputs

Screen layouts

Any documents that are printed out

What happens to the data as it flows through the system (procedures)

The structure of any files that store data.

How information is accessed and indexed or sorted.

The operating system to be used

The hardware to be used.

And so on ....

This is all about the nitty-gritty detail. Once again this phase is trying to define the system in ever greater detail.

Think of the advantages of this phase - if you were the software engineer which would you rather have given to you as a job on a Monday morning?:-
Useless specification ! :-

a) Create a big file on the hard disk that will store all the invoices.
or
Useful, specific details...

b) The invoice file shall include a data record consisting of:-
1. Customer ID (3 digit alpha code)
2. Invoice number (9 digit number)
3. Value of item (displayed as currency)
4. .... yet more detail....

If you were the poor engineer given specification (a) the chances are you would not know where to start as you are bound to get it wrong!
So the design phase is really useful for the IT programmers who have to create the system.
Another aspect of creating a system is how are you going to test it?
It is tempting to leave the testing considerations until after the system has been developed but for the people having to develop the system it is really useful to have a test procedure in place before even starting to write a line of code or to design the hardware.

This is because you know how it will be tested and so it guides you towards a good design.
Example:

The input form shall reject
- any number greater than 1000
- any number less than zero
- any text

The input form shall accept
- any customer id and password the database already recognises
- shall jump to a 'new customer' screen (see details *** ) if it does not recognise the customer id.
Can you see why having this detail in the design phase would be useful to the project team?

Prototyping

A 'prototype' is something that represents what you will finally create without having to worry about all the details - it captures the essential details to confirm that the design is likely to work.

In software, the prototype is often written in a kind of shorthand English 'Read in the record'. The details do not matter at this stage, but a record must be 'read in'.
In hardware, you can test the system on a much cheaper slow computer, knowing that you will be able to run much faster on the final design - but it proves that the system works in principle.

The master document that is created in this phase is the 'Systems Requirement Document'
In a way, this is the contract between the project managers and the development team.
Time to do the work!

Now that the client has agreed on what needs to be done (Requirements Specification), and the Analyst has defined precisely what needs to be done (Systems Requirement Document) - it is time for the project to be actually developed.

The development stage is about taking the design forward and putting it into practice
One thing to note though, is that there may be several teams involved at this stage - so it is sensible to break down the Systems Requirement document into chunks that each teams can develop. It is no use informing the hardware team of the software requirements or vice versa.

At this stage the following things may take place (depending on the how extensive the project is) : -

The software developers write code

The hardware people develop equipment

The testing team develop test plans

The user-testing groups follow the test plans and check that the system works as expected. If not an error report is sent to the developers and corrections are made. The test is then performed again.

This is an interesting time.... the implementation stage has been reached. The system has been developed and tested. It is working correctly and doing everything that was agreed during the design stage. The business is waiting in eager anticipation for the new system to be handed over to them.

The key events in this stage are:

DATA CONVERSION
Data stored in files on the old system are now converted into the correct format for the new system.

SYSTEM CHANGE-OVER
Now it is time to switch off the old system and turn on the new.
It sounds simple, but most of the time it isn't!

What are the alternatives?

1) Switch off the old system and switch on the new.
Of course, this is the simplest scenario! All the workers are waiting for the fabulous new system to come 'on -line' but as the minutes tick by, a new customer has just ordered a holiday / medical operation / flight / mortgage.
How do you deal with these last-minute (but vital) clients?
Answer: You must deal with last minute changes and accept that there may be some upheaval and mistakes made in the short term.

2) You run the old and new system in parallel for a time.
A popular method compared to the switch off / switch on approach. After all, the customer does not care what your IT system is made up of - they are only (rightly) concerned with their holiday / medical operation / mortgage etc being booked correctly.
And so, a popular method is to allow the old system to run alongside the new one. Then in the quiet period (say overnight) , the new system absorbs all the old system's information. By the next morning, the system is fully loaded and ready to go.

3) You run only part of the new system
This is the 'phased approach' to system testing. Imagine a system so sensitive to change that only a very careful change can be considered.
Example: A new air traffic control system.
Neither of the other two approaches would be suitable for such a critical system.

TRAINING

It is at the implementation stage that staff training takes place. Staff need to be shown how to use the new system and how to access help should they run into difficulties. There may be member of the development team on call for a short period of time or there may be a dedicated help line that staff can ring to get answers.
There will most definitely be a user manual to act as a source of reference.

The implementation stage is over: The system is up and running, Staff are fully trained and bugs have been ironed out.
This new stage is called the 'Evaluation phase'
It is at this point two key questions are considered:

Does the finished solution meet its requirements?
Does it solve the problem?

These questions are answered by considering details written down in the original Requirements Specification and comparing it to the performance of the new system.

For example:
Requirements specification states that the system should be able read the data file in less than 3 seconds.
Question: Does the system meet this specification?
Answer: Yes, the data file is read in 2.8 seconds.
In a complicated project, there may be hundreds of requirements specified. It could take many weeks to complete the evaluation phase.
The project manager and the client review whether or not the project has been completed successfully.

The Evaluation stage is over and the system is running smoothly. However as time passes, it will no doubt need to be looked after. This is the Maintenance phase of the Systems Life Cycle.

At this stage the following takes place:

Problems are cleared as they arise

Tweaks to the system are applied to improve performance

New circumstances might arise such as an office move. The system has to be moved.

Data is backed up and kept safe.

Printers, Monitors and other equipment are replaced as required.

This phase never really ends until the Life Cycle of the system is complete i.e. the system is switched off for the last time and a replacement system is introduced.

As you may now realise, the System Life Cycle model has been developed to make it more likely that projects are completed as planned, within budget and on time. However, even with this rigorous process, there are no guarantees that a project will succeed.

http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/index.htm

SAD1 - Assignment 3

2009-12-18T11:49:00.003+08:00

Discuss the role of a systems analyst as a project manager.

Last December 7, 2009, our group in SAD1 visited the AMS Group of Companies located at F. Torres St., Davao City for an interview regarding our report on the said subject. During our interview, we have been given a chance to include the question on our SAD1 assignment in this forum which is “What skills and characteristics must a systems analyst develop in order to be more effective in any design modeling process?” To answer that question, we approached Mr. Gemrald R. Glibara, the M.I.S Department Head of AMS Group of Companies.

Also, in our SAD1 subject, out group was assigned to report about the Chapter 3 which is The Role of a System Analyst as a Project Manager.

A systems analyst is responsible for researching, planning, coordinating and recommending software and system choices to meet an organization's business requirements. The systems analyst plays a vital role in the systems development process. A successful systems analyst must acquire four skills: analytical, technical, managerial, and interpersonal. Analytical skills enable systems analysts to understand the organization and its functions, which helps him/her to identify opportunities and to analyze and solve problems. Technical skills help systems analysts understand the potential and the limitations of information technology. The systems analyst must be able to work with various programming languages, operating systems, and computer hardware platforms. Management skills help systems analysts manage projects, resources, risk, and change. Interpersonal skills help systems analysts work with end users as well as with analysts, programmers, and other systems professionals.

Because they must write user requests into technical specifications, the systems analysts are the liaisons between vendors and the IT professionals of the organization they represent[1] They may be responsible for developing cost analysis, design considerations, and implementation time-lines. They may also be responsible for feasibility studies of a computer system before making recommendations to senior management.

A systems analyst performs the following tasks:

• Interact with the customers to know their requirements
• Interact with designers to convey the possible interface of the software
• Interact/guide the coders/developers to keep track of system development
• Perform system testing with sample/live data with the help of testers
• Implement the new system
• Prepare High quality Documentation

A Systems Analyst analyzes, designs and implements the information gathered previously to a system, the final product which is a report of yearly sales, profits, etc.

The first thing a Systems Analyst does is to interview the company which wants the report, (called the user) to find out what kind of report they want, format, etc. They must find whether the report is feasible or not, and to find out, they do an analysis of the project.

To analyze the project, they must find out where are they going to get the information, how, when is the project going to be done, etc. They then design the system, which is to make a 'skeleton' of the project. They write specifications, of what is to be in the final report. They do flow charting, specifications for the programmers of the report, and development control.

Development control is where the Systems Analyst works with the programmers along a critical path. A critical path is like a due date, if the report is to be done in thirty days, the Systems Analyst makes sure the report is done in thirty days. The Systems Analyst also follows the first analysis of when the project will be finished. The critical path also calculates how many man hours it will take to finish, etc. A critical path flowchart also helps the programmers along.

After the development is finished and a prototype of the report is finished, the Systems Analyst helps the programmers in testing the program for bugs. This is similar to quality control. The Systems Analyst helps to makes sure the work is done until the final report is achieved. Once the final report is finished and free of bugs, it is sent to the user.

The Systems Analyst has a big job to do, he/she is responsible for the design, the development, and implementation of the report, ie: what purpose will it serve, presentation, etc. The Systems Analyst creates and helps finish the final product, making all the specifications and charts for what is to be done.

A Systems Analyst requires a computer science degree to get the job. He/She must have good analytical skills, (to be able to analyze for the report) good communication skills, and experience in programming is a help also.

Basically a Systems Analyst is responsible for systems projects, from beginning to the end of a project, and they must implement the system to good use. The Systems Analyst then must follow up to make sure the program is running smoothly.
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.

The project manager is responsible for the overall success of the project. In some companies, this person might be called a Project Coordinator, or a Team Leader, however, the key aspect is that the person is responsible for ensuring the success of the project.

What does it take for the project to be a success? If you follow the Ten Step Project Management Process, or a similar approach, you first must define the project and build the schedule. This is where the project manager's responsibilities start. If the project begins and you find out later that you are not clear on scope, the project manager is the one who is accountable. If your project is executing a poor schedule, the project manager is accountable.

The work around defining the project means that you understand and gain agreement on the overall objectives, scope, risk, approach, budget, etc. It also includes defining or adopting the specific project management procedures that will be used to manage the project.

This does not mean that the project manager must do all this work themselves. There may be an entire team of people helping to create the Project Charter and schedule. However, if something does not go right, the project manager is accountable.

Process Responsibilities

Once the project starts, the project manager must successfully manage and control the work, including:

• Identifying, tracking managing and resolving project issues
• Proactively disseminating project information to all stakeholders
• Identifying, managing and mitigating project risk
• Ensuring that the solution is of acceptable quality
• Proactively managing scope to ensure that only what was agreed to is delivered, unless changes are approved through scope management
• Defining and collecting metrics to give a sense for how the project is progressing and whether the deliverables produced are acceptable
• Managing the overall schedule to ensure work is assigned and completed on time and within budget

Again, this does not mean that the project manager physically does all of this, but they must make sure it happens. If the project has problems, or scope creep, or faces risks, or is not setting expectations correctly, then the project manager is the person held accountable.

To manage the project management processes, a person should be well organized, have great follow-up skills, be process oriented, be able to multi-task, have a logical thought process, be able to determine root causes, have good analytical ability, be a good estimator and budget manager, and have good self-discipline.

People Responsibilities

In addition to process skills, a project manager must have good people management skills. This includes:

• Having the discipline and general management skills to make sure that people follow the standard processes and procedures
• Establishing leadership skills to get the team to willingly follow your direction. Leadership is about communicating a vision and getting the team to accept it and strive to get there with you.
• Setting reasonable, challenging and clear expectations for people, and holding them accountable for meeting the expectations. This includes providing good performance feedback to team members
• Team building skills so that the people work together well, and feel motivated to work hard for the sake of the project and their other team members. The larger your team and the longer the project, the more important it is to have good team-building skills.
• Proactive verbal and written communicator skills, including good, active listening skills.

Again, you are responsible for the success of the project. If the team has poor morale and is missing deadlines, you need to try to resolve it. If team members don't understand exactly what they need to do and when it is due, then you are responsible.

Multiple Roles

Depending on the size and complexity of the project, the project manager may take on other responsibilities in addition to managing the work. For instance, the project manager may assist with gathering business requirements. Or they may help design a database management system or they may write some of the project documentation. Project management is a particular role that a person fills, even if the person who is the project manager is working in other roles as well.

For instance, a project manager might manage the project for 45% of their time, perform business analysis for 25%, work on design for 15% and write documentation for 15%. This does not mean that one of the responsibilities of a project manager role is to spend 15% of their time on design. Instead, it just means that the project is not large enough to need a full-time project manager. The project manager spends the rest of their time in other project roles such as Business Analyst, Designer and Technical Writer. Depending on the size of your projects and the way your company is organized, a project manager’ time may be allocated one of three ways.

• They may have a full time role on a large project.
• They may have project management responsibilities for multiple projects, each of which is less than full time, but the combination of which adds up to a full-time role.
• They may fill multiple roles, each of which requires a certain level of skill and responsibility. On one project, for instance, they may be both a project manager and an analyst.

Having Project Management Accountability but not Responsibility

In some organizations, the project manager is accountable for the success of the project, but does not have the right level of responsibility. Managing the team in a matrix organization is an example of that. You are asked to manage a project utilizing people that you do not have direct management responsibility for. In other cases, you may find that your ability to resolve issues is hampered because you are not high enough in the organization to get an issue resolved quickly. In other instances, you may find that your ability to be innovative and flexible is constrained by organizational policies and inertia.

All of these cases can be cause for frustration. One way to deal with this is to define roles and responsibilities as a part of the Project Charter. This can help set and manage expectations. For instance, if you have no budget or expense approval authority, then note that up front, along with a process for expense approval. That way, if problems do arise later, everyone knows who has the right level of authority to resolve them. For most project managers, the frustration level is not caused so much by a lack of power as much as it is caused by ambiguity. If the project manager does not have the authority, it is important to know who does, and what process is needed to gain action.

***DURING THE INTERVIEW

http://www.studyworld.com/newsite/reportessay/Science/Social%5CThe_Duties_of_A_Systems_Analyst-34848.htm
http://en.wikipedia.org/wiki/Systems_analyst
http://www.freetutes.com/systemanalysis/role-of-system-analyst.html
http://www.lifecyclestep.com/open/407.1TheRoleoftheProjectManager.htm

SAD1 - Assignment 4

2009-12-18T11:41:00.002+08:00

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

A software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process.

The activities of the software development process:

• Planning

The important task in creating a software product is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Incomplete, ambiguous, or even contradictory requirements are recognized by skilled and experienced software engineers at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect. Once the general requirements are gleaned from the client, an analysis of the scope of the development should be determined and clearly stated. This is often called a scope document. Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of development. If the development is done externally, this document can be considered a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified.

• Implementation, testing and documenting

Implementation is the part of the process where software engineers actually program the code for the project. Software testing is an integral and important part of the software development process. This part of the process ensures that bugs are recognized as early as possible. Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the authoring of an API, be it external or internal.

• Deployment and maintenance

Deployment starts after the code is appropriately tested, is approved for release and sold or otherwise distributed into a production environment. Software Training and Support is important because a large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are often resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new clients of your software. Maintenance and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. It may be necessary to add code that does not fit the original design to correct an unforeseen problem or it may be that a customer is requesting more functionality and code can be added to accommodate their requests. It is during this phase that customer calls come in and you see whether your testing was extensive enough to uncover the problems before customers do. If the labor cost of the maintenance phase exceeds 25% of the prior-phases' labor cost, then it is likely that the overall quality, of at least one prior phase, is poor. In that case, management should consider the option of rebuilding the system (or portions) before maintenance cost is out of control. Bug Tracking System tools are often deployed at this stage of the process to allow development teams to interface with customer/field teams testing the software to identify any real or perceived issues. These software tools, both open source and commercially licensed, provide a customizable process to acquire, review, acknowledge, and respond to reported issues.

Process is “Ordered set of activities to solve a problem”.

Process models are core concepts in the discipline of Process Engineering.
Process models are processes of the same nature that are classified together into a model. Thus, a process model is a description of a process at the type level. Since the process model is at the type level, a process is an instantiation of it. The same process model is used repeatedly for the development of many applications and thus, has many instantiations. One possible use of a process model is to prescribe how things must/should/could be done in contrast to the process itself which is really what happens. A process model is roughly an anticipation of what the process will look like. What the process shall be will be determined during actual system development.

It is an iterative, milestone-based approach to the development process. The way in which activities in a systems development life cycle are sequenced, and the time and formality committed to each life-cycle stage. It is the combination of clearly defined life cycle model, project team roles, delivery milestones, and solution development principles.

Waterfall model

The waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and maintenance. Progress flows from the top to the bottom, like a waterfall.

The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.

The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995), although Royce did not use the term "waterfall" in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development—as a way to criticize a commonly used software practice.

In Royce's original Waterfall model, the following phases are followed in order:
1. Requirements specification
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA Validation)
6. Installation
7. Maintenance

To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes requirements specification, which are set in stone. When the requirements are fully completed, one proceeds to design. The software in question is designed and a blueprint is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, separate software components produced are combined to introduce new functionality and reduced risk through the removal of errors. Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. However, there are various modified waterfall models (including Royce's final model) that may include slight or major variations upon this process.

Agile software development

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated. Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Conceptual foundations of this framework are found in modern approaches to operations management and analysis, such as lean manufacturing, soft systems methodology, speech act theory (network of conversations approach), and Six Sigma. There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.

Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("timeboxes") that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.[1] Multiple iterations may be required to release a product or new features.

Team composition in an agile project is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration's requirements.
Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc. Most agile teams work in a single open office (called bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. Larger development efforts may be delivered by multiple teams working toward a common goal or different parts of an effort. This may also require a coordination of priorities across teams.

No matter what development disciplines are required, each agile team will contain a customer representative. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment and ensuring alignment with customer needs and company goals. Most agile implementations use a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative and any interested stakeholders as observers. In a brief session, team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. This standing face-to-face communication prevents problems being hidden.

Agile emphasizes working software as the primary measure of progress. This, combined with the preference for face-to-face communication, produces less written documentation than other methods—though, in an agile project, documentation and other artifacts rank equally with a working product. The agile method encourages stakeholders to prioritize wants with other iteration outcomes based exclusively on business value perceived at the beginning of the iteration. Specific tools and techniques such as continuous integration, automated or xUnit test, pair programming, test driven development, design patterns, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance project agility.

Iterative and incremental development

Iterative and Incremental development is a cyclic software development process developed in response to the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment with the cyclic interaction in between. The iterative and incremental development is an essential part of the Rational Unified Process, the Dynamic Systems Development Method, Extreme Programming and generally the agile software development frameworks. Incremental development is a scheduling and staging strategy, in which the various parts of the system are developed.

The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process are to start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving sequence of versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added.

The Procedure itself consists of the Initialization step, the Iteration step, and the Project Control List. The initialization step creates a base version of the system. The goal for this initial implementation is to create a product to which the user can react. It should offer a sampling of the key aspects of the problem and provide a solution that is simple enough to understand and implement easily. To guide the iteration process, a project control list is created that contains a record of all tasks that need to be performed. It includes such items as new features to be implemented and areas of redesign of the existing solution. The control list is constantly being revised as a result of the analysis phase.

The iteration involves the redesign and implementation of a task from the project control list, and the analysis of the current version of the system. The goal for the design and implementation of any iteration is to be simple, straightforward, and modular, supporting redesign at that stage or as a task added to the project control list. The level of design detail is not dictated by the interactive approach. In a light-weight iterative project the code may represent the major source of documentation of the system; however, in a mission-critical iterative project a formal Software Design Document may be used. The analysis of an iteration is based upon user feedback, and the program analysis facilities available. It involves analysis of the structure, modularity, usability, reliability, efficiency, & achievement of goals. The project control list is modified in light of the analysis results.

V-Model

The V-model is a software development process which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The V-model deploys a well-structured method in which each phase can be implemented by the detailed documentation of the previous phase. Testing activities like test designing start at the beginning of the project well before coding and therefore saves a huge amount of the project time.

The Phases of the V-model

The V-model consists of a number of phases. The Verification Phases are on the left hand side of the V, the Coding Phase is at the bottom of the V and the Validation Phases are on the right hand side of the V.

Verification Phases

Requirements analysis

In the Requirements analysis phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the system’s functional, physical, interface, performance, data, security requirements etc as expected by the user. It is one which the business analysts use to communicate their understanding of the system back to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase.

System Design

Systems design is the phase where system engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly. The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing is prepared in this phase.

Architecture Design

The phase of the design of computer architecture and software architecture can also be referred to as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in this phase.

Module Design

The module design phase can also be referred to as low-level design. The designed system is broken up into smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudocode:

• database tables, with all elements, including their type and size
• all interface details with complete API references
• all dependency issues
• error message listings
• complete input and outputs for a module.

The unit test design is developed in this stage.

Validation Phases

Unit Testing

In the V-model of software development, unit testing implies the first stage of dynamic testing process. According to software development expert Barry Boehm, a fault discovered and corrected in the unit testing phase is more than a hundred times cheaper than if it is done after delivery to the customer. It involves analysis of the written code with the intention of eliminating errors. It also verifies that the codes are efficient and adheres to the adopted coding standards. Testing is usually white box. It is done using the Unit test design prepared during the module design phase. This may be carried out by software developers.

Integration Testing

In integration testing the separate modules will be tested together to expose faults in the interfaces and in the interaction between integrated components. Testing is usually black box as the code is not directly checked for errors.

System Testing

System testing will compare the system specifications against the actual system. The system test design is derived from the system design documents and is used in this phase. Sometimes system testing is automated using testing tools. Once all the modules are integrated several errors may arise. Testing done at this stage is called system testing.

User Acceptance Testing

Acceptance testing is the phase of testing used to determine whether a system satisfies the requirements specified in the requirements analysis phase. The acceptance test design is derived from the requirements document. The acceptance test phase is the phase used by the customer to determine whether to accept the system or not.

http://en.wikipedia.org/wiki/Software_development_process#Models
http://dictionary.babylon.com/process_model
http://keremkosaner.wordpress.com/category/process-modeling/
http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Agile_software_development
http://en.wikipedia.org/wiki/Iterative_and_incremental_development
http://en.wikipedia.org/wiki/V-Model_(software_development)

SAD1 - Assignment 2

2009-12-17T09:18:00.003+08:00

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.

Last December 7, 2009, our group in SAD1 visited the AMS Group of Companies located at F. Torres St., Davao City for an interview regarding our report on the said subject. During our interview, we have been given a chance to include the question on our SAD1 assignment in this forum which is “What skills and characteristics must a systems analyst develop in order to be more effective in any design modeling process?” To answer that question, we approached Mr. Gemrald R. Glibara, the M.I.S Department Head of AMS Group of Companies.
A Systems Analyst analyzes, designs and implements the information gathered previously to a system, the final product which is a report of yearly sales, profits, etc.

The first thing a Systems Analyst does is to interview the company which wants the report, (called the user) to find out what kind of report they want, format, etc. They must find wether the report is feasible or not, and to find out, they do an analysis of the project.

To analyze the project, they must find out where are they going to get the information, how, when is the project going to be done, etc. They then design the system, which is to make a 'skeleton' of the project. They write specifications, of what is to be in the final report. They do flow charting, specifications for the programmers of the report, and development control.

Development control is where the Systems Analyst works with the programmers along a critical path. A critical path is like a due date, if the report is to be done in thirty days, the Systems Analyst makes sure the report is done in thirty days. The Systems Analyst also follows the first analysis of when the project will be finished. The critical path also calculates how many man hours it will take to finish, etc. A critical path flowchart also helps the programmers along.

After the development is finished and a prototype of the report is finished, the Systems Analyst helps the programmers in testing the program for bugs. This is similar to quality control. The Systems Analyst helps to makes sure the work is done until the final report is achieved. Once the final report is finished and free of bugs, it is sent to the user.

The Systems Analyst has a big job to do, he/she is responsible for the design, the development, and implementation of the report, ie: what purpose will it serve, presentation, etc. The Systems Analyst creates and helps finish the final product, making all the specifications and charts for what is to be done.

A Systems Analyst requires a computer science degree to get the job. He/She must have good analytical skills, (to be able to analyze for the report) good communication skills, and experience in programming is a help also.

Basically a Systems Analyst is responsible for systems projects, from beginning to the end of a project, and they must implement the system to good use. The Systems Analyst then must follow up to make sure the program is running smoothly.

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.

Critical attributes for an analyst

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

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

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

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

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

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

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

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

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

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

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

Analysts are always looking at least 5 years out.

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

DURING THE INTERVIEW

*****

http://www.studyworld.com/newsite/reportessay/Science/Social%5CThe_Duties_of_A_Systems_Analyst-34848.htm
http://www.freetutes.com/systemanalysis/role-of-system-analyst.html
http://it.toolbox.com/blogs/business-analyst/analyst-qualifications-9881

SAD1 - Assignment 1

2009-12-17T09:12:00.001+08:00

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

A systems analyst is responsible for researching, planning, coordinating and recommending software and system choices to meet an organization's business requirements. The systems analyst plays a vital role in the systems development process. A successful systems analyst must acquire four skills: analytical, technical, managerial, and interpersonal. Analytical skills enable systems analysts to understand the organization and its functions, which helps him/her to identify opportunities and to analyze and solve problems. Technical skills help systems analysts understand the potential and the limitations of information technology. The systems analyst must be able to work with various programming languages, operating systems, and computer hardware platforms. Management skills help systems analysts manage projects, resources, risk, and change. Interpersonal skills help systems analysts work with end users as well as with analysts, programmers, and other systems professionals.

Because they must write user requests into technical specifications, the systems analysts are the liaisons between vendors and the IT professionals of the organization they represent[1] They may be responsible for developing cost analysis, design considerations, and implementation time-lines. They may also be responsible for feasibility studies of a computer system before making recommendations to senior management.

A systems analyst performs the following tasks:

• Interact with the customers to know their requirements
• Interact with designers to convey the possible interface of the software
• Interact/guide the coders/developers to keep track of system development
• Perform system testing with sample/live data with the help of testers
• Implement the new system
• Prepare High quality Documentation

During the 1960’s and early 1970’s, the field of systems development was run by either a programmer or a system analyst. There were more analysts than programmers at that time yet since computing was just new in the corporate arena and there were those who could still look at systems as a whole. But there was so great a need for people who could program computers, thus the rise of programming.

Programming was so much a trend that many authors started writing books on how to boost programmer productivity, which led to the introduction of Structured Programming in the late 1970’s. Shortly thereafter, the Computer Aided Software Engineering or the CASE movement followed.

In the 1980’s, the rise of programming has led to the tremendous decline in system analysis, with trade groups slowly folding up. New job titles were introduced such as analyst/programmer and software engineer. The emphasis of the former title was more on programming, not systems analysis. At present, programmers are so much in demand in the corporate world, particularly in the Information Technology field.

Although a programmer and systems analyst may have pretty much the same scope in performing tasks, the two are still set apart by several characteristics. The programmer is more introverted and puts more focus on technology. A systems analyst, on the other hand, studies a business’s information requirements and designs system solutions that satisfy them.

Moreover, as the middleman of the programming staff, the analyst is responsible for specifying software requirements as well. Most analysts are also usually extroverted and business-minded and they should also be able to communicate well both verbally and in written in order to work effectively with the programming staff and the end-users. Additionally, they should also be able to conduct interviews, create presentations and look at things in a bigger scope.

The systems analyst knows and understands the problems encountered by end users as well the operations of the users’ department. In fact, analysts can make great candidates for top management positions. However, this has not materialized for some time now because the demand for analysts has dwindled for many years already.

Proper systems analysis plays an important role in increasing programmer productivity as analysts can provide quality specifications for application tasks. Programmers may lose valuable time without the help of systems analysts, as they may have to make second guesses as to what the end users want. As a result, this could lead to constant rewriting of software.

Simply put, programmers can improve their productivity through quality data and processing specifications that systems analysts can provide. In fact, this is even found to be even better than any available programming technique or tool there is. With good systems analysis, programming is made easier because the focus is on upfront work.

System problems cannot be completely solved with the mere use of programming techniques and tools alone – it also needs good systems analysis as well. And apart from its vital functions, good systems analysis can actually be an important factor in increasing programmer productivity too.

Some tasks for a System Analyst:

Provide staff and users with assistance solving computer related problems, such as malfunctions and program problems. Test, maintain, and monitor computer programs and systems, including coordinating the installation of computer programs and systems. Use object-oriented programming languages, as well as client/server applications development processes and multimedia and Internet technology. Confer with clients regarding the nature of the information processing or computation needs a computer program is to address. Coordinate and link the computer systems within an organization to increase compatibility and so information can be shared. Consult with management to ensure agreement on system principles. Expand or modify system to serve new purposes or improve work flow. Interview or survey workers, observe job performance and/or perform the job in order to determine what information is processed and how it is processed. Determine computer software or hardware needed to set up or alter system. Train staff and users to work with computer systems and programs. Analyze information processing or computation needs and plan and design computer systems, using techniques such as structured analysis, data modeling and information engineering. Assess the usefulness of pre-developed application packages and adapt them to a user environment. Define the goals of the system and devise flow charts and diagrams describing logical operational steps of programs. Develop, document and revise system design procedures, test procedures, and quality standards. Review and analyze computer printouts and performance indicators to locate code problems, and correct errors by correcting codes. Recommend new equipment or software packages. Read manuals, periodicals, and technical reports to learn how to develop programs that meet staff and user requirements. Supervise computer programmers or other systems analysts or serve as project leaders for particular systems projects. Utilize the computer in the analysis and solution of business problems such as development of integrated production and inventory control and cost analysis systems. Prepare cost-benefit and return-on-investment analyses to aid in decisions on system implementation. Specify inputs accessed by the system and plan the distribution and use of the results.

4 main skills of a system analyst

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

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

Technical skills needed by systems analysts include but are not limited to:

1. Computers (PCs, mini, mainframes, etc.)
2. Computer networks (LAN, WAN, VPNs, administration, security, etc.)
3. Operating systems (Unix, Mac/OS, Windows)
4. Data Exchange Protocols (ftp, http, etc.)
5. Programming languages (C++, Java, XML, etc.)
6. Software applications (Office, project managements, etc.)
7. Information systems (databases, MISs, decision support systems)
8. System development tools and environments (such as report generators, office automation tools, etc.)

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

Managerial skills needed by systems analysts include but are not limited to:

1. resource management effectively managing the project’s resources, including time, equipment, hardware, software, people, money, etc.,
2. project management determining the tasks and resources needed for a project and how they are related to each other,
3. risk management identifying and minimizing risks,
4. change management managing the system’s (organization's) transition from one state to another

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

Communication skills needed by systems analysts include:

1. clear and effective interpersonal communication, whether written, verbal, or visual, from writing reports to face–to–face conversations, to presentations in front of groups;
2. listening (accepting opinions and ideas from other project team members),
3. group facilitation or formal technical reviews (FTR) skills:
- setting an agenda,
- leading discussions,
- involving all parties in the discussion,
- summarizing ideas,
- keeping discussions on the agenda, etc.

Characteristics of high-performance team:

1. shared vision or goal
2. sense of team identity
3. result-driven structure
4. competent team members
5. commitment to the team
6. mutual trust
7. interdependence among team members
8. effective communication
9. sense of autonomy
10. small team size
11. high level of enjoyment

Five characteristics of a good system analyst

The system analyst must be able to communicate in writing and orally.
The analyst must easily get along with people.
The analyst must be a good listener and be able to react to what people say.
The analyst must be knowledgeable of technology. The analyst is not expected to know the intricacies of programming, but a decent general knowledge of concepts and terms is essential.
The analyst must be knowledgeable of business. The analyst is not expected to be an expert in business but a decent understanding of the client's world is required.

http://en.wikipedia.org/wiki/Systems_analyst
http://answers.yahoo.com/question/index?qid=20080725042042AA2MqMh
http://www.ankosnet.org/59-good-systems-analysis-in-increasing-programmer-productivity
http://www.careerplanner.com/Job-Descriptions/Computer-Systems-Analysts.cfm

MIS2 - Assignment 6

2009-12-17T09:07:00.000+08:00

Identify and discuss the steps for "critical success factors" approach? (at least 1,500 words)

So many important matters can compete for your attention in business that it's often difficult to see the "wood for the trees". What's more, it can be extremely difficult to get everyone in the team pulling in the same direction and focusing on the true essentials.

That's where Critical Success Factors (CSFs) can help. CSFs are the essential areas of activity that must be performed well if you are to achieve the mission, objectives or goals for your business or project.

By identifying your Critical Success Factors, you can create a common point of reference to help you direct and measure the success of your business or project.

As a common point of reference, CSFs help everyone in the team to know exactly what's most important. And this helps people perform their own work in the right context and so pull together towards the same overall aims.

The idea of CSFs was first presented by D. Ronald Daniel in the 1960s. It was then built on and popularized a decade later by John F. Rockart, of MIT's Sloan School of Management, and has since been used extensively to help businesses implement their strategies and projects.

Inevitably, the CSF concept has evolved, and you may have seen it implemented in different ways. This article provides a simple definition and approach based on Rockart's original ideas.
Rockart defined CSFs as:

"The limited number of areas in which results, if they are satisfactory, will ensure successful competitive performance for the organization. They are the few key areas where things must go right for the business to flourish. If results in these areas are not adequate, the organization's efforts for the period will be less than desired."

He also concluded that CSFs are "areas of activity that should receive constant and careful attention from management."

Critical Success Factors are strongly related to the mission and strategic goals of your business or project. Whereas the mission and goals focus on the aims and what is to be achieved, Critical Success Factors focus on the most important areas and get to the very heart of both what is to be achieved and how you will achieve it.

CSFs are best understood by example. Consider a produce store "Farm Fresh Produce", whose mission is:

"To become the number one produce store in Main Street by selling the highest quality, freshest farm produce, from farm to customer in under 24 hours on 75% of our range and with 98% customer satisfaction."

The strategic objectives of Farm Fresh are to:

• Gain market share locally of 25%.
• Achieve fresh supplies of "farm to customer" in 24 hours for 75% of products.
• Sustain a customer satisfaction rate of 98%.
• Expand product range to attract more customers.
• Have sufficient store space to accommodate the range of products that customers want.

In order to identify possible CSFs, we must examine the mission and objectives and see which areas of the business need attention so that they can be achieved. We can start by brainstorming what the Critical Success Factors might be (these are the "Candidate" CSFs.)

Objective---Candidate Critical Success Factors

Gain market share locally of 25%---Increase competitiveness versus other local stores
---Attract new customers

Achieve fresh supplies from "farm to customer" in 24 hours for 75% of products---Sustain successful relationships with local suppliers

Sustain a customer satisfaction rate of 98%---Retain staff and keep up customer-focused training

Expand product range to attract more customers---Source new products locally

Extend store space to accommodate new products and customers---Secure financing for expansion
---Manage building work and any disruption to the business

Once you have a list of Candidate CSFs, it's time to consider what is absolutely essential and so identify the truly Critical Success Factors.

And this is certainly the case for Farm Fresh Produce. One CSF that we identify from the candidate list is "Sustain successful relationships with local suppliers." This is absolutely essential to ensure freshness and to source new products.

Another CSF is to attract new customers. Without new customers, the store will be unable to expand to increase market share.

A third CSF is financing for expansion. The store's objectives cannot be met without the funds to invest in expanding the store space.

Tip: How Many CSFs?

Whilst there is no hard and fast rule, it's useful to limit the number of CSFs to five or fewer absolute essentials. This helps you maintain the impact of your CSFs, and so give good direction and prioritization to other elements of your business or project strategy.

In reality, identifying your CSFs is a very iterative process. Your mission, strategic goals and CSFs are intrinsically linked and each will be refined as you develop them.

Here are the summary steps that, used iteratively, will help you identify the CSFs for your business or project:

Step One: Establish your business's or project's mission and strategic goals (click here for help doing this.)

Step Two: For each strategic goal, ask yourself "what area of business or project activity is essential to achieve this goal?" The answers to the question are your candidate CSFs.

Tip: How Many CSFs?

To make sure you consider all types of possible CSFs, you can use Rockart's CSF types as a checklist.

• Industry - these factors result from specific industry characteristics. These are the things that the organization must do to remain competitive.
• Environmental - these factors result from macro-environmental influences on an organization. Things like the business climate, the economy, competitors, and technological advancements are included in this category.
• Strategic - these factors result from the specific competitive strategy chosen by the organization. The way in which the company chooses to position themselves, market themselves, whether they are high volume low cost or low volume high cost producers, etc.

Temporal - these factors result from the organization's internal forces. Specific barriers, challenges, directions, and influences will determine these CSFs. Step Three: Evaluate the list of candidate CSFs to find the absolute essential elements for achieving success - these are your Criticial Success Factors.

As you identify and evaluate candidate CSFs, you may uncover some new strategic objectives or more detailed objectives. So you may need to define your mission, objectives and CSFs iteratively.

Step Four: Identify how you will monitor and measure each of the CSFs.

Step Five: Communicate your CSFs along with the other important elements of your business or project's strategy.

Step Six: Keep monitoring and reevaluating your CSFs to ensure you keep moving towards your aims. Indeed, whilst CSFs are sometimes less tangible than measurable goals, it is useful to identify as specifically as possible how you can measure or monitor each one.

Critical Success Factors are the areas of your business or project that are absolutely essential to its success. By identifying and communicating these CSFs, you can help ensure your business or project is well-focused and avoid wasting effort and resources on less important areas. By making CSFs explicit, and communicating them with everyone involved, you can help keep the business and project on track towards common aims and goals.

http://www.mindtools.com/pages/article/newLDR_80.htm

MIS2 - Assignment 5

2009-12-17T09:06:00.000+08:00

In the spectrum of organizational change, which is the most radical type of change: automation, rationalization of procedures, business reengineering, or paradigm shifts?

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 focus of this topic is on principles and practices to successfully accomplish significant change in organizations. Successful organizational change can be quite difficult to accomplish -- it can be like trying to change a person's habits. Fortunately, there is an increasing body of research, practice and tools from which we all can learn. A major goal of this Library topic is to make this body of information much more accessible to many -- to give the reader more clear perspective on overall organizational change and development, along with sufficient understanding to begin applying principles and practices for successful change in their roles and organizations.

The following resources are not sufficient to guide a large, comprehensive and detailed organizational change effort -- that amount of resources comprises a significantly sized book -- and besides, there is no standard procedure for guiding change. However, the following resources might be sufficient to provide the reader at least a framework that takes him or her from which to begin guiding change in smaller efforts for organizational change -- and then to begin to learn more.

There are many approaches to guiding change -- some planned, structured and explicit, while others are more organic, unfolding and implicit. Some approaches work from the future to the present, for example, involving visioning and then action planning about how to achieve that vision. Other approaches work from the present to the future, for example, identifying current priorities (issues and/or goals) and then action planning about to address those priorities (the action research approach is one example). Different people often have very different -- and strong -- opinions about how change should be conducted. Thus, it is likely that some will disagree with some of the content in this topic. That's what makes this topic so diverse, robust and vital for us all.

To really understand organizational change and begin guiding successful change efforts, the change agent should have at least a broad understanding of the context of the change effort. This includes understanding the basic systems and structures in organizations, including their typical terms and roles. This requirement applies to the understanding of leadership and management of the organizations, as well. That is why graduate courses in business often initially include a course or some discussion on organizational theory.

Organizational change should not be conducted for the sake of change. Organizational change efforts should be geared to improve the performance of organizations and the people in those organizations. Therefore, it's useful to have some understanding of what is meant by "performance" and the various methods to manage performance in organizations.

The past few decades have seen an explosion in the number of very useful tools to help change agents to effectively explore, understand and communicate about organizations, as well as to guide successful change in those organizations. Tools from systems theory and systems thinking especially are a major breakthrough. Even if the change agent is not an expert about systems theory and thinking, even a basic understanding can cultivate an entire new way of working.

The field of Organization Development is focused on improving the effectiveness of organizations and the people in those organizations. OD has a rich history of research and practice regarding change in organizations.

Your nature and the way you choose to work has significant impact on your client's organization, whether you know it or not. You cannot separate yourself from your client's organization, as if you are some kind of detached observer. You quickly become part of your client's system -- the way the people and processes in the organization work with each other on a recurring basis. Thus, it is critical that you have a good understanding of yourself, including your biases (we all have them), how you manage feedback and conflict, how you like to make decisions and solve problems, how you naturally view organizations, your skills as a consultant, etc.

Nowadays, with the complex challenges faced by organizations and the broad diversity of values, perspectives and opinions among the members of those organizations, it's vital that change agents work from a strong set of principles to ensure they operate in a highly effective and ethical manner.

There are several phrases regarding organizational change and development that look and sound a lot alike, but have different meanings. As a result of the prominence of the topic, there seems to be increasingly different interpretations of some of these phrases, while others are used interchangeably. Without at least some sense of the differences between these phrases, communications about organizational change and development can be increasingly vague, confusing and frustrating.

There are different overall types of organizational change, including planned versus unplanned, organization-wide versus change primarily to one part of the organization, incremental (slow, gradual change) versus transformational (radical, fundamental), etc.. Knowing which types of change you are doing helps all participants to retain scope and perspective during the many complexities and frequent frustrations during change.

Successful change efforts often include several key roles, including the initiator, champion, change agent, sponsor and leaders.

Organization-wide change in corporations should involve the Board of Directors. Whether their members are closely involved in the change or not, they should at least be aware of the change project and monitor if the results are being achieved or not.

As the change agent, you might be performing different roles during the project.

Appreciative Inquiry is a recent and powerful breakthrough in organizational change and development. It's based on the philosophy that "problems" are often caused as much by our perception of them as problems as by other influencing factors. The philosophy has spawned a strong movement that, in turn, has generated an increasing number of models, tools and tips, most of which seem to build from the positive perceptions (visions, fantasies, wishes and stories) of those involved in the change effort.

There are numerous well-organized approaches (or models) from which to manage a change effort. Some of the approaches have been around for many years -- we just haven't thought of them as such. For example, many organizations undertake strategic planning. The implementation of strategic planning, when done in a systematic, cyclical and explicit approach, is strategic management. Strategic management is also one model for ensuring the success of a change effort. The following links provide more perspectives on approaches to managing change. (Note that, with the maturation of the field of OD, there are now more strong opinions about which are change management approaches and which are not -- there seems to be no standard interpretation yet.)

Many people would agree that traditional models of organizational performance management are also models for managing change.

There is now a vast array of highly reflective articles about the nature of change.

A typical planned, systemic (and systematic) organizational development process often follows an overall action research approach (as described below). There are many variations of the action research approach, including by combining its various phases and/or splitting some into more phases. This section provides resources that are organized into one variation of the action research approach. Note that the more collaborative you are in working with members of the organization during the following process, the more likely the success of your overall change effort.

Phase 1: Clarifying Expectations and Roles for Change Process

This phase is sometimes called the "Contracting" and/or "Entry" phase. This phase is usually where the relationship between you (the initial change agent) and your client starts, whether you are an external or internal consultant. Experts assert that this phase is one of the most - if not the most - important phases in the organizational change process. Activities during this stage form the foundation for successful organizational change. The quality of how this phase is carried out usually is a strong indicator of how the project will go.

Phase 2: Joint Discovery to Identify Priorities for Change

The more collaborative the change agent is in working with members of the client's organization, the more likely that the change effort will be successful. Your client might not have the resources to fully participate in all aspects of this discovery activity -- the more participation they can muster, the better off your project will be.

Whether you are an external or internal change agent in this project, you and your client will work together during this phase to understand more about the overall priority of the change effort and how you all can effectively address it. It might be a major problem in the organization or an exciting vision to achieve. Together, you will collect information, analyze it to identify findings and conclusions, and then make recommendations from that information. Sometimes the data-collection effort is very quick, for example, facilitating a large planning meeting. Other times, the effort is more extensive, for example, evaluating an entire organization and developing a complete plan for change. The nature of discovery also depends on the philosophy of the change agent and client. For example, subscribers to the philosophy of Appreciative Inquiry (referenced above) might conduct discovery, not by digging into the number and causes of problems in the organization, but by conducting interviews to disover the visions and wishes of people in the organization.

Sometimes, people minimize the importance of - or altogether skip - this critical discovery phase, and start change management by articulating an ambitious and comprehensive vision for change. Many would argue that it is unethical to initiate a project for organizational change without fully examining (or discovering) the current situation in the client's organization. Focusing most of the change efforts on achieving a robust vision, without at least some careful discovery, often can be harmful to your client's organization because your project can end up dealing with symptoms of any current issues, rather than the root causes. Also, the project could end up pushing an exciting vision that, while initially inspiring and motivating to many, could be completely unrealistic to achieve -- especially if the organization already has many current, major issues to address. Therefore, when working to guide change in an organization that already is facing several significant issues, you are usually better off to start from where your client is at -- that usually means conducting an effective discovery to identify priorities for change.

One of the most powerful means to cultivate collaboration is by working with a project team. Besides, no change agent sees all aspects of the situation in the organization -- team members help to see more of those various aspects.

Phase 3: Joint Planning of Organizational Development Activities to Address Priorities

In the previous phase about discovery, you and your client conducted research, discovered various priorities that needed attention, generated recommendations to address those priorities, and shared your information with others, for example, in a feedback meeting. Part of that meeting included discussions - and, hopefully, decisions - about the overall mutual recommendations that your client should follow to in order address the priorities that were identified by you and your client during your discovery. This phase is focused on further clarifying those recommendations, along with developing them into various action plans. The various plans are sometimes integrated into an overall change management plan. Thus, the early activities in this phase often overlap with, and are a continuation of, the activities near the end of the earlier discovery phase. This is true whether you are an external or internal consultant. Action plans together can now provide a clear and realistic vision for change. They provide the "roadmap" for managing the transition from the present state to the desired future state.

Development of the various action plans is often an enlightening experience for your client as members of their organization begin to realize a more systematic approach to their planning and day-to-day activities. As with other activities during change management, plans can vary widely in how they are developed. Some plans are very comprehensive and systematic (often the best form used for successful change). Others are comprised of diverse sections that are expected to somehow integrate with each other. Subscribers to the philosophy of Appreciative Inquiry (referenced above) might do planning by building on past positive outcomes and on the strengths of members of the organization.

Phase 4: Change Management and Joint Evaluation

During this phase, emphasis is on sustaining and evaluating the change effort, including by addressing resistance that arises from members of the organization -- and sometimes in the change agent, as well.

Evaluation occurs both to the quality of implementation of plans so far during the project and also regarding the extent of achievement of desired results from the project. Results might be whether certain indicators of success have been achieved, all issues have been addressed, a vision of success has been achieved, action plans have been implemented and/or leaders in the organization agree the project has been successful.

As part of the final evaluation, you might redo some of the assessments that you used during the discovery phase in order to measure the difference made by the project.

During this phase, if the implementation of the plans gets stalled for a long time, for example, many months, then you might cycle back to an earlier phase in the process in order to update and restart the change management project. Projects can get stuck for a variety of reasons, e.g., if the overall situation changes (there suddenly are new and other priorities in the client's organization), people succumb to burnout, key people leave the organization, the relationship between the consultant and client changes, or people refuse to implement action plans.

(Many times, this activity is defined as a separate phase in the project plan.) These activities are very important to address, even if all participants agree that the project has been successful and no further activities are needed. Project termination activities recognize key learnings from the project, acknowledge the client's development, and identify next steps for you and your client. They also help to avoid "project creep" where the project never ends because the requirements for success keep expanding.

http://managementhelp.org/org_chng/org_chng.htm

MIS2 - Assignment 4

2009-12-17T09:01:00.001+08:00

You were invited by the university president to prepare an IS plan for the university, discuss what are the steps in order to expedite the implementation of the IS Plan.

Strategic information systems planning (SISP) is the process of identifying a portfolio of computer-based applications that will assist an organization in executing its business plans and realizing its business. Because information technology is playing an increasingly strategic role in today's highly competitive business world, the need for effective strategic information systems planning (SISP) has become more and more critical. SISP can contribute substantially to an organization. It can bring IS users and IS professionals together and establish a mutual understanding of the value of information systems and the problems associated with them. It also can help the organization develop priorities for information systems development by ranking such systems in terms of their efficiency, effectiveness, and strategic value. In that manner, it helps the organization identify its portfolio of planned computer-based applications, which both align well with corporate strategy and can create an advantage over competitors. Although much SISP research has been conducted over the past few years, the same types of problems repeatedly appear, thus suggesting that SISP has not improved much in practice. A gap continues to separate the plans and expectations of the developers of an IS strategy from the actual outcome of the strategy. Often, only a few of the systems in the strategy are implemented and some of them take substantially longer than anticipated. A survey of four Norwegian organizations found that only 42% of the projects in the formal IT strategy had been implemented after five years. This lack of implementation not only leaves firms dissatisfied with their current SISP, but also creates problems establishing and maintaining priorities in future SISP.

The failure to execute SISP effectively can cause an organization to lose competitive advantage. Hence it is no surprise that both corporate general managers and IS executives have viewed improved SISP as a key issue facing them. Observers have suggested many practices to make SISP more successful. Categorizations of practices, case studies, and surveys have offered a broad look at SISP practices across large sets of organizations in different countries. The objective of the study described here was to apply the findings from such research to the problem of the failure to implement the recommendations of a SISP study and thus to identify a comprehensive and parsimonious set of factors of practices that predict implementation. The importance of SISP to both general and IS management and its challenging nature make this research issue significant. SISP has been defined as "the process of identifying a portfolio of computer-based applications that will assist an organization in executing its business plans and realizing its business goals". It also includes the specification of databases and systems to support those applications. It embraces the selection of rather prosaic applications which would best fill the organization's current and future needs, but it also entails the discovery of new applications with the potential to create an advantage over competitors. It has been viewed as comprised of six broad process dimensions drawn from strategic management - comprehensiveness, formalization, focus, flow, participation, and consistency and also as comprised of content aspects of business domain analysis and technology domain analysis, and process aspects of top management involvement, user involvement, quality of support mechanisms, and use of a steering committee.

To perform SISP, an organization typically conducts a multi-phase study. One observer summarized such a SISP study in terms of five phases. The first phase, strategic awareness, included the identification of strategic goals, identification of business and IT systems, and the definition of planning process objectives. The second, situation analysis, comprised the analysis of business systems, organizational systems, IT systems, and the external business and IT environments. The third, strategy conception, included the scanning of the future, the identification of alternative scenarios, and scenario elaboration. Strategy formulation, the fourth, contained the formulation of the business architecture, the formulation of the IT architecture, the formulation of organizational solutions, and synthesis and prioritization. Finally, strategy implementation planning comprised the definition of action plan elements for developing the applications in the plan, the elaboration of the action plan, the evaluation of the action plan, and the definition of follow-up and control procedures. SISP has also been described as a system comprised of inputs, processing, and outputs. Objectives, resources, and information serve as inputs and they influence a specific, predetermined planning process. Elements both within the organization's internal environment and beyond its control (i.e., in its external environment) also influence the process. The process itself consists
of a set of practices that result in an IT strategy whose major component is recommendations for the portfolio of new information systems. However, organizations often fail to develop the systems in the strategy. Such failure to implement can be seen as a function of the planning process, and more specifically, its practices.

SISP has evolved over time. It initially was conducted as a fairly formal and comprehensive activity, although nowadays such an administrative approach is generally not very successful. Competitive analysis and advantage later became a major objective. As organizations began to understand that IT could improve internal efficiencies, SISP began to emphasize business process reengineering. More recently, observers have recognized the importance of SISP for organizational learning. SISP generates an enormous amount of information about an organization, and its internal and external environment, and this information must be organized, managed, and understood. For example, by emphasizing measurable criteria for judging the merits and risks of proposed projects, and by creating concrete procedures for measuring the effectiveness of the plan, organizations learn from their SISP. Thus, SISP can be viewed as having evolved into a knowledge management activity. The purpose of SISP is to create a plan of recommendations that fulfill management objectives and thus benefit the organization. SISP lays the groundwork for implementation of the plan. Implementation is essential because it enables the organization to achieve SISP benefits.

Although the extent of plan implementation is positively associated to the extent of SISP, implementation of the plan is not assured and the failure to implement is common. In fact, a majority of senior IS executives have classified failure to translate goals and strategies into action plans as a major IS planning problem. Going from strategies to action plans is, however, a necessity for implementing IT strategies. Over 55% of senior IS executives have classified the "difficulty to secure top management commitment to implement the IS plan" and over 50% have classified "ignoring the IS plan once it has been developed" as major IS planning problems. Ignoring implementation issues or lack of support for information technology architecture and duration of SISP has also been suggested as the causes of the low rate of SISP implementation. In one study of SISP, less than a quarter of the recommended projects had been initiated after over half the planning horizon had passed. This suggests that organizations were not implementing their plan very vigorously. During the same horizon, 38% of all initiated projects had not been identified in the SISP plan. This also suggests that organizations were not following their plan. Finally, the same study found that satisfaction with plan implementation was significantly lower than satisfaction with the input, process, and resources used during the process.

Several reasons may explain the failure to implement the SISP plan. The duration of IS development is so long that it provides time for the business strategy to change in response to external and internal environmental change, and thus forces IS priorities to change. Users politic to raise the priorities of their projects and bypass the prioritization scheme established in the plan. The organization underestimates the cost of projects and runs out of resources. Long and short-term plans are poorly integrated. Government legislation forces changes in priorities. Groups within the IS department set their own priorities. Management raises the priority of new proposals with higher return on investment. Insufficiently high-level managers participate in SISP. In summary, management does not focus its SISP efforts on implementation issues. A Norwegian study derived ten predictor constructs of implementation from 35 SISP practices. The predictors were intended to reflect the content of the IT strategy rather than practices independent of the final plan. A full multiple regression with all ten showed a significant overall relationship between the predictors and the IT strategy implementation, but no individual one was significant. Stepwise multiple regression, however, showed that two had significant coefficients. "Responsibility for the implementation" had the highest explanatory power, and "user involvement during the implementation" had the second highest (p<.05). Perhaps surprisingly, the other eight plan characteristics - resources needed for implementation, analysis of the organization, anticipated changes in the external environment, solutions to potential resistance during implementation, information technology to be implemented, projects' relevance to the business plan, management support for the implementation, and clear presentation of implementation issues - were not significant implementation predictors. Regardless of the two predictors, the lack of implementation still often leaves firms dissatisfied with their SISP efforts.

The current research used a list of recommended planning practices presumed to produce a more accurate, convincing, and stable plan, a plan less vulnerable to the political and environmental changes that can alter the priorities of its recommendations. However, research has not yet examined the relationship of these practices to implementation. The implications of the research for managers, who want to improve the likelihood of SISP implementation based on the study's findings, are simple and succinct: Deliberately plan for implementation by identifying specific actions to accomplish it and incorporate them in the plan itself. More specifically, identify the resources and actions needed to implement new applications development and maintenance tools. Identify the MIS department's actions necessary to expedite adoption of the plan. Prepare a plan for migrating to new applications including key projects and their order of implementation. Specify actions needed to implement the proposed architecture. Evaluate the costs, benefits and risks of each proposed project to determine its priority. Complete the study in a reasonable period of time. The current research suggests that these practices, grouped together, are the strongest predictors of implementation. Also, control the progress of the SISP study and the implementation of the plan with feedback and guidance. Resolve conflict and bring about agreement on priorities quickly.

To improve the overall value of the SISP study, focus on trends, competitors, the impact of information technology, and focus on tying these issues to strategic business planning. Also, it is important to ensure the reputation of the planning team. However, do not expect these practices necessarily to lead to implementation. Analyze organization needs. However, do so quickly and not to the extent that the analysis impedes plan implementation, as this research suggested it can. Finally, managers should assess each practice regardless of whether it predicts implementation or not. Each practice might play a key role in the implementation of a particular plan. Hence each one merits careful consideration in the context of each individual organization. Different circumstances could render some - even those that do not predict implementation in a large sample - both essential and effective for individual organizations. The research examined the planning practices expected to predict the implementation of SISP plans. It found that the Migration factor predicted greater implementation using two different dependent variables, whereas Management Control predicted it with only one dependent variable, Study Focus and Team Member Selection Criteria did not predict it with either, and Needs predicted less implementation with one variable. The lack of consistent prediction of implementation may suggest practices do not play as great a role as anticipated in implementation. However, such findings are consistent with previous research that showed that only two practices, "responsibility for the implementation" and "user involvement during the implementation" out of ten predicted it using a similar, multi-item, scaled dependent variable. Combined, the two studies suggest that although many practices may be valuable, their direct impact on implementation itself is limited. This research speculated why such practices might not predict implementation, but future research should look more closely to assess the reasons.

While diligent efforts were made to ensure that this research considered all possible planning practices, more practices may exist and hence further research with a larger number of practices might be desirable. However, a larger sample of subjects would also be necessary. With a larger sample, the more powerful analytic technique of structural equation modeling would be possible; the current sample had insufficient subjects for such analysis. Some of the prescriptions correlated negatively with the implementation
measure. Future research might reword them. For example, "The SISP study used experienced external consultants" might be changed to "The SISP study avoided the use of experienced external consultants," or perhaps simply "The SISP study avoided the use of external consultants." The research assessed implementation success by regressing practices on two measures of implementation. One measure was perceptual and the other was more objective. The results were not completely consistent. The differences suggest the importance of multiple measures of variables and imply that they should be used more frequently in future research. One of those measures was the ratio of the number of implemented projects to the total recommended. Previous research has used that ratio. However, the ratio does not take into account project size. A firm that implements many minor projects would be deemed more successful than one that implements a few major projects, although in fact, it might or might not actually be more successful. In a sense the ratio is consistent with popular advice to break large projects into smaller ones to facilitate their implementation. Nevertheless, future research should consider project size in the evaluation process. Researchers could also ask about implementation success in different ways. One alternative approach would be to ask planners directly to assess how much each practice contributed to implementation.

Planners' perceptions played a major role in this study. Information systems department professionals are probably not the only parties knowledgeable about SISP. Hence, future researchers should also seek the views of business managers and other participants from outside the MIS function. Correlation and regression also played an important role in this study. Correlation and regression are not causation. Perhaps more in-depth studies of SISP would facilitate a better assessment of causality. Finally, the research predicted that the analysis of organization needs would presage the implementation of plans. Instead, it found that such analysis might impede implementation. Naturally some level of such analysis is necessary. Hence, future research should seek to determine this level. In reference to such an appropriate level of analysis, information systems managers speak informally of "analysis paralysis" - the excessive study of a problem and resultant delay in beginning to solve it. Perhaps the greatest need for research is thus to determine when enough analysis is complete so as to begin implementing and to avoid analysis paralysis. In other words, future research should ask, how much analysis is necessary to facilitate SISP implementation and how much more analysis will begin to impede it? Strategic information systems planning has evolved over time from a fairly formal and comprehensive to a knowledge management activity. It continues to challenge information systems managers and other executives. Planning is expensive and the failure to implement a SISP plan wastes valuable resources. By focusing on the actions necessary for implementation, the chances of
successfully doing so can likely be increased.

Strategic information system planning (SlSP) is the process of deciding the objectives for organizational computing and identifying potential computer applications which the organization should implement. Most information systems today are affected by one or more
regulations, and some would argue that industries as a whole are over-regulated. That is particularly true in industries such as banking and insurance. There are many valid reasons for regulations, especially when it comes to information systems. A significant portion of business processes and activities in most organizations depends completely on information systems, and could not function without them. The vast amount of information generated by information systems is used by publicly-traded companies to report to authorities and regulatory agents. Additionally, decision-makers and stakeholders use financial reports published by organizations to make business decisions about investments, mergers, and acquisitions. Internal and IT auditors are in a unique professional position. Their traditional and primary duty is to inspect and verify that business processes and practices are carried out as required by various regulatory bodies. Additionally, the main output of an audit activity is an audit report that describes risks, control deficiencies, and breach of existing controls. Auditors also can assume the role of trusted advisor and suggest ways to improve existing processes and add new processes, tools, and best practices that improve performance and reduce operating costs. This article presents some ways in which internal and IT auditors can bring tremendous value to organizations in the course of conducting an audit.

In spite of the overwhelming number of existing regulations, there is strong evidence that a tidal wave of new regulations will emerge in the next 12 to 18 months. The new regulations will ensure that better controls are applied as an oversight on activities performed by particular groups within an organization. One thing IT departments can do now is use this grace period to prepare for complying with new regulations. A paradigm shift and thinking outside of the box regarding current practices will help in accepting a different approach to complying with regulation requirements. For example, the notion that regulation is not the chief information officer’s or IT department’s responsibility and the view that regulation requirements are not part of system requirements no longer apply. Instead, IT departments should accept the involvement of stakeholders and subject matter experts (SMEs) within the organization as critical and necessary for successful implementation of regulation requirements in information systems. The following represents the primary key players and SMEs who should be directly involved in complying with regulations requirements throughout the life cycle of the information system: Chief compliance officer, Chief risk officer, Information system manager, IT project manager, Information security manager, and Quality assurance manager. Internal and IT auditors cannot and should not take an active part in the design or implementation of regulation requirements in order to prevent potential conflicts of interest in future audits.

A key point of this new approach is that regulation requirements are an integral part of the set of requirements that are defined for an information system (functional, technical, performance, security) and therefore: Regulation requirements must be documented and managed along with all other requirements. (The use of a requirements management tool is recommended.); Regulation requirements must be translated into tasks and activities to be performed throughout the life cycle of the information system and clearly defined in all project work plans; and the test plan for information systems must include specific tests to ensure effective and accurate implementation of regulation requirements. Internal and IT auditors can bring an important added value to organizations by raising the level of awareness among managers and stakeholders of the benefits to be gained by adopting a new approach to meeting regulation requirements. Auditors can express such opinions in audit reports and during audit closing meetings as general comments and recommendations. “Information System Life Cycle Phases” represents a typical life cycle model for information system development, implementation, and sustainability. The model includes some key activities that are related to regulation requirements in each phase of the life cycle. The activities relating to regulation requirements development, testing, and implementation can be easily incorporated into other life cycle models. There is no need to invent a new methodology for information systems development or to alter existing methodologies drastically. Instead, organizations should change and upgrade concepts that are currently used by IT departments. The involvement and active participation of SMEs is essential to successful implementation of this approach.

The adoption and implementation of the proposed approach to complying with regulation requirements consist 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.

An experienced auditor can suggest and recommend improvements to existing processes and recommend new tools and methods for consideration. Furthermore, over time this approach can improve work relationships between the auditor and audited parties in the organization. For a long time relationship between information system functions and corporate strategy was not of much interest to Top Management of firms. Information Systems were thought to be synonymous with corporate data processing and treated as some back-room operation in support of day-to-day mundane tasks . In the 80’s and 90’s, however, there has been a growing realization of the need to make information systems of strategic importance to an organization. Consequently, strategic information systems planning (SISP) is a critical issue. In many industry surveys, improved SISP is often mentioned as the most serious challenge facing IS managers. 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 in his recent article has argued that 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. The same article emphasizes the need to note that SISP is a management function and not a technical one. This is consistent with the earlier distinction between the older data processing views and the modern strategic importance view of Information Systems. SISP thus is used to identify the best targets for purchasing and installing new management information systems and help an organization maximize the return on its information technology investment. A portfolio of computer-based applications is identified that will assist an organization in executing its business plans and realize its business goals. There is a growing realization that the application of information technology (IT) to a firm’s strategic activities has been one of the most common and effective ways to improve business performance. The paper reviews the existing methodologies for SISP in an attempt to answer the critical question: how to move ahead and further improve the effectiveness of strategic planning for information-based enterprises? In particular, we examine their capacity for driving the development of corporate information systems ensuing the planning, and their potential to support economic evaluations of information systems investments. Strategic Information Systems Planning in the present SIS era is not an easy task because such a process is deeply embedded in business processes. These systems need to cater to the strategic demands of organizations, i.e., serving the business goals and creating competitive advantage as well as meeting their data processing and MIS needs. The key point here is that organizations have to plan for information systems not merely as tools for cutting costs but as means to adding value. The magnitude of this change in perspective of IS/IT’s role in organizations is highlighted in a Business Week article, ‘The Technology Payoff’.

According to this article, throughout the 1980s US businesses invested a staggering $1 trillion in the information technology. This huge investment did not result in a commensurate productivity gain - overall national productivity rose at a 1% annual rate compared with nearly 5% in Japan. Using the information technology merely to automate routine tasks without altering the business processes is identified as the cause of the above productivity paradox. As IT is used to support breakthrough ideas in business processes, essentially supporting direct value adding activities instead of merely cost saving, it has resulted in major productivity gains. In 1992, productivity rose nearly 3% and the corporate profits went up sharply. According to an MIT study quoted in the above article,
the return on investment in information systems averaged 54% for manufacturing and 68% for all businesses surveyed. This impact of information technology on re-defining, re-engineering businesses is likely to continue and it is expected that information technology will play increasingly important roles in future. For example, Pant point out that the emerging vision of virtual corporations will become a reality only if it is rooted in new visionary information technology. It is information technology alone which will carve multiple ‘virtual
corporations’ simultaneously out of the same physical resources and adapt them without having to change the actual organizations. Thus, it is obvious that information technology has indeed come a long way in the SIS era, offering unprecedented possibilities, which, if not cashed on, would turn into unprecedented risks. As Keen has morbidly but realistically pointed out that organizations not planning for strategic information systems may fail to spot the business implications of competitors’ use of information technology until it is too late for them to react. In situations like this, when information technology changes the basics of competition in an industry, 50% of the companies in that industry disappear within ten years. The task of strategic information systems planning is difficult and often time organizations do not know how to do it. Strategic information systems planning is a major change for organizations, from planning for information systems based on users’ demands to those based on business strategy.

Also strategic information systems planning changes the planning characteristics in major ways. For example, the time horizon for planning changes from 1 year to 3 years or more and development plans are driven by current and future business needs rather than incremental user needs. Increase in the time horizon is a factor which results in poor response from the top management to the strategic information systems planning process as it is difficult to hold their attention for such a long period. Other questions associated with strategic information systems planning are related to the scope of the planning study, the focus of the planning exercise – corporate organization vs. strategic business unit, number of studies and their sequence, choosing a strategic information
systems planning methodology or developing one if none is suitable, targets of planning process and deliverables. Because of the complexity of the strategic information systems planning process and uniqueness of each organization, there is no one best way to tackle it.

References:

http://www.allbusiness.com/technology/3502724-1.html
http://viu.eng.rpi.edu/publications/strpaper.pdf
http://www.theiia.org/intAuditor/itaudit/2009-articles/the-impact-of-regulation-on-information-system-planning/