Assignment 2: "Inception and Elaboration"

Aims Objectives Task Submission

Aims

CSCI222 Spring Session, 2015

Assignment 2: “Inception and Elaboration” 15 mark group assignment

The aims of this assignment are to:

Provide more experience in structured group work;
Provide experience with the use of UML models for systems’ architecture, activities, and classes ;
Provide additional experience with a simplified version of the Rational Unified Process (RUP) approach to software development;

Objectives

On completion of this assignment, you should be able to:

1. Participate effectively in a RUP project working in one or more of the identified roles;
2. Explain “requirements elicitation” approaches;
3. Develop initial RUP artifacts including a “vision document”, glossary, requirements specification;
4. Develop “activity diagrams” that illustrate workflows, and “use case” diagrams that capture requirements; 5. Develop an architecture for a proposed application;
6. Work from an informal requirements specification to the definition of plausible implementation classes and

defined interaction sequences whereby the work of principal use cases is achieved.
The use of a version management tool for maintaining documents produced during the course of the assignment is advised, but it is not mandatory.

Notes:

1. There is . No C++ code required. (Use of C++

is a requirement of the system, and this will affect numerous design choices – but there is no implementation!) 2. You will need to produce some UML diagrams for your system. Your group can choose the editor that all

members will use.

Tasks

Your tasks are to:

no

implementation component in this assignment

1. Reorganize your group, re-allocating roles and responsibilities to your members (your members should be the same as in Assignment 1);
2. Complete the requirements analysis and design a “Exam System” that is described in the attached informal specification document.

3. Produce a report detailing the group’s work.
All groups face the same significant problem! This exercise is on exploring the initial phases of a software project – RUP’s “inception” and “elaboration” phases. In modern practice, essentially all methodologies require an enthusiastic “customer” representative integrated into the development team at these stages (this aspect is particularly emphasized in “Agile” methodologies but it also applies to RUP). You have no customer! Each group will have to fake the interactions with an imaginary customer when developing ideas for the “requirements”, “workflows” (activity diagrams), and “use cases”.

Group and roles

The roles required for this group assignment are less rigidly defined than for A2; you will probably choose to have:

Manager (1)
Systems Architect (1) “Requirements Engineer” (many) Analysts (many)
Designers (many) Documentation (many).

As in assignment 1, the book The rational unified process: an introduction by P. Kruchten should prove helpful in characterizing roles and responsibilities.

Each group will hold formal minuted meetings. The group member holding the “manager” role is responsible for these meetings, in particular preparing agendas and keeping meetings on track, and is also responsible for the reports on meetings. As noted in the lecture on “Team work”, the tenor of meetings will differ quite significantly between your initial “inception meetings” and your “elaboration meetings”.

Each group member will maintain a work diary. This should cover: planned work schedule, actual work times, and summary of work completed.

Your system

Well that is the object of the exercise!

Clearly the system has a client-server primary architecture, and a “repository” with a “data base” of some form holding records that can be accessed via different applications.

In a real development, the group would have to “spike” technologies with which they were not familiar; this work would form part of the elaboration phase. . You are to make your best effort at assessing the suitability of different technologies.

You should probably consider the following:
1. Use UML activity diagrams to model workflows (as suggested in the informal specification document, use your

imagination to flesh out missing details); this will help you understand how the system should work.
2. “Brainstorming”: the creative bit; you decide on how your system will be implemented and exactly what

functionality you will provide.

3. Primary “Use Cases” –

   You don’t have actual users to interview. Note the XP assumption of the dedicated user who is part of the team – you would really need different users as the usage patterns of the different users (fault-reporters/support staff) are distinct. You can never really have a dedicated user in the team, but in reality you would be able to interview sample users. You will have to invent the use cases for yourselves. Note that the support staff make multiple different uses of the system.

4. Now you know something about what you are building – draft the “Vision”.
5. First forays into architecture – how is it going to be realised. This would be where in reality you would start

   seriously considering risks and where you start to do some probing prototyping (XP spikes) to check your

   confidence with the technologies you were considering.

6. Try to complete “inception” and all its deliverables.
7. Make a commitment on architecture.
8. Review risks already identified and see if there are others. What do you propose to do about the risks?
9. Analyse those primary “use cases” using “boundary, control, entity” categories. What kinds of classes might you

   have?

10. Persistent data – what data do you need. Initial ideas for data table schemas or definitions of other storage

    structures.

