source: liacs/re/as6/report.tex@ 132

\documentclass[a4paper,12pt]{report}
\usepackage{hyperref}
\usepackage{a4wide}
\usepackage{indentfirst}
\usepackage[english]{babel}
\usepackage{graphics}
\usepackage[pdftex]{graphicx}
\usepackage{latexsym}
\usepackage{fancyhdr}
\usepackage{fancyvrb}
\usepackage[all]{hypcap}

\pagestyle{fancyplain}
\newcommand{\tstamp}{\today}
\newcommand{\id}{$ $Id: report.tex 454 2008-01-05 21:18:31Z rick $ $}
\lfoot[\fancyplain{\tstamp}{\tstamp}]   {\fancyplain{\tstamp}{\tstamp}}
\cfoot[\fancyplain{\id}{\id}]           {\fancyplain{\id}{\id}}
\rfoot[\fancyplain{\thepage}{\thepage}] {\fancyplain{\thepage}{\thepage}}


\title{ Requirements engineering \\
\large{Assignment 6 - organisational analyse} \\
\large{Stichting Wireless Leiden}}
\author{Rick van der Zwet\\
  \texttt{<hvdzwet@liacs.nl>}\\
  \\
  LIACS\\
  Leiden University\\
  Niels Bohrweg 1\\
  2333 CA Leiden\\
  The Netherlands}
\date{\today}
\begin{document}
\maketitle
\chapter{Introduction}
The assignment given out by Luuk Groenewegen as part of the course
Requirement Engineering to help learning applying the theory in a
practical example. The assignment has been split into 6 parts, every
chapter will handle one of them. The original questions could be found
in appendix~\ref{chap:questions}. Instead of choosing a default
industrial or governmental organisation, a non-profit organisation is
chosen.

\chapter{Description}
Stichting Wireless Leiden (hereafter called WL) has got a mission
statement to build a wireless local network, technically comparable to the
Internet, but standing alone and functioning independently. Making
the connection easy and traffic free. This is done with the hands of
sponsors and many volunteers.

Inside WL a number groups are working on ICT related services. Some
highlighted ones:
\begin{description}
\item[Maintenance ('beheer')] Keeps the network and supporting services keeps running.
\item[R\&D ('techniek')] will build new software and hardware solutions.
\item[Support ('gebruikers')] is helping persons to get connected.
\item[Construction ('nodebouw')] will create new network points.
\end{description}

This paper will focus on the group maintenance as I am primary active
inside this group and know most about it. The group mainly communicate
by the means of an mailinglist, email send such list will received by
all members of the list. All persons are unpaid volunteers with no
agreements made with the foundations in terms of SLA or else. Every
active member however did sign the 'volunteer agreement', which ensures
people will no abuse the power they receive and will not mislead other
volunteers or external persons in the name of WL. It is a very informal
infrastructure, where apart from some technical setup nothing is
documented. There is no hierarchy in terms of bosses and/or managers and
people are free to contribute whenever they like.

\chapter{Activity diagram}
\label{chap:activity}
Instead of making activity diagrams for the whole organisation, which
are complicated and will not be clear in a short time-period. Only some
parts of organisation will be highlighted. The activity diagrams will
focus on maintenance and construction.

\begin{figure}
\centering
\includegraphics[width=.8\textwidth]{wl-maintenance-activity.eps}
\label{fig:maintenance-activity}
\caption{Activity diagram of maintenance 'group'}
\end{figure}
\begin{figure}
\centering
\includegraphics[width=.8\textwidth]{wl-construction-activity.eps}
\label{fig:construction-activity}
\caption{Activity diagram of construction group}
\end{figure}
Figure~\ref{fig:construction-activity} on
page~\pageref{fig:construction-activity} will show the activity diagram of
construction of a node \footnote{piece of hardware with radio antennas which
provides a connection point for the people around the node and a number
of antennas/hardware to provide connectivity between nodes}.
A site-survey will mean taking pictures of the possible location and do
radio scanning to check for potential connections with other nodes and
possible interference inside the neighborhood. Documenting will include
putting the information in the version control system.

Figure~\ref{fig:maintenance-activity} on
page~\pageref{fig:maintenance-activity} will show the activity diagram
of construction, the caption has quotes around 'group'. Those are
intentional cause we cannot look at the group at one glance, but we have
to look all persons individually. No person is assigned to a certain
task or responsible for certain part of the system, which will cause all
persons in the group to do the same activity diagram and not the group
all together.

None of the activities are related of monitoring the processes or making
sure problems are actually fixed or improved, which are some vital parts
of embedded feedback loop pattern. Some parts however are covered.
Environment input is set to be incoming problems from various sources,
output will be the fixed problem.  Production process is visualized
inside the activity diagram. The Management information system will the
the gathering of all problems, comments and their status. But standards,
management, control, (intern) data, information and external data are
currently lacking.


\chapter{Class diagram}
\label{chap:class}
\begin{figure}
\centering
\includegraphics[width=.8\textwidth]{wl-maintenance-class.eps}
\label{fig:m-c}
\caption{Class diagram of maintenance group}
\end{figure}

Figure~\ref{fig:m-c} on
page~\pageref{fig:m-c} has got a class diagram which reflect the
execution of the activity diagram as found in
figure~\ref{fig:maintenance-activity}. Depending whether someone has
time is very subjective and has been put in a function gotTime(), but
there is no solid definition for this case. Note that a problem is very
subjective as well and there is not definition of a problem, it might as
well could be an announcement for a birthday party.


