CSSE3002 Lecture Notes - Lecture 5: Business Process, Use Case, Process Modeling
28 Jun 2018
School
Department
Course
Professor
Release Planning
-Coherent chucks of functionality that could be delivered to the public and used by
them
-Release most important first, followed by lesser importance functionalities
-Stories has priorities, for example there are 5 must-haves that are not related to each
other. Then it will be cumbersome to deliver them, because these functionalities do
not make a coherent package, need to have coherent package as deliverable. Hence
fit other high priority stories in early deliverables
-The first release: smallest chunk of functionality and provides value
-What is the next important deliverable? (stage or incremental delivery. Each stage
delivers additional value)
-Part of the art of planning is figuring out what is feasible
-It has to be deployed somewhere tested by people who are familiar with the
environment (alpha testing, beta testing, institute testing)
-Know what is the actual overhead (e.g. oracle use extreme programming and have 2
weekly sprints, to have something delivered, a lot of sprints in a release)
-cost of deployment (how frequent, how big are the releases)
Release planning is not prioritisation
-has a relationship but not equal
-what makes a nice complete package to deliver
-e.g.
orolled out msn in aust. Initial release: big monstrous site, couldn’t break out
into smaller chunk
ohad expectations from the client, based on their perception of the Australians,
couldn’t just deliver one tv channel
otook long time for initial release
Release planning roles
-customer representatives and developers
-not input just based on dependency, must be coherent sets of functionalities
ofor msn want ketchup TV facilities (back-end), requires interface into the
system
ohave to convert, not stored in a format that can be streamed
oall have to be done to release the ketchup TV service
Release planning example
-Internet banking system: bunch of stories
find more resources at oneclass.com
find more resources at oneclass.com
-Break them up into deliverable chunks
-(must have) presume it will happen early
-release plan is not based on priority but influenced
-Stuffs that are out of scope will be “wont have”
Internet Banking example release plan
-Internal Releases
-External Releases (Minimum Viable Product) first thing to release to the public
-Nice comprehensive set of features to not be embarrassing for the non-technical
customers
-E.g. Transfer money for BPAY (think about security, reliability can implement later
internal release 2) for feasibility demonstration
-Internal releases: smaller releases, for business reasons not to make it public can do
software testing etc
-Release candidates do not have to be the same size, (e.g. 30 points for feasibility
demonstration, 20 points for security etc)
Schedule
-Put dependencies
-30 points, 1 point per day
-Release on a day that has less traffic, hence even if crashed not too many users will
be affected
-Consider about holidays (velocity is lower/half as fast during Christmas)
-Need to know resources before doing the schedule: (2 business analysts etc in
team… estimate)
-Release candidate: confident enough to release to the public (external release)
-Incrementally building the application
Release Planning Issues
-Pick dates that are suitable for deployment, aware of customer key dates
-E.g. no point of releasing commonwealth website on May because the game has
ended, must have release 1 a year before it starts then keep releasing while the
game is on. By April the website should be stable and include the extra stuffs
-Demonstrable system for the event management system, did a pitch to provide the
software for the gold coast game, to convince them it is going to do well in the next 5
years
-Deliverable needs to have value for the stakeholders
-High risk modules needs to be tested before committing resources into the project
find more resources at oneclass.com
find more resources at oneclass.com