11. Iteratively elaborate your analysis of primary use cases – i) categories, ii) sequence diagrams in terms of

    categories, iii) a first idea of classes, iv) sequence diagrams using classes.

12. Any other use cases identified? Explore them too.
13. Class definitions should now be becoming fairly complete (just as UML definitions).
14. Grouping of classes? Will you need to define any UML “packages”?
15. Use of existing components – partly resolved in your choice of architecture, but there are usually more detailed

    issues to consider.

16. Deployment issues.
17. Planning the construction iterations.
18. Baseline the executable architecture? Well this should be part of the elaboration phase, but that would take this

    exercise too far into implementation.

Report

The work of the group is to be presented in a report. Overall responsibility for the report lies with the person in the “manager” role, but each member will contribute.

The report is the basis for your assessment. The report should be concise; reports that are excessively long will be received unfavorably by the markers. The report has two distinct parts. One part presents your vision for the product, your requirements, your classes, your implementation plans. The other part is a “meta-report”, it documents the processes that you followed when completing the assignment. The entire report should use grammatically correct English and should not contain innumerable spelling errors. You should use the spelling and grammar checkers in your word processor application.

The report on the application should include:

• ·  Your vision.
• ·  A “context” section – really a combination of overview and “business case”. What is this “exam system” that you

  are to build? Who will it serve? What will it do for them? (Same as vision – but a few facts to leaven the

  inspiration.) (Optionally include activity diagrams).

• ·  Requirements – list and also use case style.
• ·  Risks and counter measures.
• ·  Architecture and deployment.
• ·  Persistent data.

• ·  Classes and sequence diagrams. Any related issues like “packages”, use of components.
• ·  Planned iterative construction.

  The “meta-report” part should include:

• ·  A tabular summary of the group structure identifying group members, the roles that they filled, the artifacts that

  they successfully delivered.

• ·  An honest summary of how much of the specification is covered in your solution.
• ·  The main report shows you final decisions as to architecture, data persistence, classes etc – the meta-report should

  provide some account as to how you converged from initial ideas to these finalized versions (not too long).

• ·  Group meeting records and individual diaries:
  • ·  There should be a summary detailing the work done at each group meeting.
  • ·  There should be an example agenda, and report from at least one of these meetings.
  • ·  There should be samples taken from the work diaries of at least two members of the group.

    Submission

    Your group is to submit a PDF formatted report file. This report file should be prepared in a word processor such as Word and “printed” to PDF file. (Note, a well prepared report on this task might be a useful addition to the “work portfolio” that you are preparing to show potential employers.) The designated group leader is to submit this report electronically using the turnin system.

    The due date for submission will be announced in lectures; the date will probably be around the middle of week 13 of session (currently set for Wednesday October 28th)

    turnin -c csci222 -a 2 A2.pdf

    In addition to the report, your group is to submit, in hard copy, its “member contribution assessment” document. This should identify the member contributions on the ordinal scale “contributed”, “some contribution”, “almost no contribution”, “no contribution”. This document should be signed by all group members. This document should be submitted in the Thursday lecture of week 13. (This is not required when all group members are content to receive the same mark.)

    Reminders:

  1. turnin isn’t chatty you don’t get email back
  2. You can check that your submitted file is safely submitted via turnout program.
  3. You should check that your uploaded PDF file is readable (use acroread on Unix); marks are lot for corrupted

     PDF files.

  4. turnin only works if you are logged in to banshee – use ssh if you are on a different machine or workstation. (If

     turnin complains that it doesn’t know about the assignment, you aren’t logged in on banshee!) You can use the Unix command uname –n to determine which computer you are logged into.

  Marks

  Mark breakdown

· Presentation of report 4 marks

This is a fairly large fraction of the overall mark. Much of “Software Engineering” is really just a matter of

communication with your stakeholders. Your markers are stakeholders. They want a report that is complete, clear, and concise.
Factors contributing to this portion of the mark will include: the clarity of the “vision” and “context” (business case), the overall structure of the report document, appropriate use of embedded images (modeling diagrams), layout of sections, indexing of the report, clear sectioning, English grammar and spelling, and general appearance.

• ·  Analysis and design efforts as evidenced by your report on the architecture, classes etc. 6 marks
• ·  Project management 5 marks

  These marks are based on evidence for the use of an effective software development process.
  Factors contributing to this part of the assessment will include: evidence for an effective group structure and adoption of roles; effective group collaboration as evidenced by meaningful group meetings; disciplined work processes of individuals.

  .