Chapter 2

1. Software engineering practices And Software requirements Engineering Chapter 2 Visit to more Learning Resources

2. Software engineering practice is a collection of concepts,principals,methods and tools that a software engineer calls upon on daily basis. • Practice allows managers to manage software projects and software engineers to build computer programs.

3. Essence of 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)

4. Understand the problem • Who are the stakeholder? • What data, functions , features and behavior are required to properly solve the problem? • Is it possible to represent smaller problems that may be easier to understand? • Can the problem be represented graphically?

5. Plan a solution • Have you seen similar problems before? • Has a similar problem been solved? • Can subproblems be defined? • Can you represent a solution in a manner that leads to effective implementation? • Can a design model be created?

6. Carry out the plan. • Does the solution conform to the plan? • Is each component part of the solution probably correct? • Has the design and code been reviewed?

7. Examine the result • Is it possible to test each component part of the solution? • Has a reasonable testing strategy been implemented? • Has the software been validated against all stakeholder requirements?

8. Core principles of Software Engineering • The Reason It All Exists. • Keep It Simple,Stupid! • Maintain The Vision. • What you produce ,Others will Consume. • Be Open To The Future. • Plan Ahead For Reuse • Think!

9. The First Principle: The Reason It All Exists • The software exists for one reason: to provide value to its users. • Before specifying system requirement,functionality,hardware platform,development process ask question such as: Dose this add real value to the system? • If answer is no,don't do it.

10. The Second Principle:Keep It Simple,Stupid! • All design should be as simple as possible,but no simpler. • This facilitates having a more easily understood and easily maintained system.

11. The Third Principle:Maintain The Vision • A Clear vision is essential to the success of a software project. • Compromising the architectural vision of a software system weakens and will eventually break even a well designed system • Having an empowered architect who can hold the vision and enforce compliance helps ensure a very successful software project.

12. The Fourth Principle:What you produce ,Others will Consume • Always specify design and implement knowing someone else will have to understand what you are doing. • Someone may have to debug the code you write,and that makes them a user of your code. • Making their job easier adds value to the System.

13. The Fifth Principle: Be open to the Future • A system with along lifetime has more value. • Software lifetimes are typically measured in months instead of years. • System should be ready to adapt changes. • System that adapt changes have been designed this way from start. • Never design yourself to a corner. • Always keep asking “what if?”

14. The Sixth Principle: Plan ahead for Reuse • Reuse saves time and effort. • Achieving a high level of reuse is arguably the hardest goal to accomplish in developing a software system. • The reuse of code and designs has been proclaimed as a major benefit of using object oriented technologies.

15. The Seventh Principle: Think! • Placing clear, complete thought before action almost always produces better results. • When you think about something, you are more likely to do it right. • You also gain knowledge about how to do it right again. • When clear thoughts has gone into system, value comes out.

16. Communication Practices • Before customer requirements can be analyzed, modeled, or specified they must be gathered through a communication activity. • Effective communication is among the most challenging activities that confront a software engineer.

17. Principles Principle #1: Listen. Try to focus on speakers words. If something is unclear, ask for clarification. Principle #2: Prepare before you communicate. Spend some time to understand the problem before you meet with others. If you have responsibilities for conducting a meeting, prepare an agenda in advance of the meeting. Principle #3: Someone should facilitate the activity. Every communication meeting should have a leader to keep conversation moving in a productive direction

18. Principle #4: Face to face communication is best. Principle #5: Take notes and document decisions. Principle #6: Strive for collaboration. Principle #7: Stay focused, modularize your discussion.

19. Planning practices • Good planning leads to successful result. • The planning activity encompasses a set of management and technical practices that enable the software team to define a road map as it travels towards its strategic goal and tactical objectives. • Planning includes complete cost estimation,resources,scheduling and also risk analysis.

20. Principle 1: Understand the scope of the project. Its impossible to use a road map if you don't know where you are going. Scope provides the software team with destination.

21. Principle 2: Involve the customer in the planning activity. The customer defines priorities and establishes project constraints. To accommodate these realities software engineers must often negotiate order of delivery,time lines and other project related issues.

22. Principle 3: Recognize that planning is iterative. Principle 4:Estimate based on what you know Principle 5:Consider risk as you define the plan Principle 6: Be realistic. Principle 7: Adjust granularity as you define the plan.

23. Principle 8: Define how you intend to ensure Quality. Principle 9: Describe how you intend to accommodate change. Principle 10: Track the plan frequently and make adjustment as required.

24. Modeling Practice • Models are created for better understanding of the actual entity to be built or design. • When the entity is a physical thing, we can build model that is identical in form and shape but smaller in scale. • When entity is software our model must take different form. It must be capable of representing information ,Architecture, functions ,features and behavior of the system.

25. In SE work, Two classes of model is created. 1. Analysis Model. 2. Design Model.

26. Principle 1: The information domain of problem must be clearly represented. Information domain encompasses the data that flow into the system(from end user,external devices),data that flow out of the system(via user interface,n/w interface,graphics), data stores collection of objects(data i.e. maintained permanently).

27. Principle 2: The function of the software must be defined clearly. • Functions are the processes those transform the I/p flow to the o/p flow. • The process specification for example algorithms provides function details. The specification must be clearly defined.

28. Principle 3: The Behavior of the software must be defined clearly. • Analysis model uses state transition diagrams to represent the behavior of the system clearly. • It shows how the system makes transition from one state to another on occurrence of some external event.

