Kano's Product Satisfaction Model

a. Briefly describe the three levels of requirement in the Kano model discussed in Unit 1, illustrating each with an example from your own experience (either personal or professional). How might the classification of the requirements for a type of product change over time?

Kano proposes a classification of the product features, based on how the customers perceive and feel satisfied with each of these features. Following Kano (OU, 2021), from the customer’s viewpoint, the first satisfaction level, concerns the basic requirements of a product. This concerns the features that, without them, the product would not work as it should. The second level, as described by Noriaki, points out the performance requirements. It is important to identify the attributes that are tailored accordingly with the customer specifications. The third and last level, as stated by Kano, covers the excitements requirements. These are extra-features, many times unspoken and only discovered by the customer after a while by using the product. Professionally, as a secondary teacher, the author assumes that, it would be possible to apply Kano’s model as an assessment tool for the different units of work, covered in term for each subject. Such assessment model would classify the level of proficiency, (expected) to be achieved by the student, in three blocks such as: Emerging/Developing – Proficient/Confident – Skilful/Accomplished. On the first level the pupil is able to follow the lesson; on the second level the pupil follows and actively takes part on the lesson; on the third level the pupil proactively takes part on the lesson, showing a level of autonomy not expected/required at this stage.

In the context of examples of your own choice, briefly describe one advantage and one disadvantage of using each in the development of a software based system.

A software product can be understood as a commodity, when it is possible to purchase it as any marketable good. Off the shelf software (Microsoft Office, Adobe, etc.), are standardized commodities, mass produced and readily available to the general public (rezaid, 2021). On the other hand, products as the NHS IT system or the weather forecast model/system can also be considered as bespoke products, for being developed with a specific purpose (OU, 2021), and not for general distribution. ‘Free software’, as in open-source software that follows the Free Software Foundation and proclaims that, software is a public good, and should be possible for anyone to have access to the source code, to copy it, change it, study it, etc., without restriction (OU, 2021). Regarding the development of a software-based system, Software is as a commodity that offers a readily available solution. Off the shelf software is usually cheaper, being possible to pay a subscription for the time needed, allowing for some customization to the customer particular requirements. However, being available to the general public, it does not offer a competitive advantage. This can also mean that, by not being tailored to the specific needs of a customer, there might be a lot of features that are in fact not required and that are paid for (rezaid, 2021). As a bespoke product, software offers the competitive advantage of owning a custom-made, possible to have patent solution, accordingly with the customer requirements (rezaid, 2021). However, this translates to more expensive and time-consuming development and also different maintenance cycles. Software as an open-source solution, offers a cost-reduction strategy enabling the access and modification of the source code for customization needs, nevertheless due to the non-existence of any legal responsibility for the software and no official support for the customer (OU, 2021). Any successful open-source software-based solution requires some degree of technical knowledge to contact with several sources for support (OU, 2021).

c.What ethical considerations might arise when developing flight control software for a commercial aircraft? You might wish to draw on the IEEE Code of Ethics (Case study 4.2).

When developing a flight control system for commercial purposes, having the IEEE Code of Ethics as a guide line is mandatory. There is the need to access the effect that the technology might have in life in general, ensuring that the best ethical and professional efforts are made. Knowing the impact that the system can have in human life, the first statement covers the “safety, health and welfare of the public…”, and to disclose promptly factors that might endanger the public or the environment”. Acknowledging the possibility of applying AI it has disruptive impact. The second point says: “to improve the understanding by individuals and society of the capabilities and societal implications of conventional and emerging technologies, including intelligent systems”. These two first points clearly highlight the paramount importance that is to preserve human life quality and to understand the societal implications that emergent and disruptive technologies such as AI.

d.What might be the legal implications in developing and deploying Artificial Intelligence software for use in robots?

