1. PRJ270: Essentials of Rational Unified Process
IBM Software Group
Best Practices of Software Development
Rational Unified Process (RUP)
Module 1 Best Practices of Software Engineering

2. Software Development Best Practices
PRJ270: Essentials of Rational Unified Process
Software Development Best Practices
Animation note:
mouse clicks
Symptom highlighted
Root causes highlighted
Best practices highlighted
Symptoms
Root Causes
Best Practices
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Undetected inconsistencies
Poor testing
Subjective assessment
Waterfall development
Uncontrolled change
Insufficient automation
Needs not met
Requirements churn
Modules don’t fit
Hard to maintain
Late discovery
Poor quality
Poor performance
Colliding developers
Build-and-release
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
Treat these root causes, and you’ll eliminate the symptoms. Eliminate the symptoms, and you’ll be in a much better position to develop quality software in a repeatable and predictable fashion.
Best practices are a set of commercially proven approaches to software development, which when used in combination, strike at the root causes of software development problems. These are so-called “best practices,” not because you can precisely quantify their value, but rather because we observe their common use in the industry by successful organizations.
The best practices are harvested from thousands of customers on thousands of projects and from industry experts.
Module 1 Best Practices of Software Engineering

3. Practice 1: Develop Iteratively
PRJ270: Essentials of Rational Unified Process
Practice 1: Develop Iteratively
We need to keep the concept of iterative development at a very high level in this module. It is easy to get bogged down in the many ramifications of iterative development.
Try just to get the concept across. Rational offers a course that covers this in more detail.
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
Developing iteratively is a technique that is used to deliver the functionality of a system in a series of releases of increasing completeness. Each release is developed in a specific, fixed time period called an “iteration”.
Each iteration is focused on defining, analyzing, designing, building, and testing some set of requirements.
Module 1 Best Practices of Software Engineering

4. Waterfall Development Characteristics
PRJ270: Essentials of Rational Unified Process
Waterfall Development Characteristics
Waterfall Process
Requirements
Analysis
Design
Code and Unit Test
Subsystem
Integration
System Test
To illustrate a problem with the waterfall model: Suppose we estimate that the project will take 2 years, and it really takes 3 years. At the end of 2 years, what do we have? Nothing useful works. No partial delivery is possible. Diagrams and models are great, but they can’t execute.
Delays confirmation of critical risk resolution
Measures progress by assessing work-products that are poor predictors of time-to-completion
Delays and aggregates integration and testing
Precludes early deployment
Frequently results in major unplanned iterations
Waterfall is conceptually straightforward because it produces a single deliverable. The fundamental problem of this approach is that it pushes risk forward in time, when it is costly to undo mistakes from earlier phases. An initial design will likely be flawed with respect to its key requirements, and furthermore, the late discovery of design defects tends to result in costly overruns and/or project cancellation. The waterfall approach tends to mask the real risks to a project until it is too late to do anything meaningful about them.
Module 1 Best Practices of Software Engineering

5. Iterative Development Produces Executables
PRJ270: Essentials of Rational Unified Process
Iterative Development Produces Executables
Planning
Requirements
Analysis & Design
Implementation
Deployment
Test
Evaluation
Management
Environment
The earliest iterations address greatest risks. Each iteration produces an executable release. Each iteration includes integration and test.
Iterations help:
resolve major risks before making large investments.
enable early user feedback.
make testing and integration continuous.
focus project short-term objective milestones.
make possible deployment of partial implementations.
Iterative processes were developed in response to waterfall characteristics. With an iterative process, the waterfall steps are applied iteratively. Instead of developing the whole system in lock step, an increment (i.e. a subset of system functionality) is selected and developed, then another increment, and so on.
The selection of the first increment to be developed is based on risk, the highest priority risks first. To address the selected risk(s), choose a subset of use cases. Develop the minimal set of use cases that will allow objective verification (that is, through a set of executable tests) of the risks that you have chosen. Then select the next increment to address the next highest risk, and so on. Thus you apply the waterfall approach within each iteration, and the system evolves incrementally.
Each iteration results in an executable release.
Module 1 Best Practices of Software Engineering

