Tampere University of Technology Department of Pervasive Computing TIE-13106 Project Work on Pervasive Systems Haamuryhmä/5 Valmet Power Oy - Continual Improvement Web Tool Project plan Markus Sinisalo: 211309 Susanna Sinisalo: 212250 Minna Viitanen: 218138 Tuomas Liikala: 240493 Aleksi Sinisalo: 212272 Tommi Kanervo: 206024
Version history Version Date Author Description 0.1 24.09.2014 MV Document first edit 0.2 25.09.2014 AS Added chapters 1, 2 and 3. Added chapter 4 introduction 0.3 26.09.2014 SS Added text to chapter 4 and 5 0.4 27.09.2014 MS Added text to chapter 6 0.5 28.09.2014 MS Added text to chapter 6 0.6 30.09.2014 AS, SS Modified the document, added text to chapters 6, 7 0.7 01.10.2014 AS, SS, MS, TL Added text to Chapter 5, 6 and 7 0.8 02.10.2014 MS Text modifications and fixes 0.9 03.10.2014 MS, SS Final document Last modified: 3.10.2014 16:58 2/17
Contents 1 Introduction...4 1.1 Purpose and scope...4 1.2 Product and environment...4 1.3 Customer's current system...5 1.4 Development constraints...5 1.5 Project constraints...5 1.6 Definitions, abbreviations and acronyms...5 2 Project organisation...6 2.1 Group members...6 2.2 Customer...7 2.3 Related organisations...7 3 Project goals and ending/termination...7 3.1 Goals of the project group...7 3.2 Goals of the customer...8 3.3 Goals and deliverable of the project...8 3.4 Quitting (termination) criteria of the project...8 3.5 Ending criteria of the project...8 4 Project management...8 4.1 Methods and tools...9 4.2 Monitoring and guidance...9 4.3 Learning and study plan...9 5 Project iterations and timing...10 5.1 Iterations...10 5.2 Iteration 0 (4.9.2014-5.10.2014)...10 5.3 Iteration 1 (6.10.2104-19.10.2014)...10 5.4 Iteration 2 (20.10-2014-2.11.2014)...11 5.5 Iteration 3 (3.11.2014-16.11.2014)...11 5.6 Iteration 4 (17.11.2014-30.11.2014)...11 5.7 Iteration 5 (1.12.2014-14.12.2014)...11 5.8 Iteration 6 (15.12.2014-28.12.2014)...12 5.9 Iteration 7 (29.12.2014-11.1.2014)...12 5.10 Iteration 8 (12.1.2014-6.2.2014)...12 6 Test and quality assurance plan...12 6.1 General approach...13 6.2 Definition of done...14 6.3 Special testing...14 6.4 Test documentation...14 7 Risk management...15 7.1 Risk list...15 7.2 Risk monitoring...16 8 References...17 Last modified: 3.10.2014 16:58 3/17
1 Introduction This chapter describes the purpose of this document and general information about the project and the product. 1.1 Purpose and scope This document is meant for the customer and the project work group. Its purpose is to provide the reader a view on how the project of developing the Continual Improvement Web Tool for Valmet Power Oy is going to progress. The document also states what is agreed between the project work group and the customer. Chapter 1 contains information about the Continual Improvement Web Tool that is the end product of this project. It also describes the environment where the product will be used, customer s current continual improvement system and the constraints of the project. Chapter 2 introduces the project organization i.e. the project work group members and the customer. Chapter 3 contains the project goals for both the project work group members and the customer and also the ending criteria for the project. Chapter 4 describes the project management practises of the project. This includes the methods and tools used, monitoring and guidance and the learning and study plan of the project work group. Chapter 5 describes the iterations that divide the project into smaller units. Chapter 6 introduces the test and quality assurance plans for the product. Chapter 7 includes the risk management of the project. Chapter 8 includes references. 1.2 Product and environment The product that is developed during this project is the Continual Improvement Web Tool for Valmet Power Oy Tampere Production. The product is replacing the previous continual improvement Excel based tool and the product is used in Valmet Power Oy Tampere Production Site in Lahdesjärvi. The product is used to create and view reports that are part of the continual improvement process in Valmet Power Oy. The reports can describe for example hindrances in production, risks noticed on site or problems noticed during audits. A person is assigned for each report who is responsible for taking action to improve the current situation. The main goals of the product are to provide an easy to use interface for creating the reports and to provide a way for the assigned persons to monitor the reports that are assigned to them. The product is designed around the principles of simplicity, usability and efficiency. The product is to be used with a web browser and the content will scale depending on whether the product is accessed by a computer or a mobile device. At first the user group consists of office workers in the Valmet Power Oy Tampere Production Site but later the user group may also include production site workers as report creators. The product design also takes into account that the product may be used in other production sites in the future. This includes assigning reports only to relevant production sites and providing support for localisation. The product is developed to be integrated with the production site s existing production management web tool. Last modified: 3.10.2014 16:58 4/17
1.3 Customer's current system Currently the customer is using an Excel based continual improvement tool in combination with whiteboards that are used for writing continual improvement reports. The purpose of the whiteboards is to be accessible for all production site employees with low effort. The reports are transferred from the whiteboards to the Excel based tool. The current Excel based tool is using filters to show relevant information to the viewer. It also includes several dozen columns and many of those contain yes or no type of information. The customer has stated the need for a simpler way to create the reports and for the assigned persons to view reports relevant to them. 1.4 Development constraints The existing production management web tool is written with PHP and JavaScript and it uses a MSSQL database. Therefore, the product is also developed using these technologies. The product is integrated as part of the customer s existing production management tool. Because of that, the product is using web styles similar to the existing tool. The styles are provided by the customer. The product is also sharing the user login with the existing tool. The product is developed in project work group members own environments and increments are pushed into customer s production environment after inspections are done by the customer. The product is developed to support all main browsers highest priority on Mozilla Firefox and Microsoft Internet Explorer. 1.5 Project constraints The project work group members have signed confidentiality agreement on not using or distributing the confidential information gained during the project. Intellectual property rights of the product are still to be decided with the customer. 1.6 Definitions, abbreviations and acronyms Project work group Product Project work group refers to the students specified on the cover page of this document. Product refers to the continual improvement web tool that is being developed in this project. 2 Project organisation This chapter describes the project organization. The project organization consists of the project work group members and the customer s representatives. Each project group member is introduced briefly by describing their experience and interests. This chapter also con- Last modified: 3.10.2014 16:58 5/17
tains the contact information of the project work group members and the customer s representatives. 2.1 Group members Susanna Sinisalo 0503276319 susanna.sinisalo@student.tut.fi Susanna has completed courses related to software development, testing, web programming and databases. She has some hands on work experience on software development with Visual Basic.NET, SQL, XML and C#. During TUT courses she has used C++/QT, PHP, HTML, CSS, XML, Ajax and JavaScript technologies. Markus Sinisalo 0503276356 markus.sinisalo@student.tut.fi Markus has done bachelor's thesis on software testing. He has completed different courses related to software development, testing, web programming, databases and hypermedia. He has some hands on work experience on software testing and test development (e.g. working with Powershell scripting and manipulating XML). During studies he has done two small project works with PHP, SQL and CodeIgniter framework and one project work with Javascript, Node.js and Ajax. During studies he has also used and got experience on C++, Qt, HTML, XML etc. Aleksi Sinisalo 0503276304 aleksi.sinisalo@student.tut.fi Aleksi has completed courses related to software development, testing, web programming and databases. He has some hands on work experience working with Scrum on C# ASP.NET MVC development, JavaScript, AJAX, jquery, Android development and application integration. Also during his studies in TUT he has completed courses where following technologies have been used: C++/Qt, PHP, SQL, HTML, CSS, XML. He is interested in server and client side programming. Minna Viitanen 0408652059 minna.viitanen@student.tut.fi Minna is studying software engineering as her major and hypermedia as her minor and has written her bachelor's thesis on web programming. She has completed courses related to software development, testing, web programming and user interface design. She has got some hands on work experience on web application design (both front-end and back-end). During her studies and work she has used and got experience on e.g. HTML, CSS, JavaScript, JQuery, XML, Ajax, SQL, C++, C# and also some experience on different frameworks (codeigniter, bootstrap). Minna is especially interested in programming the client side. Tuomas Liikala 0405913064 tuomas.liikala@student.tut.fi Tuomas has completed courses on user experience, testing, and software development. He has worked with a.net projects for two summers. Portfolio with more information: http://www.netikka.net/tuppul/ Tommi Kanervo Last modified: 3.10.2014 16:58 6/17
0405311754 tommi.kanervo@student.tut.fi Tommi is currently working part-time as a research assistant/software developer at TUT (developing a web-based tool, technologies used are mostly PHP with the Code- Igniter framework, JavaScript/jQuery, Ajax, HTML, CSS, and a postgresql database). He is studying software science as his major and hypermedia as his minor. He is familiar with multiple programming languages and web technologies including those he uses at work as well as C++/Qt and Python+Django. 2.2 Customer Valmet Power Oy, Production, Tampere Main Contact Person, Domain Expert: Jyri Palmu 0505559285, jyri.palmu@valmet.com Domain Expert: Marko Eleinen 050317814, marko.eleinen@valmet.com Domain Expert: Jussi Sinisalo, jussi.sinisalo@valmet.com 2.3 Related organisations Related organisation in this project is Tampere University of Technology. This project is part of Project Work on Pervasive Systems course and the progress of the project and its deliverables are monitored and inspected by the course staff. Some demos of the product will also be given to the other students on the course. Tampere University of Technology will also provide some guidance and lectures to help in the development of the product and in the organisation of the project related work. 3 Project goals and ending/termination This chapter describes the project goals and the termination and ending criteria of the project. Project goals are divided into project group s goals and customer s goals. These goals are also fitted together to produce the common goals of the project for the project group and the customer. 3.1 Goals of the project group The project group s first priority goal is to make a product that answers to customer s needs and expectations in the course s time frame. For the project group the aim is to first produce high quality product and then add any extra features desired by the customer. The second priority goal is to learn about project management, customer collaboration, delivering working product to the customer s production environment and developing software with agile methods as a development team. 3.2 Goals of the customer Customer s priority one goal is to get a working product that meets as many of the requirements as possible as the end result of the project. The product also needs to be Last modified: 3.10.2014 16:58 7/17
easy to use and its visual appearance and quality has to be up to standards with other products used by Valmet Power Oy. The product has also to be easy to use for all kinds of users working in the production site. Customer s second priority goal is to get a working version of the product and start piloting it as soon as possible. This way the customer gets to test the product in their own environment during the development and may notice any needs for changes in the product requirements. The product should have at least functionalities for creating and viewing the reports during year 2014. 3.3 Goals and deliverable of the project The customer and project group both want the product to be completed to a high quality usable version during the time frame set by the course. Both parties agree that the product has to be simple, easy to use and up to Valmet Power Oy standards. The product is to be implemented in small increments so working version of the product with limited but sufficient amount of features can be piloted during the year 2014. Both parties agree that the product quality is not sacrificed to make time for adding more features to the product. Minimum requirements for the final product are the ability to write, send and view continual improvement reports and a dashboard view which shows relevant information to the user currently logged in. The customer understands that the project is part of the project group s members studies and agrees to help the project group in learning customer collaboration and working in the business environment. 3.4 Quitting (termination) criteria of the project Project can be terminated if customer decides to withdraw. Withdraw may be caused by customer not being satisfied with the quality of work or the production velocity of the project team. Monthly project steering group meeting is held between the project work group and the customer s representatives to ensure that the project reaches its goals. This practise makes project termination extremely unlikely to happen. 3.5 Ending criteria of the project The absolute final end date for the project is 23.01.2014. On that date or earlier the final working version of the product is delivered to the customer s production environment. Any further development of the product has to be done outside this project. Customer may end the project on an earlier date if they are satisfied with the product. 4 Project management This chapter covers the project management practices of the project.this includes describing the methods and the tools used for communication, work collaboration, documentation and version control during the project. This chapter also introduces the monitoring and guidance the project group will exercise within the group and the external monitoring and guidance provided by the TUT course personnel and the customer. This chapter also includes the learning and study plan of the project group. The learning and study plan contains information about how the project work group is learning Last modified: 3.10.2014 16:58 8/17
technologies and practices they are not familiar with but which are needed to complete the project. 4.1 Methods and tools During the project a form of SCRUM will be used to make change management possible. There will be 6 sprints and at the start of every sprint changes will be handled. When changes arise they will be written down and changes to the features under development will be evaluated right away. Development of a feature can be halted until next sprint if necessary. Project work group will meet at the start of every sprint to discuss changes. Other times project work group will meet in Skype or organize a meeting at TUT if necessary. During the development all new features will be included in a cumulative way. After every iteration a new working version of the product will be produced. Skype and email will be used in communication between the project work group members. Documentation will be done in Google docs documents so all documents are available for project work group members all the time. Created documents are product requirements document, project plan document, testing report, functional specification document and final report. GitHub will be used as version control. Each member will have their own development environment and integrated code will be located in GitHub. 4.2 Monitoring and guidance Project work group members will regularly check other members code. Project work group members will also guide each other on technologies and software development methods they are proficient in. Project work group will send a progress report every week to TUT course personnel. Course personnel can then help with arising risks and difficulties. There will also be code viewings and meetings with course personnel to ensure that the project is progressing well. Project work group will meet with the customer once a month in a steering group meeting to show the customer new features and discuss the next iteration. The customer will provide guidance on integration with their existing production management web tool. The customer s representatives will also act as the voice of the users on the meetings. 4.3 Learning and study plan Each project work group member will study on their own and help others when they can. Markus Sinisalo is in charge of testing tools and will teach others how to use them. Group members will attend as many lectures and workshops as possible provided by the course to learn techniques needed for the project work. Last modified: 3.10.2014 16:58 9/17
5 Project iterations and timing This chapter lists all the project iterations and people related to them. This chapter also includes important deadlines for the project. 5.1 Iterations The iterations in this chapter contain rough estimate of what the project work group will be implementing during iterations. Table 1 below lists the deadlines for the project. Table 1: Deadlines Date Deadline. What should be ready? 3.10 Project plan, requirements document 3.11 Demoable version of the product 22.1 Final product, test report 29.1 End report 5.2 Final presentation 5.2 Iteration 0 (4.9.2014-5.10.2014) During iteration 0 requirements are gathered by meeting the customer and requirements document and project plan are written. Weekly reports are sent to course personnel. Minna Viitanen prepares document bases and puts them on Google docs. All project team members take part in writing the documents. Susanna Sinisalo prepares and sends weekly reports to course personnel. Work estimation is 8 hours per week for one person which is about 150 hours for the Deliverables are requirements document and project plan. 5.3 Iteration 1 (6.10.2104-19.10.2014) During iteration 1 the project work group installs development environment to their computers. The group also creates lightweight functional specification which contains database specification and module and function specification. During iteration the project work group will have a meeting with the customer to discuss the architecture of the product. Aleksi Sinisalo prepares and sends the weekly reports to course personnel. Tommi Kanervo stands in for Susanna Sinisalo as the project manager. Project work group creates the functional specification document as a group effort. Work estimation is 10 hours per week for one person which is about 120 hours for the Deliverable is the Functional specification document. Last modified: 3.10.2014 16:58 10/17
5.4 Iteration 2 (20.10-2014-2.11.2014) During iteration 2 the project work group creates their own development databases. The project work group starts to implement basic functionalities for example connection to database, navigation from main page to create report page. Aleksi Sinisalo prepares and sends the weekly reports to course personnel. Tommi Kanervo stands in for Susanna Sinisalo as the project manager. Project work group implements database and basic functionalities. Work estimation is 10 hours per week for one person which is about 120 hours for the Deliverables are the new functionalities. 5.5 Iteration 3 (3.11.2014-16.11.2014) During iteration 3 the project work group continues developing the functionalities. Project work group has meeting with customer to demo the product. Mid-presentation is held at TUT. Estimated features to be finished: report creation and modification, report list. Susanna Sinisalo prepares and sends the weekly reports to course personnel. Project work group implements functionalities. Work estimation is 10 hours per week for one person which is about 120 hours for the Deliverables are the new functionalities. 5.6 Iteration 4 (17.11.2014-30.11.2014) During iteration 4 the project work group continues developing the functionalities. Project work group aims to release a pilotable version of the product. Estimated features to be finished: report list filtering, dashboard view. Susanna Sinisalo prepares and sends the weekly reports to course personnel. Project work group implements functionalities. Work estimation is 10 hours per week for one person which is about 120 hours for the Deliverables are the new functionalities. 5.7 Iteration 5 (1.12.2014-14.12.2014) During iteration 5 the project work group continues developing the functionalities. Project work group has meeting with customer to demo the product. Estimated features to be finished: report commenting, notification to user about new reports. Susanna Sinisalo prepares and sends the weekly reports to course personnel. Project work group implements functionalities. Last modified: 3.10.2014 16:58 11/17
Work estimation is 10 hours per week for one person which is about 120 hours for the Deliverables are the new functionalities. 5.8 Iteration 6 (15.12.2014-28.12.2014) During iteration 6 the project work group continues developing the functionalities. Estimated features to be finished: report deleting, start tag handling page. Susanna Sinisalo prepares and sends the weekly reports to course personnel. Project work group implements functionalities. Work estimation is 5 hours per week for one person which is about 60 hours for the Deliverables are the new functionalities. 5.9 Iteration 7 (29.12.2014-11.1.2014) During iteration 7 the project work group continues developing the functionalities. Project work group has meeting with customer to demo the product. Estimated features to be finished: tag handling. Susanna Sinisalo prepares and sends the weekly reports to course personnel. Project work group implements functionalities. Work estimation is 10 hours per week for one person which is about 120 hours for the Deliverables are the new functionalities. 5.10 Iteration 8 (12.1.2014-6.2.2014) During iteration 8 the project work group continues developing the functionalities. Project work group writes end report and test report and has meeting with customer to demo the product. Final presentation held at TUT. Estimated features to be finished: extra features, refactoring. Susanna Sinisalo prepares and sends the weekly reports to course personnel. Project work group implements functionalities. Whole group prepares end report and test report. Work estimation is 10 hours per week for one person which is about 120 hours for the Deliverables are the new functionalities, end report, test report. 6 Test and quality assurance plan This chapter describes testing specific matters in this project. Also, testing methods, tools and ways of documentation are discussed. Last modified: 3.10.2014 16:58 12/17
6.1 General approach Testing will be done by the project work group on unit, integration and system levels. Markus Sinisalo has the role of main tester/test system designer but other team members take part in test design and implementation when their expertise on a certain field of area or specialized knowledge on a certain product feature is needed. Testing is planned to be started as soon as there is something to test. In addition, some aspects of test driven development can be used in the project which can help the developers to better implement the needed features and ensure that different special cases and error management is handled correctly straight from the beginning of the implementation of the product. The testing should consider both correct and incorrect use of the product or individual functions. The product is a web application and this should be taken into account during development to make the product smoothly testable. For testability it is beneficial that functions have clear responsibilities. On server side the functions for assembling the data for a request and the functions for providing the answer/opening a view for the client should be implemented separately for easier separate testing of data and how it is represented. On client side javascript the use of too numerous anonymous functions should be avoided to ensure testability. Also, the functions should have as clear responsibilities as possible. These responsibilities include for example data presentation & modification, application state and communication with the server. [1] In general the unit tests will be designed according to functionality described in the planned interfaces or function specifications of different modules and classes. Unit tests will be made available in version control and they should be executed by the project work developers before pushing new updates into version control. PHPUnit framework will be used for server side unit testing and Jasmine framework will be used for client side. Server side and client side will be unit tested separately and these unit tests shouldn t contain serverclient interaction to ensure easier identification of bug root causes. Selenium will be used in integration testing which enables the automation of browser based UI testing. This part of testing ensures that client side and server side implementations work well together [1]. Integration level testing might also include testing of functions that require cooperation of various individual modules (in server side or client side, not their interaction) if the unit tests don t cover all these cases. Currently there are plans to use continuous integration system Jenkins to automate integration testing when version control is updated with new content. Jenkins will be installed and run on Markus Sinisalo s PC. Running Jasmine tests as part of automation might require use of headless webkit (basically a way of running browser tests without opening a browser window [2]) such as PhantomJS. The used testing tools and frameworks will be assessed during the project work and adjustments to these choices and plans can be made in response to their observed performance. Customer is interested in piloting early versions of the product in everyday use and this will take part mainly on system level and will also provide information on product usability. This enables the project work group to get valuable feedback from real users during development. This kind of testing in the early development phases may be restricted to a certain part of the future potential users. Otherwise system level testing activities will be performed by the project work group during the development. Project work group members will test any new features added or changes made by using the web application in their own development environment when possible. This kind of testing is not supposed to be planned too much but will be an addition to unit testing. This kind of system level testing during development might give an idea if the Last modified: 3.10.2014 16:58 13/17
changes and updates are working as they should and especially if the current version of the product looks and feels as it should and if the usability of the product has been considered correctly. A more systematic and planned system level testing will be done in end phases of every sprint. This kind of testing will target the features added or affected in the current sprint and also important existing features. 6.2 Definition of done Feature is done when it is implemented, tested by the project work group, all known bugs are fixed and the feature is approved by the customer. 6.3 Special testing The product will be tested at least with Mozilla Firefox, Internet Explorer and Safari browsers which are the mostly used browsers within the customer s organization. Google Chrome may also be tested for compatibility. This browser testing can be done parallel to the system level testing activities described in chapter 6.1. Browser compatibility is also tested during integration testing with Selenium which can simulate different browsers. The product will also need be tested with ipad tablets because that will be the customer s main platform for mobile use. Testing with ipads will at least be done by the customer during their pilot testing. It also needs to be considered if the project work group can get access to an ipad device for this important part of hardware compatibility testing. Customer s pilot testing can provide information and feedback on usability. The quality of usability feedback may be improved by giving the users certain tasks to complete and provide them feedback questions to be answered on each task or the usability of the product as a whole. This may help the users to have a better idea which things to consider. Also, usability can be monitored by the project work group during system level testing activities. Project work group members can especially provide feedback on the usability of the features implemented by the other group members. 6.4 Test documentation There are plans that test logs will be generated for integration and unit level testing as part of Jenkins test runs. These logs should include debug output generated by test cases to enable a better and quicker way to pinpoint bug root causes. During developers unit testing the PHPUnit console logs should be able to be saved into text files for more detailed viewing and debugging purposes. Jasmine uses a special SpecRunner.html file for its testing and the output of this file acts itself as a visual test report in browser that the project work group members can make use of when trying to debug their code. PHPUnit offers a way to write test reports into XML files and Jasmine should have a similar solution available. Also, recent test results should be saved at least in Jenkins for identification of possible regression (failing of test cases that have previously passed). Last modified: 3.10.2014 16:58 14/17
System level test cases will be documented. System level test cases can vary from very simple to more complex use cases. System testing documentation can be used as a basis when executing sprint end system testing. 7 Risk management This chapter lists risks related to the project. The risks are divided into three categories: project group, customer and hardware/software. Risk tables include following information about risks: Risk - name of the risk, Causes - what may cause the risk to realize, Signs - how the risk can be identified beforehand, Avoidance - how to avoid the risk, Recovery - how to recover after the risk has realized, Size - how severe and probable the risk is on a scale from 1 to 5 where 1 is not severe and small probability and 5 severe and high probability. 7.1 Risk list Project Group risks are shown in table 2. Table 2: Project group risks Risk Causes Signs Avoidance Recovery Size Illness Member quits the course/disappears Members don t have enough time for the project Lack of clarity regarding tasks and responsibilities Catching a cold, accident Loses motivation or doesn t have time Busy with other projects Group members don t plan work properly or don t communicate Feeling ill Doesn t attend to lectures, doesn t answer to messages Weekly hours are low. No one seems to know what to do next. Nothing seems to get finished Customer risks are shown in table 3. Clothing according to the weather, avoiding dangerous sports All members commit to finishing the course Members try not to attend too many other courses and try to find time for project work Project work group members communicate often when developing new features. Distribute responsibilities to group members The ill person rests for a few days. Tasks are divided to other group members or postponed 2 x 3 = 6 Redistribute tasks 1 x 4 = 4 Make up for the lost time on later iterations or negotiate with customer to include fewer features Define and distribute tasks properly. Have a meeting with all the group members 2 x 2 = 4 2 x 3 = 6 Table 3: Customer risks Risk Causes Signs Avoidance Recovery Size Customer changing functional requirements Customer changes how some features work or removes features and adds new Customer doesn t seem happy with some feature Project work group tries to find out what customer wants early on so there won t be many changes to requirements Try to create the product in a way that allows modifications 3 x 2 = 6 Last modified: 3.10.2014 16:58 15/17
Customer is difficult to contact Misunderstood requirements Customer is busy and can t attend meetings or answer to messages Group members don t understand a requirement and don t ask clarifying questions Meetings are rescheduled, message response times are long Customer doesn t seem happy with some feature Define set days for meeting with the customer Asking why, why why.. Prototyping done on every iteration. Avoiding too massive documentation at the beginning. Agile methodologies Try to get as much information as possible from the customer while they are available Redesigning failed parts 2 x 3 = 6 1 x 5 = 5 Hardware/software risks are shown in table 4. Table 4: Hardware/software risks Risk Causes Signs Avoidance Recovery Size Version control issues Difficulties in installing and using tools Compatibility issues Changing chosen technologies Documentation lost Mistake with using version control causes trouble Tool has complex installation or is difficult to use Project work group has different development environment than customer s production environment Used technology is not capable of achieving what needs to be done Somebody deletes the files or files in Google drive are somehow deleted Group members are feeling that the version control is difficult to use Other people have had trouble with the tool. Multiple group members have problems with the tool Production environment is different. Product doesn t work in production environment Feature is not implemented because it s too difficult to implement with chosen technology Documentation is not found where it s supposed to be Define rules for the project work group to follow when using version control Read instructions properly and help other group members Try to make the development environment as close as possible to the production environment. Test in production environment. Do research and choose technologies so that the project work group is capable of implementing the product Taking backups frequently and saving them to a safe place Correct conflicts and and learn from mistakes Try again after reading more and getting help. Don t use the tool or change it Find out what is different in production environment and try to make necessary changes to the product. Learn new technology as quickly as possible and install required tools Using version control, recovering documentation or redocumentation 4 x 2 = 8 4 x 3 = 12 2 x 4 = 8 1 x 4 = 4 2 x 1 = 2 7.2 Risk monitoring Risks are monitored at the end of each iteration. Project work group members have a meeting to revise the list of risks and decide if any additional action needs to be taken to avoid certain risks. If some risks have realized during the iteration the group can assess how the same risks can be avoided in the future and if there is a need to alter the Last modified: 3.10.2014 16:58 16/17
avoidance plan. The recovery actions after a risk has realized are also analyzed and corrections to the risk recovery plan are made if necessary. 8 References [1] Murphey, Rebecca. Writing Testable Javascript. Full Frontal Javascript Conference 2012 [WWW] [27.09.2014] http://youtu.be/ozjogcfo4zo [2] Friesel, Rob. headless JavaScript unit testing with Jasmine and PhantomJS. 2012 [WWW] [27.09.2014] http://blog.founddrama.net/2012/09/headless-javascript-testing-with-jasmine-andphantomjs/ Last modified: 3.10.2014 16:58 17/17