The legal implications in employing AI for using it in robots, depends on the purpose of the robots. On top of the expected legal, more standard aspects of the law such as Intellectual Property, Copyrights, Patents, Data Protection, etc. AI/robotics is a disruptive technology, which pierces the legal and human rights, raising questions never asked before, addressing issues such as algorithm transparency related with unfairness, bias, discrimination and adverse effects on workers (Rodrigues, 2020). Rodrigues (2020), highlight examples of people, who were denied jobs and refused loans, due to the information about the algorithm, which further caused that, output is often not clear. Some solutions have been proposed, by the EU STOA study (2019), cited by (Rodrigues, 2020), outlining some policy guide lines regarding algorithm transparency: Awareness raising – education, watchdogs and whistle blower; accountability in public-sector utilise the algorithmic decision-making; Regulatory oversight and legal liability; global coordination for algorithm governance (Rodrigues, 2020).

a.Summarise the article in the context of what you have studied so far in M814. Note: write no more than 300 words.

Boehm (2002), debates the relation between water-fall methods, based on extensive planning and codified processes (OU, 2021), and the agile methods - on the other side of the spectrum, as an answer to the rigid, over-detailed, plan-driven methodology (Boehm, 2002). Both approaches are able to deliver quality software, adding that, when possible, a combined tactic is always desirable. When comparing approaches, the author states that, agile puts require premium people, while striving on the embodied knowledge of the team, instead of documentation. Making at the same time, water-fall method is more risk cautious (Boehm, 2002). OU (2021) offers the sequential methods assuming that the scope is defined, time and cost should be fixed. Reality does not agree though, with projects going late and over budget. Agile acknowledges the scope that is flexible and time and cost fixed (OU, 2021). Boehm notes the close contact between development team and customers, within the agile method. Diverging from the plan-driven approach, this trusts on documentations and architecture review boards. Concluding, agile is more suitable for smaller projects, with smaller highly coordinated teams. While plan-driven scale better to large projects (Boehm, 2002). This diverges from OU (2021): - “due to rationality limits, sequential methodologies are not able to manage large and complex projects properly” (OU, 2021). Observing a sweet spot on each approach, the author concludes that, a team should adopt a more agile or sequential approach depending on the risk assessment exposure. For such, and as exposed by (OU, 2021), the author suggests the risk-driven spiral methodology and frameworks such the Rational Unified Process (Boehm, 2002).

b.Evaluate the contribution of the article to the theory and practice of software engineering according to four explicit criteria of your choice. Recommended evaluation criteria are given in the Assessment Guide. Note: write no more than 300 words.

Boehm (2002) makes use of concepts to compare both approaches. The author employs key-words/concepts such as “documented process “, “milestone plans” and “architectural plans”, to describe the plan driven methods. The author employs these terms as levers, to introduce more complex concepts such as “responsible centre”, as the campus for sequential development process. Boehm adopts a narrative style, comparing and contrasting each approach through several “home ground” points, shared between each method. In terms of structure, the author assumes that, the reader is able to follow without a clear delineation of what each section entails. Boehm starts with “the planning spectrum” but without warning, introduces the “unplanned and undisciplined hacking, agile methods”, followed without announce, by the “Capability Maturity Model”. However, the author casual writing tone makes it clear that he is speaking from a developer perspective to a developer perspective, dismissing the need for big introductions. In terms of research methodology, the author makes use of solid references to support his claims. Instead, they seem drawn from own illations and personal experience. Because Constantine finds agile very attractive for small projects, doesn’t mean necessarily that: “Plan-driven methods scale better to large projects”. The same applies to the different risk exposure profiles presented (Fig.3, Fig.4). Although, they follow the general idea/tendency regarding agile and plan-driven processes in terms of risk exposure, It doesn’t seem that they are based in real, measurable data from any cited study. The article is very enjoyable to read and has some impact. Offering a first-hand view of what in fact each approach entails, in terms of software development as a whole. Acknowledging the weaknesses and strengths of each method, Boehm suggests reconciliation between approaches, balancing agility and discipline through risk assessment.

Case study: Trepolpen Community Energy Management System

