Student Software Development Process Scott Heggen Computer Science Student Software Development Process

All slides originally developed and supported by William Peterson, LeanBP.com

Mission The Software Systems Developers provide technical solutions to Berea College through the design and implementation of software to solve Berean problems and provide technical and professional development opportunities to our students, while respecting the Berea schedule of students in the Labor Program, meeting College Business deadlines, and protecting institutional data. Vision Creation of a software development process that results in timely delivery of software to customers by capturing rework necessitated by customer collaboration in small feedback loops, providing developers quick answers to questions, avoiding development of code that does not target the customers needs, and reducing variation in lead times for delivery.

SIPOC Suppliers Inputs Policies Outputs Customers Berea College Community Internet System Request Problems Information(data) IS&S Policy FERPA Computer Abuse Act Faculty Manual Staff Manual Style Guides Soft systems Customer Support Regular Maintenance Improved Processes Features Professional Development Field Experience Learning Environment Tech Skills Students

Hi-Level Process Map Volume = 3-5 projects per year WIP = 3 Lead Time = up to a year Rework = 37.5% Constraint = Rework due to lack of customer awareness, defined process for developing software Hi-Level Process Map Receive request or problems Design potential solutions Iterate over prototypes to reach final solution Test final solution Document solution Deliver to customer

SWOT Analysis Internal External Strengths Weaknesses Threats Opportunities SWOT Analysis Internal External Institutional Support Tools Student Enthusiasm Communication/Teamwork CS Faculty Lots of Demand Lack of Tech Knowledge Outside of Group Security Rotating Students IS&S Policies Organization New Tech/Tools Students Process Communication Organization/Structure Time Budget Student Inexperience Logging

Gap Analysis Opportunities and Priorities Problem Statement: Developers lack a clear understanding of the customer’s goals.  Customers lack a clear understanding of benefits/limitations of software solutions.  These two constraints combine to cause a large amount of rework within the current process.  This delays delivery and decreases customer satisfaction.  Student programmers are not given a clear process for approaching new problems. This lack of awareness results in messy code that must be reworked.

Charter Mission – The Software Systems Developers provide technical solutions to Berea College through the design and implementation of software to solve Berean problems and provide technical and professional development opportunities to our students, while respecting the Berea schedule of students in the Labor Program, meeting College Business deadlines, and protecting institutional data. Burning platform – Increased demand for the services provided by the Student Software Development Team combined with limitations in student staffing require a reduction in rework to ensure delivery deadlines and customer needs are fulfilled. Process Description – Receive request/problem, design potential solutions, prototype, iterate over prototypes, until reaching a final solution, test the solution, document the solution, and deliver to the customer Problem Statement – Ambiguity and poor communications leading to missed and unclear deadlines. Sponsor –Derrick Singleton Process Owner – Scott Heggen Team Lead – Scott Heggen Facilitator – Scott Heggen Team – Scott Heggen, Cody Myers, Guillermo Ramos-Macias, Ishwar Agarwal, Robert Hosking III

Seeing the Process (Current Process)

Cause and Effect Diagram Lack Of Org. Focus Inventory Transportation Motion Waiting Defects Overproduction Undesirable Effect Over-processing Lack of communication  results in creation of  inventory of unused code. Poor understanding of  customers needs Production stalled waiting for ad-hoc meetings High % of re-work Time spent developing unwanted features Handoffs cause delays awaiting review

Examples of Lean Countermeasures Used Instituted weekly “Battle Rhythm” meetings with customers to decrease re-work and development of unnecessary code. Instituted daily “Scrum” meetings to increase situational awareness. Creation of “Standard Work” for process flow ensure improved understanding of customers needs, eliminate ad-hoc meetings, halt the over-processing waste of unnecessary features. Instituted WIP Boards for tracking individual activity as well as group progress Utilizing single-text negotiation through the use of Git repositories and Issue Queues

(Intermediate Process) Seeing the Process (Intermediate Process)

Results Summer 2015 (under current state): We ran 5 projects with 5 students in Summer 2015 Two completed successfully that summer Two were completed the following Spring 2016 One was scrapped.  Of the four that are deployed, three of them have undergone significant rework (see next summer). In all, 2000 hours of work completed this summer, resulting in four deployed applications An additional 1200 hours (approximate) of rework completed during the Fall and Spring (37.5% rework) Summer 2016 (under intermediate state):   We ran 3 new projects with 6 students in Summer 2016  We ran 3 continuing projects with 2 students in Summer 2016 (significant reworks from previous year) All six of the projects were finished by end of summer (though they were not live due to resource constraints imposed by another department) None will be scrapped Minimal rework on these systems is planned for the upcoming summer In all, 3200 hours of work completed this summer, resulting in 6 deployed applications An estimated 200 hours of rework completed during the Fall and Spring (4% rework) The elimination of rework resulted 1400 hours (approximate) of continued development of new features during the Fall and Spring 

Results 1200 hours of rework before 200 hours of rework after 1000 hrs * $30/hr1= $30,000 labor savings 1 - Berea College published labor rate for students in primary labor positions

Programmer Observations Student Programmer #1 reports: Improvements realized by the process change: The weekly scrum has been very useful for the weekly sprints.  The definition and scope of what we do have also been better established. The system of methods we used has helped the process and it has helped me improve and SHOW improvements to other. Remaining Challenges:   There is less communication between programmers. The phone is further away.  Exploring other aspects of Agile Student Programmer #2 reports: Standardization: With the way, our current system is setup it is now much easier to be able to jump into an unfamiliar project.  Coding Standards: Flask has provided us a better standard for separating different parts of the system according to the web framework model, view, controller. Whereas, with our old system they were all mixed in together creating confusion.  Learning Curve: I think the learning curve for flask is not as drastic as php. It's a little easier for our student programmers to pick up due to their prior knowledge in python.  Remaining Challenges: Community: Due to our growth and new projects our sense of community has decreased. It seems that the student programmers are more focused on their own particular project and only ask either Scott or the lead programmer for help. I would like to see more communication across different projects.  What Could Be Improved:  Security Checks: I can say with 100% confidence that all of our forms across all of our systems are built in a manner that doesn't allow escape characters. Documentation and Commenting: It's just not done enough.  Authorization: It really should be standard across all of our systems, and I don't currently think that it is. 

Faculty Observations Interdepartmental hand-offs still are not well-defined processes, and often still result in delays       (E.g., creating new servers from our IT dept.) Retraining each year A natural part of working with the labor program Significant learning among multiple dimensions must occur early for the students Standard work can help with this, but can’t solve

Call or email anytime, but send what you have so far Progress Check Call or email anytime, but send what you have so far