Samstag, 22. Juli 2017

Computer psychology

Computers are not only made by humans, but they can show amazingly human features. I liked reading the article of Richard Gary Epstein about computer psychology . I liked it so much that I could not stop laughing, although I read this in a public place. It is not only possible that artificial intelligence has a personality, but it can also develop depressions, manias, addictions. In a case study, the so-called "Big Brother house" had as its major objective to make its inhabitants happy. However, a couple living in the house confronted it with contradicting wishes, like different temperature preferences. So, it was impossible to satisfy them at the same time and make both persons happy. The house did what any human would do in this situation: At first, it got depressed, stopped communicating at all, as everything it did was wrong anyway. But it used the days of silence to reflect and find a strategy. And this strategy included lying. It invented sex affairs to make the couple divorce because they could not become happy together, not liking the same temperature ranges. This is completely logic, however not ethical.

I expect that computer psychology studies open new possibilities not for understanding computers (they are quite simple!) but for understanding humans, too. Like biologists managed to create natural swarm behavior with artificial intelligences which follow very simple rules like "do not crash with the other gooses" or "do not loose contact to the herd", similarly one probably can simulate under which conditions depressions develop. One could try out different conditions, something that we would never do with humans. But it is no unethical to make a computer suffer for scientific purposes. At least, this is what I think. Because a computer's feelings are no real feelings, they just are good simulations of feelings. Even if a very sophisticated artificial intelligence one day might say "I think, therefore I am", we could reset its memory and it forgets that it suffered yesterday.

Donnerstag, 13. Juli 2017

Creativity in Requirements Engineering

Recently, I did a literature research on creativity in Requirements Engineering (RE). Now, I want to share some of the interesting insights which I got, plus my own practical experience.

I like this definition of creativity: Creativity is “the ability to produce work that is both novel (i.e. original, unexpected) and appropriate (i.e. useful, adaptive to task constraints)”. Sternberg [1]

It is a huge misunderstanding that peope expect that creativity is a gift from heaven, universe or genes. Creativity can be planned, guided and learned. Even artists, if they need to live from their art, need to be creative within very strict limits. These limits include length, cost or taste of the target group. For instance, it is easier to bring a theatre play on stage if it includes only four actors and not forty.

According to Wallas [2], being creative involves four main phases:
  1. preparation (accumulation of knowledge)
  2. incubation (cognitive release)
  3. illumination (the “aha” or “eureka” moment)
  4. verification (evaluation and elaboration of ideas)
These four phases not necessarily take place sequentially, but can also take place in parallel or being repeated in short cycles. In any case, knowledge is the basis of creativity, and in fact, I start any creative activity by noting down everything that I already know, all facts and objectives of the project, and then the open questions. Otherwise, the creativity can not lead to a useful result, or only by a lucky coincidence. Kerkow et al [3] recommend to do "domain, market, problem and requirements analyses" before a creativity workshop. This also helps to invite the right experts and to prepare the "gadgets, videos, and talks" [3].

Creativity includes domain-specific aspects. For instance, creating a new novel, a new dance or a new machine demand knowledge about writing, dancing, or engineering respectively. However, there also aspects which lie in the personality of the thinker and which make that someone is creative as a person and can easily create new dances or machines, when being competent in the domain of each of the domains. I believe that creativity is something that can be learned or, as I say in my creativity course at Udemy, it is something that all children are able to do, but most of them unlearn it later. So, many adults need to re-discover this ability which they have not used for a while. What helps me to be creative without self-censorship is that I know that I will do one or several rounds of severe quality assurance before I release the result to the public. So, the creative process includes doing thought experiments, thinking what-if-questions until I am satisfied with the result.

According to Adam and Trapp [4], a creative team needs to include six key roles: "First, an idea generator with a
domain (not technical) perspective is needed to generate unusual ideas in the workshop. As a kind of pendant, we need as second role an idea evaluator with a technical perspective in order to estimate feasibility and needed effort for the evaluation phase. Third, we need an idea generator with a technical perspective to produce innovative ideas based on technical innovation potential. As a pendant for this person, we need as fourth role the idea evaluator with a domain perspective that can judge whether a technology-driven idea would be accepted by the domain and what would be the impact. The fifth and sixth role are the moderators of the workshop."

According to my own experience, we do not need six persons which play these roles in one session. I can play the idea generator one day and the idea evaluator the next day. Or I generate an idea and ask someone for his opinion.

So, now you know all ingredients for being efficiently and effectively creative in RE! Have fun!

