UST-ICS

Practice – is a collection of concepts, principles, methods, and tools that a software engineer calls upon on a daily basis.  It transforms an unfocused approach into something that is more organized, more effective, and more likely to achieve success.

The Essence of Software Engineering Practice (George Polya)

1.      Understand the problem (Communication and analysis)

·        Who has a stake in the solution to the problem? 

– That is, who are the stakeholders?

·        What are the unknowns? 

– What data, functions, features, and behavior are required to properly solve the problem?

·        Can the problem be compartmentalized? 

– Is it possible to represent smaller problems that may be easier to understand?

·        Can the problem be represented graphically?

– Can an analysis model be created?

2.      Plan a solution (modeling and software design)

·        Have you seen similar problems before? 

– Are there patterns that are recognizable in a potential solution? 

– Is there existing software that implements the data, functions, features, and behavior that are required?

·        Has a similar problem been solved? 

– If so, are solutions readily apparent for the subproblems?

·        Can subproblems be defined?

– If so, are solutions readily apparent for the subproblems?

·        Can you represent a solution in a manner that leads to effective implementation? 

– Can a design model be created?

3.      Carry out the plan (code generation)

·        Does the solution conform to the plan? 

– Is source code traceable to the design model?

·        Is each component part of the solution probably correct? 

– Has the design and code been reviewed, or better, have correctness proofs been applied to the algorithm?

4.      Examine the result for accuracy (testing and quality assurance)

·        Is it possible to test each component part of the solution? 

– Has a reasonable testing strategy been implemented?

·        Does the solution produce results that conform to the data, functions, features, and behavior that are required? 

– Has the software been validated against all stakeholder requirements?

Principle – an important underlying law or assumption required in a system of thought.

Seven Core Principles on Software Engineering Practice (David Hooker)

1.      The reason it all exists.

·        A software system exists for one reason: to provide value to its users.

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

·        The more elegant designs are usually the simple ones.

·        Simple does not mean “quick and dirty.”  It often takes a lot of thought and work over multiple iterations to simplify.

·        The pay-off is software that is more maintainable and less error-prone.

3.      Maintain the vision.

·        A clear vision is essential to the success of a software project.

·        Without conceptual integrity, a system threatens to become a patchwork of incompatible designs, held together by the wrong kind of screws.

4.      What you produce, others will consume.

·        In some way or other, someone else will use, maintain, document, or otherwise depend on being able to understand your system.

·        Always specify, design, and implement knowing someone else will have to understand what you are doing.

·        Specify with an eye to the users.

·        Design, keeping the implementers in mind.

·        Code with concern for those who must maintain and extend the system.

5.      Be open to the future.

·        A system with a long lifetime has more value.

·        Never design yourself into a corner.

·        Always ask “what if,” and prepare for all possible answers by creating systems that solve the general problem, not just the specific one.

6.      Plan ahead for reuse.

·        Reuse saves time and effort.

·        The reuse of code and designs has been proclaimed as a major benefit of using object-oriented technologies.

·        Planning ahead for reuse reduces the cost and increases the value of both the reusable components and the systems into which they are incorporated.

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

·        If you think about something and still do it wrong, it becomes valuable experience.

·        A side effect of thinking is learning to recognize when you don’t know something, at which point you can research the answer.

·        When clear thought has gone into a system, value comes out.

Communication – is the exchange of thoughts, messages, or information, as by speech, signals, writing, or behavior.

 Communication Practices

1.      Listen.

·        Try to focus on the speaker’s words, rather than formulating your response to those words.

·        Ask for clarification if something is unclear, but avoid constant interruptions.

·        Never become contentious in your words or actions as a person is talking.

2.      Prepare before you communicate.

·        Spend time to understand the problem before you meet with others.

·        Prepare an agenda in advance of the meeting.

3.      Someone should facilitate the activity.

·        Every communication meeting should have a leader (facilitator) to keep the conversation moving in a productive direction; (2) to mediate any conflict that does occur; (3) to ensure that other principles are followed.

4.      Face-to-face communication is best.

·        It usually works better when some other representation of the relevant information is present.

5.      Take notes and document decisions.

·        Someone participating in the communication should serve as a “recorder” and write down all important points and decisions.

6.      Strive for collaboration.

·        Collaboration and consensus occur when the collective knowledge of members of the team is combined to describe product or system functions or features.

7.      Stay focused, modularize your discussion.

·        The facilitator should keep the conversation modular, leaving one topic only after it has been resolved.

8.      If something is unclear, draw a picture.

·        A sketch or drawing can often provide clarity when words fail to do the job.

9.      (a) Once you agree to something, move on; (b) if you can’t agree to something, move on; (c) if a feature or function is unclear and cannot be clarified at the moment, move on.

·        People who participate should recognize that many topics require discussion and that “moving on” is sometimes the best way to achieve communication agility.

