Section 4: Managing Software Development

Section 4: Managing Software Development

“Introduction … Making software the old-fashioned way … Why managing software projects is hard … New breed of software development methods”
(Source URL)

Summaries

  • Managing Software Development > Making software the old-fashioned way > Waterfall method
  • Managing Software Development > Why managing software projects is hard > Software Project Management
  • Managing Software Development > New breed of software development methods > Agile methods of developing software

Managing Software Development > Making software the old-fashioned way > Waterfall method

  • Building software has historically been similar to making buildings.
  • Software is not like buildings though, it is far more complicated.
  • The basic units with which software is made is programming code.
  • Since there is no one way of making software, the challenge is to find the best, or if not the best, a good way of writing code.
  • Let us start with an example of how to create a software application.
  • We will rely on a well-known model of making software applications.
  • To build a software application, you have to go through all the steps.

Managing Software Development > Why managing software projects is hard > Software Project Management

  • What was Vasa’s story? Why did she sink? Judge: Let’s ask the Captain himself! Captain: Hello there! I’m Captain Hanson at your service.
  • On 10th August, 1628 Captain: The Vasa set sail from Stockholm Harbour, on her maiden voyage.
  • Captain, why do you think she sank? Captain: Well, three reasons mainly.
  • King: Increase ship length! Add a gun deck… or two! Cannons are in this year… More cannons?! Chapter 2 “No Documentation” Henrik Hybertsson, an experienced shipwright, got the Vasa contract… Sadly, he became ill in 1626… His assistant Jacobsson took over the project after his death in 1627… However… There were No clear milestones.
  • Chapter 3 ‘The Failed Test’ A stability test was conducted on the Vasa, which failed.
  • Captain: So despite the test’s failure, the Vasa sailed… Judge: And sank… Truly sad, Captain.

Managing Software Development > New breed of software development methods > Agile methods of developing software

  • Some of the common agile methodologies include Scrum, Extreme Programming or XP, Crystal and Adaptive Software development.
  • We will use Scrum as an example to understand agile methods and how these are different from Waterfall.
  • Scrum is borrowed from the Rugby sport, in which the team gains possession of the ball and jointly moves forward with it This approach of a cross-functional team going the distance as a unit, passing the ball back and forth is what agile scrum is about.
  • Scrum can be seen as consisting of roles, events and artifacts.
  • The three core roles in Scrum are-the Product Owner, the Scrum Master and the Developers.
  • The product owner owns the requirements and it is his or her job to ensure that requirements… …from business owners are communicated to the scrum team.
  • The scrum is facilitated by the scrum master who is responsible for removing any impediments the team faces.
  • The scrum master is not a project manager: the team is expected to self-manage and the scrum master acts as a facilitator.
  • A sprint is an iteration that is time-boxed usually from two to four weeks.
  • While there could be one week sprints also, it is generally not recommended to have a sprint duration of more than a-one calendar month.
  • A sprint commences with a sprint planning meeting which is time-boxed to a few hours-usually 4 hours for a two-week sprint.
  • There is a daily scrum meeting which is used to discuss the progress and to collaborate with other team members.
  • The sprint ends with a sprint review that is usually a demo of the developed system… …to the end user and concludes with a sprint retrospective.
  • Finally, there are a set of scrum artifacts, such as the Product and the Sprint backlogs.
  • Finally, there is the product increment-a working software that is developed during the sprint.
  • The team meets during the daily scrum to review progress, plan activities and collaborate with each other.
  • The output of a sprint is an increment to the software that is potentially shippable.
  • In Scrum, requirements are captured as epics and user stories that are maintained in a product backlog.
  • A user story describes a functionality that is of value to a user and is usually described in the format: “As a user….
  • You will notice that the user story is at a high level and does not capture all the details.
  • B) Details about the user story are fleshed out through conversations between the users and the developers.
  • There are three epics-one from the user perspective, and two from the librarian perspective.
  • A sprint starts with sprint planning, during which, the product owner presents the prioritized list of the product backlog to the team.
  • The product owner also articulates a goal for the sprint.
  • The scrum developers then analyse the user stories, convert them to tasks, estimate the effort, and self-select tasks.
  • Assume that the product owner suggests that the first sprint goal is to create a database of the books and the subscribers.
  • After the sprint planning, the scrum team participates in development of the user stories.
  • Prof: The sprint concludes with a sprint review which is a demo of the developed functionality to the users of the system.
  • The feedback so obtained is entered into the product backlog and shapes the direction of future sprints.
  • The last activity of a spr

Return to Summaries

(image source)

 

Print Friendly, PDF & Email