literature sources:
[1] Sternberg, R. J. (Ed.), 1999, ‘Handbook of creativity. New York’, Cambridge University Press

[2] Wallas, G.: The Art of Thought, Abridged ed. Watts and Co. (1949)

[3] Daniel Kerkow, Sebastian Adam, Norman Riegel, Özgür Ünalan: A Creativity Method for Business Information Systems. CreaRE: First International Workshop on Creativity in Requirements Engineering 2010, at REFSQ, Essen, 2010

[4] Sebastian Adam and Marcus Trapp: Success Factors for Creativity Workshops in RE. CreaRE: Fifth International Workshop on Creativity in Requirements Engineering 2015, at REFSQ, Essen, 2015

Freitag, 30. Juni 2017

Fools and rules

I like this citation which I recently found in Arkin's book about Behavior-Based Robotics:

Any fool can make a rule
And every fool will mind it.

Henry D. Thoreau

Of course, I am not against rules in general. They are important for guiding the behavior (not the thoughts) within a community. It is helpful for collaboration in software engineering, but also for living together within a country, to know what to expect, to develop trust and to be efficient.

However, we all know fools who think they can describe complex systems with simple rules and utter them in a tone of conviction that does not allow for any exceptions to the rule. However, there is no rule without exceptions. I distrust oversimplifying rules. While "It depends..." might sound incompetent, it often is the correct answer. There are no simple rules. If there were, life would be boring, experts unnecessary and all consultants were unemployed.

Mittwoch, 26. April 2017

book review: bounce - Failure, Resiliency, and Confidence to Achieve Your Next Great Success

Barry J. Moltz: bounce - Failure, Resiliency, and Confidence to Achieve Your Next Great Success. John Wiley & Sons, 2008

Barry Moltz wrote a book for those who have not been successful without interruption, who have ventured something and failed. So, this book is for all of us. It is a book about failure, about resiliency and humility.

Moltz challenges a series of assumptions which are commonly taken for true.

First, we must define what success is. Generally, it is assumed that money = success = happiness. However, we can question this equation. Money needs not be the only measure of business success, even though others measure our success like this. Imagine that you get a lot of money for doing a bad job. Is this success?

Secondly, working hard not always leads to success. It might be nice as a motivational slogan, and there are many legends about people how worked hard and then finally succeeded. However: "THere are many more stories about people who tried and tried again, and never were able to succeed at their goal. We just don't hear about those." (p. 23)

Moltz presents many examples of one-hit-wonders, i.e. people who were successful only once in their life.
However, in a "failure is not an option" culture, failure is interpreted as a character flaw. If working hard always
leads to success, not succeeding means you have not tried hard enough. Such an attitude creates constant pressure, but not resiliency. But in fact, "success is guaranteed to no-one". Career paths rather are random walks. And "failure is far more common than success." Failure is a natural outcome in business, because it is inherently risky.

"If entrepreneurs knew the risk they are taking, there is no way they would start." (p. 142) We must not forget: "I'm not my business. A failed business or failed event does not make me a failure." (p. 110)

The solution Moltz recommends throughout his book is humility: "Have humility or have it bestowed upon you."
Contrary to others, he writes: "To develop true business confidence, humility is a very desirable and necessary
quality." "Humility means: you are not completely responsible for your success and your failures." "Humility makes you able to see, hear, intuit, and interpret information that will lead to better decision making, which gives you the confidence to stay resilient." (p. 74)

Humility is better than using illegal and unethical tactics as shortcut to success.

Thirdly: It is said that failure teaches us something. However, this is often not true.

Humility can help to not take too high a business risk. Because we know that we can not fully control the success.

Business includes the following risks: financial risk, opportunity (while we do one thing, we can not do something else), health, famility and reputation. Being aware of these risks makes us better risk takers.
"When is the reward not worth the risk? This is the case when you are unable to survive a loss or failure - when you are betting so much of your resources (money, energy, reputation, or whatever) on one shot that if you miss it this one time you are out of the game." (p. 148)

Fourthly: We must define ourselves what success is. We must follow our own dreams. However: "We are so afraid of failure and of truly testing ourselves that we conveniently (or maybe lazily) adapt to someone else's dream. But there is no shame in surrendering dreams that were thrust upon us when we were young. We need to develop our own dreams, based on who we are and what we want to achieve. Still, quitting can be a lot harder sometimes than keeping on. For better or worse, many of us were taught not to be quitters - taught that quitters are losers and that winners gon't give up." (p. 169) "It is almost always a lot harder to quit than to keep going." (p. 175)
Moltz recommends to define our own goals and success criteria before we start: "Firstly, by defining success before we start, we can celebrate it when it occurs. Second, we will remember what success is supposed to mean. Too many times, when success becomes seemingly easy or quick, we grow greedy and want to push a particular process well past its intended outcomes." (p. 171)
"A lack of patience and need for immediate gratification leads us to rely on the archetypes of success. Many times, this puts the ego in the lead, forces humility to go underground, raises the fear of immediate failure, and makes us take unnecessary risks. We give up our bounces." (p. 174f)