10.  Negotiation is not a contest or a game. It works best when both parties win.

·        Negotiation will demand compromise from all parties.

Planning – encompasses a set of management and technical practices that enable the software team to define a road map as it travels toward its strategic goal and tactical objectives.

 Planning Principles

1.      Understand the scope of the project.

·        Scope provides the software team with a destination.

2.      Involve the customer in the planning activity.

·        The customer defines priorities and established project constraints.

3.      Recognize that planning is iterative.

·        The plan must be adjusted to accommodate changes.

·        In addition, iterative, incremental process models dictate replanning based on feedback received from users.

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.

5.      Consider risk as you define the plan.

·        If the team has defined risks that have high impact and high probability, contingency planning is necessary.

·        In addition, the project plan (including the schedule) should be adjusted to accommodate the likelihood that one or more these risks will occur.

6.      Be realistic.

·        Realities should be considered as a project plan is established.

–         People don’t work 100 percent of every day.

–         Noise always enters into any human communication.

–         Omissions and ambiguity are facts of life.

–         Change will occur.

–         Even the best software engineers make mistakes.

7.      Adjust granularity as you define the plan.

·        Granularity refers to the level of detail that is introduced as a project plan is developed.

·        A fine granularity plan provides significant work task detail that is planned over relatively short time increments.

·        A coarse granularity plan provides broader work tasks that are planned over longer time periods.

8.      Define how you intent to ensure quality.

·        If formal technical reviews are to be conducted, they should be scheduled.

·        If pair programming is to be used during construction, it should be explicitly defined within the plan.

9.      Describe how you intend to accommodate change.

·        Example situations:

–         Can the customer request a change at any time?

–         If a change is requested, is the team obliged to implement it immediately?

–         How is the impact and cost of the change assessed?

10.  Track the plan frequently and make adjustments as required.

·        It makes sense to track progress on a daily basis, looking for problem areas and situations in which scheduled work dons not conform to actual work conducted.

·        When slippage is encountered, the plan is adjusted accordingly.

W⁵HH Principle – Project Plan (Barry Boehm)

1.      Why is the system being developed?

·        Does the business purpose justify the expenditure of people, time, and money?

2.      What will be done?

·        Identify the functionality to be built, and by implication, the tasks required to get the job done.

3.      When will it be accomplished?

·        Establish a workflow and timeline for key project tasks and identify the milestones required by the customer.

4.      Who is responsible for a function?

·        The role and responsibility of each member of the software team must be defined.

5.      Where are they organizationally located?

·        The customer, users, and other stakeholders also have responsibilities.

6.      How will the job be done technically and managerially?

·        Once product scope is established, a management and technical strategy for the project must be defined.

7.      How much of each resource is needed?

·        Develop estimates based on answers to earlier questions.

 Modeling Practice

            We create models to gain a better understanding of the actual entity to be built. A software model must be capable of:

·        Representing the information that software transforms,

·        The architecture and functions that enable the transformation to occur,

·        The features that the users desires, and

·        The behavior of the system as the transformation is taking place.

 Two Classes of Models

1.      Analysis models

– represent the customer requirements by depicting the software in three different domains: the information domain, the functional domain, and the behavioral domain.

2.      Design models

– represent characteristics of the software that help practitioners to construct it effectively: the architecture, the user interface, and component-level detail.

 Analysis Modeling Principles

1.      The information domain of a problem must be represented and understood.

·        The information domain encompasses the data that flow into the system (from end0-usrs, 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).

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.

·        Some functions transform data that flow into the system.

·        Functions effect some level of control over internal software processing or external system elements.

3.      The behavior of the software (as a consequence of external events) must be represented.

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

4.      The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered fashion.

·        Analysis modeling is the first step in software engineering problem solving.  It allows the practitioner to better understand the problem and establishes a basis for the solution (design).

·        Partitioning, is a key strategy in analysis modeling where a large, complex problem is divided into subproblems until each subproblem is relatively easy to understand.

5.      The analysis task should move from essential information toward implementation detail.

·        Analysis modeling begins by describing the problem from the end-user’s perspective.  The essence of the problem is described without any consideration of how a solution will be implemented.

·        Implementation detail indicates how the essence will be implemented.

 Design Modeling Principles

1.      Design should be traceable to the analysis model.

·        The design model translates the information from the analysis model into an architecture: a set of subsystems that implement major functions, and a set of component-level designs that are the realization of analysis classes.

2.      Always consider the architecture of the system to be built.

·        Software architecture is the skeleton of the system to be built. It affects interfaces, data structures, program control flow and behavior, the manner in which testing can be conducted, the maintainability of the resultant system, etc.

3.      Design of data is as important as design of processing functions.

·        A well structured data design helps to simplify program flow, makes the design and implementation of software components easier, and makes overall processing more efficient.

