Lecture-2

1. Lecture-2 Advance Software Engineering (SEII)

2. Today We will cover • Basic Topics of Software Engineering • Requirement Engineering • Design and Architecture • Software Quality Assurance • Software Maintenance • Software Project Management • Introduction to Agile Methodologies • Agile • Scrum • Extreme Programming • RUP

3. Requirement Engineering • Requirement engineering is a branch of software engineering that deal with problems, goals and functions of real world. • The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. • The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process.

4. User and system requirements • User requirements are statements, in a natural language plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate. • System requirements are more detailed descriptions of the software system’s functions, services, and operational constraints. The system requirements document should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers.

5. Requirement Types • Three types of requirements • Functional Requirements • Non Functional Requirements • Domain Requirements

6. Requirement Types • Functional Requirements • Statements of services that system should provide • How system should behave in particular situations • May state what the system should not do. • Non Functional Requirements • Constraints on the services offered by system such as timing constraints, constraints on the development process, standards, etc. • Quality Attributes • Domain Requirements • Relevant to domain of the system

7. The software requirements document • The software requirements document is the official statement of what is required of the system developers. • Should include both a definition of user requirements and a specification of the system requirements. • It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it.

8. Agile methods and requirements • Many agile methods argue that producing a requirements document is a waste of time as requirements change so quickly. • The document is therefore always out of date. • Methods such as XP use incremental requirements engineering and express requirements as ‘user stories’ . • This is practical for business systems but problematic for systems that require a lot of pre-delivery analysis (e.g. critical systems) or systems developed by several teams.

9. Requirement Engineering Process • Requirement Elicitation • To get requirements from different stakeholders • Requirement Analysis • To analyze requirements to ensure completeness and consistency • Requirement Specification • To document requirements • Requirement Verification and Validation • To validate requirements • Requirement Management • To manage changes in requirements

10. Requirement Engineering Process Requirement Elicitation • Sometimes called requirements elicitation or requirements discovery. • Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. • May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.

11. Problems of requirements analysis • Stakeholders don’t know what they really want. They express requirements in their own terms. • Different stakeholders may have conflicting requirements. • Organisational and political factors may influence the system requirements. • The requirements change during the analysis process. New stakeholders may emerge and the business environment may change.

12. Requirements elicitation and analysis • Software engineers work with a range of system stakeholders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc. • Stages include: • Requirements discovery, • Requirements classification and organization, • Requirements prioritization and negotiation, • Requirements specification.

13. Therequirements elicitation and analysis process

14. Requirements validation • Concerned with demonstrating that the requirements define the system that the customer really wants. • Requirements error costs are high so validation is very important • Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.

15. Requirements checking • Validity. Does the system provide the functions which best support the customer’s needs? • Consistency. Are there any requirements conflicts? • Completeness. Are all functions required by the customer included? • Realism. Can the requirements be implemented given available budget and technology • Verifiability. Can the requirements be checked?

16. Requirements validation techniques • Requirements reviews • Systematic manual analysis of the requirements. • Prototyping • Using an executable model of the system to check requirements. • Test-case generation • Developing tests for requirements to check testability.

17. Requirements management • Requirements management is the process of managing changing requirements during the requirements engineering process and system development. • New requirements emerge as a system is being developed and after it has gone into use. • You need to keep track of individual requirements and maintain links between dependent requirements so that you can assess the impact of requirements changes. You need to establish a formal process for making change proposals and linking these to system requirements.

18. Design and Architecture Different UML Diagrams • Class Diagram • Show dependencies between different classes • Use Case Diagram • To show relation between actor and functionalities • Sequence Diagram • Show different functionalities according time

19. Design and Architecture Different UML Diagrams • State Transition Diagram • Show transitions between different functionalities • Communication Diagram • To show communication between different functionalities

20. Software Quality Assurance/Testing • To validate software product • Unit Testing • System Testing • Testing Techniques • Black Box Testing • White Box Testing

21. Software Quality Assurance/Testing • Unit testing tests each individual component (often a program) to ensure it is as defect-free as possible. • Integration testing occurs between unit and system testing to test functionally grouped components. • System testing tests the entire system as one entity. • User acceptance testing is an independent test performed by end users prior to accepting the delivered system.

22. Testing Techniques • Black box testing • Input/output behavior • White box testing • Correct implementation of internal units and relation among them

23. Software maintenance • Changing the system after it has been delivered • Types of software maintenance • Fault repairs • Environmental adaption • Adding functionalities

24. Software Project Management • To manage the project • Supervise overall software development activity • To manage risks in software project • To deal with configuration management, cost and effort estimation and project scheduling

25. Agile Methodology • Most commonly used software development life cycle now a day • Seems like to be rapid application development life cycle • Used when company is developing small or medium size project • When there are external rules and regulations • When customer is fully committed to be involved in software development process

26. Difference between Agile and RAD • Agile is a flavor of RAD but not RAD • RAD based projects are developed with help of prototypes but in agile project logically break down the solution into features • RAD is managed by project manager but in agile team members are independent • Agile does continuous integration but RAD does not face changes • In RAD, firstly prototype is developed then complete product develops but in agile complete software is developed at a time

27. Plan Driven and Agile Development Plan based development Requirement Change Request Agile Development Requirement Engineering Requirement Specification Design and Implementation Requirement Engineering Design and Implementation

28. Plan Driven and Agile Development • If we make specification document before going to implementation then use plan driven approach • If we want to get rapid feedback from customer then use agile method • Used when company is developing small or medium size project • Plan driven approach is used when we want analysis before implementation • If we have good programmers and designers in team then pal driven approach will be used

29. Agile Methods • Extreme Programming • Scrum • Rational Unified Process

30. Extreme Programming • Most widely used of agile method • Name was coined by Beck in 2000 • Requirements are expressed as scenarios which are implemented as series of tasks • Story cards are main input in extreme programming • Development team break those cards in tasks • Releases are delivered to customer roughly every 2 weeks

31. Phases of Extreme Programming Four phases of extreme programming • Coding • Testing • Listening Requirements • Designing

32. Pair Programming • In extreme programming, programmers work pair to pair to develop software • Team as a whole is responsible for software development • Discover high percentage of software errors • Supports refactoring which is a process of software improvement • Less efficient technique • Time Consuming technique

33. Scrum • Flavor of Agile • If customer change their minds then scrum can accommodate it • Emphasizes feedback from customer • Build properly tested product increments in short period • Scrum has three roles

34. Roles of Scrum • Scrum Master • To coordinate with all teams and product owner • To manage the project • Product Owner • Owner of the product/ stakeholder • Team • Development team • QA team • Designing team

35. Rational Unified Process (RUP) • Object Oriented Methodology • Web enabled program development methodology • Consists of 4 phases called inception, elaboration, construction and transition

36. Phases of Rational Unified Process • Inception phase • Developer define scope of the project • Elaboration Phase • Developer analyze the project needs in greater detail • Define architecture • Construction Phase • Developer create application design and source code • Transition Phase • Developer deliver code system to customer

37. Summary • Basic Topics of Software Engineering • Requirement Engineering • Design and Architecture • Software Quality Assurance • Software Maintenance • Software Project Management • Introduction to Agile Methodologies • Agile • Scrum • Extreme Programming • RUP

38. Thank You!