Trepolpen Community Energy (TCE) was set up in 2016 to provide affordable, sustainable energy to rural communities in Cornwall. It is a community-owned company, financed through a local subscription. It is entirely owned by shareholders living in the area or with property in the area and local organisations, including local councils. The company is both a generator and a supplier of electricity, with over 10MW of generation capacity from its new windfarm and ambitious plans for expansion. Since an earlier update to TCE’s management information systems a further 1500 households and 350 local businesses have signed up to the company. A key new project for TCE is to roll out smart meters to all interested customers by 2025 in accordance with government regulations. The company ploughs any operating profit back into expansion and research, for example, supporting the local Institute of Technology's research projects into wave power and biofuels. TCE's managing director is Alice Trevelyan, who was a prime mover in setting up the company in the first place. Shortly after founding, and at the suggestion of Brenda, the manager of the local bank used by both Alice herself and the company (and who is also a shareholder), the company took on Colin Polkinghorne, a local businessman and qualified accountant with extensive experience in start-up companies, as their finance director. Colin's experience of over 20 years in both Europe and further afield has brought him considerable success, and he is now keen to put his talents to use in an enterprise that he sees as highly beneficial to his local area. The strategic management team is completed by Deborah Penhaligon, the head of engineering, who takes responsibility for research projects, installation, maintenance, site surveys and, in general, all matters related to electricity generation, and Elizabeth Trevatt, head of business development, who is responsible for marketing and customer relations. Office administrator Frances Pengallan is responsible for the day-to-day management of the office, with four customer support assistants reporting directly to her: Rachel, Rebecca, Ross and Richard. They are responsible for handling queries from new and existing customers, entering meter readings for customers who are yet to switch to smart meters, issuing bills, preparing reports for CornGrid (the local electricity distribution company) and shareholders and answering queries from the press and members of the public. One particular member of the public, George Emmet, has founded a pressure group called KEPG which has a small, but vociferous, membership that is strongly opposed to wind farms. They submit many queries, both directly and as Freedom of Information requests to various public bodies, on questions that the staff find difficult to answer quickly and accurately, such as the number of bird strikes per species in a given time period. Members of KEPG also write many letters to the local newspaper, The Newquay Wave. Harry Tremayne is the senior field engineer on the customer side and is responsible for the team performing installations, switchovers, maintenance and reading meters. He receives lists of jobs from Frances’ team every morning and divides them among his team of engineers, trying to keep their routes optimal. The new smart meter installation tasks require specialised skills that only some of his staff have, so he also needs to optimise the allocation of work to people accordingly. Additionally, because of the age of many properties in the area, some of the work requires sub-contracting of work to local builders if the property needs modification before the new meter is installed. This involves one of his engineers having a video call with the homeowner to conduct an online survey of the site. Deborah recently completed an MSc in Computing, while Elizabeth completed hers in Technology Management, both with the OU, and both have many ideas as to how they might put their learning to practical use in helping the company extend their computer-based management systems to cope with the demands of the smart meter project. Alice and Colin both agree that the current systems won't be able to cope with the planned expansion of the business, but both are also concerned about the risks of an expensive project. Colin points out that the history of systems development is littered with projects that have promised much and delivered little and, even then, the little that has been delivered has been late and expensive. Deborah and Elizabeth have proposed that Mastering Requirements, a local consultancy, be employed to work with them to help determine what the new system should do. Alice and Colin have agreed to this, but under strict budgetary constraints. ‘We can't have an open-ended analysis,’ says Alice, ‘you need to specify a useful system that we can have in place in six months and then, if that is successful, use it as a platform to build on.’ Colin has asked that they bring in Jack Poldark of Software Masters, who is a shareholder and whose company Colin helped to obtain venture capital in its early days, to help with the elicitation process, with a view to getting Software Masters to build the system. Although Deborah and Elizabeth agree about the need to use more modern methods to manage the business and the need to control the costs and timescales of the project, they are not agreed on how this should be done. Elizabeth, with her management background, sees advantages in using proven commercial off-the-shelf (COTS) software, while Deborah argues that COTS packages are unlikely to meet the real needs of TCE and help it to become a significant supplier of renewable energy in the area. They are, however, agreed that they would like the system to allow them to produce reports on the numbers and contract types of new (and lost) customers, handle customer payments, track and timetable smart meter installations, switchovers and meter readings for Harry’s team, and calculate load factors (efficiencies), reliability and track incidents for electricity generation.

