1. Software Engineering Saeed Akhtar The University of Lahore Lecture 6 Originally shared for: mashhoood.webs.com

2. Review of Last Lecture Working of Agile Model? Pros and cons of Agile Model? When to use Agile? Difference from other Models?

3. Software Engineering Practices

4. The Essence of Practice George Polya, in a book (about problem solving), describes the essence of software engineering practice … Understand the problem (communication and analysis). Plan a solution (modeling and software design). Carry out the plan (code generation). Examine the result for accuracy (testing and quality assurance).

5. Core Software Engineering Principles The reason it all exists: Provide value to the customer and the user KISS—keep it simple, stupid! Does not mean quick and dirty Maintain the product and project “vision” What you produce, others will consume Be open to the future Plan ahead for reuse Think! (before action)

6. Communication Practice Principles 1. Listen (instead of talking too much) 2. Prepare before you communicate Understand the business domain Prepare an agenda 3. Facilitate the communication, there should be a leader Ensure moving in a productive direction Mediate any conflict Ensure other principles are followed 4. Face-to-face is best 5. Take notes and document decisions

7. Communication Practice Principles Cont’d 6. Collaborate with the customer 7. Stay focused, modularize your discussion (conclude each issue) 8. Draw pictures when things are unclear 9. Move on … Once you agree to something If you can’t agree Something is unclear and cannot be resolved at the moment 10. Negotiation works best when both parties win (not a contest or game). Compromise when necessary

8. Planning Practice Principles 1. Understand the project scope Scope clears your destination 2. Involve the customer (and other stakeholders) Customer defines priorities and constraints Negotiate order of delivery, timelines, … 3. Recognize that planning is iterative (revised based on feedback) 4. Estimate based on what you know Provide an indication of effort, cost, and task duration (maybe unreliable) 5. Consider risk

9. Planning Principles Cont’d 6. Be realistic Noise, change, mistakes, omissions, ambiguity 7. Adjust granularity as you plan (level of details) 8. Define how quality will be achieved (formal technical reviews, pair programming) 9. Define how you’ll accommodate changes 10. Track what you’ve planned and make adjustment

10. Planning Practices Ask Boehm’s questions Why is the system being developed? Justify the expenditure of people, time, and money What will be done? Identify functionality When will it be accomplished? Workflow, timeline, milestones Who is responsible for a function? Where are they located (organizationally)? How will the job be done technically and managerially? How much of each resource is needed? (estimation)

11. Analysis Modeling Practice We create models to gain a better understanding of the actual entity to be built Analysis models represent the customer requirements by depicting the software in three different domains: the information domain, the functional domain, and the behavioral domain. Design models represent characteristics of the software that help practitioners to construct it effectively: the architecture, the user interface, and component-level detail.

12. Analysis Modeling Practice Analysis modeling principles 1. Represent the information domain Input data: from end-users, other systems, or external devices Output data: via the user interface, network interface, reports, graphics, … The data stores 2. Represent software functions Different levels of abstraction 3. Represent software behavior As a consequence of external events 4. Partition these representations Partitioning: divide and conquer Layered or hierarchical 5. Move from essence toward implementation

13. Design Modeling Principles Principles 1. Design must be traceable to the analysis model 2. Always consider architecture 3. Focus on the design of data 4. Interfaces (both user and internal) must be designed 5. Components should exhibit functional independence 6. Components should be loosely coupled 7. Design representation should be easily understood 8. The design model should be developed iteratively

14. Construction Practices Preparation principles : Before you write one line of code, be sure you: Understand of the problem you’re trying to solve (see communication and modeling) Understand basic design principles and concepts. Pick a programming language that meets the needs of the software to be built and the environment in which it will operate. Select a programming environment that provides tools that will make your work easier. Create a set of unit tests that will be applied once the component you code is completed.

15. Construction Practices Coding principles: As you begin writing code, be sure you: Constrain your algorithms by following structured programming practice. Select data structures that will meet the needs of the design. Understand the software architecture and create interfaces that are consistent with it. Keep conditional logic as simple as possible. Create nested loops in a way that makes them easily testable. Select meaningful variable names and follow other local coding standards. Write code that is self-documenting.

16. Construction Practices Validation Principles : After you’ve completed your first coding pass, be sure you: Conduct a code walkthrough when appropriate. Perform unit tests and correct errors you’ve uncovered. Refactor the code.

17. Construction Practices Testing Principles All tests should be traceable to requirements Tests should be planned Testing begins “in the small” and moves toward “in the large”

18. Deployment Practices Principles Manage customer expectations for each increment A complete delivery package should be assembled and tested Instructional materials must be provided to end-users Buggy software should be fixed first, delivered later

19. Thank You