1. Software Engineering Principles I (Spring 2017)
Software practice: concepts and principles

2. Knowledge vs. principles
“You often hear people say that software development knowledge has a 3-year half-life: half of what you need to know today will be obsolete within 3 years. In the domain of technology-related knowledge, that’s probably about right.
But there is another kind of software development knowledge—a kind that I think of as "software engineering principles"— that does not have a three-year half-life. These software engineering principles are likely to serve a professional programmer throughout his or her career. ”
- Steve McConnell
Steven C. McConnell is an author of software engineering textbooks such as Code Complete, Rapid Development, and Software Estimation. He is cited as an expert in software engineering and project management.
Education: Seattle University, Whitman College

3. What Software practice
a broad array of principles, concepts, methods and tools that you must consider as software is planned and developed.
what you do day in and day out as software evolves from an idea to a reality

4. Principles guiding practice
Principle #1. Divide and conquer.
Stated in a more technical manner, analysis and design should always emphasize separation of concerns(SoC).
Principle #2. Understand the use of abstraction.
At it core, an abstraction is a simplification of some complex element of a system used to communication meaning in a single phrase.

5. Principles guiding practice
Principle #3. Strive for consistency.
A familiar context makes software easier to use.
Principle #4. Focus on the transfer of information.
Pay special attention to the analysis, design, construction, and testing of interfaces.

