Wednesday, December 9, 2009

Profiles of typical users

Anna is an 81-year-old lady living in a care house. She has some trouble walking, but she is very interested in current news from all around the world. She spends most of her time reading newspapers and watching news on TV.
She is not very interested in technology, but she has learned how to use simple devices like a TV remote and a microwave oven.

Pekka is a 67-year-old man, also living in a care house. He has poor eyesight, even with glasses on he can not read text in normal newspapers, only the headings. His hands are shaking, making it impossible for him to hold things steadily or perform complicated gestures.
He is fascinated with technology; he has a mobile phone (with a large display and buttons). Sometimes his grandson visits him and shows him a laptop computer; but Pekka can't use it because the buttons and text are too small.

Technology notes for a multi-touch device.



Screen Resolution

iPhone 320x480
new iPod 640x480
Wacom Cintiq 12WX 1600x1200

Touch resolution
Can be smaller than screen resolution

Newspaper-like UI
Magazines 133-150 lpi 200 dpi
Newspapers 85 lpi 150-200 dpi
High-quality book 200 lpi

Programming interfaces
Multitouch for Java
Qt 4.6 (Low-level and/or gesture events; not mature; LGPL)

Operating System support
Windows CE
Embedded Linux
Qt Embedded


Common technologies
E-paper (low resolution & refresh rate, no backlight needed)
OLED (expensive)
LCD (backlight needed)

Gesture support/pressure-sensing
Gesture support: need 2 points of contact
Pressure sensing: not needed

Overall suggestion of technology
LCD, capacitive touchscreen, Qt Embedded for software

Wednesday, December 2, 2009

Use cases




Select transaction type
Use case ID: 1

Description
The user selects the duration of the parking time and the method of payment

Actors
User

Assumptions and constrains
Pre-condition: The machine is not disabled
Post-condition: The user has selected the duration and method of payment

Steps to achieve the goal
1. The user selects the duration (see use case 2)
2.
The user selects the method of payment (see use case 3)

Related non-functional requirements
The system shall correctly respond to a button press within 0.25s

Error cases
a. Selecting the duration or method of payment is aborted
1. The system shows the welcome message
2. The use case is repeated

__________________________________________

Select parking duration
Use case ID: 2

Description
The user selects the duration of the parking time

Actors
User

Assumptions and constrains
Pre-condition: The machine is not disabled
Post-condition: The user has selected the duration

Steps to achieve the goal
1. User presses the GET TICKET button
2. The system shows a list of duration options: ½, 1, 2, and 4 hours
3. User presses a button corresponding to one of the options

Related non-functional requirements
The system shall correctly respond to a button press within 0.25s

Error cases
a. There is not enough free parking places after User presses the GET TICKET button
1. The system shows the message “No parking spaces left”
2. The use case is aborted.
b. There has been more than 30 seconds without user's activity
2. The use case is aborted.

__________________________________________

Select payment method
Use case ID: 3

Description
The user selects the payment method

Actors
User

Assumptions and constrains
Pre-condition: The user has selected the duration
Post-condition: The user has selected the Credit card payment method

Steps to achieve the goal
1. The system shows a list of payment options: “Credit card” and “Phone”
2. User presses a button corresponding to one of the options

Related non-functional requirements
The system shall correctly respond to a button press within 0.25s

Error cases
a. User selects a button that does not correspond to one of the choices on the list
1. The system shows the message “Invalid choice, please try again”
2. Go back to step 1 of the use case.
b. There has been more than 30 seconds without user's activity
2. The use case is aborted.


__________________________________________

Select payment by phone
Use case ID: 4
Extends Use Case 3

Description
The user selects the Phone payment method

Actors
User

Steps to achieve the goal
1-2 same as in Use Case 3
3. The system displays its phone number and phone-payment instructions.

Related non-functional requirements
The system shall correctly respond to a button press within 0.25s

Monday, November 23, 2009

Parking system changes

