Software Development Best Practices

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 29

Libyan International Medical University

Faculty of Information Technology

Software Development
Best Practices

By:
Maryam Farkash 1734
Malak Baltu 1705
• Introduction:

• Software is the fuel on which modern businesses are run,


governments rule, and societies become better connected.

• Software has helped us create, access, and visualize information in


previously inconceivable ways and forms.

• Software is an indispensable part of our modern world.


• Introduction (Cont’d):

• The good news for software professionals is that worldwide


economies are becoming increasingly dependent on software.
Kinds of software-intensive systems are expanding in size,
complexity, distribution, and importance.

• The bad news is that when trying to advance legacy systems to


more modern technology brings its own set of technical and
organizational problems.
* Introduction (cont’d):

SOFTWARE DEVELOPMENT PROBLEMS:

• Inaccurate understanding of end-user needs.


• Software that’s hard to maintain or extend.
• Late discovery of serious project flaws.
• Poor software quality.
• Team members in each other’s way, making it impossible to
reconstruct who changed what, when, where, and why.

• Cases like these made the developers come up with practices


that might help them build a software from scratch and
without any problems.
Software Development Best Practices:

1. Develop software iteratively.


2. Manage requirements.
3. Visually model software.
4. Use component-based architectures.
5. Verify software quality.
6. Control changes to software.
1. Develop software iteratively:

Classic software development processes follow the waterfall life cycle.


In this approach, development proceeds linearly from requirements
analysis through design, code and unit testing, subsystem testing, and
system testing.
1. Develop software iteratively (Cont’d):

• The fundamental problem of this approach is that the late


discovery of design defects tends to result in costly overruns or
project cancellation. As Tom Gilb said, “If you do not actively
attack the risks in your project, they will actively attack you.”

• The waterfall approach tends to mask the real risks to a project


until it is too late to do anything meaningful about them.
1. Develop software iteratively (Cont’d):

• An alternative to the waterfall approach is the iterative and


incremental process. In this approach, building on the work of
Barry Boehm’s spiral model, the identification of risks to a project
is forced early in the life cycle, when it’s possible to attack and
react to them in a timely and efficient manner.
1. Develop software iteratively (Cont’d):

Developing software iteratively solutions:

1. Encourages user feedback so as to elicit the system’s real


requirements.
2. Continuous, iterative testing enables an objective assessment of
the project’s status.
3. Inconsistencies among requirements, designs, and
implementations are detected early.
4. The workload of the team is spread out more evenly throughout
the life cycle.
2. Manage Requirements:
A requirement is a condition or capability a system must meet. The
active management of requirements encompasses three activities:
eliciting, organizing, and documenting the system’s required
functionality and constraints; evaluating changes to these
requirements too.

Managing requirements are dynamic: you must expect them to change


during the life of a software project. It is impossible to completely state
a system’s requirements before the start of development.
2. Manage Requirements (Cont’d):
Managing the requirements offers a number of solutions to the
software development problems.

1. A disciplined approach is built into requirements


management.
2. Communications are based on defined requirements.
3. Requirements can be prioritized, filtered, and traced.
4. Inconsistencies are more easily detected.
3. Visually Model Software:
A model is a simplification of reality that completely describes a
system from a particular perspective, We build models so that we can
better understand the system we are modeling;
3. Visually Model Software:

Visual modeling tools facilitate the management of these models,


letting you hide or expose details as necessary such as UML
(Unified Modeling Language) these tools provide support for UML
modeling.
When coupled with the practice of developing software iteratively,
visual modeling helps you expose architectural changes and
communicate those changes to the entire development team.
3. Visually Model Software (Cont’d):
Modeling your software visually offers a number of solutions to the
software development problems.

1. Use cases and scenarios unambiguously specify behavior.


2. Models unambiguously capture software design.
3. Non-modular and inflexible architectures are exposed.
4. Details can be hidden when necessary.
5. Application quality starts with a good design.
4. Use Component-Based Architectures:
Visualizing, specifying, constructing, and documenting a software-
intensive system demand that the system be viewed from a number
of different perspectives. Each of the different stakeholders; end
users, analysts, developers, testers, and project managers looks at
that system in a different way at different times over the project’s
life.

A system’s architecture is the most important deliverable that is


used to manage these different viewpoints and thereby controls the
iterative and incremental development of a system throughout its
life cycle.
4. Use Component-Based Architectures (Cont’d):
A system’s architecture encompasses the set of significant
decisions about:

