Software Development Practice

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1

Lecture 5

Software Development Practice

Instructor: Hossein [email protected]

Mazandaran University of Science and Technology


What is “Practice”?

Practice is a broad array of concepts, principles, methods, and tools that you must consider as software is planned and developed.

It represents the details—the technical considerations and things that you’ll need to actually build high-quality computer software.


The Essence of Practice

George Polya, in a book written in 1945 (!) (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).

At its core, good practice is common-sense problem solving


Software Engineering Practices

Consider the generic process framework Communication

Planning

Modeling

Construction

Deployment

Here, we’ll identify Underlying principles

How to initiate the practice

An abbreviated task set


Communication Practices 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 best5. Take notes and document decisions6. Collaborate with the customer7. Stay focused, modularize your discussion (conclude each issue)8. Draw pictures when things are unclear9. 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


Communication Practices

Initiation The parties should be physically close to one another

Make sure communication is interactive

Create solid team “ecosystem”

Use the right team structure

An abbreviated task set Identify who it is you need to speak with

Define the best mechanism for communication

Establish overall goals and objectives and define the scope

Get more detailed Have stakeholders define scenarios for usage

Extract major functions/features

Review the results with all stakeholders


Customer and end-users

Main stakeholders

Customer: Originally request the software

Defines overall business objectives

Provides basic product requirements

Coordinate funding

End-user: Actually use the software to achieve some business purpose

Defines operational details


Generic task set for communication

1. Identify primary customer and other stakeholders

2. Meet with primary customer to address “context free questions” that define

Business need and business values

End-users characteristics / needs

Required user-visible outputs

Business constraints

3. Develop a one-page written statement of project scope

4. Review statement of scope with stakeholders

5. Collaborate


5. Collaborate with customer/end-users to define

Customer visible usage scenarios using standard format

Resulting outputs and inputs

Important software features, functions, and behavior

Customer-defined business risks

6. Develop a brief written description (a set of lists) of scenarios, output/inputs, features/functions and risks

7. Iterate the lists with customer to refine them.

8. Prioritize the items (customer-defined priorities)

9. Review

10. Prepare for planning


Planning Practices 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

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


Planning Practices

Initiation 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)


Generic task set for Planning

Re-assess project scope

Assess risks

Extract functions/features

Consider infrastructure functions/features

Create a coarse granularity plan Number of software increments

Overall schedule

Delivery dates for increments

Create fine granularity plan for first increment

Track progress


Create fine granularity plan for first increment Define work tasks for each function/feature

Estimate effort for each work task

Define work products

Identify quality assurance methods to be used

Describe methods for managing change


Modeling Practices

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.


Analysis Modeling Practices

Analysis modeling principles1. Represent the information domain

2. Represent software functions

3. Represent software behavior

4. Partition these representations

5. Move from essence toward implementation

Elements of the analysis model Data model

Flow model

Class model

Behavior model

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 implementation16

Generic tasks of analysis modeling1. Review business requirements, end users’

characteristics/needs, user visible outputs, business constraints, and other technical requirements (determined during communication and planning)

2. Expand and refine user scenarios (actors, interactions, functions)

3. Model the information domain (objects, attributes, relationships)

4. Model the functional domain

5. Model the behavioral domain

6. Model the user interface

7. Review to check for completeness, consistency and omission 17


Design Modeling Practices 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

Elements of the design model Data design

Architectural design

Component design

Interface design


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.



Coding principles: As you begin writing code, be sure you: Constrain your algorithms by following structured programming [BOH00]

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 (e.g., indentation and blank lines) that aids understanding.



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.



Testing Principles All tests should be traceable to requirements

Tests should be planned

Testing begins “in the small” and moves toward “in the large”

Exhaustive testing is not possible


Deployment Practices

Principles Manage customer expectations for each increment

A complete delivery package should be assembled and tested

A support regime should be established

Instructional materials must be provided to end-users

Buggy software should be fixed first, delivered later

Date post:	03-Feb-2022
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Software Development Practice

Documents