CS383Lecture4_241013_065731.pdf

CS383 - Software Engineering Software Process Models (II) Semester: 452 Lecture: 4 Topics to be covered in this lecture Software process models in practice Agile software development IEEE documentations Software Process Models in Practice Software organisat...

CS383 - Software Engineering Software Process Models (II) Semester: 452 Lecture: 4 Topics to be covered in this lecture Software process models in practice Agile software development IEEE documentations Software Process Models in Practice Software organisations may combine aspects of generic process models to meet the specific needs of their projects The choice of process model is also constrained by a range of other factors: ○ Contractual or regulatory requirements ○ Experience and familiarity with the process model ○ Process models used by related projects 3 Rapid Methodology and overhead problems Nowadays software are developed very rapidly ○ Very fast changing of requirements (unstable software!) ○ Software to be evolved quickly to business needs Specification, design and implementation are interleaved (combined) Systems are developed in series of iterations Change user interface using toolset and IDE Therefore, using plan-driven approaches may have overheads software process and documentation 4 Agile Methodology Focus on the code rather than design or documentation Incremental development of small new releases for clients (usually 2-3 weeks) Same as rapid process models, iterative approach Software evolves at same speed but maybe with stable versions Successful and good for: ○ Small- and medium- sized product ○ Clear commitment of the customer in development process 5 Principles of Agile Methodology 6 Agile Methodology Drawbacks Sometimes, practicing agile methods is difficult ○ Difficult to keep the interest of customers ○ Team members may be unsuited to the intense involvement ○ Newly joining team members into the development require documentation to better understand the system ○ Priority changes can be difficult because of multiple stakeholders ○ Maintaining simplicity requires extra work 7 Agile Method: Extreme Programming An ‘extreme’ approach to iterative development 8 Agile Method: Extreme Programming (con.t) 1. Incremental planning: ○ requirements recorded on story cards and then prioritize ○ tasks become the basis of scheduling and cost estimation 2. Small releases: ○ frequently and incrementally releases (2-3 weeks window) 3. Simple design: ○ just enough design to continue meetings and get requirements 4. Test-first development: ○ automated unit test is used for each functionality/task added (regression testing) 9 Agile Method: Extreme Programming (cont.d) 5. Refactoring: ○ improve code by refactoring more oftenly 6. Pair Programming: ○ Developers checking each others code for improvement (understandability) ○ Tidy up the code and make it clear (informal review and checks) ○ Helps to make refactoring much easier ○ Risk to need architecture refactoring for improvement 7. Continuous integration: ○ integrate new completed task or functionality into the system (must pass all tests) 8. On-site customer: ○ customer should be available full time. 10 Agile Method: Extreme Programming (cont.d) Incremental development (plan-driven) and XP approach (agile) ○ Generally, incremental development tends to degrade the software structure over development time Changes become harder and harder to implement Workaround is applied to overcome hard implementation Usually resulted in duplicate code ○ XP suggests developers do constant refactoring to the code look for possible improvements and implement them immediately 11 Agile Method: Extreme Programming (cont.d) XP and automated testing ○ Test-first development and automated testing results in a large number of tests ○ However, this does not necessarily lead to thorough program testing. Reasons: Programmers sometimes take shortcuts when writing tests Incomplete tests that do not check all variations/complete coverage Not all test can be written incrementally 12 User Stories Project owners and developers do user stories, each story contains ○ Who (user role): customer, employee, admin, etc ○ What (goal): what functionality must be developed ○ Why (reason): why does this functionality needed Also, a user story can have estimation of its numerical points Examples: ○ As a user, I want a cascade action warning before updating or deleting a record, because I want to avoid dependency problem ○ As a developer, I need a graphical hierarchy model of the developed components updated automatically, so that I better understanding of components dependency. 13 Plan-Driven and Agile Development 14 Plan-Driven and Agile Development (cont.) Concern Plan Agile Driven 1- Very detailed specification and design before implementation 2- Deliver software to customers and get rapid realistic feedback 3- Large systems development 4- Systems require a lot of analysis before implementation 5- Long-lifetime system is require 6- Development may require up-to-date technologies for support 7- Development team are distributed (outsourced) 8- Development team has strong rapid development skills 9- The system is subject to regulation/organization (external entity) 15 Plan-Driven and Agile Development (cont.) Concern Plan Agile Driven 1- Very detailed specification and design before implementation X 2- Deliver software to customers and get rapid realistic feedback X 3- Large systems development X 4- Systems require a lot of analysis before implementation X 5- Long-lifetime system is require X 6- Development may require up-to-date technologies for support X 7- Development team are distributed (outsourced) X 8- Development team has strong rapid development skills X 9- The system is subject to regulation/organization (external entity) X 16 Agile and project management Typical project management work well for plan-driven approaches ○ Clear specification, objectives and documentation are present for management In agile, requirements developed incrementally, and new releases are made constantly Therefore, different approaches to project management for incremental development and embraces agile are proposed. Most notably, Scrum 17 Agile Project Management: Scrum Focuses on managing iterative development of agile approach Three phases: 1. The initial phase: ○ Establish general objectives and design the software architecture 2. Sprint Cycles (2-4 weeks): ○ Each cycle is an increment of the system (features are selected, developed and assessed) 3. Closure phase: ○ Wrap up the project including documentations 18 Scrum: sprint planning Sprint planning must be established before the sprint cycle 19 Scrum: sprint planning (cont.d) Team capacity: the amount of effort or work that team can put forward to the upcoming sprint. Each individual is encourage to be self-organized and determine his/her strength and working/output rate. ○ Then, such detail is used to determine capacity planning of the team Team capacity = members count x productive days Ideally, team capacity is determined after 3rd or 4th sprint cycle (why?) ○ Once we have accurate and actual data of individuals performance From team capacity, it is easier to determine Focus Factor ○ Basically, the team’s ability to focus on the sprint goals Where the sprint velocity is the average completed story points over the past 3 to 5 sprint cycles 20 Scrum: sprint planning (cont.d) Example: Assume that you have 5 members who are willing to work 8 hrs per day. Assume that the average sprint story points (estimated from previous cycles) is 30. Then the focus factor is: FF = 30 ÷ (5 x 8) = 0.75 (ideal/optimal range is 0.6 to 0.8) From focus factor, we can compute the effective team capacity of future sprint cycle. Assume that the focus factory is (0.75) and duration of next sprint cycle development is 3 weeks (total 15 days subtracting weekend days), then we have Effective team capacity = 0.75 x (5 x 8 x 15) = 450 hours effort estimated for next sprint 21 Example of Product Backlog 22 Example of Sprint Backlog 23 Summary: Software Process Model Waterfall Incremental Reuse-oriente Agile model development d methods development Requirements Low Medium Low Hight Volatility Project Size Large Medium Any Small Customer Low Medium Low Hight Involvement Technical Risk Low High Medium High Release Long Medium Short Very Short Schedule 24 IEEE Documentations Documentation plays a good part in software engineering process There are a list of documentation for each software engineering phase: ○ SPM – Software project management ○ SCM – Software configuration management ○ SRS – Software requirements specification (required in your project) ○ SDD – Software design description (required in your project) ○ SQA – Software quality assurance ○ V&V – Software verification and validation ○ STD – Software test documentation ○ SRA – Software reviews and audit ○ SUD – Software user documentation 25 SRS – Software requirements specification 1. A 1. Introduction 2. B 3. C 4. 1.1. Purpose 5. Non-functional Requirements 1.2. Product scope 5.1. Performance Requirements 1.3. References 5.2. Safety Requirements 1.4. Structure 5.3. Security Requirements 5.4. Software Quality Attributes 2. System Overview 2.1. Product perspective 6. External Interface Requirements 6.1. User Interface requirements 2.2. Product features 2.3. User roles and characteristics 6.2. Hardware Interface requirements 2.4. Operating environment 6.3. Software Interface requirements 2.5. Design and implementation constraints 6.4. Communication Interface requirements 2.6. Assumptions and dependencies 3. Requirements Engineering 3.1. Requirements elicitation 3.2. Requirements analysis 3.3. Requirements validation 4. Functional Requirements 4.1. Requirement 1 4.2. Requirement 2 4.3.... 26 SDD – Software design document 1. A 1. Introduction 2. B 3. C 4. 1.1. Purpose 5. Component Design 1.2. Product scope 5.1. Class diagrams 5.2. State diagrams 1.3. References 5.3. Activity diagrams 1.4. Structure 5.4. Sequence diagrams 2. System Overview 6. Human Interface Design 3. Architecture Design 6.1. Overview of user interface 3.1. Architecture description 6.2. Detail design of user interface 3.2. Decomposition description 3.3. Design rationale 4. Data Design 4.1. Database description 4.2. Data structure 4.3. Data-flow Diagram (DFD) 27