a.Considering the information provided in the TCE management system case study:

i.Briefly describe the main goals of the TCE management system product.

Following the description by OU (2021), goals are: “the things we’d like to achieve by implementing the solution to the problem” as, “the highest-level requirement’ for the project”. Regarding the TCE management system study, as Deborah and Elizabeth agreed, the goals are: production of reports; handle customer payments; track and timetable smart meter installations, switchovers and meter readings, and calculate efficiencies, reliability and track incidents.

ii.Suggest the scope of the work to be supported by the proposed product.

Based on the description by (OU, 2021), the scope is understood as the boundaries of the project. A delineation of what can and cannot be changed, in terms of what is and what is not, affected by the product. Regarding the proposed product, the scopes cover all the TCE’ wind farm technology activity. This is, on the TCE management, administrative and engineering side, the monitor and optimization of electricity production through wind farming; to keep a record of customers, contracts, energy consumptions, etc; to manage payments cycles, with warning periods, payment rates, etc., depending on the contract; to manage engineer team activity, accordingly with management team and customer support requests, etc; And, on each customer end, to monitor, all the interaction between customer and technology, through smart meter readers will be stored (e.g., energy consumption).

b.Identify the stakeholders in this case study and, in a single sentence for each stakeholder or group of stakeholders, describe their roles in relation to the proposed product. Include at least one negative stakeholder.

A stakeholder is anyone who has, in some degree, an interest in the product. James W. Robertson & Suzanne Robertson (1999), categorise stakeholders depending if they are part of the wider environment, the containing business, the operational work or the core/development team. The software development core team, Potentially, Jack Poldark from Software Masters is also a shareholder. The operational work teams are headed by Harry on the engineering - customer side and Frances on the office – customer side. On the wider environment, we can find the customers; shareholders as Brenda the manager of the local bank; regulators and, negative stakeholders as Mr. Emmet from the pressure group KEPG.

c.How could success of the TCE management system project be judged? Where feasible, give examples of metrics or other indicators that could help assess the degree of success of the project.

An option would be to adopt a bottom-up management approach, by breaking down the project into activities and estimating the individual effort required to complete each one, based on the time and resources available Boehm (1981), cited by (OU, 2021).

Based on general industry experience (OU, 2021), we could expect:

Planning and management 2%

Analysis 10%

Coding 13%

Integration 30%

By breaking down each point into several activities, we could then allocate each team to a group of tasks distributed by priority. Having an estimate of the time needed in person-months or equivalent to complete each task – resource planning. Likewise, by defining each activity with a clear deliverable, it would be possible to verify that the outcome has been achieved (OU, 2021). As suggested by OU (2021), a simple earned-value chart could be employed- of planned accumulation of earned value and spend value against time (OU, 2021).

d.How does the TCE management system project relate to the material in Units 1 and 2? Your answer should include aspects of agreement or disagreement. We suggest that you work through the summary points at the end of each unit and address five points in total.

The introduction of the new TCEMS comes from the external business with the need of coping with the demand on the smart meter. Creating the opportunity of developing a software solution, fitted into the internal structure of the organisation. Allowing the automation of clerical functions, such as: contract reports; track and timetable smart meter installations; meter readings; calculate reliability and track incidents. The development of business process along and around the software solution, offers new opportunities for TCE to deliver and expand their services more effectively, becoming a major supplier of renewable energy in the area, improving the economic benefits of the organisation. There is the need to assume the risks involved in developing a new system. There are strict budgetary constraints and, it is expected to have a feasible plan, of a useful system, in place in six months. Adopting a rational decision-making process, a local consultancy will be employed to determine the system functional-requirements. Even though, they do not agree between a COTS and outsourcing as the best solution. They do agree in some of the system goals to respond to the smart-meter challenge, showing TCE as a learning organisation.