29. Principle 4: The clear hierarchy among information,functions and behavior must be shown. • The proper hierarchy of analysis model leads to easy design. Hence information,functions and behavior of the system must be represented using proper hierarchy i.e. levels or layers.

30. Principle 5: analysis should be clear enough to convert it into design model. • If analysis of requirements is clear and simple then it will be easy for design and implementation in construction step. Hence requirement analysis should be clear enough.

31. Design modeling Principle 1: Design should be traceable from analysis model. Principle 2: Consider the architecture of the system to be built. Principle 3: Design of data is as important as design of function. Principle 4: Internal as well as external interfaces must be designed.

32. Principle 5: user interface design must satisfy all need of end user. Principle 6: Component level design should be functionally independent. Principle 7: Components should be loosely coupled to one another and to the external environment. Principle 8: designed modules should be easy to understand. Principle 9: Accept that design behavior is Iterative.

33. Construction Practices • The construction activity encompasses a set of coding and testing tasks that lead to operational software that is ready for delivery to the customer or end user. • The initial focus of testing is at the component level, often called unit testing. Other levels of testing include integration testing, validation testing and acceptance testing.

34. Coding Principles & Concepts Preparation Principles: Before you write one line of code, be sure you, 1.Understand the problem you're trying to solve. 2.Understand basic design principles & concepts. 3.Pick a programming language that meets the needs of the software to be built & the environment in which it will operate. 4.Select a programming environment that provides tools that will make you work easier. 5.Create a set of unit tests that will be applied once the component you code is completed.

35. 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. • Create a visual layout that aids understanding.

36. Validating principles: After you've completed your first coding pass, be sure you: • Conduct a code walk through when appropriate. • Perform unit tests and correct errors you've uncovered. • Re factor the code.

37. Testing principles Testing rules or objectives: • Testing is a process of executing a program with the intent of finding an error. • A good test is one that has a high probability of finding an as yet undiscovered error. • A successful test is one that uncovers an as yet undiscovered error.

38. Principle #1: All tests should be traceable to customer requirements Principle #2: Tests should be planned long before testing begins. Principle #3: The Pareto principle applies to software testing. Principle #4: Testing should begin “in the small” and progress toward testing “in the large”. Principle #5: Exhaustive testing is not possible.

39. Deployment • The deployment activity encompasses 3 actions: delivery, support and feedback. • Modern software process models are evolutionary in nature, deployment happens not once, but a number of times as software moves towards completion. • Each delivery cycle provides the customer and end users with an operational software incremental that provides usable functions and features.

40. Each support cycle provides documentation & human assistance for all functions and features introduced during all deployment cycles to date. • Each feedback cycle provides the software team with important guidance that results in modifications to the functions, features and approach taken for the next increment.

41. Principle #1: Customer expectations for the software must be managed. Principle #2: A complete delivery package should be assembled and tested. Principle #3: A support regime must be established before the software is delivered. Principle #4: Appropriate instructional materials must be provided to end users. Principle #5: Buggy software should be fixed first, delivered later.

42. Requirement Engineering • Requirements engineering, like all other software engineering activities, must be adapted to the needs of the process, the project , the product, and the people doing the work. • Software process perspective, requirements engineering is a software engineering action that begins during the communication activity and continues into the modeling activity.

43. The requirements engineering process is accomplished through the execution of seven distinct functions: • Inception • Elicitation • Elaboration • Negotiation • Specification • Validation • Management

44. Inception • At project inception, software engineers ask a set of context free question. • The intent is to establish a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired and effectiveness of preliminary communication and collaboration between the customers and the developer.

45. Elicitation • Ask the customer, the user and others what the objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of the business, and finally, how the system or product is to be used on a day to day basis. • Christel and Kang identified a number of problems that help us understand why requirements elicitation is difficult 1. Problem of scope. 2. Problem of understanding 3. Problem of volatility

46. Elaboration • It means to work out in detail. • The information obtained from the customer during inception and elicitation is expanded and refined in elaboration. • S/w engg focuses on developing a refined technical model of software functions,features and constraints. • It describes how the end user will interact with the system. • The end result is an analysis model that defines the informational ,functional,behavioral domain of the problem.

47. Negotiation • The requirements engineer must reconcile conflicts through process of negotiation. • Customers, users and other stakeholders are asked to rank requirements and the discuss conflicts in priority. • Risks associated with each requirements are identified and analyzed. • Rough “guesstimates” of development effort are made and used to assess the impact of each requirement on project cost and delivery time. • Using an iterative approach, requirements are eliminated, combined, and /or modified so that each party achieves some measure of satisfaction.

48. Specification “Standard template” should be developed and used for a specification, arguing that this leads to requirements that are presented in a consistent and therefore more understandable manner. The specification is a final work product produced by the requirements engineer. It serves as the foundation for subsequent software engineering activities.

49. Validation The work products produced as a consequence of requirements engineering are assessed for quality during a validation step. Requirements validation examines the specification to ensure that all software requirements have been stated unambiguously. The review team that validates requirements includes software engineers, customers, users and other stakeholders.

50. Requirements Management Requirements management is a set of activities that help the project team identify, control and track requirements and changes to requirements at any time as the project proceeds. Requirement management begins with identification. Each requirement is assigned a unique identifier. Once requirements have been identified, traceability table are developed. Each traceability relates requirements to one or more aspects of the system.