Project Tokyo status report

Hi,

We, the Project Tokyo developers, would like to provide a brief project status report:

Project management:

The sprint planning has been done according to the guidelines provided by the ASE course administration. Releases (=milestones) have been added to the pivotaltracker project whereas the releases including their deadlines specified by ikangai solutions have been mostly respected but adjusted where necessary. We believe that we will manage to fully implement the feature bundle “remote registry backend” which was marked as an optional feature by ikangai within the given time frame. In contrast, we believe that the feature bundle “registry frontend” which has been specified by ikangai in the Google Doc “Activities ASE” was not agreed on in the initial meetings (at least this was completely new to Bernd and me as we read the document). Also, the sprint schedule suggested by pivotaltracker proves that this feature bundle would not fit into our time frame. For this reason, we would suggest moving this feature bundle to after the ASE project has been finished (Yes, the team will continue to work on Project Tokyo even after the ASE course has ended).

Documentation:

Project definitions for the project Tokyo in general as well as for the two sub projects q-card and q-launcher have been created; the test plan has been started; the Gantt chart has been created; time sheets have been updated. Next steps will be finishing the test document as well as creating the domain model, design document, software architecture and non-functional requirements.

Implementation:

As of now, the q-framework features generators for q·.:card, vCard and meCard. The q·.:card application features a mockup screen which attempts to comply with the actual design specification for the application and shows a QR-code actually generated by the q-framework. Next steps will be the implementation of parsers for q·.:card, vCard and meCard formats as well as the implementation of the QR-code scanner. Also, the q·.:launcher project will be set up and some further investigation concerning Intents, starting apps and passing data on to them will be made.

Testing:

Testing has not actively been done as of yet. Next steps will be testing the q-framework’s generators as well as setting up the test suite and lay the foundation for a , e.g. JUnit tests as well as tests according to the Android test best practices.

Feedback:

As we got some constructive critique from the customer, ikangai solutions, we would also like to provide constructive critique to them so they can improve the collaboration on their end as well:
We have asked ikangai several questions which would have required ikangai’s answers in the past weeks, especially concerning the architecture and design of the q·.:launcher application as well as the remote registry and most of them have as of yet been unanswered. We would appreciate if ikangai solutions would face this project with the same professionality and reliability they demand from us developers whereas we are well aware that this has to be improved on both sides. We are already setting a trend to act more professional and and reliable and would appreciate to see that trend continue on the customer’s end.

Cheers,
Stefan A.

,
  • Delicious
  • Facebook
  • Digg
  • Reddit
  • StumbleUpon
  • Twitter

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>