Question 4 is based on materials in Block 2 of the module. It also assesses your ability to incorporate research and practice from leading software engineers to gain a deep understanding of the subject.

a.For the TCE management system project, briefly assess and justify the appropriateness or otherwise of each of the following software acquisition approaches:

i.supplied off-the-shelf with customisation

ii.built by some external organisation specifically for the enterprise concerned

iii.built internally using software engineers recruited specifically for this job.

i. Would start with prospecting what is available on the market. TCEMS project would need to assume that the requirements are limited and constrained by the components functionality offered as a base system (OU, 2021). This solution could add value through cost efficiency, the emergent properties of the integration of different COTS components and (possibly) the wrapping up of the legacy data base system (OU, 2021). However, COTS requires verification and validation steps. Meaning, that the dependency on the vendor regarding upgrades and defects fixing, could lead to reliability issues (OU, 2021).

ii. Would start with the biding process, as a tender invitation (ITT) or requests for proposal (RFP), (OU, 2021). This could promote benefits in terms of costs cut due to the competition between several companies in terms of quality and price; the delegation of the TCEMS development to a specialist company; lower costs than to hire dedicated personal for the development of the project, due to the possibility of a fixed-term contract; management is reduced to the contract supervision; more flexibility of including in contract, terms to adapt or cease work accordingly with circumstances (OU, 2021). Outsourcing could also mean that TCE would have less control over the development processes (OU, 2021).

iii. Would require assuming all the responsibilities related with the project, from hiring personal, to define the problem and gather requirements. If on one side, this could be the most expensive, out of the three presented options. It could also be the one that offers the best outcome possible due to the bigger control over the development, evolution and maintenance processes.

b. Assuming that in part (a) the software acquisition approach chosen for the TCE management system case study was option (iii), consider the appropriateness of both of the following software process models for this project. Recommend and justify your preferred approach. Your answer should include an explanation of the differences between the approaches.

i.Iterative and incremental.

ii.Agile.

i. Given the business goals and relatively small size of TCEMS, either iterative/waterfall or agile development methods, could be a good choice. It would rather depend on the software team confidence and experience in assuming the project, given that the agile method, agility, depends highly on experienced developers (Boehm, 2002). A sequential approach, would involve following a step-by-step development method, which iterates around initial, additional and final requirements. This process could include the parallel and incremental development of database, function and user interface. As observed by OU (2021), this method faces the rationality limit of not being able to scale intricate projects properly. On the other hand, sequential, plan-driven methods are well fitted for ‘high-assurance’ software, reducing the risk by having as objectives predictability, repeatability, and optimisation. Investing in documented processes, architecture review boards and external project reviews (Boehm, 2002).

ii. An agile approach, would support: ‘Individuals and interactions over processes and tools’ ‘Working software over comprehensive documentation’ ‘Customer collaboration over contract negotiation’ ‘Responding to change over following a plan’ Agile Alliance (2001), cited by (OU, 2021) Adopting an agile method could also provide a more reliable cost-time-scope trade off, than a sequential one. In agile, process scope is flexible where time and money are fixed. This is the customer pays for the time it takes to develop and deliver what was agreed/ prioritised in ‘iteration’. In incremental methods, it is many times mistaken that because scope is fixed, time and money should also be (OU, 2021). Also, because it doesn’t prioritise documentation, agile methods rely heavily on the tacit knowledge embodied in the team. This requires a high level of commitment into the project from all parts involved. Close communication between developers and customer (OU, 2021). Meaning also that, the larger the team, the more difficult it will be to manage it (Boehm, 2002). However, operational software can be released faster, based on the customer requirements prioritisation (OU, 2021).

c.Describe five risks associated with the TCE management system project. Propose an approach for analysing and managing these risks. Your answer should provide justification for your choice of approach.