6. Practice 2: Manage Requirements
PRJ270: Essentials of Rational Unified Process
Practice 2: Manage Requirements
You can generate discussion with the students concerning how they get requirements and how they manage them now.
Students who want to know in detail how to manage requirements should take the Rational course on the subject.
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
CHAOS: A Recipe For Success (1999) from the Standish Group shows that by 1998, the rate of success of software development projects was still only 26%, compared with 16% in The remaining 74% of projects were either cancelled before completion, or completed and operational but over time, over budget and with fewer features and functions than originally specified. Contributing factors to these low rates of success were incorrect definition of requirements from the start of the project and poor requirements management throughout the development lifecycle.
Source: The Chaos Report (1994) and CHAOS: A Recipe For Success (1998) at
Module 1 Best Practices of Software Engineering

7. Requirements Management Means…
PRJ270: Essentials of Rational Unified Process
Requirements Management Means…
Making sure you
solve the right problem
build the right system
by taking a systematic approach to
eliciting
organizing
documenting
managing
the changing requirements of a software application.
Module 1 Best Practices of Software Engineering

8. PRJ270: Essentials of Rational Unified Process
Map of the Territory
Problem
Problem Space
Needs
Solution Space
Features
Traceability
The Product to Be Built
Software
Requirements
Managing requirements involves translating stakeholder requests into a set of key stakeholder needs and system features. These in turn are detailed into specifications for functional and nonfunctional requirements. Detailed specifications are translated into test procedures, design, and user documentation.
Traceability allows you to:
Assess the project impact of a change in a requirement.
Assess the impact of a failure of a test on requirements (that is, if the test fails, the requirement may not be satisfied).
Manage the scope of the project.
Verify that all requirements of the system are fulfilled by the implementation.
Verify that the application does only what it was intended to do.
Manage change.
Test Scripts
Design
User Docs
Module 1 Best Practices of Software Engineering

9. Use Cases as a Basis for Iteration Planning
PRJ270: Essentials of Rational Unified Process
Use Cases as a Basis for Iteration Planning
The way that use cases drive analysis and design is intuitive to most students. However, they may be surprised to find that use cases become an important factor in planning the activities for a given iteration.
Iteration Plan
Fine-grained plan for
a single iteration
Project Management
Constraints
During Elaboration, use cases are implemented to validate the architecture.
Use-Case Model
Supplementary
Specifications
Planning is part of the Project Management discipline. Planning is done at several levels, from high-level project plans, to the detailed plans generated for each individual iteration. Iteration plans are largely driven by the subset of use cases that are selected for implementation in the iteration. Many constraints must also be taken into account, such as the number of developers available, the results of previous iterations, the overall Project Plan, and so on.
Module 1 Best Practices of Software Engineering

10. Use Cases as a Basis for System Modeling
PRJ270: Essentials of Rational Unified Process
Use Cases as a Basis for System Modeling
As in traditional engineering disciplines (e.g., electrical and civil), models are the language of designer.
Note: RUP is use-case- driven. A use-case model is used to drive design, development and testing of the project throughout the project lifecycle.
Come to an agreement with the customer on what the system should do (Use- Case Model)
Assure that the design matches the requirements (Design Model)
Produce source code that matches the design (Implementation Model)
Verify and validate the delivered product against the requirements (Test Model)
In this course, we will be concentrating on the Design Model (the Data Model is considered part of the Design Model, but will not be addressed in detail in this course).
The other models are each developed in separate RUP workflows.
Use-Case Model
(requirements)
realization
verification
influence
Use cases defined for a system are the basis for the entire development process. They provide the unifying thread through the system and define the behavior performed by a system. Use cases play a role in each of four core disciplines.
The use-case model is a result of the Requirements discipline. In this early process you need the use cases to model what the system should do from the user's point of view.
In Analysis and Design, use cases are realized in a design model. You create use-case realizations which describe how the use case is performed in terms of interacting objects in the design model. This model describes, in terms of design objects, the different parts of the implemented system and how the parts should interact to perform the use cases.
During Implementation, the design model is the implementation specification. Because use cases are the basis for the design model, they are implemented in terms of design classes.
During Test, the use cases constitute basis for identifying test scripts, which are the step-by-step instructions that realize a test, enabling its execution.
Use cases have other roles as well:
Basis for planning an iterative development
Foundation for what is described in user manuals
Ordering units: For example, a customer can get a system configured with a particular mix of use cases.
Design Model
(classes and objects)
Implementation Model
(source code)
Test Scripts
Module 1 Best Practices of Software Engineering

