Systems Analyst Resume

John D. Bradshaw III
Jdbradshaw_3@yahoo.com
10 Mine Hill Drive
North Little Rock, AR 72118

EXPERIENCE

System Administrator

Baptist Health Schools, Little Rock, AR (June 2006 – Present)

• Gathered requirements for the development of www.bhslr.edu
  
• Diagramed the website layout and created mockups to aid programmers in the development of the website.
• Continually works to develop functionality of the website by meeting with management to determine how to best utilize the website to help current students

• Reviewed available e-mail systems on the market and implemented e-mail system for students at Baptist Health Schools.
• Created documentation and training materials for e-mail users.
• Works with vendor to resolve system issues as needed.

• Developed interactive form that allows users to fill out information regarding withdrawn students and is sent automatically to different departments within Baptist Health.
• Interviewed users to determine what functionality they needed from the form.
• Designed the form to prevent errors in data entry and to minimize the amount of data entry required by users.

Computer Operator III

Fidelity Information Services, Little Rock, AR (November 2004 – May 2006)

• Monitored the production environment in Client/Server Operations.
• Resolved server issues and responded to client requests.
• Coordinated with developers and client support teams to maintain optimal functionality of servers.

Web Design and Development Internship

Harding Academy, Searcy, AR (Spring 2004)

• Gathered website requirements from client.
• Worked on a team to develop and launch a new website.
• Composed user documentation and trained staff to maintain the website upon completion of the project.

EDUCATION

Bachelor of Business Administration in Management Information Systems
Harding University, Searcy, Arkansas
May 2004

SKILLS

Experience in Microsoft Access, Excel, Project, Visio, Word, Powerpoint, Adobe Dreamweaver CS3, Adobe Designer, Adobe Professional, HTML,Visual Studio.Net, Java, SQL, Active Directory, Unix, AS400, Windows NT/2000, XP, Vista

Thoughts on Chapter 6

Chapter 6 of our book discussed different types of requirements modeling used in development. The chapter specifically emphasized use case diagrams, use case descriptions, activity diagrams, system sequence diagrams and statechart diagrams. The different diagrams are used to represent different aspects of the system with varying levels of detail. Another purpose of using multiple diagrams and descriptions is so that users and other non-technical stakeholders can have multiple perspectives for understanding how the analysts intend the system to function. The variety of diagrams and descriptions helps cater to different learning styles such as drawings for visual learners or highly detailed written descriptions for users who learn by verbal or written communication.

Learning about the different diagrams and their purposes led me to evaluate which diagrams prove to be the most effective for myself in conveying information. I personally think that the verbal/written descriptions found in the fully developed use case description would benefit me most in understanding the purpose of a specific use case. I liked the high level of detail found in the use case description and I feel like it specifically states information for users that otherwise could be neglected or misunderstood in a drawing diagram. While I think I prefer written descriptions, I also found diagrams to be very beneficial as well especially when used for a snapshot of a simple process or a particular process that would be difficult to describe in words. I believe I would prefer a detailed description of complex use case when applicable rather then solely a diagram but I definitely see the how diagrams are beneficial. The use case and activity diagrams were my favorite type of diagrams we have studied. I feel that they are very direct in describing what is occurring and could be interpreted fairly easily by all levels of users. I found the statechart to be the most confusing diagram type so far. Simple statecharts make sense and are easy to understand but I have found that more involved statecharts are difficult for me to draw accurately. I feel I have done a fairly good job at interpreting the statecharts we have gone over so far but I do not have the same degree of confidence in interpreting them as I do for activity or use case diagrams.

Certain diagrams we have studied have specific purposes and in some instances may be required. I believe it is important though to try to understand the different learning styles users or stakeholders may have and when possible adapt diagrams and descriptions accordingly. Creating diagrams and descriptions in way the user understands helps them to better communicate how they want the system to operate and can in turn save the analyst time in the long run.

Tech Topic - Inside Chrome: Google's New Browser

