OU blog

Personal Blogs

Sebastian Tyrrell

Veni vidi wiki

Visible to anyone in the world
Edited by Sebastian Tyrrell, Thursday, 24 Jan 2013, 15:07

 

It is not at all unusual for the wiki deadlines to slip for some people, and as it is often difficult to fit course work in to busy lives I try to make allowances. However, marks are awarded based on contributions towards the overall goal, and clearly late contributions are of lower overall benefit.

If you are achieving your deadlines but others are not we try to make sure that you do not in principle suffer. In the worst case you could even make up your own comments, and then update your requirements appropriately. I say "in principle" because the entire purpose of the exercise is to strengthen the requirements through peer review, with someone else looking at your requirements with a different perspective and so helping you to improve them. Clearly it is not as easy to do this yourself - if you need to, think in terms of a persona: take one of the roles and try to address your requirements from that perspective.

If you are delayed or have been unable to contribute so far, please do your colleagues the courtesy of leaving a note on the wiki to explain your reasons and suggest when you may be able to complete your part

If anyone feels their wiki at this stage has no more than two active members, please contact me

Hope this help and good luck

 

Permalink Add your comment
Share post
Sebastian Tyrrell

A belated welcome to M883 2012k

Visible to anyone in the world

Welcome

Many thanks for your patience and understanding over the last few weeks as well as the many kind emails I received: they are all very much appreciated.

So: welcome to the OU module M883 - Software Requirements for Business Systems.

Your first port of call for materials and general information should always be the module website: if you look at the "Resources" section (right hand sidebar) you will see links to module resources, including electronic versions of the study guides, the TMA scripts and supporting papers and the wikis for the collaborative exercise.

The module is based around the set book, "Mastering the Requirements' Process" (2nd edition) by Suzanne Robertson and James Robertson, with additional information, guidelines and self-assessment materials provided in the associated study guides. You should by now have received all your materials, if there are any problems please contact me.

Assessment is through three Tutor Marked Assignments, or TMAs, and an exam in April. Due dates for the TMAs can be found on the study calendar on the course website – as most of you have realised, the first is only a week away!

