Jira and A-Spice

[SITTER_Adrien]

Hello Everyone,

I am working in consulting company and most of our work is on Software Embedded development.
We have started a transition to be A-Spice level 3. After one year working on it we reached A-Spice level 2 few weeks ago.

I am in charge of implementation of process follow-up tools.

I started to implement a A-Spice workflow on Jira at least for the software part of the V-cycle (from architecture design to SW qualification).

This can be tricky as differents teams used differents organization and project can go from 2 peoples to severals dozen.

Did your company do something like this? Do you need to?
Did you ask for a support of companies specialize in this kind of transformation ?

I will ask my management if I can make something like an Article about our transition.

Thank you all for the feedback you may have on A-Spice

Regards,

Adrien

[Christoph Piotrowski _catworkx_]

Hi Adrien, I have worked in two different companies as an SW project lead delivering different sizes of embedded Software products. Congratulations for reaching level 2. I think you are aware of this fact, but looking to your statement I just want to add, that a SPICE level is not applied to a company (unlike CMMI), so the level can be different for multiple projects you have assessed. Also the assessment often picks out some areas, not all - so when you talk about workflows I assume you concentrate on SWE process group? I did not understand exactly, if you want to setup as a consulting company a level3 template for other companies or for your internal projects?

Having one template for all kind of projects will be a challenge. Be aware to leave some kind of flexibility as the project methodology in different projects can vary a lot. If you "force" the people too much on a specific path (like one specific workflow with too many states for all projects), you might achieve at the end level3, but maybe can not be as efficient as you would need to be. Getting an external expert for SPICE support might be a very good decision.

I would be interested in your article - or your level2 implementation experience :-)

[SITTER_Adrien]

Hi Christoph,

Thank you for your answer. Yes I know that Automotive SPICE is not applied to a company. We have a project still level 1 and an other that just reached level 2. In both case this is an evaluation made by our customer, as A-SPICE is not something you get an certification for, it is self-evaluated.

Yes we are concentrate on SWE process group for now. But also MAN3 (focused on SWE) and SUP (also focused on SWE)

That the point, my company for now has one template for both project, and severals other project are coming in. But with only two project we see problems with the "unique template solution". Mostly because the configuration management between the two projects are a lot divergent.

My company is interested in a way to may be propose a different "Ready To Use" solution (process + tooling) to ours project managers. They can look at the A-SPICE level they want to reach, what part (SWE, SYS, SUP, MAN) they want to use and take into account the size of their project.

Creating this kind of systems is going to be challenge and we are questioning ourself about may be call the services of a company specialized on this or doing it by ourself and gathering experience.

The second choice open the possibility to sell this experience and our "Ready To Use" implementation and tools configuration to other company.

All of this is still subject to discussion right now. We have too many dark point, where we miss information to be able to choose.

So this is the main question about this discussion. Did other company did already make this kind of decision? What the feedbacks you can give?

Thank you,

Adrien

[Christoph Piotrowski _catworkx_]

Hi Adrien,

the following is my personal opinion from working as a project manager in a SPICE context. I am not an A-SPICE assessor, so I recommend also to get in contact with SPICE quality experts to discuss your approach. My opinion: 

Creating one approach for several customers and for your process groups could be a big project. At first you might think about your target customer: e.g. customers in the large enterprise segment will have rules, processes and tools in their landscape and want to understand how to work SPICE compliant within this setup. For example: in the area of requirements management there are tools like DOORS that can be interfaced with Jira or you can use specific apps in Jira to setup your requirements management. You even might just use Jira and Confluence without additional apps. This would depend on the enterprise tool environment and project type (size of project, number of requirements, type of requirements). Having one approach will be at least a challenge. So, a modular concept might be a good approach, but will this be "ready to use"?

Another interesting point would be, how your "ready to use" product will support learning organizations: will there be a handover to an enterprise QA team or do you support updates and improvements?

Also consider how to show that your product fulfills all SPICE needs: either you have a list of reference implementations or you can show that SPICE experts have reviewed your approach. This would be a reason again to look for some kind of cooperation with A-SPICE consultants.

I don't know of companies that offer such a generic approach. You might have a look to Stages (https://www.methodpark.com/stages.html) from Method Park to find one approach for a generic process modeling tool, that wants to ensure A-SPICE compliancy, but does not mean an Atlassian based approach. But looking to this tool will give you a feeling about how processes are applied project wise based on a template process.

Hope I could give some general ideas and opinions. Feel free to contact me by mail for a deeper exchange of thoughts.

Best regards

Christoph

[Julian Idle]

JIRA, being a task-based management system, can be used in an Automotice SPICE process environment with a bit of thought. For SWE, I would suggest splitting the various process groups into separate JIRA projects: SWE.1-2, SWE.3-4, and SWE.5-6. Your design and architecture tasks would be performed in the SWE.1-2 project and the integration and validation tasks in the SWE.5-6 project. As the most churn or parallel work occurs in SWE.3-4, I suggest a scalable approach where more than one SWE.3-4 JIRA project can exist, based on technology, functionality, or similar attributes.

As work in the SWE.1-2 project wraps up and components and sub-components are created, as well as release versions and dates from the project management, Stories can be cloned from SWE.1-2 to the appropriate SWE.3-4 JIRA project.

[I would suggest using a software factory approach, i.e. Kanban, rather than Scrum, as a two- or three-weekly tempo is unlikely to be achievable, in my experience. Anything longer than a three-week sprint causes the team to lose focus and to have a too-broad deliverable. There is nothing in the Kanban approach that doesn't allow you to stop work on one Story, pass it back to the backlog, and pick up another Story, with the unfinished Story simply waiting for its turn again.]

Once Stories reach SWE.3, they can be further refined and analysed, split into smaller work items or even returned (moved back) to the SWE.2 project. Stories from SWE.1-2 will retain their association with components, Epics, and releases throughout their lifetime, regardless of which project they find themselves moved to.

Once a Story has been implemented and unit tested in the SWE.4 phase, it is ready for further integration in SWE.5-6. No that we're on the upward side of the V, I would suggest the integration and validation Stories are cloned from their associated predecessors from SWE.1-2 and not from SWE.3-4, preserving the traceability and consistency of the specification rather than the implementation. They remain associated with the Epics from SWE.1-2. This allows the integration and validation to progress with little dependency from the implementation.

It is probably not needed to be mentioned, but JIRA is not the respository of work items. Use your VCS for that! And whether SW requirements should be created in JIRA or simply referenced from DOORS, Polarion, etc. remains a project decision.