6. Principles guiding practice
Principle #5.Build software that exhibits effective modularity.
Separation of concerns (Principle #1) establishes a philosophy for software. Modularity provides a mechanism for realizing the philosophy.
Principle #6.Look for patterns.
The goal of patterns within the software community is to create a body of literature to help software developers resolve recurring problems encountered throughout all of software development.

7. Communication principles
Principle # 1. Prepare before you communicate.
Spend the time to understand the problem before you meet with others.
Principle # 2. Someone should facilitate the activity.
Every communication meeting should have a leader (a facilitator) to keep the conversation moving in a productive direction; (2) to mediate any conflict that does occur, and (3) to ensure than other principles are followed.

8. Communication principles
Principle #3. Face-to-face communication is best.
But it usually works better when some other representation of the relevant information is present.

9. Communication principles
Principle # 4. Take notes and document decisions.
Someone participating in the communication should serve as a “recorder” and write down all important points and decisions.
Principle # 5. Strive for collaboration.
Collaboration and consensus occur when the collective knowledge of members of the team is combined …

10. Planning principles Principle #1. Understand the scope of the project.
It’s impossible to use a roadmap if you don’t know where you’re going. Scope provides the software team with a destination.
Principle #2. Involve the customer in the planning activity.
The customer defines priorities and establishes project constraints.

11. Planning principles Principle #3.Recognize that planning is iterative.
A project plan is never engraved in stone. As work begins, it very likely that things will change.
Principle #4. Estimate based on what you know.
The intent of estimation is to provide an indication of effort, cost, and task duration, based on the team’s current understanding of the work to be done.

12. Planning principles
Principle #5. Consider risk as you define the plan.
If you have identified risks that have high impact and high probability, contingency planning is necessary.
Principle #6. Be realistic.
People don’t work 100 percent of every day.
Principle #7. Define how you intend to ensure quality.
The plan should identify how the software team intends to ensure quality.

13. Planning principles
Principle #8. Describe how you intend to accommodate change.
Even the best planning can be obviated by uncontrolled change.
Principle #9. Track the plan frequently and make adjustments as required.
Software projects fall behind schedule one day at a time.

14. Modeling principles Two kinds of models Analysis (requirements) Design
In software engineering work, two classes of models can be created:
Requirements models(also called 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 modelsrepresent characteristics of the software that help practitioners to construct it effectively: the architecture, the user interface, and component-level detail.

15. Modeling principles Requirement modeling principles
Principle #1. The information domain of a problem must be represented and understood.
Principle #2. The functions that the software performs must be defined.
Principle #3. The behavior of the software (as a consequence of external events) must be represented.
#1. The information domain of a problem must be represented and understood.
#2. The functions that the software performs must be defined.
Requirements models (also called analysis models)
represent customer requirements by depicting the software in three different domains:
the information domain, the functional domain, and the behavioral domain.
The information domain encompasses the data that flow
into the system (from end users, other systems, or external devices), the data
that flow out of the system (via the user interface, network interfaces, reports,
graphics, and other means), and the data stores that collect and organize persistent
data objects (i.e., data that are maintained permanently).
Principle 2. The functions that the software performs must be defined.
Software functions provide direct benefit to end users and also provide internal
support for those features that are user visible.
The behavior of computer software is driven by its interaction with the external environment. Input provided by end users,
control data provided by an external system, or monitoring data collected
over a network all cause the software to behave in a specific way.

16. Modeling principles Requirement modeling principles
Principle #4. The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion.
Principle #5. The analysis task should move from essential information toward implementation detail.
#1. The information domain of a problem must be represented and understood.
#2. The functions that the software performs must be defined.
Requirements models (also called analysis models)
represent customer requirements by depicting the software in three different domains:
the information domain, the functional domain, and the behavioral domain.
The information domain encompasses the data that flow
into the system (from end users, other systems, or external devices), the data
that flow out of the system (via the user interface, network interfaces, reports,
graphics, and other means), and the data stores that collect and organize persistent
data objects (i.e., data that are maintained permanently).
Principle 2. The functions that the software performs must be defined.
Software functions provide direct benefit to end users and also provide internal
support for those features that are user visible.
The behavior of computer software is driven by its interaction with the external environment. Input provided by end users,
control data provided by an external system, or monitoring data collected
over a network all cause the software to behave in a specific way.

18. Modeling principles Design modeling principles
Principle #1. Design should be traceable to the requirements model.
Principle #2. Always consider the architecture of the system to be built.
Principle #3. Design of data is as important as design of processing functions.

19. Modeling principles Design modeling principles
Principle #4. User interface design should be tuned to the needs of the end-user. However, in every case, it should stress ease of use.
Principle #5. Component-level design should be functionally independent.
Principle #6. Components should be loosely coupled to one another and to the external environment.

20. Modeling principles Design modeling principles
Principle #8. Design representations (models) should be easily understandable.
Principle #9. The design should be developed iteratively. With each iteration, the designer should strive for greater simplicity.

21. Construction principles
Preparation principles
Understand of the problem you’re trying to solve.
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.
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.

22. Construction principles
Preparation principles
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.
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.

23. Construction principles
Coding principles - as you start
Constrain your algorithms by following structured programming [Boh00] practice.
Consider the use of pair programming
Select data structures that will meet the needs of the design.
Coding principles and concepts are closely aligned programming style, programming languages, and programming methods.

24. Construction principles
Coding principles - as you start
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.
Coding principles and concepts are closely aligned programming style, programming languages, and programming methods.

25. Construction principles
Coding principles - as you start
Select meaningful variable names and follow other local coding standards.
Write code that is self-documenting.
Create a visual layout (e.g., indentation and blank lines) that aids understanding.
Coding principles and concepts are closely aligned programming style, programming languages, and programming methods.

26. Construction principles
Coding principles – after finishing first pass (validation principles)
Conduct a code walkthrough when appropriate.
Perform unit tests and correct errors you’ve uncovered.
Refactor the code.

27. Construction principles
Testing principles
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.

28. Construction principles
Testing principles
Principle #4. Testing should begin “in the small” and progress toward testing “in the large.”
Principle #5. Exhaustive testing is not possible.

29. Deployment principles
Principle #1. Customer expectations for the software must be managed.
Too often, the customer expects more than the team has promised to deliver, and disappointment occurs immediately.
Principle #2. A complete delivery package should be assembled and tested.

30. Deployment principles
Principle #3. A support regime must be established before the software is delivered.
An end-user expects responsiveness and accurate information when a question or problem arises.

31. Deployment principles
Principle #4. Appropriate instructional materials must be provided to end-users.
Principle #5. Buggy software should be fixed first, delivered later.

32. Summary Software process vs. software practice Principles
That guide software practice

33. Summary Software process vs. software practice Principles
That guide each of the framework activities
Communication
Planning
Modeling
Construction
Deployement