Tag Archive for: DevOps

The Jama Support Community is a forum for Jama Software users to interact and collaborate with other users and with Jama support engineers. It’s full of resources for everyone from novices to masters, including tutorials and webinars, help guides and FAQs, feature requests and announcements and a robust knowledge base. For today’s post, we spoke with one of our Jama Support Community power users — frequent contributors with great questions and powerful insights into using Jama — about how their organization uses Jama and the value they’ve seen from the Support Community.

Srilatha Kolla works on the DevOps team at at Hill-Rom Cary in the Raleigh, North Carolina area. Hill-Rom’s Clinical Workflow Solutions team develops medical devices that protect patients by anticipating the care they will need and communicating that information to their healthcare providers.

The process of developing these Class II and Class III medical devices is heavily regulated by the FDA, and Kolla’s team needed to achieve full traceability in order to satisfy these requirements. Hill-Rom was using IBM Rational DOORS for their requirements and test case management prior to 2012, but it didn’t meet their traceability needs, among other shortcomings.

Kolla, who started her career as a developer at IBM, was on the Quality Engineering team at Hill-Rom when they began looking for a superior solution. Her QE team evaluated several options before choosing Jama Connect™ in 2012.

Since then, Kolla has moved to the DevOps team, where she’s responsible for deploying and managing processes to help development, requirements and quality engineering teams build, test and release products that are safer and more reliable. Her team is closely involved from the requirements stage to coding, testing and verification of the product, and she’s responsible for managing the solutions, including Jama Connect, that her team depends on.

Kolla’s DevOps team serves as the Jama administrator at Hill-Rom, but the development, requirements and quality engineering teams, she says, also “live in Jama Connect day in and day out.” Among the organization-specific best practices her team has developed is a multi-project structure, which works better for them than a single, more complex project structure.

As an FDA-regulated company, Kolla says, Hill-Rom values Jama Connect for its traceable requirements and test case management: “That’s what we depend on highly.” She’s also a fan of the Review Center in Jama Connect. The Review Center enables teams to collaborate without hunkering down in the same room or emailing a Word document back and forth. Stakeholders can also review and sign off on requirements within the Review Center, which comes in handy when you need to reach consensus between team members quickly.

Kolla began using the Jama Support Community to get her questions answered. She wanted to see how other people were using Jama to address the same product development challenges her team was facing. As Kolla says, “We’re definitely not the only ones using this platform.” ­­

Like many Jama customers, Kolla’s team uses Jama Connect in conjunction with Jira, so she turns to the Support Community to ask relevant questions about Jama’s functionality and interconnectivity with Jira, Microsoft Office and other tool suites. Given her team’s focus on traceability, Kolla has often sought Jama-related input from other users on things like item management, defects, Test Center, Trace View, Coverage Explorer, Reuse and Filters.

Stay tuned for more posts on how Jama users are leveraging the Jama Support Community to get the most out of the platform. In the meantime, connect with Sri and other fellow Jama users on the Jama Support Community. 

software-internship-blog-featured-image

Starting a new internship can be intimidating; new responsibilities, new people, new office, and perhaps the most daunting of all, a new codebase. With so many new things, it’s easy to become overwhelmed and want to dive straight into the code. I’ve had the opportunity to be in five software internships over the past few years through the Portland Cooperative Education Program (PCEP) and as a result, have learned enough to compile a list of things to do at the start of an internship. I hope the following things help you start off on the right foot:

1. Complete Onboarding

When it comes to onboarding, every company does it differently. If you are a part-time intern like I was most of the time, this is a good time to establish the hours you’re going to be working with your team. Make sure to give yourself time to get from school to the office and vice versa. More importantly, make sure you’re not too overloaded to do your schoolwork.

2. Introduce Yourself

I didn’t learn the importance of making a proper introduction to my coworkers right away. I’d spend hours on end banging my head against a wall (metaphorically) because I didn’t want to ask for help from someone I didn’t know. If I had introduced myself and gotten to know them earlier, I would’ve felt a lot more comfortable asking for help. Feel free to invite people for coffee or lunch and take every opportunity you can to go with someone who invites you. You’re being hired on as an intern to work with your team, not to be a lone wolf who tries to solve all their own problems.

3. Settle into Your Environment

I had an internship where I did didn’t get my computer until two weeks in and had to read out of a textbook. Hopefully this is a rare experience, but if you don’t have what you need don’t be shy about asking for it and following up with IT.

In my experience, setting up my dev environment has been tedious. Most companies do not have a well documented process, so this is where some assistance from a co-worker will be really helpful. Asking them for help shouldn’t be a problem now because you’ve already introduced yourself. Now is a good time to download any programs you use for productivity and configure your IDE to adhere to the code style of the team.

4. Get the Lay of the Land

Once you’re all set up, you can actually start learning. If you don’t already know about git (or any other Version Control Software), I highly recommend you to learn it. It’s absolutely crucial to figure out how VCS is used before diving into the code.

You should also get familiar with the programming language(s) that the application is using and the parts of code that your team works with. Watching a few videos and then doing an online tutorial or two helps me get comfortable with the code. Once you’ve got a better grasp on the language, you should take a look at the structure of the code for the application. Some things to look out for are:

  • The folder structure for the project, including
    • Back-end/Server-side code
    • Front-end code and styles
    • Test code
    • API code
    • Database code
  • Which libraries/modules are used
    • These can typically be found in files that deal with dependencies such as pom.xml, package.json, Gemfile, etc)

5. Experiment

Look through the application, think of something you’d like to change, and then make the necessary code changes. Figure out how to write tests for your code and look at existing tests as reference. Try to make changes related to each area listed above if your team works in those areas.

Another thing that’s proven to be extremely helpful for me is picking up a small and easy task and go through it with another engineer who has been around for a while. At Jama, we use a technique called pair-programming to get the perfect balance between productivity and sharing domain knowledge. If you’d like to learn more about pair-programming, check out my colleague’s blog post about it.

6. Contribute!

After you’ve gotten comfortable with the code and making changes, you should be ready to start fixing small bugs and adding new features. To get your features and fixes live, you’ll need to know the process for putting your code into production. This process typically involves some form of merge request to get your code into the master branch. The merge requests are a an excellent way to review your code changes and have another developer look over it to ensure that it’s high quality.

Above all, remember that the main point of an internship is to learn new things. Don’t worry about contributing a lot until you’re comfortable with making changes on your own. Don’t be afraid to make mistakes; your VCS is very forgiving and your team will be too.