Lindstrom 1 Nathan W.

Lindstrom Professor Jebaraj Systems Analysis and Design 1 October 2010

Information Systems

Jaxtr, Inc. was a small technology startup that was growing rapidly within the Internet telecommunications space. In order to keep ahead of its competitors and continue to grow its user base, its product offering had to rapidly and continually evolve. This meant its developers were making constant changes to the codebase, and production releases occurred on a very frequent basis of three to four times per week. Jaxtr soon discovered that it faced a challenge: as the code grew in complexity and more developers were hired, communication was breaking down and the incident rate of code defects (bugs) was skyrocketing, all due to the lack of a particular information system for use by the engineering group. In their early days when Jaxtr only employed a handful of developers, communication via email and spoken word was sufficient for aligning priorities and keeping track of who was working on what. But as the company expanded, this informal system broke down in two key areas:

Lindstrom 2 1. Communication: As more and more people sent email, individual developers become overwhelmed by the flood of information and often conflicting directives. Additionally, people who might have had valuable information on a given topic were not guaranteed to be copied on relevant emails, leading to conflict and further confusion. 2. Knowledge: When one developer solved a particular problem, he might send an email to some of his fellow developers with information that they could use in the future. But often when a developer came up against the same issue, or a close variation, he would either lack the email that contained a solution, not even know it existed, or be simply unable to locate it among the thousands of email messages he already had. As a result, critical know-how and other kinds of knowledge were being lost. 3. Process: A critical step of a successful production release is the code freeze; and as there was not a uniform tool in place to facilitate this, code freezes were haphazard events that often occurred without sufficient notice (a further communications challenge) which would lead to important code changes being omitted from a release, or being included prematurely, thereby leading to more code defects (bugs). As the companys systems analyst, I was tasked by management to come up with a solution to these issues. I began by identifying the system owner (the Director of IT) and the system users (the developers within the engineering team, and their manager, the Director of Engineering.) I worked with the system owner to establish a budget for the project, covering both the software and hardware for the solution. I met with several stakeholders from within the engineering team to ascertain their concerns and needs. While the system owner was chiefly concerned with cost (both upfront and ongoing maintenance), the system users were concerned with features.

Lindstrom 3 Of course, within the system users group, the features they focused on varied according to their own roles: developers wanted a ticketing system that allowed for easy updating, powerful search features, and which would show code commit details in line with their comments; while the managers wanted the ability to organize tickets by software component, a dashboard to view who was working on what, and the ability to extract meaningful statistics like average bug timeto-resolution. Based on the system users requirements and working within the constraints set forth by the system owner, I acted in the role of a system designer by developing several alternatives and documented the pros and cons of each. Ultimately a popular COTS solution made by Atlassian (JIRA plus FishEye) was chosen. Once I fulfilled the role of system builder by provisioning the servers that hosted JIRA and FishEye, and installed the products, I then worked to configure the software to best meet the needs of the system users. This process took several weeks, and approximately followed the Deming Cycle by iterating through the following until most of the users were happy with the state of the system: Plan: By working closely with the system users, I established the objectives for process changes within JIRA and FishEye necessary for the delivery of the desired results. y y Do: I then implemented the new processes within JIRA and FishEye. Check: I measured the success of the new processes by asking the system users to compare the results against what they expected in order to ascertain any differences.

Lindstrom 4 y Act: By analyzing the differences I was able to determine their cause, which in turn prompted a new PDCA cycle to address further refining a process which, from the perspective of a system user, still needed improvement. The end result was a customized turnkey solution built on COTS software that encouraged end user alignment with clearly defined development and documentation processes, preserved critical business knowledge in a format that was easily accessible, and facilitated clear lines of communication within every level of the engineering group.

Lindstrom 5 Works Cited Whitten, Jeffrey, and Lonnie Bentley. Systems Analysis and Design Methods. New York: McGraw-Hill, 2007.