Pages

Monday, 3 June 2013

DAM-DAW. Project module

This document is authored by (in alphabetical order):
  • Moreno Pastor, José A.
  • Plana Lacasa, Robert

Presentation

Along this module you will work all the professional competencies related to your studies in a comprehensive way according to the module program.
You have to carry out the development of a specific application, from the very beginning to its full completion.
You will practise all you have learned within all modules belonging the CFGS you are enrolled in, the same way a professional developper does, including requirement analysis, application design and writing and documenting code.
You will be writing the code during the last weeks of this course, but some analysis and design work must be done previously in order to develop the application in a short period of time.
To do so, you must follow the guidelines that you will find here, and deliver your work the days set in the project module schedule stablished by your teachers.

Professional terms

project [ˈprɔdʒekt] Collection of writings, calculations and drawings made to give an idea of how an arquitectural or engineering work has to be done.
Agile software development Group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages fast and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle. The Agile Manifesto introduced the term in 2001. (from Wikipedia, 30/11/2012).
Actor In UML, an actor is a role played by a user or a system block that interacts with the application.
Use case A use case is a list of steps defining the interaction between an actor and the application.

Unit 1: Starting up

Estimated duration: 2 hours.
It's time to get to work. Once the working groups (1 or 2 students) have been formed and accepted by your teachers, the first task you are going to do is to choose the name and objectives of the project you are planning.
Try to explain clearly your intentions and the scope of your project.
Think about all the functional requirements, their priority and results. Think, also, about the target users of each functional requirement. Although you will deliver all this information lately, writing a brief description of these items is very useful when designing and plannig your developpement.
Use the project file indicated in the activity explanation.
Activity
Fill in the document Project file with the title of your work and a brief description of its intentions, main goals, target customers, technologies you are supposed to use, etc. and submit it to the virtual campus.

Unit 2: Planning your project

Estimated duration: 5 hours.
Title, Purposes, Functional and non-functional requirements, Use case diagram and their textual description, Entity-relationship diagram, Description of the methodology to be used and Project planning (Agile or classic approaching with Gantt: dates, tasks and resources with their costs).
Activity
Write a document with the analysis of your project and submit it to the virtual campus.

Unit 3: Ready to start?

Estimated duration: 5 hours.
Title, Purposes, Functional and non-functional requirements, Use case diagram and their textual description, Entity-relationship diagram, Description of the methodology to be used and Project planning (Agile or classic approaching with Gantt: dates, tasks and resources with their costs), as well as Class diagram and Case tests.
Activity
Write a document with the analysis of your project and submit it to the virtual campus.

Unit 4: The adventure begins now!

The daily routine in order to develop the project properly will be carried on following the “Agile Methodology” named scrum, this methodology has been explained in Project planning. So everyday must start with a Sprint named “Daily Scrum and Sprint Execution”.

Daily Scrum and Sprint Execution

Every day at the same time and place, the Scrum Development Team members spend a total of 15 minutes reporting to each other. Each team member summarizes what he did the previous day, what he will do today, and what impediments he faces.
Standing up at the Daily Scrum will help keep it short. Topics that require additional attention may be discussed by whomever is interested after every team member has reported.
The team may find it useful to maintain a current Sprint Task List, a Sprint Burndown Chart, and an Impediments List. During Sprint execution it is common to discover additional tasks necessary to achieve the Sprint goals. Impediments caused by issues beyond the team’s control are considered organizational impediments.
It is almost always useful for the Product Owner to attend the Daily Scrum. But when any attendee also happens to be the team's boss, the invisible gun effect hampers self-organization and emergent leadership. People lacking real experience of team self-organization won’t see this problem, just as fish are unaware of water. Conversely, a team that needs additional expertise in product requirements will benefit from increased Product Owner involvement, including Daily Scrum attendance.
The Daily Scrum is intended to disrupt old habits of working separately. Members should remain vigilant for signs of the old approach. For example, looking only at the ScrumMaster when speaking is one symptom that the team hasn’t learned to operate as a self-organizing entity.
In order to control all the tasks that must be made, a “Sprint Backlog” is designed. In this log the tasks are organised in for different levels according to the state of each task:
  • Committed backlog items.
  • Tasks not started.
  • Tasks in progress.
  • Tasks completed.

Assessment and qualification criteria

The final qualification will take into account the continuous assessment and will be calculated according to the following table:
Block Item Percentatge
Final documentation 35
Use cases diagram and their textual description 5
Test cases, test data 5
Class diagram 5
Entity relationship diagram 5
Project memo: initial planning, diary log, problems and solutions, final conclusions. 3
Analysis Usability and accessibility of web interfaces 2
Correspondence with initial functionalities 10
Source code 40
POO: encapsulation, inheritance and polymorphism 10
Multilayered design 10
Internal documentation 10
Innovation 10
Presentation 25
Effectiveness of presentation 10
Accurate answers. Strong knowledge of the whole application 10
Working demonstration 5
In order to evaluate the project, it is required that the application works properly. If application fails anyhow, the final qualification will be fail.
Correctness of writing will be taken into account.
A qualification equal or upper than 4 is required in each block to calculate the final qualification.
Quality criteria to evaluate the source code:
  • Object oriented programming is required.
  • Split classes into different layers. Model-control-view pattern will be appreciated.
  • Use of known design patterns: factory, observer, etc.
  • Flexible design.
  • Good internal documentacion of code.
  • Fit to standards.

Documentation schema for project module

Index

Description

This chapter should contain a brief description of the project. At least, it may relate the main reasons why you decided to do it, the most important goals to achieve, the target customers of the application, the needs it is supposed to satisfy and the technical characteristics of the programming and resources to be used.

Implementation

Explain here the characteristics concerning to technology: why you have chosen the languages, databases, etc. to develop this project.

Use case

Test case

Class diagram

Entity - Relationship diagram

Planning and project memory

Usability of interfaces

Conclusion

Source code

No comments:

Post a Comment