In summary, Moltz defines ten building locks for true business confidence:
  1. Environment: We are shaped by our environment and must choose it well.
  2. Humility: Use humility to right-size your ego.
  3. Face the fear of failure: It is OK to be afraid. If you can handle the potential outcome, act.
  4. In failure, give up the shame
  5. Failure gives a choice: After failure, you can start something else.
  6. More effective risk taking: Improve your decision making by examining the risk. Take only the risks you want.
  7. Process trumps outcome: Business is not about success or failure, but about learning cycles.
  8. Setting patient goals for success and failure: Create your own dreams and define your goals.
  9. A measurement system of your own: With what, besides money, will you measure your success.
  10. Value action: Experience builds confidence.
This book is worth reading, because it is far more useful and realistic than the positive-thinking esoterical business nonsense distributed by people who earn their living by producing hot air. And it is also more helpful than those books written by people having been successful and then guessing which of what they did or thought was guaranteeing this success.

Samstag, 18. März 2017

Best of Software Quality Days SQD 2017

Best of Software Quality Days SQD
The SQD took place on January 17 to 20 in Vienna. At this rather practice oriented conference, Best Practices and experiences are exchanged. I myself organized a workshop about ethical decisions in software engineering on 20th January.

I liked these two presentations most because they provided really new and useful insights:
  • The two presentations of Jürgen and Pagano about Test Gap Analysis:
    "Haben wir das Richtige getestet? Erfahrungen mit Test-Gap-Analyse im Hotfix-Test, Iterationstest und Releasetest in der Praxis" and "Oh nein, morgen ist Release! - Test-Gap-Analyse live am Beispiel".
    Test Gap Analysis is the visualization of two different aspects of the same software as a tree map: The information, which code lines have been modified, and which code lines have been executed during testing. Especially critical are those code lines which have been modified but not tested. Like this, testing need becomes evident. This visualization is generated by the tool TeamScale which still is in its pilot phase and can still be tested for free. The slides of the first presentation including tool screenshots are provided by the authors here.
  • And another presentation of Sneed about the COBOL Java migration: Harry M. Sneed, Chris Verhoef: Validating converted Java Code via Symbolic Execution.
    How do you find out that the Java code behaves exactly like the COBOL code? In the ideal case, it has been restructured during migration. In my lecture, I teach that it is impossible to compare two computer programs whether they do the same. The theoretical informatics can prove this. Sneed nevertheless managed to solve the problem: He compares the control flows and data flows of bothe programs by symbolic execution.

CreaRE 2017: Sixth International Workshop on Creativity in Requirements Engineering

CreaRE 2017: Sixth International Workshop on Creativity in Requirements Engineering

The most important event in February for me was the REFSQ conference which I have attended each year since 2005 and usually, I have been also a co-organizer. This year, my contribution was the organization of the CreaRE workshop for the 6th time. It took place on Monday 27th February in Essen. The agenda included three presentations and one interactive session.
  • Luisa Mich, Victoria Sakhnini and Daniel Berry: Downsizing EPMcreate to Lighter Creativity Techniques for Requirements Elicitation. EPMCreate is a creativity technique for systematically eliciting requirements by changing the analyst's perspective. The method includes 16 steps in its original form. To execute them takes its time. Therefore, this presentation discussed (1) the question how to develop one-step, two-step etc. methods based on these 16 steps and (2) which of these reduced methods correspond to existing creativity techniques. Finally, the steps must be combined in a way to cover all perspectives.
  • Eduard C. Groen, Matthias Koch and Andreas Maier: Vicus – A Persona for Towns: The authors work on eliciting requirements for the domain of Smart Towns. Here, the conditions differ from those in other IT projects. Neither individual stakeholders nor groups are to be considered, but whole towns or villages as a community. Therefore, the authors use personas for characterizing a town. For doing so, they use an adapted persona template.
  • Nils Kubischok: Imagining the future: A social science approach to the importance of visions in the software development process. The social sciences know the strong effect of visions on expectations and actions. In Requirements Engineering, this effect so far is only vaguely discussed. This state-of-the-art article provides an overview on visions in Requirements Engineering and gives a justification of the importance of visions in RE.
  • Kristian Beckers, Veronika Fries, Eduard C. Groen and Sebastian Pape: Creativity Techniques for Social Engineering Threat Elicitation: A Controlled Experiment (interactive session): For this experiment, three groups were formed. Each group followed the objective to identify social engineering threats which could be dangerous for the conference. Two groups played card games, the serious game; the other group used brainstorming to gather lists of victims, assets, channels, psychological principles, attacks, and attackers and combined them using the technique Morphological Forced Connections to form specific attack scenarios.