11. Use Cases as a Basis for Test Planning
PRJ270: Essentials of Rational Unified Process
Use Cases as a Basis for Test Planning
The complete behavior of a use case is tested using Test Scripts and Test Suites.
In case there is a student question: It is not necessarily true that an entire use case is tested in a single iteration. In that case, it may be several scenarios that are tested, or it may be that parts of several scenarios are tested. A scenario is an instance of a use case or, equivalently, a single path through the use case.
Test scripts are also mentioned in RUP. A test script is a set of computer- readable instructions that automate the execution of test procedures.
Test Suite
Test Script
A Test Script is the step-by-step instructions that realize a test, enabling its execution. Test Scripts may take the form of either documented textual instructions that are executed manually or computer-readable instructions that enable automated test execution.
A Test Suite is a package-like artifact used to group collections of Test Scripts, both to sequence the execution of the tests and to provide a useful and related set of Test Log information from which Test Results can be determined.
For more information, see Disciplines->Test->Guidelines Overview.
Module 1 Best Practices of Software Engineering

12. Practice 3: Use Component Architectures
PRJ270: Essentials of Rational Unified Process
Practice 3: Use Component Architectures
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
Software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost, according to the authors of Software Architecture in Practice (Len Bass, Paul Clements & Rick Kazman [1998] Addison-Wesley). The Software Engineering Institute (SEI) has an effort underway called the Architecture Tradeoff Analysis (ATA) Initiative to focus on software architecture, a discipline much misunderstood in the software industry. The SEI has been evaluating software architectures for a long time and would like to see architecture evaluation in wider use. By performing architecture evaluations, AT&T reported a 10 percent productivity increase (from Vol. 1, No. 2).
Module 1 Best Practices of Software Engineering

13. Purpose of a Component-Based Architecture
PRJ270: Essentials of Rational Unified Process
Purpose of a Component-Based Architecture
Basis for reuse
Component reuse
Architecture reuse
Basis for project management
Planning
Staffing
Delivery
Intellectual control
Manage complexity
Maintain integrity
Because students vary in how familiar they are with the concept of architecture applied to software, it is best to get a sense of this from the students before beginning this section. If they are fairly unfamiliar, it helps to use the analogy of buildings or civil engineering. The more complex the building, the more critical a good architecture is. The longer you want the building to be useful, the more effort and expense you will put into the architecture. And in both of these cases, the choice of architect is critical.
Component-based architecture with layers
System-
software
Middleware
Business-
specific
Application-
What is a “software component”?
RUP Definition: A nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component conforms to and provides the physical realization of a set of interfaces.
UML Definition: A physical, replaceable part of a system that packages implementation and conforms to and provides the realization of a set of interfaces. A component represents a physical piece of implementation of a system, including software code (source, binary, or executable) or equivalents, such as scripts or command files.
Module 1 Best Practices of Software Engineering

14. Practice 4: Model Visually (UML)
PRJ270: Essentials of Rational Unified Process
Practice 4: Model Visually (UML)
You may wish to lead a discussion about models and why we build models in general. For example, before building a bridge, the architect builds a model and has it reviewed.
We build models because the thing we are studying is so complex that no one can understand all of the details. A model leaves out all the details that are unimportant for a given purpose. It facilitates our understanding of the larger issues.
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
A model is a simplification of reality that provides a complete description of a system from a particular perspective. You build models so that you can better understand the system you are modeling. You build models of complex systems because you cannot comprehend any such system in its entirety.
Module 1 Best Practices of Software Engineering