I will generally keep in touch with the group by email, though you are welcome to phone me at any time. This blog will be used for course related posts, while my own blog (http://needsmust.wordpress.com) is more generally related to requirements' engineering, often derived from questions I receive by email. I would encourage you to subscribe to both for the duration of the module at least. I will aim for about one a week, though not immediately after the TMA due dates. There are two reasons for this: one I will be busy marking, and two if there are late TMAs still to come I don’t want to give those people an unfair advantage!

If you haven't already, I would encourage you to have a look at the website, which also includes links to a number of additional papers that form an integral part of the course materials as well as background reading, copies of the course software and pdf versions of the study guides and the assessment materials (the TMA questions and guide, specimen exam paper and solutions) There is also a link to the course conference where you can exchange experiences with other students and to the course wiki.

This is a feature that you may not have come across in other courses and which you will be expected to use for collaborative work: please note that this work is an assessed part of your TMAs. You will be assigned to groups of about 6 people for this collaboration: I would suggest you exchange personal emails and maybe telephone numbers with the other members of your group.

Please do your very best to keep to the due dates for your TMAs. If you do have problems, please contact me before the due date and we can discuss a short extension. I have a small amount of discretion for the first two TMAs but none for the final one which must be submitted on time. However, please remember that you are no longer the only person affected by your delay: as in most software projects other people - your collaboration group - are dependent on your input. There are suggested deadlines for the collaborative work about a week before the TMAs are due. So please ensure your collaborative contributions are made in good time otherwise they will not count towards your mark.

However since this email is itself so late I will be extra sympathetic on this occasion - if you need extra time email me, but please do your wiki contribution as soon as possible and in any event before the 29th.

If you do this and fulfil your obligations to your group I will be more likely to look favourably on requests for extensions for the remainder of the work!

In this module the TMAs are submitted electronically, through the eTMA system. If you are not familiar with this I would encourage you to submit the "test" TMA, which appears as "TMA 00", to upload a file and check that there are no problems. You could use this to tell me a little about yourself, and it is also a good idea to include examples from any drawing tools you are planning to use - this will check that we have compatible software.

Just to tell you a little about myself. I am a systems' design consultant with more than 20 years experience working in telecoms, and more recently energy, industries as well as with public administrations and voluntary organisations. I first came to the OU as a student in the early 1990s, so I do understand the difficulties of balancing work, life and study.

If you have any questions or comments about the course, or about the Open University in general, please feel free to contact me. The best way of contacting me is by email, either at s.d.tyrrell@open.ac.uk or sebastian.tyrrell@ieee.org. I would generally check my email at least daily, although sometimes not at weekends. If you prefer to contact me by phone then evenings and weekends are the best times, and my mobile (+353 86 3120 974) will usually reach me. Other numbers you might like to note are:

Hom- +353 76 602 6049

British number - +44 2895 81 0330

One final point to note: if you need to submit an assignment in paper form (for example because of a problem with the eTMA system) then please contact me first to ask where I will be! I travel a good deal, especially between Ireland and Germany, and it would be a real shame if your TMA turned up on the day I left and sat waiting for me for 10 days.

Please do get in touch to confirm that you have received this mail, and to tell me a little about yourself and your reasons for choosing this course.

I am looking forward to working with you over the next few months. Good luck, and feel free to contact me with any questions.

Permalink Add your comment
Share post
Sebastian Tyrrell

Some notes on DFDs

Visible to anyone in the world

I've had a couple of questions about DFDs, and this part of Q1 is often a stumbling block so I thought I'd just give you a few pointers.

The key point with DFDs is they are formal documents, and as such they have a formal structure and need to be complete and consistent. I don't have the case study or TMA script available at the moment, so I can only comment in a very general way.

  1. make sure you include all appropriate data flows, both into and out of the processes. You will also need to think about what other data you need to be able to select an appropriate itinerary. All data flows should be specific, labelled and consistent with the data store they go to or come from.
  2. You could start with what is called a "level 0" dfd for your own benefit: a single process and think about what information the customer must provide and what result they should get back. Then develop it to think about what data the system needs to store and add those flows to and from data stores. Then you go to the next level (level 1 dfd, which is effectively what you are looking for here) and break the process down to its next level constituent parts.
  3. The general problems I see on this question are:
    • incomplete and poorly labelled data flows and inappropriately (usually vaguely) named data stores inconsistent with the data flows.
    • Not answering the question, which is usually on a very specific change to the existing diagram: concentrate exclusively on that change and answer that part completely. If in doubt about the scope then state your assumptions (that is actually general advice for all questions!).
    • Poor naming of processes, not clear what is intended (your processes have good names - clear, concise and precise - though without better data flows it is difficult to gauge how appropriate they are).

Hope this helps: you can find some more general information at the links below. .

http://openlearn.open.ac.uk/mod/oucontent/view.php?id=397581&section=4.1

http://learn.open.ac.uk/file.php/6968/%21via/resourcepage/63775995/6968/moddata/resourcepage/Some_important_course_concepts_2.pdf

 

Permalink Add your comment
Share post
Sebastian Tyrrell

Welcome to M883 2010e

Visible to anyone in the world
The welcome note may be found at http://hubpages.com/hub/Welcome-to-M883-Software-Requirements-for-Business-Systems.
Permalink
Share post
Sebastian Tyrrell

Function points

Visible to anyone in the world
Edited by Sebastian Tyrrell, Saturday, 6 Mar 2010, 15:01

I received a question relating to the calculation and use of function points the other day.

The first point to make is that these are in no way central to this course but for those that are interested there is a quick primer in Appendix C. Function point analysis (see http://www.ifpug.org) is one way of measuring the size and complexity of a software based product before it is built, and can also be useful in tracking changes and maintenance costs.

The analysis is based on the complexity of the inputs, outputs and data storage requirements - all things that will be familiar to you from your data flow analyses. It is a formal technique and appears to get good results when used properly - it can be used not only for system development but also for maintenance (an organisation might monitor the maintenance cost per function point and replace their systems if it goes above a critical level, for example).

The fp's are measured on the basis of the system as seen from the user perspective, which ties in well with our course.

Some common problems:

  • fp analysis not planned and too hurried → guesstimates being made that are really not much better than guessing the numbers of lines of code.
  • unqualified analysts do the job → non-repeatable and non-verifiable result.
  • different perspectives in different organisations → difficult or impossible to compare between companies and often projects

See http://www.softwaremetrics.com/fpafund.htm for an overview, there is also an online tutorial at http://devdaily.com/FunctionPoints/.

p. 279 of MRP discusses the the delivery rate (suppose we start with an average delivery rate of 16 function points per person month). Although MRP describes this as an "average" they don't source it and they don't state which "average" they mean.

The appendix does introduce a sourced "rule of thumb" from Capers Jones (see MRP p. 508)

  • effort (person-months) = (function points / 150) x function points0.4.

There is more detail on this derivation at Software Sizing during Requirements' Analysis, with some discussion of  differences between domains and languages. Although these might provide first-cut rules of thumb it is fair to say that most organisations starting to use fp's would need to derive them over time and the first couple of projects: development methodology, process and implementation language as well as the application domain will all affect the efforts needed. Another factor is the inevitable (though hopefully small) difference in the fp counts coming from different organisations.

Generally though the figures I have seen over the years tend to be in the range 10 - 100 function points per person month, and more clustered around the lower end of that range and, as the Capers Jones equation neatly demonstrates, the effort is in any case not a linear function of the fp count.

I have come across a variant called "use case points", somewhat more related to the concepts of the course but clearly less well-known. See http://www.ibm.com/developerworks/rational/library/2870.html

 

Permalink
Share post
Sebastian Tyrrell

Welcome to my blog ..

Visible to anyone in the world

Hi to all my students and anyone else who uses this blog: I am going to start using it to pass on information on requirements' management in general and course M883 in particular that I think will interest many of you.

Various events might inspire to put up a post. Firstly, I receive many queries on matters relating to the course or to study in general, and where I feel this may be of interest to others I will post it.

Secondly I will try to take a couple of important teaching points from each TMA and post something relevant on the blog. How many points and in how much detail may depend on the amount of time I have available for it.

Thirdly I will post stuff I come across myself in my work, reading or study that could be of interest.

Feedback is, as always, appreciated. If it was useful, let me know, and if not tell me why not!

Enjoy your studies ...

 

Permalink
Share post

This blog might contain posts that are only visible to logged-in users, or where only logged-in users can comment. If you have an account on the system, please log in for full access.

Total visits to this blog: 75070