Google’s recent launch of their new browser Chrome has generated a lot of interest from those wondering how it will fare against the established browsers that currently dominate the market. Google has had internal discussions for years about creating their own browser, but any specific details about its development have been kept under wraps until recently. The prior lack of information regarding Chrome has led to many questions such as: How is Google going to separate Chrome from other browsers currently on the market? What kind of functional and nonfunctional requirements did Google establish for Chrome? Is Chrome designed any differently than other browsers? The October 2008 issue of Wired Magazine addresses these questions and provides a behind the scenes look at Google’s developers as they prepare for the release of Chrome.

Google has been looking into building their own browser since 2001, however their CEO did not believe it was the right time for Google to compete against other browsers at that point. Google did decide to assemble a browser team for the purposes of contributing to the open source browser Firefox. In 2006 the Google Firefox team started to revisit the idea of creating a Google browser. If the team was going to create a browser, they wanted to start from scratch in order to utilize the internet in a way that current browsers could not. Google understood that the internet had evolved and browsing had become more complex since Internet Explorer and Firefox were first developed. These changes were evident in functions such as spreadsheets and databases management that were previously only accessed from a user’s desktop but can now be utilized online. These changes spurred Google to build its browser from the ground up so that it could be used for cloud computing rather then just a standard browser for delivering content.

When Google evaluated the requirements they wanted to include in Chrome, they emphasized a few key functional and non-functional requirements. One of the important non-functional requirements Google wanted to implement into Chrome was a multiprocessor architecture. Multiprocessor architecture is the aspect of a computer system that helps it continue to operate when an application crashes. Google wanted to extend this idea to their browser so that if one tab crashes it does not crash the entire browser and keeps the remaining tabs active. Each tab in Chrome has its own memory and its own copy of the global data structure. This allows issues to stay contained within that particular tab and helps contain memory usage of the browser. The multiprocessor architecture has also led Google to implement a Task Manager within Chrome much like Windows utilizes. The Task Manager feature enables users to determine which web pages are using the most memory and can identify any memory leaks that may be occurring within a particular tab. Google extended its efforts to isolate tabs for security purposes by purchasing the software security firm GreenBorder Technologies in 2007. GreenBorder Technologies was purchased with the specific purpose of creating virtual sessions for the tabs within Chrome. These individual virtual sessions or “sandboxes” as referred by Google are used in each tab to prevent malware from disrupting other tabs or any other data on the user’s computer. Enabling a sandbox for each tab is important because it not only improves the stability of Chrome but also improves the security of the browser as well.

Another nonfunctional requirement Google wanted to emphasize was to make Chrome fast. Google began the process of establishing the speed of its browser by choosing which rendering engine to use. The rendering engine is the software that converts a websites code into a viewable page. Google determined WebKit was the fastest open source rendering engine available which is utilized by Apple’s Safari browser. Google also wanted to ensure that Chrome’s JavaScript engine was state of the art in order for Chrome to be able to run web based applications effectively. Google contacted Lars Bak, a Danish computer scientist who is an expert at designing virtual machines, to create the JavaScript engine for Chrome. When Lars Bak and his team completed the JavaScript engine for Google it was benchmarked at ten times faster then Safari or Firefox and fifty-six times faster then Internet Explorer 7. Google believes that this type of speed combined with the fact that Chrome is open source will encourage developers to create new and exciting web applications which will further the growth of the internet even to the point that the browser will become the equivalent of an operating system.

The key functional requirements included in Chrome are its navigational abilities, the ability to move tabs to different windows and its ability to allow the user to either archive browsing history or operate in incognito mode for private surfing. Chrome differentiates its navigational abilities from other browsers by introducing a feature called the “omnibox”. The omnibox, which is a combination of an address bar and search box, allows users to enter the terms they would like to search for or choose to enter a specific website address rather then having a separate box for each navigational option as in other browsers. Also when a new tab is opened, rather then displaying the user’s home page or a blank tab, the user is presented with a page that displays the individual’s nine most visited pages. This feature was added to Chrome to help anticipate the user’s needs by displaying pages they will likely want to visit. Chrome also allows users to move an existing tab to another window, which is a feature not currently found on other browsers. The ability to move tabs creates new implications for web applications, for example Google’s Gmail can be placed into its own window and can be designated as an “app shortcut”. When the user chooses this option the browser buttons, tabs and other features that give the appearance of a browser disappear and it looks similar to a standard desktop application. The ability for the user to transform the appearance of a web application from a standard looking webpage to one that looks like a desktop application demonstrates the type of capabilities Google had in mind when designing a browser for cloud computing. Google, primarily known for its search engine abilities, implemented a feature that allows users of its browser to search their website history which enables people to quickly find a site they have visited previously. Conversely, Chrome also allows users to surf the internet in what they call incognito mode which is a read only mode where bookmarks are accessible but none of the browsing history is kept and cookies are deleted as soon as the window is closed. These two surfing modes are key functional requirements aimed at getting all types of individuals to use Chrome as their primary browser.