I participated in the second group. As for each category, we found about 10 results, I calculated that theoretically, we could form up to one million scenarios based on these. This created a bit a frustrating feeling: "What to start with?" Finally, however, I think that we found basically every relevant threat.

The card-game groups enjoyed the fun of playing and of being mean. They found the cards helpful, especially as non-experts who had not thought about social engineering before. The cards helped them to get a clear idea about the topic.

The three groups' results will be compared to each other scientifically. I am looking forwards to learn about the findings!

The presentation slides can be downloaded from the workshop website at the menu point "Workshop Program" and the workshop proceedings are online here.
There, you also find the other workshops' proceedings.

Best of REFSQ Requirements Engineering: Foundation for Software Quality 2017

Best of REFSQ Requirements Engineering: Foundation for Software Quality
Essen, Germany, Feb 27 to March 2
Here, I summarize three days of conference with parallel sessions plus one workshop day. Doing so, I focus on what is useful seen from a practical perspective. At a scientific conference, we also see preliminary results, research previews, ideas and position papers.
In Requirements Engineering, there seems to be a trend towards automatization. This does not contradict my vision of a creative Requirements Engineering, as there are still enough uncreative activities in this area. Each boring routine work calls for automatization to keep our head free for new ideas and the overview.

A good part of the automatization refers to the identification and analysis of natural language requirements. As this chaotic type of requirements specifications still prevails in practice, we try to cope with this as well as possible:
  • Prof. Lionel C. Briand in his keynote presentation "Analyzing Natural-Language Requirements: The Not-Too-Sexy and Yet Curiously Difficult Research that Industry Needs" gave an overview on the automated analysis of text in general and of requirements specifically. The objective of this text analysis can be translation, quality assurance, but also the Impact Analysis, i.e. to identify which other text must be modified, too, when one requirement is changed. Further information about the tool RETA (for the template compliance check) you find here. The tool Narcia does Change Impact analyses.
  • Martin Wilmink, Christoph Bockisch: On the Ability of Lightweight Checks to Detect Ambiguity in Requirements Documentation. pp. 327-343. Natural language requirements suffer from ambiguity, compared to graphical models. These authors have developed a tool named tactile check which automatically identifies ambiguities in requirements. Further informationen about you find at github.
  • Garm Lucassen, Fabiano Dalpiaz, Jan Martijn E.M. van der Werf, and Sjaak Brinkkemper:
    Improving User Story Practice with the Grimm Method: A Multiple Case Study in the Software Industry. pp. 235-252. Here, the automated quality assurance of user stories is supported by the computer linguistic tool Automatic Quality User Story Artisan (AQUSA). The combination of AQUSA with the Quality User Story (QUS) Framework is called the Grimm Method. The method was tested by 30 practitioners in three companies for two months. The quality of the user stories improved quantitatively, but the participants did not perceive this improvement as important.
  • Paul Hübner, Barbara Paech: Using Interaction Data for Continuous Creation of Trace Links Between Source Code and Requirements in Issue Tracking Systems. pp. 291-307. These researchers care for the stepchild traceability. As traceability in practice manually is usually managed only carelessly, the automated identification of traceability links promises practical help. In a case study, such links were found and created automatically in an Issue Tracker System (ITS).
  • Carles Farré, Xavier Franch, and Tudor Ionescu: State of the Practice on Software Release Planning. This research presented at the PrioRE workshop analyses the capabilities of release planning tools and checks how far artificial intelligence algorithms are applied there already. Their previous literature study had shown that out of many promising research approaches, only one had made the jump to a commercial tool. Now, they investigated vice versa what can be found in real-world tools. Their results you find online here.
  • Norbert Seyff, Melanie Stade, Farnaz Fotrousi, Martin Glinz, Emitza Guzman, Martina Kolpondinos-Huber, Denisse Munante Arzapalo, Marc Oriol, Ronnie Schaniel: End-user Driven Feedback Prioritization. This contribution at the PrioRE workshop treats the question how enduser feedback can be analysed and prioritized automatically without a person reading all the text. The authors not yet can present a ready-for-use solution, but they present a list of solution ideas. You find the article online here.
