project plan project plan - aalto university wikiplan.pdf · 3. to get research data of the use of...
TRANSCRIPT
Project plan
Project Plan
CloudSizzle
Version Date Author Description 1.0 18.6.2007 Vanhanen 1.1 23.9.2009 Jari Pääkkö Added my personal learning goals
1.2 12.10.2009 Markus Lindberg
Started writing:
2.1, 4.2, 5.1.3, 5.1.6, Divided up work.
1.3 14.10.2009 Janne Vanhala
Updated coding conventions and continuous integration sections
1.4 16.10.2009 Markus Lindberg Added project budget
1.5 18.10.2009 Jari Pääkkö Wrote the introduction 1.6 18.10.2009 Jari Pääkkö Updated the project goals
1.7
18.10.2009
Markus Lindberg
Wrote risk management procedures
1.8 18.10.2009 Jari Pääkkö Updated section 5.1.1 about iterative development
1.9 18.10.2009 Jari Pääkkö Updated section 5.1.2 about iteration planning
1.10 19.10.2009 Jari Pääkkö Updated section 5.1.14 about design 1.11 19.10.2009 Jari Pääkkö Removed the QA plan from the project plan 1.12 19.10.2009 Jari Pääkkö Updated sections 6.3 and 6.4
1.13 19.10.2009 Jari Pääkkö Updated section 5.1.13 on requirements engineering
1.14 19.10.2009 Jari Pääkkö Updated the risk log
Contents
CloudSizzle o Contents
1. Introduction 2. Stakeholders and staffing
o 2.1 Steering committee
o 2.2 CloudSizzle development team o 2.3 Other stakeholders
3. Goals o 3.1 Customer project goals o 3.2 CloudSizzle team project goals o 3.3 Personal learning goals o 4. Resources and budget o 4.1 Personnel o 4.1.1 Roles and responsibilities o 4.2 Materials and facilities o 4.3 Budget
5. Work practices and tools o 5.1 Practices
5.1.1 Iterative development 5.1.2 Iteration planning 5.1.3 Documenting 5.1.4 Risk management 5.1.5 Time tracking 5.1.6 Communication 5.1.7 Iteration demo 5.1.8 Defect tracking 5.1.9 Continuous integration 5.1.10 Version control 5.1.11 Coding convention 5.1.12 Process improvement 5.1.13 Requirements engineering 5.1.14 Design
o 5.2 Tools o 5.2.1 Development server o 5.2.2 Development tools o 5.3 Standards
6. Phasing o 6.1 Schedule o 6.2 Project Planning o 6.3 Implementation 1 o 6.4 Implementation 2
7. Risk log References
1. Introduction
This project plan describes the CloudSizzle system that is developed by the CloudSizzle team for Helsinki Institute of Information Technology (HIIT). This project is part of the Software Development Project course in Helsinki University of Technology and will be developed during the semester 2009-2010. This document will help communication between the stakeholders and will be kept up to date during the project.
The CloudSizzle system that is developed is part of the OtaSizzle research project that is coordinated by HIIT. The OtaSizzle research project studies mobile social interaction services in campus life. It develops new social services to be used by the community of students, employees and partners of the Aalto University. OtaSizzle provides an application programming interface, the so called Aalto Social Interface (ASI), that can be used to create new social services easily. Currently there are two existing services that have been built on top of ASI and that are published to a wide audience, namely Kassi and Ossi. [1]
The system that is developed during this project will be created on top of ASI. It will function as a social study planner for students. In the system students can create a study plan, share it to their friends, enroll to courses, invite friends to courses and utilize the social networks to collaboratively work on assignments in exercise groups and talk about course related matters in discussion channels. The system will gather course related information from Noppa and WebOodi and aggregate it in order to create a new mashup service for students.
The main motivation for the development of the system is to get an understanding of the Smart-M3 RDF store and how it can be used to enable interoperability between OtaSizzle services and third party services without making these services directly aware of each other. Thus, this project can be considered a research project and the service that is built is a prototype that may be expanded in the future, if the service becomes popular. The RDF store functions as a middleware for aggregating data and it helps to achieve loose coupling between the services that are used for the mashup. The CloudSizzle system will be licensed under the MIT open source license. [2]
2. Stakeholders and staffing
The following picture presents the project's environment.
2.1 Steering committee
The steering committee is the highest decision taking body in the CloudSizzle project. The steering committee is responsible for
Following up progress and costs of the project. Taking decisions about project scope, schedule and budget. Approving project deliverables
The steering committee meets once every month.
Members of the steering committee are:
Name Role Esko Nuutila Chairman Seppo Törmä Member Markus Lindberg Secretary Jari Pääkkö Member Shao Qiven Member
2.2 CloudSizzle development team
The following picture presents the cloudSizzle development team's organization:
Name Role Telephone email Markus Lindberg
Project manager
040 525 2043 first dot last at tieto dot com
Shao Qiven
Software architect
Jari Pääkkö
QA manager
050 532 5244
Kristoffer Snabb
assistant project manager
040 737 5576 [email protected]#[email protected]
Ville Koivunen developer 044 344
6918 vkoivune at cc dot hut dot fi
Yalei Xiang
assistant QA manager
040 726 2528 [email protected]
Bo Pang developer 046 633 4095
Janne Vanhala
developer 040 830 9090
jpvanhal at cc dot hut dot fi
Usman Hassan
assistant Software architect
050 408 2322 shassan at cc dot hut dot fi
2.3 Other stakeholders
Name Role Telephone email Esko Nuutila Project manager, SizzleLabs Seppo Törmä assistant project manager, SizzleLabs Juho Makkonen
Thesis worker, SizzleLabs
Jani Heikkinen Researcher, authentication and privacy, SizzleLabs
Olli Mäkinen Researcher SizzleLabs Martti Mäntylä Professor, HIIT manager Jari Vanhanen Course Teacher, SoberIt Kari Suhonen Team Mentor, SoberIt Timo Riihiaho Peer group project manager
3. Goals
3.1 Customer project goals
Table 1 describes the most important project goals for the customer. Table 1. Goals of the customer in the priority order
Goal
Evaluation criteria
1. To achieve loose coupling between OtaSizzle services and third party services with the use of the Smart-M3 RDF store.
The implementation uses Smart-M3 succesfully for data aggregation.
2. To get an understanding of how Smart-M3 works in practise and what benefits and disadvantages it has.
A report on advantages and disadvantages of the use of Smart-M3.
3. To get research data of the use of social media services.
The implementation uses the Aalto Social Interface that sends research data to Ressi.
4. To build a new useful service for the Aalto University students.
To have a well-functioning service that can be used to plan studies.
5. To have the social study plan done.
The requirements relating to the social study plan are done by the end of the project.
6. To attract more users to OtaSizzle by developing new services for them.
The number of users in OtaSizzle increases as a result of the system.
7. The system is easily maintanable and extensible.
A modular architecture and high inner quality of the system.
8. To convince other third party services to develop APIs.
Noppa and WebOodi develop APIs for their services in the near future.
3.2 CloudSizzle team project goals
Table 2. CloudSizzle team project goals in priority order
Goal
Evaluation criteria
1. Achieve good communication inside the group.
Everything is transparent inside the group and all group members know the responsibilities and tasks and are aware of the project status.
2. Achieve good communication to external stakeholders.
The project status is transparent to the mentor and customer and they now the project status and everybody understand each other in terms of goals and requirements.
3. Produce good and useful documentation.
The documentation meets the requirements set in the course process framework.
4. Iteration demos are good
There is a general feeling that the demos went well. Positive feedback from mentor, course staff or customer.
4. Apply the best software engineering practices for the project.
The software engineering practices chosen for the project help to achieve a successfull project outcome.
5. To meet customer expectations.
The final system meets the customer expectations and needs.
6. Achieve the personal learning goals.
The group members achieve their personal learning goals as stated in section 3.3.
6. Keep the planned No deadlines are missed and the estimated hour
schedule and hour budget.
budgets for tasks requirements and group members is somewhat accurate.
7. To win the quality award.
The group gets the quality award.
8. To get grade 5 of the project.
The group gets the grade 5 of the project.
3.3 Personal learning goals
Table 3: Personal learning goals
Member Personal learning goal
Jari Pääkkö
During this course I hope to be able to apply the theories and best practices I have learned on other software engineering courses and observe how they work in real projects. One of my personal learning goals for this course is also to get experience of being a manager for a group and to learn about the social aspects of being a manager. In addition, it will be interesting to work as part of a big international group for an open source project. I also hope to learn many new things regarding tools, technologies and software engineering from the other group members.
Pang Bo
During this project I want to learn how a software project runs from planning to implementing in Finnish Style, besides this I hope to study some new technology langauges and tools and to apply them to real software development. What's more, I will be very pleasure to contribute my power to build a easy-use software for Aalto University.
Yalei Xiong
This is the first project related to QA I practice. I want to assist the QA manager to obtain the experience I need. I also want to observe how Finnish implements a real software project with own management style. Besides, I hope to learn some new technology and toolkit. Wish we could get a better multi-national cooperation!
Kristoffer Snabb
During this course I hope to learn more about software management practices and try out different methods that I can´t try out in my real work. I also wish to learn about new tools that is not familliar to me. I also want to be part of a project which will deliver good software that will be used in practical situations.
Ville Koivunen
My foremost interest is actually seeing how a larger group works together. I am also interested in seeing the QA methods, especially testing and requirements engineering, applied in practice. And it is always interesting to learn new technologies as well.
Usman Hassan
My main learning aim in this project is very much the core reason of the project itself i.e. to bundle together a set of services by learning new and using existing/known tools and technologies (practically and professionally) in a way that is more helpful and efficient than using those services independently. I also want to analyze and improve on how such a system gets structured along with every development phase, because this system will have many new entries and ideas throughout development. Separating services is relatively easy but joining them is a challenging task.
Markus Lindberg
I also want to try out agile SW development practices and improve in facilitating these practices. The challenge is leading a team of people physically distant, with various cultural backgrounds and who I don't know beforehand to achieve a goal which I can't quite understand and using technologies that I am not familiar with and for a customer, who's needs are not clear to me. I also want to try out how new tools such as AgileFant, wiki and chat are able to support the project and find out what is still missing
Janne Vanhala
I'm interested in seeing how software development process works in real world project of this magnitude. I also want to learn new technologies and tools, and strengthen my skills in areas that I'm already familiar with.
Shao Qiwen
I want to learn how to design a web service based platform as an architect. How the documents should be prepared and how the design scheme should be prepared. How to design a successful architecture of the platform to match the requirements.
4. Resources and budget
Present the planned resources for the project.
4.1 Personnel
The CloudSizzle project team:
Table 3: Allocated effort - initial
Member PP I1 I2 Total Lindberg, Markus
48
36
36
120
Pääkkö, Jari
58,8
44,1
44,1
147
Shao, Qiwen
73,5
44,1
29,4
147
Hassan, Syed Usman
73,5
44,1
29,4
147
Koivunen, Ville
40,2
80,4
80,4
201
Pang, Bo
29,4
58,8
58,8
147
Snabb, Kristoffer
48
36
36
120
Vanhala, Janne
29,4
58,8
58,8
147
xiong, yalei
24
48
48
120
Total 424,8
450,3
420,9
1296
Availability information:
Usman Hassan - Not present(out of Finland) during the period 17.01.2010-30.01.2010 (i.e. after official project break[09.12.2009-17.01.2010])
4.1.1 Roles and responsibilities
Role
Responsibilities
Project manager
Manages project in accordance to the project plan Timely and problem-solving communication with the
Software architect, Quality assurance manager
Conflict-resolution and team building Collects metrics data (such as baseline, actual values
for costs, schedule, work in progress, and work completed) & reports on project progress
Manages the project budget Responsible for the timely delivery of documents Secretary of the steering group
QA manager
Evaluates the working of the software to assess quality Is responsible for requirements of the system.
Software Architect
Presents the system in a manageable model Is responsible for problem solving and guiding people to
the right
sources in case of problems
Scrum master
responsibility for the team's adoption of Scrum and practice of it.
Product owner
Is responsible for requirements of the system. Is responsible for prioritization of the requirements
Developer
Develop solutions according to the requirements Develop solutions according to coding standards and
other guidelines
4.2 Materials and facilities
The materials for the project include the following:
1. A (virtual) development server (Fedora Core 11) hosted at the CS lab containing the following services
o trac version 11.5 o django o subversion o smart-m3 version 0.9 beta o python version 2.6
2. Collaboration tools provided by third parties o Skype o Google docs o Irc
3. Documentation of the development platform o RDF (Resource Description Framework):
http://www.w3.org/TR/REC-rdf-syntax/ http://www.w3schools.com/rdf/default.asp http://www.w3.org/People/Ivan/CorePresentations/SWTutori
al/ o Smart-M3
http://smart-m3.sourceforge.net o Python
http://docs.python.org/contents.html o Django
http://www.djangoproject.com/ 4. A working room in the CS building A243 Next to the T4 lecture hall. Jari
has the key for now.
4.3 Budget
If the project were a real life project run by a small startup company, the pricing could be based on the following hourly rates:
- SA trio - 80€/h
- others - 60€/h
GIven these prices, the total project cost for the customer would be
414 h á 80€/h = 33120 €
882 h á 60€/h = 52920 €
Total: = 86040 €
5. Work practices and tools
5.1 Practices
5.1.1 Iterative development
The project will use an iterative and incremental development process that is based on Scrum. I1 and I2 iterations will be divided into smaller sprints with a duration of two weeks. These short sprints ensure that feedback is received as early as possible in order to react to changing requirements and other problems.
At the beginning of I1 and I2 iterations an internal iteration planning meeting will be held by the SE trio. The outcome of this meeting is an initial iteration plan that contains goals and high level tasks for the iteration. Shortly after the internal iteration planning meeting an iteration planning session with the customer is arranged. During this meeting the requirements that will be implemented in the upcoming iteration are analysed, prioritized and re-estimated in more detail. Moreover, the requirements and bigger tasks are broken down into smaller tasks and given responsibles. The task size should be small enough so that one person can handle it and be able to complete at least one task per week. If the task size grows too big, for example over 8 hours, it will be difficult to estimate the overall effort of the task. The requirements are prioritized by the customer, but the effort estimations are done collaboratively using the Delphi method by the team.
The SE trio will use the knowledge from the iteration planning meeting with the customer and refine the final iteration plan according to it. The architecture for the most important requirements and concerns will be worked on in parallel with the the requirements elicitation and analysis. The first sprint in each iteration will act as a planning sprint, during which requirements are elicited and analyzed, the architecture is refined and the tasks for the iteration are decided upon. After the first sprint the implementation will begin along with testing. Implementation and testing will be carried out in parallel as much as
possible. This way the testing activities will not be left till the end of the iteration.
In the beginning of each sprint a sprint planning session will be held. During this session the tasks for the upcoming sprint are planned. Furthermore, in the end of each sprint a sprint retrospective will be held that discusses what has gone well in the sprint, what can be improved and how can things be improved for the upcoming sprints. After each sprint a small increment of functionality should be ready so that the customer can evaluate it and give feedback in a sprint demo.
At the start of an sprint, the requirements for that sprint are frozen, meaning that they cannot be changed during the sprint. The sprint length will also be time-boxed, which means that the sprint length cannot be modified even if all requirements can not be completed during a sprint. If it is detected that all requirements and tasks cannot be completed during a sprint, the scope of the sprint will be reduced according to requirements prioritization and the uncompleted tasks will be moved to the next sprint. There will also be goals for each sprint, which will be assessed at the sprint retrospective. In short, each sprint will involve more detailed planning, some requirements analysis, design, implementation, testing and evaluation.
At the end of each iteration an iteration reflection workshop will be organized. The agenda of this meeting is to discuss what has gone well in the iteration and what and how things can be improved for the next iterations. In addition a demo will be held for the customer and course staff.
5.1.2 Iteration planning
In the beginning of each iteration, the SE trio has initial iteration planning meeting to discuss the goals and high level tasks for the upcoming iteration. Shortly after this meeting an iteration planning meeting with the customer and other group members will be arranged. The purpose of this meeting is to clarify the goals for the iteration, specify the requirements to be implemented and estimate their effort. Generally the prioritization of requirements is done by the customer and the effort estimations are done by the SE trio and developers. After these meetings the SE trio will produce an iteration plan that is updated during the iteration to reflect the latest situation.
5.1.3 Documenting
Documents to be delivered in the project, all deadlines refer to the schedule:
Document
Responsible
Delivery Format
Delivery Deadline
Reviewer
PP Iteration plan Markus PDF PP Iteration Jari, Kristoffer
delivery
Project plan
Markus PDF
PP Document delivery
Project group, Esko Nuutila, Seppo Törmä
Requirements document
Jari PDF
I1 Iteration delivery
Project group, Esko Nuutila, Seppo Törmä
Quality assurance plan
Jari PDF PP Document deliver
PP1 iteration demo slides
Markus
Powerpoint
I1 Document delivery
Architecture document
Shao PDF I1 Document delivery
Technical designs
Shao PDF I1 Document delivery
Test plans
Jari
PDF I1 Document delivery
Test results
Jari PDF I2 Document delivery
Project final report
Markus PDF ?
Handover checklist
Shao PDF
I1 Document delivery
Iteration 1 demo slides
Jari
Powerpoint
I2 Document delivery
Iteration 2 demo slides
Markus Powerpoint
I2 Document delivery
QA Report [iteration 1]
Jari
I1 Document delivery
QA Report [iteration 2]
Jari PDF
Test cases and Jari Spreadsheet
test log matrix
Meeting notes Secretary Wiki
The final deliverable documents are stored under the Cloudsizzle wiki site. The working copy of each document is managed in Google docs accessible to the whole cloudSizzle team unless indicated otherwise.
5.1.4 Risk management
Risk management consist of:
Risk identification, where risks are identified. A risk identification workshop will be organized in the beginning of iteration I1. The identified risks are logged and documented.
Risk analysis attempts to evaluate the impact and probability of each risk on the scale low - medium - high. The product of these values gives the exposure value for each risk.
Risk controlling actions attempt to reduce probability of the risk occuring or limit the impact of the risk. Controlling activities need to be planned for the high exposure value risks.
Risk monitoring is the responsibility of the steering group and the project manager. New risks may and should also be logged whenever they appear.
5.1.5 Time tracking
During the PP iteration, the project team members report their spent hours onto the common GoogleDocs spreadsheet, and the project manager follows up spent hours on a weekly basis.
During iterations I1 and I2, time reporting will be done in Trac. We are using trac plugins like timeandestimation and scrum burndown which helps the project managers to follow up the spent time versus the time estimated time needed to finish some task or iteration. Everyone should add tickets to trac and assign added tickets to one person. The assigned person is responsible to provide accurate information about the ticket and change any faulty information included in the ticket report. When a ticket is created the estimated time have to be added and the ticket assigned to somebody. The new tickets have to be approved by one of the SE group members. The SE group member also decides when the work on the ticket should be done. The SE adds the ticket to a sprint or to an longer Iteration which will add the estimated hours of the ticket to the estimated hours of the sprint/iteration. Trac with the scrum burndown plugin will give a good overview of the state of project for the project manager.
5.1.6 Communication
Language
All formal and written communication including all documents produced in the project is in English.
The virtual working room on IRC.
Anybody interested / participating in the project should be monitoring and communicating on the #cloudsizzle IRC channel. IRC channel is hoped to provide the closest possible equivalent of a shared room. Instructions are in the cloudsizzle wiki.
Regular meetings:
Iteration planning day Each iteration begins with a planning day where the iteration is planned.
Participants: Project Manager, Software architect, QA manager Agenda:
1. Iteration target - presented by the QA manager 2. Solution architecture - presented by the software architect
Weekly wrap-up takes place every week on Friday from 15:00-16:00 over Skype
Participants: CloudSizzle-devel Agenda:
1. Developer walk-through: What did you do this week. Review hour reports. Any problems.
2. Tasks for next week. QA manager prioritizes. Assignments, work amount estimates
Steering committee meetings are held every 3 weeks.
Participants: Project Manager, Software architect, QA manager, customer representatives
Agenda:
1. Opening the meeting - The customer 2. Project status and progress report - presented by the project manager 3. Project financial report
4. Risk list review 5. Communication 6. Next meeting
Organizing meetings:
The meeting organizer books the meeting in the cloudSizzle google calendar
The meeting organizer invites each member to the meeting by
Mailing lists:
Developers: [email protected] All cloudsizzle concerned people: [email protected]
Tools
Trac will be handling the hour reporting and the task management. Trac sends emails of updates and other changes to tickets which will take of the other communication load.
Trac has also the benefit of letting the customers follow up on how the project is evolving.
5.1.7 Iteration demo
The software demo will be prepared under the software architect's leadership. The project demonstrations will be held by the project manager or by his stand-in. The QA will be providing quality for both the manager and the architect.
5.1.8 Defect tracking
Defects are reported to trac as tickets. The ticket type should be set as defect and the other fields in trac ticket reporting should be filled in with care. The ticket is always assigned to somebody and the time estimate to fix the defect is attached to the ticket. The new defect tickets should stay in the new state until one of the SE approves the ticket and the work can begin for fixing the defect. The person that has been assigned a ticket is responsible of taking care that the ticket task, defect or other will be fixed or otherwise handled wisely. Also other inaccurate information in the ticket should be updated by the assigned person. The defects and all other trac tickets have the possibility for comments and discussion which makes communication about defects easier and the possibly unclear ticket tasks or defects can be brought to a conclusion faster. Everyone should provide all possible help in the form of discussion to the defect tickets.
5.1.9 Continuous integration
The development server will have a continuous integration plugin for Trac called Bitten. It will be configured so that for every revision it will check out the source from version control, run the unit tests, gather code coverage data, check the code conventions, and build a distribution package. Developers will be notified by email if the build fails.
5.1.10 Version control
Subversion on the development server is used for version control. Branching and tagging policies are managed by the Software architect and communicated during the planning day.
Check in frequency should be frequent. Every day the developer has done something he should be able to commit his parts without any testing failure from bitten.
5.1.11 Coding convention
For Python code, the coding conventions in PEP-8 (http://www.python.org/dev/peps/pep-0008/) should be followed. These are also the conventions followed by the Python standard library and Django. For writing good quality docstrings, the conventions in PEP-257 (http://www.python.org/dev/peps/pep-0257/) should be followed as recommended by PEP-8.
A tool called Pylint is used for checking that the Python coding conventions are followed. Pylint will be integrated with the continuous integration tool.
5.1.12 Process improvement
The weekly wrapup meeting has a short reflection section to reflect on the week before. At the end of each iteration, a separate reflection workshop is held by the team. Each process improvement initiative is discussed and the resulting improvement tasks will be entered into Trac.
5.1.13 Requirements engineering
The requirements engineering activities will follow the process defined in the course framework. In the PP iteration the main goal of requirements elicitation is to get an understanding of the business goals, main domain concepts, user groups and functional requirements, non-functional requirements and constraints of the system to be built. During the PP iteration two requirements elicitation meetings have been arranged with the customer, where these matters have been discussed. Furthermore, the requirements are analyzed and the most important requirements are documented. A rough estimation on
customer value, effort and impact to architecture is also made on these requirements.
In I1 and I2 iterations the requirements will be analyzed again and documented with greater detail. A requirements elicitation meeting with a user will also be organized. In the beginning of I1 and I2 an iteration planning meeting will take place, during which the requirements are prioritized and the requirements to be implemented in the particular iteration are chosen. The group will then estimate the effort of the requirements and the requirements that are implemented are written as use cases. During the iteration the requirements will be reviewed and validated in the beginning and after each sprint. Change management and requirements management will be done during the whole iteration in parallell with the implementation. All of the implemented requirements will also be traced to test cases in order to ensure that the quality goals are achieved. The requirements chosen to be implemented are always reviewed with the customer and project group in order to avoid ambiguity and other errors regarding them.
As described in section 5.1.1, each iteration will be divided into smaller sprints. The requirements are frozen for each sprint, but before each sprint and after each sprint the status of requirements will be updated. The short sprints ensure that feedback on requirements is received frequently. Short sprints also ensure that it is possible to respond to changes regarding requirements as soon as possible. This helps to achieve the goals of meeting customer expectation and needs. The progress of requirements will be updated in the requirements document. The requirements elicitation, analysis and management is an iterative process that will be carried throughout the project.
5.1.14 Design
The architectural design begins with capturing the needs of the customer. The requirements document will serve as an input for this as well as meetings with stakeholders. The initial scope and context are defined in the beginning. Later the architecturally significant concerns of stakeholders are identified and documented. The most important concerns will be used to identify important scenarios that the system must handle. Usually these have to do with quality concerns that are architecturally significant decisions. Considering the architecturally significant concerns, different architectural style and design patterns will be assessed. The evaluation of architectural styles and design patterns will produce a candidate architecture. The candidate architecture and its alternatives will be evaluated. Finally, the architecture will be validated using a predefined process for architecture validation. During the architecture definition process, the architecture will be reworked till it is acceptable. The architecture definition its different views and viewpoints are then used to describe the low level design of the system.
5.2 Tools
We are going to use the following tools:
Trac version 0.11 Time and estimation plugin for trac scrum burndown plugin for trac bitten continuous integration plugin for trac subversion m3 beta version 0.9 can be found on source forge Python version 2.6 (we cannot use 3.1 because most Python software
(including Django) are not yet compatible with the backwards-incompatible changes introduced in 3.x series)
Google Docs for writing documents Google Calendar IRC Fedora 11 development server
5.2.1 Development server
The development server is a virtual server provided by the SizzleLabs and run by the CS department it services. It is a Fedora 11 development server.
5.2.2 Development tools
Tool
Version
License
Availability
Trac
0.11.4
BSD
http://trac.edgewall.org/
Timing and Estimation Plugin for Trac
0.8.0
MIT
http://www.trac-hacks.org/wiki/TimingAndEstimationPlugin
Bitten Continuous Integration Plugin for Trac
0.6b2
BSD http://bitten.edgewall.org/
Scrum Burndown Plugin for Trac
1.9.2
Apache License 2.0
http://stuq.nl/software/trac/ScrumBurndownPlugin
Subversion Apache License
http://subversion.tigris.org/
Smart M3 0.9beta
BSD
http://sourceforge.net/projects/smart-m3/
Python 2.6 Python http://www.python.org
Software Foundation License
Django MVC framework
Summary of all tools used. Mention version numbers and availability information, if relevant to the project. Description of all development and test environments that are needed; both software and hardware environments.
5.3 Standards
Coding conventions are specified in section 5.1.11.
6. Phasing
6.1 Schedule
Schedule below shows the externally imposed schedule. Internal deadlines are managed in Google Calendar.
Event Date Time Place Notes / Deliverables Delivery of iteration plan for PP
2.10
13:00
PP Iteration plan
Delivery of all documents
19.10
13:00
Project plan, Requirements document and slides for iteration demo
Iteration demo
20.10
17:00-18:00
Innopoli 2
Presentation of slides
End of Project Planning (PP)
21.10
Beginning of Implementation 1 (I1)
22.10
Delivery of Iteration plan (I1) and QA plan
28.10
13:00
Iteration plan + QA plan
EES for QA Managers
3.11
16:15-18:00
Innopoli 2
Topics for session
EES for Architects
10.11
16:15-18:00
Innopoli 2
Topics for session
EES for Project Managers
17.11
16:15-18:00
Innopoli 2
Topics for session
EES for Usability Engineers
24.11
16:15-18:00
Innopoli 2
Topics for session
Delivery of all documents
7.12
13:00
Project plan, Requirements document, Technical specification (at least the general architecture), Test cases, QA report and test log + slides for the iteration demo)
Iteration demo
8-9.12
16-18?
Innopoli 2
Presentation of slides
End of Implementation 1 (I1)
9.12
Christmas vacation (if you so prefer)
10.12-17.1
Beginning of Implementation 2 (I2)
18.1
Delivery of Iteraration plan (I2) and QA plan
20.1
13:00
Project plan, Requirements document, Technical specification, Test cases, QA report and test log, Peer test session charters, Peer test summaries, User's manual, Final report, Slides for the iteration demo
Delivery of final system and testing guidelines
15.2
13:00
Final system + testing guidelines
EES for Project Managers
16.2
16:15-18:00
Innopoli 2
Topics for session
EES for Architects 17.2
16:15-18:00
Innopoli 2
Topics for session
Deliver testing results to peer group
18.2
13:00
Testing results
EES for QA Managers
18.2
16:15-18:00
Innopoli 2
Topics for session
Delivery of all documents
22.2
13:00
Complete project documentation
Iteration demo
23-24.2
16-18?
Innopoli 2
Presentation of slides
End of Implementation 2 (I2) and project (whew!)
24.2
Legend:
Document deadline Begin/End of Iteration Final system delivery
6.2 Project Planning
The goals, deliverables and Tasks for the project planning iteration were presented in the PP iteration plan.
6.3 Implementation 1
This section gives a view of what goals, deliverables and tasks will be implemented during Implementation 1 iteration. At the moment this section is very brief, but it will be updated in the beginning of Implementation 1 iteration.
Goals:
Architecture
define scope and context identify the most important stakeholders identify the most important concerns of the stakeholders identify the most important scenarios regarding the concerns evaluate architectural style and design patterns construct views and viewpoints to clarify the architecture to different
stakeholders evaluate alternatives for the architecture validate the architecture
QA
define overall quality goals define quality goals for the iteration define QA practices evaluate the QA practices during the iteration produce a quality dashboard of the system and update it during the
iteration summary of defects and their status test cases for the requirements that are implemented in the iteration
Requirements engineering
prioritization of requirements decisions on which requirements will be implemented during the iteration refine the requirements that will be implemented
Infrastructure
Development environment set up
Deliverables:
Iteration plan Updated project plan Updated requirements document Quality assurance plan Architecture description Test cases Test log and charters Progress report First prototype of the most important requirements of the system
Tasks:
Writing the iteration plan
Updating the project plan Updating the requirements document Writing the QA plan Writing the architecture description Writing test cases Writing test logs and charters Updating the progress report Implementing the system Identify and control risks
6.4 Implementation 2
This section gives a view of what goals, deliverables and tasks will be implemented during Implementation 2 iteration. At the moment this section is very brief, but it will be updated in the beginning of Implementation 2 iteration.
Goals:
Second version of the system ready for use
Deliverables:
Iteration plan Updated project plan Updated requirements document Updated quality assurance plan Updated architecture description Test cases Test log and charters Progress report Improved version of the system
Tasks:
Writing the iteration plan Updating the project plan Updating the requirements document Updating the QA plan Updating the architecture description Writing test cases Writing test logs and charters Updating the progress report Implementing the system Identify and control risks
7. Risk log
ID Risk Prop. (1-10)
Sev. (1-10)
Exposure Effects Mitigation
actions Controlling
actions Responsible
1
A developer quits in the middle of the project.
3 8 24
Crucial knowledge is lost.Project scope must be decreased.
Taking care of good team spirit. (avoiding)The development work of critical parts is done using pair programming. (minimizing effect)
Project manager
2
The setting up of development tools will be delayed or generaly fail.
3 5 15
Time will be lost and project tracking will not be accurate enough.
Find out other ways and tools to follow up the project, and inform the other members of the team of changes.
Project manager
3
A developer will be lost in translation
5
4
20
Some tasks might be undone and stress the other developers
Make sure everyone has got the information and understood it correctly.
Project manager, QA, Architect
4
Communication problems inside the group
9 9 81
Responsibilities and tasks are unclear, motivation decreases
Clearly defined communication practices and retrospectives.
Face-to-face meeting between all group members
Project manager
5
The architecture description is unclear
4 8 32
The development of the system will be delayed
The documentation of the architecture is started early enough so that the developers have a design by the time
Architect
they are starting development.
References
A list of references.
[1] OtaSizzle. http://www.sizzlelab.org/ [2] Project assignment description. http://www.soberit.hut.fi/T-76.4115/09-10/topics/proposals/tkk-cloudsizzle-2.doc