15. One Language for All Practitioners
PRJ270: Essentials of Rational Unified Process
One Language for All Practitioners
Application Modeling
Requirements
Modeling
Tecnology Modeling
Business Modeling
Data Modeling
One language – One tool – One team
Module 1 Best Practices of Software Engineering

16. PRJ270: Essentials of Rational Unified Process
Role of UML in RUP
Rational Unified Process was developed hand-in-hand with the UML.
Many artifacts in Rational Unified Process have a UML representation.
Rational Unified Process also includes guidelines for UML concepts.
Some have the notion that just by using UML you are following a process. Clear up any confusion that exists on that point. UML is integral to RUP, but it is a modeling language, not a process.
Clarification of UML and Process:
Rational has worked with OMG on the definition of a meta model for software development processes. This work is called SPEM. It provides a consistent way to describe processes, but is not a process in its own right.
In order for development organizations to reap the true benefits of the UML, they need to know how to use it effectively.
The UML provides a set of standards for the artifacts of development. Artifacts of development are the things that must be controlled and exchanged, for example, semantic models, syntactic notation, and diagrams. However, the UML is not a standard for the development process.
Despite all of the value that a common modeling language brings, you cannot achieve successful development of today’s complex systems solely by the use of the UML. Successful development also requires employing an equally robust development process.
Module 1 Best Practices of Software Engineering

17. Practice 5: Continuously Verify Quality
PRJ270: Essentials of Rational Unified Process
Practice 5: Continuously Verify Quality
Do not assume that verifying quality and testing are synonymous. While testing is used to do the bulk of quality verification, there are other techniques that we will mention.
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
Quality is defined in RUP as “…having demonstrated the achievement of producing a product which meets or exceeds agreed-upon requirements, as measured by agreed-upon measures and criteria, and is produced by an agreed-upon process." Given this definition, achieving quality is not simply "meeting requirements" or producing a product that meets user needs and expectations. Quality also includes identifying the measures and criteria (to demonstrate the achievement of quality), and the implementation of a process to ensure that the resulting product has achieved the desired degree of quality (and can be repeated and managed).
In many organizations, software testing accounts for 30 percent to 50 percent of software development costs. Yet most people believe that software is not well-tested before it is delivered. This contradiction is rooted in two clear facts. First, testing software is enormously difficult. The different ways a particular program can behave are almost infinite. Second, testing is typically done without a clear methodology and without the required automation or tool support. While the complexity of software makes complete testing an impossible goal, a well-conceived methodology and use of state-of-the-art tools can greatly improve the productivity and effectiveness of the software testing.
Module 1 Best Practices of Software Engineering

18. Continuously Verify Your Software’s Quality
PRJ270: Essentials of Rational Unified Process
Continuously Verify Your Software’s Quality
Software problems are 100 to 1000 times more costly to find and repair after deployment
Many people remember Barry Boehm’s groundbreaking work in Software Economics where he quantified the relative expense to fix a bug at different times in the development lifecycle. Be cautious, however, since his work was based on the waterfall model, not an iterative development model.
The iterative model fundamentally changes how and when we test.
Cost to Repair Software
Cost of Lost Opportunities
Cost of Lost Customers
Cost
This principle is driven by a fundamental and well-known property of software development: it’s a lot less expensive to correct defects during development than to correct them after deployment.
Tests for key scenarios ensure that all requirements are properly implemented
Poor application performance hurts as much as poor reliability
Verify software reliability—memory leaks, bottlenecks
Test every iteration—automate test!
Development Phases
Module 1 Best Practices of Software Engineering

