offllne / psp Goto Github PK

Allows the User to modify the number of robots he wants in the parking lot

According to the functional requirement (#8), the program should show a comparison of the number of parking spaces between a standard car park and the Pit Stop solution. To do this, the user should initially manually mark the parking spaces.

When pressing the 'Make robot lot' button after manually marking some spaces, the manually set parking spaces still remain in their locations in the robot lot.

Steps to replicate:

1. Mark some parking spots: http://i.imgur.com/By6bxJY.png
2. Hit 'Make robot lot'
   Expected result: http://i.imgur.com/86ApJxn.png
   Actual result: http://i.imgur.com/fdYuYta.png

Testing what has been done by the 2nd Iteration

polishing whole app

User actions must not create menus/screens deeper than 3 steps

Currently no error displayed when choosing an incorrect file.

Mistake issue

Testing the whole program

Program Calculates two different optimal parking models based on the shape (a standard car park and the Pit Stop solution)

Implement car swapping/moving algorithm

Add details if you know anything to add. (eg where the programm will be done, what languages will be used etc.)
https://github.com/OFFLlNE/PSP/wiki/Welcome-to-Pit-Stop-Parking-Wiki-page!

The mockups of your application are not very understandable, in order to fix this, I propose to introduce within the mockups some arrows with comments and steps (numbers), for instance, 1) user selects new project, 2) draws parking places, 3) draws cars, 4) press button to calculate and so on.

Places parking spots too randomly

Program shows a comparison of the number of parking spaces between a standard car park and the Pit Stop solution(According to those examples there would be shown 16 vs 30 parking spaces)

Visual prototype which shows the difference between normal vs robot parking lot

Does not make parking spots near the pillars

User has to be able to choose the amount of cars currently in a parking lot

Allows the User to modify the rate at which cars enter and exit the parking lot

Debugging if there is anything problematic

Allows the user to draw the shape of the parking lot (including the doors, windows, elevators etc) from a jpg or other image file

Cannot save a .dat file

Prior giving feedback for 2nd iteration, please start making a quick check about the deliverables https://courses.cs.ut.ee/2015/tvp/fall/Main/Second-iteration

Detailed requirements.

The detailed requirements are consistent with the initial requirements, meaning that the development is going as expected. The detailed requirements also considered different flows, e.g., errors. Perhaps the only addition to the current format of requirements is what happens after an exception arises, e.g., a help window popup up showing how it has to be done, and one the user clicks ok, return to the application.

Finish the desktop application

Please find below the feedback from your work done in the 1st iteration.

Wiki
Homepage (Vision)

• Limitations can be set in order to define specifically the purpose of the application, e.g., it can be used just by developers, it can be used by any person, etc.
• Some text polishing could help to understand more clearly the vision of the application, for instance, it is not very clear what you meant by "The program will give the user Robot parking lot in the same space, but with more parking spots." You could start by defining the terminology used by your application, e.g., what is the purpose of the robot/platform in this context?

Functional requirements.

• Define the actors of the system. This can be easily fixed by providing an overview about how do you envision that the application will work. This can be written before staring your FR. In this manner, you can properly refer to a specific actor within your requirements. For instance, a user uploads a parking lot schema to the application. Currently, some requirements just generalizes functionality, which is not very clear to who is provided. Try to follow a format "X" does/should do/generates "Y".
• Some requirements are not very clear, more specific details are missing. For instance, what the properties required by the app to read a parking lot schema? what is the type of the image you are reading? when drawing the parking lot, how can differentiate a door from a window? and so on. Reading the critic section of this link may help to understand the issue (http://users.csc.calpoly.edu/~jdalbey/SWE/QA/nonfunctionalExamples.html)
• Entities of your application should be defined, e.g., what is a standard car defined? what is a standard parking spot? how many cars can fit into a standard parking spot? By reading the requirements I could assume multiple things, but this should be written concretly in order to avoid ambiguity.

Non-Functional requirements

• Try to locate non-functional requirements into a well defined category, for instance, 1. Performance, 1.1. The response time of the algorithm should be under 10 seconds for calculating the optimal distribution of cars in the parking lot, 1.2. The response time of the application should be under 2 seconds when interacting with the user. 2. Fault tolerance, 2.1....., 2.2.... 3. Reliability, 3.1...., 3.2.....
• It will be a good idea also to mention what is the alternative functionality if the application fails for all the requirements, for instance, the algorithm time is beyond 10 seconds, then what happens?
• Actually, there is a mismatch between the requirements 2 and 6. How are you planning to provide 2 seconds responsiveness if it takes 10 seconds to the algorithm to convert parking lot to a robot parking lot (whatever that means)
• This requirements also lack from clarity. For instance, (Robot amount has to be changable 1-2 clicks) and (Robot speed has to be changable in 1-3 clicks). It means that if the user provides 1 click, then the amount of Robots changed or Robot just speeds up? or do you mean that exact to click over the robot are required to change the amount of the Robot? same for the Robot speed.
• Finally, requirements can be associated to a priority in order to define effort and workload. Same with FR.

Project Plan

• Current plan is not consistent with the requirements, there should be an obvious mapping between the plan and how the requirements will be completed.
• Testing should be in every iteration when developing the application

Team structure.

• The roles are brief and clear. However it is unclear what back-end or front-end you will have. This means that requirements must be improved.

Team communication with the customer

• During the project, it would be good to schedule regular meetings, which are fixed.

Work process

• This section is fine, but it may benefit from some polishing and restructuring. For instance, you can start by saying what kind of methodology you will follow, e.g., SPRING methodology. Then, you can mention the technologies that you will use to manager your project, e.g., Trello and Toggl. Finally, you can describe the iterative process you will follow, this includes, integrating feedback from customer, releasing a version of the the application, verification of the feedback integrated in the latest release and so on. Naturally, as stated in this section, it is expected that in the future more details will be in place.

Wiki

• Meetings with the customer and mentor also should be linked from the homepage by a "meetings" page.
• Remember that during the project, once one requirement is done, then this has to be mapped to the requirement located in the wiki.

Issue tracker

• The milestone "Wiki has to be done" is in fact "1st iteration"
• As we discussed in the meeting, you can create a few issues, for instance, creating "functional requirements" and you can close the issue with a link to that page.

VCS.

• Issues and sub-issues should be linked (when applicable). Each commit should be associated their respective issue. Finally, remember to close each issue with the last token commit as seen in the meeting.

Transparency.

• Not graded in this iteration, but it has to be considered from now. This point means that all the requirements, wiki, issue tracker, etc. are well integrated. In short, there should be consistency in the project, e.g., the requirements of the wiki must match the issues of the issue tracker.

Iterative tuning

• This issue can be used for tuning 1st iteration deliverable. Thus, after you applied changes, it may be possible to extend the discussion.

Whole parking lot has to be "Fill-all" type, since the robots will be moving under cars

Help menu for user to see the meaning of different symbols when drawing the parking lot in the program

• Today 30/09/2015, we will have Skype meeting, we always can agree another time based on your convenience. In case all the team cannot be present, it is a good idea to talk about the progress with at least two team members. My skype ID is huber.flores

Testing what has been done for the 3rd Iteration

Add some details
https://github.com/OFFLlNE/PSP/wiki/Project-plan

Application UI is prototyped using wireframes or mockyps and the detailed requirements contain are linked to the corresponding UI screens.