Wall-e and 9 movie
-
Watch at least two of the following movies:
• Make a comprehensive reaction paper for the two movies in no less than
300 words each.
• Make a comparative ...
15 years ago
Friday, February 5, 2010
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.
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.
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.
Saturday, January 30, 2010
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
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
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
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
Friday, December 18, 2009
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):
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:
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:
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:
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:
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 :-
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) : -
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:
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
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.
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
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
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
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)
;;
Subscribe to:
Posts (Atom)