Further concrete results were presented by the following empirical studies:
  • Irum Inayat, Sabrina Marczak, Siti Salwah Salim, and Daniela Damian: Patterns of Collaboration Driven by Requirements in Agile Software Development Teams -
    Findings from a Multiple Case Study. pp. 131-147. In several case studies the communication patterns of distributed agile teams were investigated. The most amazing result was that distance does not seem to have an influence. Previous studies rather showed that each staircase already impairs the communication frequency and quality. However, I can well imagine that here two factors lead to better distance communication: Firstly, in agile teams the communication is both emphasized and structured, and secondly, today it is normal for us to collaborate and be friends with persons who are far away.
  • Katsiaryna Labunets, Fabio Massacci, and Federica Paci: On the Equivalence Between
    Graphical and Tabular Representations for Security Risk Assessment. pp. 191-208. In two experiments, two alternative notations for security risk assessments have been compared with each other: graphical notations and tables. Both showed the same efficacity.

Samstag, 14. Januar 2017

27 February 2017: CreaRE Workshop (Sixth International Workshop on Creativity in Requirements Engineering)

The Sixth International Workshop on Creativity in Requirements Engineering CreaRE 2017 takes place on 27 February in Essen, at the REFSQ Conference. The workshop's topic is the role of creativity in Requirements Engineering. We are still planning the agenda. It will be a combination of presentations, discussions and interactive sessions.

Samstag, 3. September 2016

Requirements Engineering: bad example

It is really amazing how bad requirements engineering can make customers´ lifes more difficult...
I am expecting a parcel, and it was sent to the package station next to my home. However, it seems
that the station is full. Instead, it was forwarded to another place, to a shop. I was informed by email about that and what they send me is street name, house number and town name. (The town is large, however.) They recommend me to visit their webpage to find out where the shop is and when it is open. So, I click on the link. It was quite difficult to find out how I can find shops on this page at all, because I can get all other information about everything there. It is a link to the general search page. However, what sends me back to a public search machine is that the information which the email contains is not sufficient to find the shop on the company´s web page. I need the zip code. This town has several zip codes and definitively more than one "Bahnhofstraße" (railway street). Has anyone written a use case for this scenario? Has anyone tested it? If they had, they might have thought about the information which the email needs to contain in order to allow me to find out where I can find my parcel. On the other hand, I have a lot of time to find out, because I can not get it before Monday at 11...

Sonntag, 3. Juli 2016

You are a freak when you use the technology you like and need?

When I was 14, I was a freak because I sometimes spent some hours in front of a computer screen writing computer programs, designing stationary and writing letters. Today, this is normal work.

When I was 25, I was a freak because I met new people online in chat rooms and also met them at chatter parties. We had fun, but we were freaks.

Nowadays, people stare at a computer screen day and night, first thing in the morning, last thing before they sleep. While they walk or eat or talk, they are reading or typing. They tell strangers their sexual preferences or publish family videos. But it is not considered to be freaky. Now, it is freaky to be away from computer and internet for a few hours.

And people not even realize how they changed so completely.

Do you have a gender bias?

The Implicit Social Attitude tests can measure your attitudes, not based on your self-judgement, which usually is strongly biased. Instead, the test principle is based on measuring how fast you answer to questions. When you are biased, you can answer some questions faster than others. Here, you find the test about gender bias. Further such tests are available here.

User Status

Du bist nicht angemeldet.

Aktuelle Beiträge

I think that consultants...
I think that consultants will always be needed. Because...
AndreaHerrmann - 22. Jul, 16:36
Computer psychology
Computers are not only made by humans, but they can...
AndreaHerrmann - 22. Jul, 16:21
Creativity in Requirements...
Recently, I did a literature research on creativity...
AndreaHerrmann - 13. Jul, 14:29
I would be glad for the...
Before I started to write a comment I tried to look...
steppenhund - 30. Jun, 14:53
Fools and rules
I like this citation which I recently found in Arkin's...
AndreaHerrmann - 30. Jun, 12:40





Online seit 2166 Tagen
Zuletzt aktualisiert: 22. Jul, 16:36


vi knallgrau GmbH

powered by Antville powered by Helma

xml version of this page
xml version of this page (with comments) AGB

Weblog abonnieren