Download - 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
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 2
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.
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 3
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
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 4
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
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 5
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
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 6
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
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 7
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
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 8
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
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 9
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
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 10
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
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 11
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)
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 12
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
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 13
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
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 14
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.
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 15
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
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 18
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
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 19
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.
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 20
Construction Practices
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.
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 21
Construction Practices
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.
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 22
Construction Practices
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
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 23
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