- The organization of a software system


- The selection of the structural elements and their interfaces by
which the system is composed
- The composition of these structural and behavioral elements
into progressively larger subsystems
- The architectural style that guides this organization: these
elements and their interfaces and their composition.
4. Use Component-Based Architectures (Cont’d):
Component-based development (CBD) is an important approach to
software architecture because it enables the reuse or customization
of existing components from thousands of commercially available
sources.

Coupled with the practice of developing software iteratively, using


component-based architectures involves the continuous evolution
of a system’s architecture. Each iteration produces an executable
architecture that can be measured, tested, and evaluated against
the system’s requirements. This approach permits the team to
continuously attack the most important risks to the project.
4. Use Component-Based Architectures (Cont’d):
Components make reuse possible on a larger scale, enabling systems to
be composed from existing parts and a few new parts that address the
specific domain and glue the other parts together. (See the figure below)
4. Use Component-Based Architectures (Cont’d):
Using component-based architectures offers a number of solutions
to the software development problems.
1. Components facilitate resilient architectures.
2. Modularity enables a clear separation of concerns among
elements of a system that are subject to change.
3. Components provide a natural basis for configuration
management.
4. Visual modeling tools provide automation for component-
based development.
5. Verify Software Quality:
Software problems are 100 to 1,000 times more expensive to find
and repair after deployment. (See the figure below)
For this reason, it’s important to continuously assess the quality of a
system with respect to its functionality, reliability, application
performance, and system performance.
5. Verify Software Quality (Cont’d):
Verifying a system’s functionality; the bulk of the testing activity;
involves creating tests for each key scenario, each of which
represents some aspect of the system’s desired behavior.

You can assess a system’s functionality by asking which scenarios


failed and where, as well as which scenarios and corresponding code
have not yet been exercised. As you are developing your software
iteratively, you test at every iteration, a process of continuous,
quantitative assessment.
5. Verify Software Quality (Cont’d):
Verifying software quality offers a number of solutions to the
software development problems.
1. This objective assessment exposes inconsistencies in
requirements, designs, and implementations.
2. Testing and verification are focused on areas of highest risk,
thereby increasing their quality and effectiveness.
3. Defects are identified earlier, radically reducing the cost of fixing
them.
4. Automated testing tools provide testing for functionality,
reliability, and performance.
6. Control Changes to Software:
A key challenge when you’re developing software-intensive systems
is that you must cope with multiple developers organized into
different teams, at different sites, working together on multiple
iterations, releases, products, and platforms. In the absence of
disciplined control, the development process goes into chaos.
Coordinating the activities and the artifacts of developers and teams
involves establishing repeatable workflows for managing changes to
software and other development artifacts.
6. Control Changes to Software (Cont’d):
This coordination allows a better allocation of resources based on
the project’s priorities and risks, and it actively manages the work
on those changes across iterations.
This practice lets you continuously monitor changes so that you can
actively discover and then react to problems. Coordinating
iterations and releases involves establishing and releasing a tested
baseline at the completion of each iteration.
6. Control Changes to Software (Cont’d):
Controlling changes to software offers a number of solutions to the
software development problems.

1. The workflow of requirements change is defined and repeatable.


2. Change requests facilitate clear communications.
3. Workspaces contain all artifacts, facilitating consistency.
4. Change propagation is assessable and controlled.
5. Changes can be maintained in a robust, customizable system.
The Rational Unified Process:
1. Provide guidance as to the order of a team’s activities.
2. Specify which artifacts should be developed and when they
should be developed.
3. Direct the tasks of individual developers and the team as a
whole.
4. Offer criteria for monitoring and measuring the project’s
products and activities.

Such a well-defined process enables and encourages all of the best


practices described earlier. When you codify these practices into a
process, your development team can build on the collective
experience of thousands of successful projects.
Summary:

* Building quality software in a repeatable and predictable fashion is


hard. And there are a number of symptoms of common software
development problems.

* Six best practices strike at these software development problems:


– Develop software iteratively.
– Manage requirements.
– Use component-based architectures.
– Visually model software.
– Verify software quality.
– Control changes to software.

* The Rational Unified Process brings these best practices together in


a form that is suitable for a wide range of projects and organizations.
Reference:
https://www.ibm.com/developerworks/rational/library/content/l
egacy/parttwo/1000/0664/0664_Kruchten_Ch01.pdf
THANK
YOU! 

You might also like