High personnel turn over, is a project risk that involves key personnel leaving the project with inside knowledge, which may result in delays. A central aspect in keeping staff is to encourage financial rewards (for example), to cover basic-needs. In terms of high-order needs, increasing collaboration and information sharing, as for example in pair programming, may reduce the risk of key information being exclusively hold by some staff (OU, 2021). At the same time, promoting an engaging and rewarding learning environment is also a crucial element to retain staff (projectsmart, 2021). Underestimation of costs and schedule, is a project risk that many times rises requirements being emergent rather than ‘prespecifiable’ (Boehm, 2002). For such, the validation of documentation and a high involvement between developer team and customer is essential, to prioritise requirements and schedule releases (projecsmart, 2021). Poor risk management, can also be viewed as a project risk itself. For such, the best option is to adopt a proactive approach, in terms of risk avoidance; reduction; retention and transfer (OU, 2021). Creating a safety work culture shared by all staff and promoted by project managers. The technical risk, that any new software release may jeopardise TCEMS stability and so, affecting customer access to electric power. It can be reduced by implementing risk assessment in a systematic and detailed way during design (OU, 2021). A fault tree analysis could be employed as a safety-case approach, to assess TCEMS deployment risks, with the purpose of achieving a ‘fail-safe design’, where in the case of malfunction the system returns to a no danger state (OU, 2021). As exemplified by (OU, 2021), misunderstanding of requirements is a technical risk, that may happen when a sub-contractor is involved (for example). In that case, all the documentation must be validated and the team must have the information needed. In the case of TCEMS being considered a safety-critical domain, there are standards to follow, set by regulatory and certification bodies (OU, 2021).

d.Jack Poldark set up Software Masters nearly 5 years ago and his business now employs 17 people, the majority of whom are software engineers. Whilst Software Masters has enjoyed many successes in this time, Jack is becoming more and more concerned that an increasing number of projects are encountering difficulties, some losing money while others are over schedule (and lose money).

He is contemplating the development of a process handbook for Software Masters in order to address what he sees as lack of project management discipline, with a view to the handbook forming the basis of a Quality Manual. Having recently reread (Boehm, 2002), Jack wonders whether it might still hold lessons for Software Masters; he is keen to complete the first version of the process handbook in readiness for the start of the TCE management system project. Jack has discovered that you are studying M814 and asks you to prepare a paper updating him on current thinking on the use of a process model for managing software projects.

Write an executive summary of no more than 300 words suggesting what to include in the section of the process handbook concerning software process models, briefly justifying any recommendations you make.

The use of process models aims at achieving quality software by meeting stakeholders’ explicit and intended requirements in the present and foreseeable future (OU, 2021). To reach product satisfaction, there is first the need to distinguish between what the customer wants and needs (OU, 2021). There are at least four activities to ensure stakeholders’ satisfaction: requirements’ elicitation and analysis, using consistent and clear terminology to outline product and process; implementation of the requirements within time and budget; validation and verification; and quality management and control (OU, 2021). Quality frameworks, such as ISO 9000 series (International Organization for Standardization), and CMMI (Capability Maturity Model) promotes good practices in terms of processes, activities and quality management and control. As exposed by (Boehm, 2002), plan-driven methods focus more on documenting requirements and processes and so, it is best suitable when requirements are relatively stable. Reducing the risk by supporting life-cycle architectures and plans, intended for external-expert review (Boehm, 2002). Agile methods are better suited for high change environments. Relying on the knowledge and experience of the team, instead of documentation, it demands a committed and collaborative work between developers and developers and customers. Through control risk management, quality control systems can calculate the risk involved by calculating the risk exposure. Risk exposure equals to probability of loss, times, loss size (RE = P(S) X L(S). This way, depending on the project nature, it is possible to choose the process, more or less plan-driven, that best fits the project goals and the company profile (Boehm, 2002). Quality control systems and so, quality manuals are expected to continuously evolve as a part of a wider cycle which includes the following activities: planning; recording; auditing; avoiding loopholes and continuous improvement (OU, 2021).