When developing the user interface, Google wanted to keep it clean and very simple. The goal for developing the interface was for the user to not even realize they were using a browser. The team at Google wanted to browser to be functional but not be bogged down by buttons and options. They began the process of adding buttons and features by eliminating everything and then determining what was actually needed. Essential buttons such as the forward and back buttons were kept but extraneous features, such as the browser status bar, were eliminated.
The testing process for Chrome was greatly aided by Google’s web crawling infrastructure and in-house expertise. When a new build of Chrome would become available, it was tested by a “Chrome-bot”, which could access upward of a million web pages and was able to provide information on bugs found within Chrome. The ability to locate bugs via the “Chrome-bot” saved time and money in the development process, rather then waiting for an external beta release to discover certain types of bugs. While Google has tested Chrome extensively, they believe that by making Chrome open source it will encourage further testing by developers around the world. Google believes this type of collaborative effort will help make Chrome better than Internet Explorer.

Google has taken drastic steps in the creation of Chrome to differentiate it from Internet Explorer, Firefox and Safari and to promote growth in the area of cloud computing. The stripped down user interface and unique features may not initially attract the average user, but it will likely be embraced by web developers and tech enthusiast. As cloud computing increases among the general population Chrome will likely grow as a major competitor in the browser market. Google has shown its ability to revolutionize the way people use search engines and locate information despite competition from Microsoft, Yahoo and others. Now Google is hoping to provide the same change to the way people view and use their browser.

Levy, S. (October 2008). Inside Chrome: The Secret Project to Crush IE and Remake the Web. Wired Magazine,Issue 16.10
http://www.wired.com/techbiz/it/magazine/16-10/mf_chrome?currentPage=all

An example of what not to do...

The first chapter in our book discussed different information gathering techniques a systems analysts may use when developing a system. I found this topic interesting because it reminded me of an experience my wife had at work in dealing with the development of a system and her lack of interaction with the system analysts that were involved in the project. My wife works for Dillard’s at their corporate offices in their private label division which oversees Dillard’s in-house brands that are sold in their stores. The system they were using for transferring clothing specifications and details to factories was partly developed in-house while another component they used was purchased from a vendor. The IT department decided to build this other component in-house so that they would no longer need to pay for the vendor software. When gathering the requirements and learning how the existing system worked the IT department relied only on information from my wife’s manager who does not even use the system. She said they did not interview her or others on her team to see how they actually interacted with the system or to determine what functionality they needed from the system. When they released the program it did not have the features the users needed which resulted in my wife’s team being frustrated and less productive. The users were then required to report their issues and complaints to their manager who then relayed the issues to the programmers. I do not know if this process for handling issues was a mandate from the IT department or my wife’s manager but it made the process of getting the system correct even more tedious. The programmers were able to eventually get the program to where it was useable but still had multiple issues. A year after the program was launched the IT management decided to meet with the users and see how they use the program on a daily basis and discuss the issues they have with the software. During the meeting the IT department became aware of software features that were not needed while discovering features that the users wanted but were left out. This meeting with the users yielded the greatest amount of progress in getting the system to meet its intended purpose but it should have been held prior to the development of the system.

I thought this real life situation provided a good example of how important it is to truly understand the business processes of a department or company before developing a system. This example also demonstrates the need for working closely with the individuals who will be using the system and getting feedback from them throughout the development process. The lack of collecting information on the front end resulted in a loss of productivity and an increase of work after the software was initially released. I do not know the entire preparation process the IT department did prior to developing the software but I do know that they did not do an adequate job of gathering information from the users or understanding the business needs of the department.

More Coming Soon...

This blog is for class MGMT 7307 Systems Analysis & Design Methods.