Welcome to our blog. We are the Team ABC. Following is a short introduction to our magic team and upcoming project.
Our Project
Our team is assigned to the task of designing and implementing a Money Management software capable of recording daily income and expenses and any related feature entailed. We are very excited about the project and can’t wait to get started on this exhilarating adventure.
Our Team
The name of our Team is “ABC”, which comes from the abbreviation of [A]lways [B]e [C]reative, an interesting creation of Deepak Togarla, who also designed the logo.
We are a small team of four interesting people from diverse backgrounds.
- Deepak Togarla (Electronics and Communication Engineering)
- Rahul Gurrapu (Mechanical Engineering)
- Revanth Kumar Kolla (Computer Science and Enginnering)
- Ashraful Islam (Electrical and Electronics Engineering)
Despite our interesting backgrounds, we are all students of Digital Engineering(M.Sc.).
We grouped together for the course Introduction to Software Engineering(ISEE) with the motivation of
learning about the fundamentals of Software Engineering and experience the life cycle of a software
development from idea collection to public release.
Complementary Skills
Our team is an excellent combination of complementary skills. Deepak brings creativity and fresh new ideas as well as team management skills while Rahul has extensive experience on software programming. Revanth with his background in Computer Science brings the knowledge of problem solving and software architecture while Ashraful has experience in code management and organization.
Being engineering students, we are all familiar with the importance of time managament and meeting deadlines while supporting other team members to successfully complete any project.
Responsibilities
Each of our team members are well familiar with programming as well as basic software architecture principles. But there should be some specific roles to avoid conflicts and duplication of effort. On the general discussion, following roles were initially delegated to respective members
- Requirement Specification and Documentation - Deepak Togarla
- Architecture - Revanth Kumar Kolla
- Implementation and Testing - Rahul Gurrapu & Ashraful Islam
Despite the concrete separation of responsibility, our work will merge during development process to avoid overloading one member or avoid wrong implementation of requirements.
Communication
Our team meets every week for discussion and progress.A constant contact is maintained in group on Google Hangout.
All non-code related documents are hosted on shared Google Drive so everyone has latest versions. All code will be hosted on github repository during development and testing phase so that every member of the group can work and update on their own convenient time. An strong emphasis is put on the communication because it is the core factor that helps to avoid misunderstanding, divergence of idea and ultimate failure of the project due to missing out.
Team Reaction to Changes
As with all software development lifecycle, changes will be introduced at later stages. Our team is well equipped to handle changes requested, as the ultimate goal of the project is to deliver something the customer wants.
We intend to follow strict guidelines to label each changes as one of the following
- Essential (Priority: High)
- Necessary (Priority: Medium)
- Wishlist (Priority: Low)
Depending on deadline, progress of the project and other factors, Essentials will be introduced first followed by Necessary. Any change that requires more than 20% change to the code-base at the time of the change requested, a negotiation is necessary to decide an alternative. If a requested change conflicts with an existing feature, a negotiation is also necessary.
Conclusion
Today, we had the initial meeting with our acting customer(and supervisor) Dr. Sandro Schulze. We collected the initial requirements for the project and will discuss and combine our notes so that all team members are on the same page about the requirements. Then we will continue to generate an overview of the fundamental behaviors for the application extracted from the requirements.
Stay tuned for our next post about the requirement analysis and initial outline of the application.