19. Testing Dimensions of Quality
PRJ270: Essentials of Rational Unified Process
Testing Dimensions of Quality
Usability
This is the FURPS model of dimensions of quality presented in RUP. See RUP for details about all these types of tests. Be prepared to define and discuss all.
Test application from the perspective of convenience to end-user.
Functionality
Test the accurate workings of each usage scenario
Reliability
Test that the application behaves consistently and predictably.
Supportability
Functional testing verifies that a system executes the required use-case scenarios as intended. Functional tests may include the testing of features, usage scenarios, and security.
Usability testing evaluates the application from the user’s perspective. Usability tests focus on human factors, aesthetics, consistency in the user interface, online and context-sensitive wizards and agents, user documentation, and training materials.
Reliability testing verifies that the application performs reliably and is not prone to failures during execution (crashes, hangs, memory leaks). Effective reliability testing requires specialized tools. Reliability tests include integrity, structure, stress, contention and volume tests.
Performance testing checks that the target system works functionally and reliably under production load. Performance tests include benchmark tests, load tests, and performance profile tests.
Supportability testing verifies that the application can be deployed as intended. Supportability tests include installation and configuration tests.
Test the ability to maintain and support application under production use
Performance
Test online response under average and peak loading
Module 1 Best Practices of Software Engineering

20. PRJ270: Essentials of Rational Unified Process
Test Each Iteration
UML Model and Implementation
Tests
Iteration 1
Test Suite 1
Iteration 2
Test Suite 2
Iteration 4
Test Suite 4
Iteration 3
Test Suite 3
The point to be made on this slide is that it is important to start automating test in the earliest iterations. Some people think that you don’t need to automate testing until the later iterations when requirements are pretty stable. Even if you expect that the requirements, and hence the tests, are still unstable, it is still more efficient to automate.
In each iteration, manual and automated tests are created to test the requirements addressed in that iteration. As new requirements are added in subsequent iterations, new tests are generated and run. At times, a requirement may be changed in a later iteration. In that case, the tests associated with the changed requirement may be modified or simply regenerated by an automated tool.
Need for automated testing increases
Module 1 Best Practices of Software Engineering

21. Practice 6: Manage Change
PRJ270: Essentials of Rational Unified Process
Practice 6: Manage Change
Control of change is especially important in an iterative project. Artifacts are generally produced incrementally. At the end of each iteration, another increment is put under configuration control. Otherwise, no progress will be made, and iterations will not converge on a complete and consistent system. We are not just talking about changes to source code, but also to requirements, models, documents, plans, and all development artifacts.
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
As indicated earlier, change will inevitably be introduced into your project. However, you must control how and when changes are introduced into project artifacts, and who introduces the changes. You must also synchronize change across development teams and locations.
Unified Change Management (UCM) is Rational Software's approach to managing change in software system development, from requirements to release.
Module 1 Best Practices of Software Engineering

22. Muutostenhallinta - Change Request Management
PRJ270: Essentials of Rational Unified Process
Muutostenhallinta - Change Request Management
Change requests come from many sources throughout each iteration of the product lifecycle
Customer and User inputs
New Feature
Single Channel
for Approval
Req
Marketing
New
Requirement
Design
Approved Decision Process
(CCB)
Coders inputs
Testers inputs
Code
As requests come in during our lifecycle, intercept them and pass through a single approval channel.
The single channel of approval may be one person (like a project manager), or perhaps a group of representatives (for example; a CCB, Change – or Configuration – Control Board). The CCB should have representatives from each of the relevant groups.
Bug
Test
Change Request (CR)
Help Desk
User inputs
Maint
Module 1 Best Practices of Software Engineering

23. Unified Change Management