Requirements 1–5 are deleted.
New requirements:
9. The machine shall make it possible to print an unpaid ticket.
10. Each ticket shall have an unique ID number.
11. For each ticket, a piece of paper shall be printed with a phone number and SMS text used to charge the ticket or get information.
12. Whenever a SMS with valid recharge text is received, the corresponding ticket shall be extended by a pre-set amount of time.
13. When there is less than ten minutes remaining on a ticket, an informational SMS shall be sent to the phone number last used to recharge the ticket, if any.
14. It shall take less than one minute to print a ticket and pay it using SMS for 95% of users who are not familiar with the system.



6 7 8 9 10 11 12 13 14
Relative benefit 2 9 3 7 6 6 6 3 4
Penalty if missing 1 6 3 7 8 6 9 1 5
Cost of implement. 1 7 6 4 4 1 7 4 7
PRIORITY 2 8 0 10 10 11 8 0 2



Task 2:
6 7 8 9 10 11 12 13 14
Complete - - - - - - - - -
Traceable Y Y Y Y Y Y Y Y Y
Testable Y N Y Y Y Y Y Y Y
Consistent Y Y Y Y Y Y Y Y Y
Feasible Y Y Y Y Y Y Y Y Y
Uniq.Determined Y Y Y Y Y Y Y Y Y
Design Free Y Y Y Y Y Y Y Y Y
“Shall” N Y N Y Y Y Y Y Y

Monday, November 16, 2009

Parking system SRS & Evaluation

  1. The system shall accept 90% of valid 10¢, 20¢, 50¢, 1€, 2€ coins. (This requirement may change in the future; it is essential)
  2. The system shall reject 99.9% of other coins used in the world. (This requirement is stable and essential)
  3. If the user has, in one transaction, put in coins whose value exceeds the cost of the ticket, the system shall print out the ticket and return the difference in smaller coins. (This requirement is stable and essential)
  4. If enough smaller coins are not available to return the difference, an error message shall be displayed and all coins from the current transaction shall be returned to the user. (This requirement may change in the future and essential)
  5. Unless a ticket has already been printed out, the system shall return all money from the current transaction when the CANCEL button is pressed. (This requirement is stable and essential)
  6. All error messages shall display a service telephone number. (This requirement may change in the future, it is conditional)
  7. The system shall accept all major credit cards. (This requirement is stable and essential)
  8. The operating company shall be able to deactivate or activate all its machines, or a specific subset, remotely. (This requirement is stable and conditional)

   Corr. Unambig. Compl. Cons. Ranked Ver. Mod. Tr.
1. Yes   Yes      -      Yes   Yes    Yes  Yes  Yes
2. Yes   Yes      -      Yes   Yes    Yes  Yes  Yes
3. Yes   Yes      -      Yes   Yes    Yes  Yes  Yes
4. Yes   Yes      -      Yes   Yes    Yes  Yes  Yes
5. Yes   Yes      -      Yes   Yes    Yes  Yes  Yes
6. Yes   Yes      -      Yes   Yes    Yes  Yes  Yes
7. Yes   No       -      Yes   Yes    No   Yes  Yes
8. Yes   Yes      -      Yes   Yes    Yes  Yes  Yes
-----------------------------------------------------
*  Yes            No     Yes               No

*) Whole document

Cor. = Correct

Unambig. = Unambiguous

Compl. = Complete
This SRS far from complete. Much more work is needed for additional requirements.

Cons. = Consistent
This SRS is internally consistent; it would also needs to agree with higher-level documents.

Ranked = Ranked for importance/stability

Ver. = Verifiable
All requirements except 7 are verifiable.

Mod. = Modifiable
The SRS does not have an organization; however, it is not redundant and itemizes requirements well.

Tr. = Traceable
Each requirement has a number for forward traceability, backwards traceability is not an issue since this is the first version.


Extreme Chaos Report – answers to questions

