It's computer science something UNIT 2.pptx

Yujvcnb

1. UNIT 2 Software engineering practices

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 ? Problem: Write a function which takes two numbers and returns their sum.

5. Plan a solution Have you seen similar problems before? Has a similar problem been solved? Can sub-problems 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 provably 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. Simple does not mean that features should be discarded in the name of simplicity. Indeed, the more elegant designs are usually the more simple ones.

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 a long 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?” and prepare for all possible answers.

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. Works better when some other representation of the relevant information is present. For example, a participant may create a drawing Principle #5: Take notes and document decisions. Someone participating in the communication should serve as a “recorder” Principle #6: Strive for collaboration. trust among team members and creates a common goal for the team. Principle #7: Stay focused, modularize your discussion. discussion will bounce from one topic to the next

19. Principles Principle #8: Draw a picture to clear your idea : A sketch or drawing can often provide clarity when words fail to do the job. Principle #9: Keep the discussion to “ move on ”  once there is an agreement to do something . If you cannot agree to something. If a feature of function is not clear. Principle #10: Negotiation is successful when both parties win.

20. 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.

21. 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.

22. 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.

23. 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.

24. 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.

25. 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.

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

27. 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).

28. 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.

29. 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.

30. 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.

31. 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.

32. 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.

33. 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.