Software engineering course cmps, Lecture notes of Software Engineering

Download Software engineering course cmps and more Lecture notes Software Engineering in PDF only on Docsity!

▪ A structured set of activities that governs the way software is developed

▪ Many different processes exist, but all involve:

▪ Requirements (features) gathering

▪ Architecture/Design

▪ Specifications

▪ Construction

▪ verification/testing

▪ Validation/testing

▪ Deployment

▪ Evolution/maintenance

▪ In this class we will interchangeably use the following terms: “Software Process”; “Software Development Process”; “Software Lifecycle Process”; “Software Development Methodology”… while noting the (minor) differences between them

▪ SDP: Often starts with an “off the shelf” process and then tailor it to your project

needs

▪ Factors to take into consideration:

▪ Size of the company ▪ Startup, funding stage

▪ Strict time constraints

▪ Penalties imposed by contract

▪ Security/Safety/critical issues that favor one activity over another

▪ Are the teams distributed or local

▪ Is the customer and other stakeholders involved with the project

▪ Prescriptive models (Waterfall) advocate an orderly approach to software engineering

▪ Would explicitly state that at stageX you do this, stageY you do that… with specific details and

documentation… whether needed or not. The stages are not revisited.

▪ UML use cases, class diagrams, sequence diagrams, state diagrams, activity diagrams etc. are they

always useful/needed?

▪ Agile process models advocate flexibility and speed

▪ Focus on developing a working piece of software

▪ Less focus on documentation and formal design models… but do them on need basis

▪ XP (Extreme Programming)

▪ Scrum

▪ Both types of process models have their place in software engineering

▪ We’ll be using Scrum whose focus is on producing a “minimum viable product” at every “ sprint ”

▪ Goal is to get the software in front of the customer earlier but not necessarily something that is releasable ▪ The requirements are divided into several modules that can be incrementally developed and delivered ▪ The core features are favored first ▪ There is no fixed time to complete the next iteration (not time-driven) Some parts could be done in parallel

▪ Shift focus: from following a strict “Process” – to - > getting out a “Working Software”

▪ Goal: faster delivery of working software to customers without “excessive” process burdens

▪ Avoid things that “waste time”

▪ However, processes related to Quality Control will be strongly emphasized →?

Testing

▪ Agile methods emphasize:

▪ Individuals and interactions vs. strict processes and tools

▪ Working software vs. comprehensive documentation

▪ Customer collaboration vs. contract negotiation

▪ Responding to change vs. following a plan/schedule

▪ Delivery of “minimum viable product” at each iteration

All features Sprint meeting every 2 weeks – decide what to go in the next Sprint (and remove from Product Backlog) During the Sprint, you meet daily: what got done? Are we on track?

▪ In Scrum, an “Increment/Iteration” is called a “Sprint”

▪ Sprints are calendar based as opposed to being based on product deliverables

▪ A typical Sprint timeframe is measured in few weeks, say 2 weeks

▪ Every 2 weeks you will have something to show your customer: maybe a mockup/prototype at

first… later a minimum viable product that works → convincing the customer that they are getting

closer to what they want

▪ Benefit of Agile Development:

Every 2 weeks, you get feedback (positive or negative)

vs.

Waiting years to possibly find out that you and the customer misunderstood each other

All features Sprint meeting every 2 weeks – decide what to go in the next Sprint (and remove from Product Backlog) During the Sprint, you meet daily: what got done? Are we on track?

▪ No “correct” answer

▪ Agile is becoming the more prominent approach

▪ If you are 100% sure that your requirements will not change (frozen) → WATERFALL might be better

▪ Mission critical, medical devices, avionics, NASA… likely to go with “Prescriptive Processes”

▪ Depends on the characteristics of your project and team environment

▪ There are a few caveats to using agile methods:

▪ Teams should ideally be co‐located with frequent interactions – need to meet daily! (online?)

▪ Teams should be small (7 ± 1 rule generally applies) – for CMPS271 we are going 3-5 given the size

of the project

▪ Does not easily tolerate weak team members

▪ Team members need to be dedicated to a single project (no part-timers)

Waterfall Model Agile Model Progress measured in terms of the number of completed and reviewed artefacts such as requirement specifications, design documents, test plans, code reviews, etc. Progress measured in terms of the developed and delivered functionalities (features) If a project is cancelled mid-way during development, then there is nothing much to show If a project is cancelled midway, it still leaves the customer with some worthwhile functionality Proper documentation is very important, which gives a clear idea what should be done to complete the project and it also serves as an agreement between the customer and development team Lack of proper formal documentation might result in misinterpreting requirements (but customer is expected to be present) Team sizes are large (with minimal interaction) Team sizes are small ( 6 to 8 ) with frequent interaction