What are the trends in the failure/success/challenged projects?
Overall, the number of successful projects is rising. The ratio of challenged projects is also rising, and the ratio of failed ones is decreasing.
Also, the average project size is decreasing, which may be the primary cause of these good results.

What are the reasons for past projects to be success and what are main reasons for failure?
The main reason for project success is executive support, which has become the most important only recently. Other reasons are user involvement, an experienced project manager, clear business objectives and minimized scope.
The reasons for failure is, generally, the lack of these.

What are the suggested recipes for success according to the report (see also last page)?
A small project has the best chance of being successful. The CHAOS recipe recommends no more than 4 people, at most 4 months of time, and less than $500000 (about ⅓ million €) in budget.

Compare the previous answer with the recipe from 1994: http://standishgroup.com/sample_research/chaos_1994_4.php. What are the differences? Can you explain them?
Aside from the difference in writing style, the newer report is much more specific – it gives actual numbers instead of vague terms. This is understandable, since there is more research data now.
The old “recipe” instruct to release early and often, to break the project into smaller pieces. The new recipe just calls for smaller projects. The report says (near the end of page 4) that “the act of minimizing scope leads to greater success than that of creating smaller milestones”. This is probably a result of more data as well.
The last difference is that the old recipe mentions that project managers should learn from their mistakes and bad luck. This is missing from the newer version, either because the Standish Group didn't have enough data to support it, or just because they didn't find a good cooking pun to go with it.

What skills a project manager should have? How do you judge your skills if you were assigned to such a task?
  • Business skills. Here, I would fail. I do not have business skills.
  • Technical skills. I can safely say my technical skills are good enough for leading a big project.
  • Project management skills. I have some experience with project management, but I definitely need more. That is partly the reason why I am taking this course.
  • Decision skills. I am able to make firm decisions if I am given authority.
  • Process skills. I do not have experience in this field, although I plan to improve this.
  • Detail skills.This is my strong point; I have no problems thinking about both the big picture and details.
  • Organization skills. In school projects, I tend to lead and organize work. I would say my organization skills are above average.
  • Communication skills. I'm average in this regard.

Monday, November 9, 2009

SRS Documents

Document 1. ProcessImpact SRS template
http://www.processimpact.com/process_assets/srs_template.doc
(HTML version from Google: http://209.85.135.132/search?q=cache:8fmA-O1OsYcJ:www.processimpact.com/process_assets/srs_template.doc+software+requirements+specification&cd=3&hl=en&ct=clnk&gl=fi)

Document 2. ACIS SRS (complete document)

Structure
All documents are structured clearly and hierarchically.
The IEEE and ACIS documents have more structural levels than the ProcessImpact template. This may be due to their size.

Contents
The three documents are of different kinds: the IEEE one gives guidelines for requirements specification,
ProcessImpact gives a template for such a specification, and ACIS has a full specification document for a complicated system.
The IEEE guidelines has the richest structure, featuring an abstract, keywords, an introduction, table of contents and appendices, in addition to the main text.
It also includes a template. The ACIS document generally follows this template (specifically, the variant in A.5), although it leaves out or adds some sections.
The
ProcessImpact template is organized quite differently.
The template does not give clear, concrete descriptions of what should be written, nor a rationale for why it is needed. However,
it has sections relating to the evolution of the document: the Revision History and Issues List sections. (IEEE mentions a “formal change process” and suggests an audit of changes should be provided, but does not include this in its template.)
The ACIS document has only the requirements themselves. The requirements are not ranked for importance/stability, but the ones that are not essential are listed in an appendix. The requirements I have looked at are unambiguous, verifiable, modifiable and traceable as per IEEE guidelines. (Checking if they are correct, complete or consistent would require analyzing the whole document, which I did not do.)

Style
The IEEE and ACIS are written in scientific style, which reinforces the fact that they are well thought-out and formalized. The
ProcessImpact template is written in a more general language, in the imperative mood.