Project Based Training Programme
- 1. THE VALHALLA PROJECT Dhaval M. Anjaria
- 2. About me ● Former small time freelance developer. ● Worked on some small projects for individuals. ● Mostly stuck to C# with .NET 2.0 / 3.5 and basic IT support. ● No corporate experience. ● Some hiccups: Qt Project went bust, learned Android but no projects, major PHP based e-commerce thing didn’t happen, etc. ● However, wide range of skills in systems administration and development because of time. ● Worked on several different things in Cognizance 2015.
- 3. I like making Pasta. ● I like making “Aglio Olio”, which is Pasta in Garlic and Olive oil. ● I like it spicy, no cheese, crunchy with walnuts and cashews and I don’t mind if it’s a little roasted. ● My sister on the other hand likes very different kind of Pasta. She likes smooth, creamy, cheesy pasta. ● The pasta I make simply for myself, is very different from what I make for other people, especially if we have guests. ● Similarly, software engineers are not paid to turn caffeine into code. They are paid to make software that works for the customer.
- 4. Cognizance is the Pasta, Valhalla is how you make it
- 5. ● Ritu said it best, “We’re not getting anything but mere certificates for all the work we are doing”, which is true for most people. ● Cognizance 2015 was very productive (for myself). ● Learned PHP, practiced HTML5/CSS3/JS and some Photoshop.Got projects in Feb 2016 and August 2016. ● Worked on setting up OpenStack cluster, which failed spectacularly. ● Valhalla isn’t about solving a problem, as much as exploiting an opportunity. ● It uses Cognizance as an opportunity to learn and grow. The idea is to implement the theory we learned in college and in IT. The Problem and the Opportunity
- 6. The Valhalla Project ● “Valhalla” comes from old Norse mythology. The idea is that to go to heaven, you must die fighting. ● Created to manage and conduct Cognizance. ● Meta-project; which means that it is a project that pertains to conducting the Cognizance event. ● The basic idea is to apply the ideas of Software Development to managing a tech fest. ● Exists in the form of a document. It is basically like an RFC. ● In fact, the document was supposed to conform to RFC 2119. ● Provides guidelines and rules for projects to follow.
- 7. Inspiration: OS and SSAD ● In Semester II, we had two very important subjects: “Operating Systems” and “Structured Systems Analysis and Design” ● OS was about how an entire Operating System (and so how large software systems) are implemented. ● SSAD was a more classical approach to creating a systems. Introduced the concept of “The Analyst” and “The System”. ● SSAD presented a different, much more formal and structured approach to developing systems than what I was used to. ● Presented the SDLC as applied to entire systems. ● A lot of the ideas in the Valhalla project are taken from OS and SSAD.
- 8. The Primary Purpose ● The whole point of this is simple: to gain knowledge and experience. ● It uses Cognizance as a platform to try to implement the principles of Software Engineering to the management of a tech fest. ● Cognizance is a laboratory, a crucible, to experiment with stuff that we already know or want to learn and actually apply them in a real scenario. ● It creates an environment that gives us problems that we won’t face in a mock project. ● Basically, it uses the ideas of software development to conduct Cognizance in a cost-effective and productive manner.
- 9. Projects and Teams ● There are two basic ideas, “Projects” and their “Teams”. ● These are split completely into two categories: Technical and Creative. ● Each category will have a respective Lead. ● Technical refers to any project that uses computers extensively, and creative projects refer to anything else that is part of Cognizance. ● Each Project will be assigned to one Team and will fall under either Technical Projects or Creative Projects. ● Projects can have sub-teams that are part of sub-projects, but mostly these are very isolated from each other so as to reduce dependency. ● Structure is basically the MIS pyramid.
- 10. Flowchart Project is proposed or decided Submit Documentation Approval by Lead / Valkyrie Project commences Progress reports to Lead Presentation
- 11. Flow of Information (Greater amount of info) (Lesser amount of info) Docs, reports, budgets, etc. Approvals, decisions
- 12. Projects ● Projects are divided into two categories: Technical and Creative. ● Technical Projects are those which involve computers (primarily) and creative projects are all the rest. ● Projects refer to a goal that needs to be achieved, and it may or may not be towards the completion of the Cognizance event. ● Projects must also be isolated and mostly independent from each other. This is somewhat similar to concepts in Process Management and DBMS, (i.e. the ACID principles). ● The reason for this is so that the failure of one project does not affect any other projects.
- 13. Teams ● One team is assigned to one and only one project. The idea being separation of concerns, UNIX philosophy, etc. ● They would be reasonably autonomous. This means that they would decide which members to take, how to approach their project, what organization they would have and who would do what. ● Recommended maximum of five members, if there are more, they should be split into sub-teams. Sub-teams are associated with one sub-project. ● Teams should not share members. This is to reduce dependencies. ● The Valkyrie, in Norse Mythology, were the angels of Odin that decided the outcome of a battle. This way, the Valkyrie would decide which project would be considered for review by the Leads.
- 14. Budgets and Dependencies ● Document proposes that the budgets be separate. If there is a common budget, then a certain amount of money be set aside for both categories of projects, and subsequently for each project. ● Teams must also justify a budget. That is to say that a proper breakdown of where they’re spending the budget must be submitted to the Valkyrie. ● Projects could actually depend on the completion of other projects. For example, Snakes and Ladders technically depended on the completion of the Dice Throw project. ● Under Valhalla, it is recommended that if a team requires work from another team, they should enter something of a formal agreement to do this. It simply recommends that a process be followed and document.
- 15. Technical Projects ● Projects that require the use of computers extensively. ● Should use a new tool or development methodology. ● General Guidelines are: ○ Should be focused on tech. ○ Must implement a technology that the teams are mostly unfamiliar with. ○ Must have a presentation at the end. ● These projects would fall under the purview of the Technical Lead, since they would have the responsibility for these projects. ● The technical lead is answerable (and responsible) for these projects. This is because they would have an overview of all the projects, their needs, deadlines, etc.
- 16. Technical Projects done under Valhalla. ● Dice throw by Akshat Sharma. ● Online Examination System by Kishor Trimal. ● Android platformer game by Siddhant Kumbhar ● CS by Yash Atishay and team ● FIFA by Rahul Chettiyar and team ● Arduino bot by Dishant Dubey and team. ● Raspberry pi gaming system by Arvind Thevar and team. ● Website by Dhaval Anjaria
- 17. Creative Projects ● May not strictly follow Valhalla. This is because since Valhalla aims to apply the principles of Software Development, these principles may not be fully applicable to non-technical projects. ● Deadlines should be the dates of Cognizance and no presentation is required. ● Should not, in theory, interfere with the function of Technical projects and vice versa. Sharing of resources and personnel is also greatly discouraged. ● Threads and processes in OSes work this way. They have to be as separate as possible to avoid problems (eg, Race Conditions and Deadlocks)
- 18. Technical and Creative Leads ● Technical lead would be in charge of all technical projects and the Creative Lead for creative projects. ● Each lead would have authority to decide which projects may or may not be approved. This is because they would be responsible for all the projects under their purview and communication to the rest of the Valkyrie. ● This is so that the teams can focus on the project, the Valkyrie can focus on other things and in this way, we reduce dependencies and the workload on all of these parties.
- 19. Role of the Technical Lead ● Technical Support. ● Negotiations of Budgets ● Setting deadlines. ● Communicating and coordinating requirements, budgets, etc. for all the projects. ● Making sure documentation is in order. ● Setting a failure state. ● Coordinating presentations and deciding what should be covered in each presentation.
- 20. Role of the Creative Lead. ● Providing resources, time, etc. to each creative team. ● Managing between various teams and taking care of what work each team is doing. ● Coordinating a budget and keeping track of everything. ● Planning and organizing with each team with regards to how they will work together. ● Any sort of support that a team would require from other projects or the Faculty, etc.
- 22. General guidelines for both types of Projects ● Experimentation ○ Required to use new or unfamiliar technology, or some form of management (for creative projects). ● Documentation ○ Projects should submit initial documentation describing the project. ○ This includes Requirements, Feasibility review, Budget estimate, etc. ● Independence ○ Projects should be reasonably independent of each other. ○ It should also be reasonably able to meet its goals without dependence on other projects. ● Cost-effectiveness
- 23. General Guidelines (contd.) ● Failure ○ Projects must have the option to fail. ○ Failure may mean unable to reach a deadline or coming across an issue that cannot be resolved or not being able to reach the goals in the requirements document. ○ This is why “Valhalla” was chosen. The idea is, even if a project fails, the experience and knowledge gained from it would be invaluable. ○ This is why independence of projects and teams is crucial. ○ For example, when the project I had in February didn’t pan out, it wasn’t costly to me because I at least learned the Bootstrap framework for it.
- 24. Specific guidelines for technical projects ● Use of Technology ○ Technical projects must use a technology of methodology or something unfamiliar to at least one team member. ○ Eg, it is recommended that the Technical Project follow at least the Waterfall approach ● Budget and Expenses ○ Budget should be around 1000 rupees. ○ This is based on past experience and other factors. ● Documentation ○ Most important part of all of this. ○ Projects must submit an initial proposal to the technical lead. Once it is approved, they must submit a more detailed SRS.
- 25. Specific guidelines for technical projects (contd.) ● Documentation (contd.) ○ Projects must also submit progress report so that there is a written record of where each project is in their development. ○ Along with this, a written list of team members should be submitted to the TL. ● Deadlines ○ Deadlines must be decided by the TL by coordinating with other teams in Valhalla / Cognizance. ● Failure State ○ The failure state of a project may decided by several factors. ○ This could be decided by the TL, or the team members themselves. What constitutes as a technical project failing may be determined at a later date, but this is not really important as long as all the documentation is in order.
- 26. Specific Guidelines for Creative Projects ● Creative projects need not conform as strictly to these guidelines as technical projects. ● Budget and Expenses ○ A proper budget should be submitted to the Valkyrie ● Documentation ○ It is recommended that proper documentation be maintained similar to technical projects. ● Deadlines ○ Deadlines should be Cognizance. ● Failure state ○ May be defined by the projects themselves or the Creative Lead. ● Presentation or Workshop. ○ It is not necessary for creative projects to have a presentation or workshop.
- 28. Presentation and Workshop ● This is basically what Valhalla leads up to. ● Regardless of failure, all technical projects must submit a presentation or prepare a workshop detailing what technology or principles they have applied, what issues they faced, etc. ● The objective of these presentations would be to share the knowledge gained by a team with others, hence meeting the primary objective of the Valhalla project.
- 29. Lessons learned.
- 30. QA and Incentives ● One of the primary challenges as a Technical Lead, was that people weren’t properly motivated to submit Documentation. ● I believe the reason for this was that at the end of the day, there wasn’t a proper incentive for doing this. ● In fact, no QA measures or Incentives or any form of control was applied. ● The reason for this was to give people as much freedom as they need so long as the do something constructive. ● However, how well this worked out is another matter.
- 31. Time and Complexity of the Valhalla Project ● The project is not entirely simple. To explain it to someone took time and effort. ● This presentation should have been given prior to starting the project itself. ● There was a lack of motivation among the participants to follow these ideas, perhaps due to lacking incentives. ● A decision was made to not inform the participants of the individual projects, of the specifics of this project, to avoid confusion between Valhalla and Cognizance. ● One unfortunate outcome was that sub-teams were not properly formed where they should have and would have been useful.
- 32. Single points of failure. ● If you look at the structure, the leads are a single point of failure. ● If a lead is unavailable, the entire structure is lost. This actually happened. ● Fortunately the lead that was unavailable was quickly replaced and tasks were performed on time. ● Secondly, leads required understanding of the projects under their category, which if inadequate, would be very problematic. ● One of the purposes of maintaining proper documentation was in fact to mitigate this. ● In theory, a replacement could come in and because of the documentation, could pick up where their predecessor left off easily.
- 33. Relation to Cognizance ● A key point of concern was Valhalla’s relation to Cognizance. ● Technically, any forum could be part of Valhalla without contributing anything to Cognizance. ● Cognizance could be overtaken if Valhalla was followed to the letter, without regard for Cognizance. ● In fact, several projects had nothing to do with Cognizance at all but were still part of Valhalla. ● This extensibility may be a good thing, because it provides people a platform if they want to work on something in the future. ● However, technically, reading a book could also be a project under Valhalla.
- 34. The Potential ● The most important lesson to take from this is, in whatever form, it worked. ● Projects were completed with reasonable documentation. ● Participants learned far more than they could have (or would have) otherwise. ● Questions raised were answered quickly because of proper documentation and because a proper process was followed. ● Conflict and interference was avoided wherever the rules of isolation were followed. ● All in all, the opportunity this presents, and the precedent it sets is very promising