\chapter{Use Cases}
\label{chap:use-case}
\begin{figure}
\centering
\includegraphics[width=.8\textwidth]{wl-maintenance-use-case.eps}
\label{fig:use-case}
\caption{Uses Case of maintenance application, the mailinglist. In order
to keep the picture readable the generalisations of the actors are left
out. This is a hierarchical tree namely admin, moderator, member, user}
\end{figure}

Figure~\ref{fig:use-case} on page~\pageref{fig:use-case} has got the use case of
the open source mailinglist system called
mailman \footnote{http://www.gnu.org/software/mailman/}, this application
is used in maintenance group to support communication and problem
solving of activity and class diagram as described in
chapter~\ref{chap:activity} and chapter~\ref{chap:class}.  Functionality
is relatively simple, both powerful at the same time. The system does
not say anything about the possible usage of the system which makes it
workable for multiple parts of the organisation, inside WL system is
virtually used in all groups of WL to communicate and discuss various
topics.
The admin is in charge of the technical parts of the mailinglist system,
most of the times he/she is responsible for all mailing-lists of the
organisation.
The moderator is set in place in order to prevent abuse of the
system, by sending fake/unwanted messages like spam and to ensure to
keep certain lists free of non-volunteers, like a list of all
volunteers which did sign their 'volunteer agreement'. But also to make
sure the admin could focus on his part and not to get distracted/flooded
by the moderator requests.

\chapter{Change Proposal}
The so powerful, easy to use, simple mailing system as described in
chapter~\ref{chap:use-case} has one major problem as it comes to
supporting the maintenance group. This is no way to track a problem or
to do something which related to reporting as there are no states
defined. Which will cause the embedded feedback loop to be broken,
the flow from the main process to the management and back is missing.
Changing this will be almost impossible, cause it require a lot of rule
setting -like predefined email formats- which will make it more
difficult for persons to participate in the process. A better solution
will be to start looking at a so called issue tracking system, which
makes it possible to address a state to a problem.

An other problem relates to the moderators' task, email is frequently
abused as spam making the moderator job cumbersome and time consuming.
Every email of a non-member needs to verified and checked.

The last problem relates to the email communication in general;
\begin{itemize}
\item Everybody use their own email client which makes every message unique.
\item There are social rules involved, where to type your text when
replaying on a email message for example.
\item The underlying email communication systems are fairly difficult and
error prone, due the many technical factors -like
DNS/network/programs/filters- involved.
\end{itemize}

\chapter{New Use Cases}
\begin{figure}
\centering
\includegraphics[width=.8\textwidth]{wl-maintenance-issue-tracking.eps}
\label{fig:issue-tracking}
\caption{Uses Case of suggested maintenance application, issue tracker. In order
to keep the picture readable the generalisations of the actors are left
out. This is a hierarchical tree namely admin, moderator, member, user}
\end{figure}

Figure~\ref{fig:issue-tracking} at page~\pageref{fig:issue-tracking}
will propose the use cases involved into such issue tracking system.
There exist almost an one-to-one mapping with the old use case at
page~\pageref{fig:use-case}. To get rid of email communication as
primary source, a web-based application will be setup. To address the spam
problem, users will first need to register before they are allowed to
create a issue, which removes the 2 use cases `Moderate email' and `Post
email` (linked to the actor user). `Post email' has been split into `Create
issue' and alter `Alter issue'. `Set list properties will become `Set
project properties'

\chapter{Check effectively}
Effectively could be defined in many ways in a volunteer organisation,
only checking the time needed to solve a problem might not be sufficient.
More important is looking at the human touch. Volunteers needs to be
more happy with the systems and willing to address more time to a
project cause of the new system. The new system will need to assist them
more than the old systems.

Next will be the user -the person who reported the problem-. Checking
whether a user is more happy with the new system could be checked by
simply asking him, but there could also be a more technical approach.
Check the amount of problems coming in and whether a user asks multiple
different questions. Asking new questions means that the user is willing
to spend time to have a problems fixed and has trust the system and
underlying structure will solve the problem.

Talking to volunteers and users will the only way to check whether the
new system works more efficient, as the bits and bytes only will be far
from sufficient.

\appendix
\chapter{Original questions}
\label{chap:questions}
RE-assignment November 2005
my deadline proposal: Monday 2 January 2006

Select an existing organization - industrial or governmental - about
which you can be informed quite easily and in which ICT-applications do
play a role; e.g., the organization your mother is employed in or your
father or yourself or someone else you are acquainted with.

a. Describe the organization verbally and not too long, including ICT's
role(s) in it; use a half to one A4 for it.

b. Give an activity diagram of it (drawing!), which moreover is according
to the embedded feedback loop pattern; apart from the figure, explain in
not more than one A4.

c. Give a class diagram with their attributes and methods, such that
these methods reflect the execution of the above activities or the
manipulations by these activities and with relationships reflecting
relevant connections between them.  Explain in not more than one and a
halve A4.

d. Give one or more use case diagrams together with a description of the
various use cases, covering the process support offered by the software
/ information system(s) as well as the main activities in and around the
organization.  Explain in not more than two A4 - and one might be
enough.

e. Formulate a change proposal for the support as modelled in d.  Keep
the embedded feedback loop pattern (as clear) as it was; also, keep as
many of the classes involved as you can. Explain in one A4.

f.  Describe new use cases, where relevant in relation to already
existing ones. explain the goal of the change proposed in not more than
one A4.

g. How can one, after the change has been implemented, check the
effectivity of the change in relation to the goal.  Explain carefully,
but in not more than one A4.
\end{document}