4.      Interfaces (both internal and external) must be designed with care.

·        A well-designed interface makes integration easier and assists the tester in validating component functions.

5.      User interface design should be tuned to the needs of the end-user.

·        User interface should stress ease of use.

·        A poor interface design often leads to the perception that the software is “bad”.

6.      Component-level design should be functionally independent.

·        Functional independence is a measure of the “single-mindedness” of a software component.

·        The functionality that is delivered by a component should be cohesive – that is, it should focus on one and only one function or subfunction.

7.      Components should be loosely couple to one another and to the external environment.

·        Coupling is achieved in many ways – via a component interface, by messaging, through global data.

·        As the level of coupling increases, the likelihood or error propagation also increases and the overall maintainability of the software decreases.

·        Component coupling should be kept as low as possible.

8.      Design representations (models) should be easily understandable.

·        The purpose of design is to communicate information to practitioners who will generate code, to those who will test the software, and to others who may maintain the software in the future.

9.      The design should be developed iteratively. With each iteration, the designer should strive for greater simplicity.

 Construction Practice

This 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.  Coding may be: (1) the direct creation of programming language source code; (2) the automatic generation of source code using an intermediate design-like representation of the component to be built; (3) the automatic generation of executable code using a fourth generation programming language.

 Coding Principles and 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 and concepts.

3.      Pick a programming language that meets the needs of the software to be built and the environment in which it will operate.

4.      Select a programming environment that provides tools that will make your work easier.

5.      Create a set of unit tests that will be applied once the component you code is completed.

Coding principles: As you begin writing code, be sure you:

1.      Constrain your algorithms by following structured programming practice.

2.      Select data structures that will meet the needs of the design.

3.      Understand the software architecture and create interfaces that are consistent with it.

4.      Keep conditional logic as simple as possible.

5.      Create nested loops in a way that makes them easily testable.

6.      Select meaningful variable names and follow other local coding standards.

7.      Write code that is self-documenting.

8.      Create a visual layout (e.g., indentation and blank lines) that aids understanding.

Validation principles: After you’ve completed your first coding pass, be sure you:

1.      Conduct a code walkthrough when appropriate.

2.      Perform unit tests and correct errors you’ve encountered.

3.      Refactor the code.

 Levels of Testing

1.  Unit testing

·        Testing conducted at the component level.

2.  Integration testing

·        Testing conducted as the system is constructed.

3.  Validation testing

·        Testing that assesses whether requirements have been met for the complete system (or software increment).

4.  Acceptance testing

·        Testing conducted by the customer in an effort to exercise all required features and functions.

 Testing Objectives

·        Testing is a process of executing a program with the intent of finding an error.

·        A good test case 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.

 Testing Principles

1.      All tests should be traceable to customer requirements.

·        The most severe defects are those that cause the program to fail to meet its requirements.

2.      Tests should be planned long before testing begins.

·        All tests can be planned and designed before any code has been generated.

3.      The Pareto principle applies to software testing.

·        The Pareto principle implies that 80 percent of all errors uncovered during testing will likely be traceable to 20 percent of all program components.  The problem, of course, is to isolate these suspect components and to thoroughly test them.

4.      Testing should begin “in the small” and progress toward testing “in the large.”

·        The first tests planned and executed generally focus on individual components.  As testing progresses, focus shifts in an attempt to find errors in integrated clusters of components and ultimately in the entire system.

5.      Exhaustive testing is not possible.

·        The number of path permutations for even a moderately sized program is exceptionally large.  Therefore, it is impossible to execute every combination of paths during testing.

·        It is possible, however, to adequately cover program logic and to ensure that all conditions in the component-level design have been exercised.

 Deployment

The deployment activity encompasses three actions: delivery, support, and feedback.

 Deployment Principles

1.      Customer expectations for the software must be managed.

·        Be sure that your customer knows what to expect before a software increment is delivered. Otherwise, you can bet the customer will expect more than you deliver.

2.      A complete delivery package should be assembled and tested.

·        A CD-ROM or other media containing all executable software, support data files, support documents, and other relevant information must be assembled and thoroughly beta-tested with actual users. 

·        All installation scripts and other operational features should be thoroughly exercised in all possible computing configurations (i.e., hardware, operating systems, peripheral devices, networking arrangements).

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.

·        Support should be planned, support material should be prepared, and appropriate record keeping mechanisms should be established so that the software team can conduct a categorical assessment of the kinds of support requested.

4.      Appropriate instructional materials must be provided to end-users.

·        Appropriate training aids should be developed, trouble-shooting guidelines should be provided, and a “what’s-different-about-this-software-increment” description should be published.

5.      Buggy software should be fixed first, delivered later.

 Reference:  Software Engineering: A Practitioners Approach by Roger S. Pressman