24. Best Practices Reinforce Each Other: An Example
PRJ270: Essentials of Rational Unified Process
Best Practices Reinforce Each Other: An Example
Best Practices
This slide may be confusing unless it is explained properly. We have discussed each Best Practice individually in this module. This slide is intended to illustrate how the Best Practices used together provide much more benefit than each individually. The slide only illustrates how ONE of the Best Practices (Develop Iteratively) supports the others. How others interact might make a good discussion point for the students. For example, how do Manage Change and Continuously Verify Quality relate? Well, there is no point in running a test against an unknown configuration and no point in writing a defect against an unknown baseline. Similarly, there is no point in controlling changes until you have reached a stable level of quality in a product.
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
Ensures users involved
as requirements evolve
Validates architectural
decisions early on
In the case of our six Best Practices, the whole is much greater than the sum of the parts. Each of the Best Practices reinforces and, in some cases, enables the others. The slide shows just one example: how iterative development leverages the other five Best Practices. However, each of the other five practices also enhances iterative development. For example, iterative development done without adequate requirements management can easily fail to converge on a solution. Requirements change at will, users can’t agree, and the iterations can go on forever. When requirements are managed, this is less likely to happen. Changes to requirements are visible, and the impact on the development process is assessed before they are accepted. Convergence on a stable set of requirements is ensured. Similarly, each pair of Best Practices provides mutual support.
Addresses complexity of
design/implementation incrementally
Measures quality early and often
Evolves baselines incrementally
Module 1 Best Practices of Software Engineering

25. RUP Implements Best Practices
PRJ270: Essentials of Rational Unified Process
RUP Implements Best Practices
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
Why use a process?
It provides guidelines for efficient development of quality software
It reduces risk and increases predictability
It promotes a common vision and culture
It captures and institutionalizes best practices
RUP is a generic process for software development. It describes a common structure and a common process architecture from which a family of related software engineering processes can be derived. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget. RUP captures the best practices in modern software development in a form that can be adapted for a wide range of projects and organizations.
Module 1 Best Practices of Software Engineering

26. Bringing It All Together: The Iterative Approach
PRJ270: Essentials of Rational Unified Process
Bringing It All Together: The Iterative Approach
time
content
Can iterations overlap?
No. Our model is to show no overlap among iterations. In a large project, several teams may work in parallel on their portions of the iteration, but we do not consider these to be separate iterations.
How many iterations should you have?
It depends on many factors. Err on the side of too many iterations.
Animation note: The callouts and black rectangle appear 2 seconds after the slide.
In an iteration, you walk through all disciplines.
This graphic illustrates how phases and iterations (the time dimension) relate to the development activities (the content dimension). The relative size of the color area indicates how much of the activity is performed in each phase/iteration.
Each iteration involves activities from all disciplines. The relative amount of work related to the disciplines changes between iterations. For instance, during late Construction, the main work is related to Implementation and Test and very little work on Requirements is done.
Note that requirements are not necessarily complete by the end of Elaboration. It is acceptable to delay the analysis and design of well-understood portions of the system until Construction because they are low in risk.
Disciplines group related activities.
Module 1 Best Practices of Software Engineering

27. Changing Focus of Phases Over Time
PRJ270: Essentials of Rational Unified Process
Changing Focus of Phases Over Time
Planned (Business) Decision Points
Iterations represent the engineering perspective of the project. This is what concerns the developers on a day-to-day basis.
Scope and Business Case agreement
Architecture baselined
Product sufficiently mature for customers to use
Acceptance
or end of life
understand
problem
understand
solution
have a
solution
efficient use
of solution
Inception
Elaboration
Construction
Transition
Preliminary
Iteration
Architecture
Architecture Iteration
Development
The dotted line indicates that the first product build may not be at executable level. However, later builds will have increasing functionality, culminating in the completed product.
Planned (Technical) Visibility Points
Module 1 Best Practices of Software Engineering

28. Typical Effort and Time Percentages by Phase
PRJ270: Essentials of Rational Unified Process
Typical Effort and Time Percentages by Phase
Time
People
Const
Elab
Trans
Inc
Note the fact that a relatively small part of the expense is incurred by the end of Elaboration, when the all significant architectural risks are removed and the product can be built with high confidence.
Note also that Inception and Elaboration can be considered the Engineering Stage (where discovery and invention are firmed up) and that Construction and Transition can be considered the Implementation Stage (where work can proceed on a firm foundation).
Inc
Elab
Const
Trans
Effort 5%
20%
65%
10%
Time/Schedule
30%
50%
Module 1 Best Practices of Software Engineering