New approaches, new elements, new combinations of already existing elements are what IoTAC is supposed to deliver in the area of IoT. The question a software technologist always poses is whether the novelty of an approach in any area of software development exempts designers and developers from using well-established approaches to define requirements, elaborate and document design work? In other words: can a new framework be conceived, defined, built and tested based on already proven, documented, therefore “old” methodologies or shall we leave the specialists to use any desired approach to do the innovation?
Can ingenuity and discipline be matched?
Our answer is YES, we expect that research is done based on a methodologically thorough background and developers, analysts and designers are supposed to follow best practices of software engineering.
Can we expect that all the independent teams of the project adapt the same concept and methodology?
Our answer is NO, though we can define common guidelines to follow basic software engineering standards, those that contain the most widely accepted processes of a software development lifecycle, as well as the process elements. The processes and process elements will be used to describe the project’s standard process for requirement elicitation, requirements definition and design. Standard process description and tailoring guidelines will then permit the partners to define their own process to follow when eliciting and defining requirements and doing the design. This way, the IoTAC project will benefit from a standardized approach that is flexible enough not to limit the generation of creative ideas.
The basic standard encompassing the main processes of software development is ISO/IEC/IEEE 12207:2017 – Systems and software engineering — Software life cycle processes. We agreed to choose the following processes to be included in our IoTAC methodology:
- Stakeholder needs and requirements elicitation process
- System/Software requirements definition process
- Design Definition process.
In order to give the possibility of a higher-level view on mandatory process elements, we made use of the CMMI Model V2.0[1] (https://cmmiinstitute.com/, owned now by ISACA). This model synthesises the most important processes in software development. We use recommendations of CMMI V2 regarding practices of Requirements Development and Management process area and Technical solution process areas which contain the essence of the 3 processes taken from ISO 12207:2017.
Our methodology description follows ISO 12207: 2017 standard recommendations for process elements definition, asking in case of each process for: process name, process purpose, process outcomes, activities and tasks. Some modelling and notation techniques, standards were also referenced. When using the UML elements for modelling we made the recommendation to use at least the following UML diagrams:
- class / object diagram (to model static view)
- use-case diagram (to model dynamic view):
- sequence diagram (to model dynamic view)
- communication diagram (to model dynamic view)
- component diagram (to model static view).
Our methodology document also gives some recommendation regarding the tools to be used, without imposing any mandatory rules.
The concept described here before is defining the process dimension of our methodology. This part of the methodology comprises the minimum requirements of the processes that must be executed by each partner for requirements definition and / or design.
Another dimension of a process-oriented methodology is the process capability dimension. In our approach within the IoTAC project, we decided to use the generally accepted process assessment standard described in ISO/IEC 33001:2015[2].
The process capability levels, and process attributes are identical to those defined in ISO/IEC 33020: 2015. Process attributes are features of a process that can be evaluated on a scale of achievement, providing a measure of the capability of the process. A capability level is a set of process attribute(s) that work together to provide a major enhancement in the capability to perform a process.
Each attribute addresses a specific aspect of the capability level. The levels constitute a rational way of progressing through improvement of the capability of any process. According to ISO/IEC 33020:2015 there are six capability levels, incorporating nine process attributes.
A capability level consists of related specific and generic practices for a process area that can improve the organization’s processes associated with that process area. Each level is a layer in the foundation for continuous process improvement. Thus, capability levels are cumulative, i.e., a higher capability level includes the attributes of the lower levels.
Process capability determination will be done using a 2-dimensional model (as suggested in ISO / IEC 33020). On one dimension the chosen processes are represented (horizontal axis, Process dimension). On the other dimension (vertical axis, Capability dimension) capability levels are shown, that are further subdivided into process attributes. The process attributes provide the measurable characteristics of process capability. Thus, based on ISO / IEC 33020, our aim within the IoTAC project is to gradually build processes from Capability Level 1 to Capability Level 3. With progressing through the steps of reaching TRL[3] results within the project, we foresee that the capability level of the processes followed in the development will also increase.
Based on all above explanation, we can now build the IoTAC Process Assessment Model, as shown in the following figure.
Figure 1: IoTAC Process Assessment Model
To summarize: the basic approach applied in the IoTAC project for using standardized requirements management, requirement definition and design processes is the following:
- choose the relevant processes from ISO 12207:2017,
- choose further processes from other relevant standards,
- build the most suitable software development life cycle model from the chosen processes, concentrating on requirements management, requirements definition and design,
- do the development activities according to the process descriptions.
[1] CMMI V2 appeared in 2018 and is the only CMMI model in use since the complete sunset of CMMI V1.3 on 30th September 2020.
[2] ISO/IEC 33001:2015 Information technology — Process assessment — Concepts and terminology
[3] TRL: Technology readiness levels
