A guide to tailoring your SDLC to include modern practices such as DevOps, Agile and more!

1. Tailoring the SDLC
Updating the SDLC to include DevOps, Agile and more.
April 28, 2013
Confidential

2. Introduction
 MomentumSI encourages the tailoring of an SDLC
based on industry practices
 The processes, practices and bodies of knowledge
(BOK) should serve as inspiration to your custom SDLC
 Ultimately, the practices should also provide
traceability from your new SDLC back to industry best
practices

3. Investigate
Integrate
& QA
Analysis Design Release OperateConstruct Consume EvolveStrategize
Solution LifecyclePortfolio Lifecycle
SDLC Extensions
EA & Bus. Process Lifecycle Extensions
SOA Service Lifecycle Extensions
Compliance & Security Extensions
Channel & UI Extensions
ITIL & Cloud Operating Model Extensions
Common Information Model
Model Driven Engineering
Product Line Variability
Special Purpose
Extensions
Organizational Design
Roles
Positions
Responsibilities
Org Units / Centers
Reporting Structures
Measurements
SDLC Tailoring
Roles
Disciplines
Activities
Workflows
Philosophies
Best Practices
Philosophies
& Practices

4. Processes and Bok Influences
Software processes and bodies of
knowledge are mined for ‘best
philosophies’ to direct your SDLC
efforts.
Tailored
Philosophies

5. PRACTICE INDEX

6. Scrum
ID Affects Description
SC1 Project Management Transparency ensures that aspects of the process that affect the outcome must be
visible to those managing the outcomes.
Techniques include: ‘information radiator’, ‘sprint planning meeting’, ‘product
backlog’, ‘sprint backlog’
SC2 Project Management The various aspects of the process must be inspected frequently enough so that
unacceptable variances in the process can be detected.
Techniques include: ‘daily scrum meetings’, ‘burn down chart’
SC3 Project Management If the inspector determines from the inspection that one or more aspects of the
process are outside acceptable limits, and that the resulting product will be
unacceptable, the inspector must adjust the process or the material being
processed.
Techniques include: ‘daily scrum meetings’, ‘sprint review meeting’

7. ID Affects Description
TD1 Coding/Testing Writing a small number of new and failing automated unit test case(s) for the task at hand
TD2 Coding/Testing Implementing code which should allow the new unit tests cases to pass
TD3 Coding/Testing Re-running the new unit test cases to ensure they now pass with the new code
TD4 Coding/Testing Integrate code and tests for new code into existing code base
TD5 Coding/Testing Re-running all the test cases in the code base to ensure the new code does not break any
previously running test cases
TD6 Coding/Testing Refactoring the implementation or test code (as necessary)
TD7 Coding/Testing Re-running all tests in the code base to ensure that the refactored code does not break any
previously passing test cases
Test Driven Development

8. ID Affects Description
FD1 Design Perform domain object modeling
FD2 Design / Code Developing by feature
FD3 Coding Have class / code ownership
FD4 Management Have feature teams
FD5 Testing Perform inspections
FD6 Code / Release Have regular build schedule
FD7 Release Implement configuration management
FD8 Project
Management
Reporting / visibility of results
Feature Driven Development

9. ID Affects Description
LS1 All Eliminate Waste
LS2 All Minimize Paperwork / Artifacts
LS3 Project Mgmt. Implement in Small Increments
LS4 All Decide as Late as Possible
LS5 All Decide as Low as Possible / Empower the team
LS6 All Satisfy All Stakeholders
LS7 Coding/Testing Focus on Testing
LS8 Management Measure Business Results
LS9 Management Optimize Across Organizations
LS10 All Never Stop Improving
Lean Software Development

10. ID Affects Description
AM1 Release Mgmt. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
AM2 Change Mgmt. Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
AM3 Release Mgmt. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
AM4 Analysis Business people and developers must work together daily throughout the project.
AM5 Management Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
AM6 Management The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
AM7 Management Working software is the primary measure of progress.
AM8 Management Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
AM9 Architecture & Design Continuous attention to technical excellence and good design enhances agility.
AM10 Architecture & Design Simplicity--the art of maximizing the amount of work not done--is essential.
AM11 Management The best architectures, requirements, and designs emerge from self-organizing
teams.
AM12 Management At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
Agile Manifesto

11. ID Affects Description
XP1 Project Mgmt. User stories are written.
XP2 Project Mgmt. Release planning creates the release schedule.
XP3 Project Mgmt. Make frequent small releases.
XP4 Project Mgmt. The project is divided into iterations.
XP5 Project Mgmt. Iteration planning starts each iteration.
XP6 Management Give the team a dedicated open work space.
XP7 Management Set a sustainable pace.
XP8 Management A stand up meeting starts each day.
XP9 Management The Project Velocity is measured.
XP10 Management Move people around.
XP11 Management Fix XP when it breaks.
Extreme Programming (XP)

12. ID Affects Description
XP12 Design Simplicity.
XP13 Design Choose a system metaphor.
XP14 Design Use CRC cards for design sessions.
XP15 Design Create spike solutions to reduce risk.
XP16 Design No functionality is added early.
XP17 Design Refactor whenever and wherever possible.
XP18 Coding The customer is always available.
XP19 Coding Code must be written to agreed standards.
XP20 Coding Code the unit test first.
XP21 Coding All production code is pair programmed.
XP22 Coding Only one pair integrates code at a time.
XP23 Coding Integrate often.
Extreme Programming (cont’d)

13. ID Affects Description
XP24 Coding Set up a dedicated integration computer.
XP25 Coding Use collective ownership.
XP26 Testing All code must have unit tests.
XP27 Testing All code must pass all unit tests before it can be released.
XP28 Testing When a bug is found tests are created.
XP29 Testing Acceptance tests are run often and the score is published.
Extreme Programming (cont’d)

14. DevOps
April 28, 2013 Confidential
ID Affects Description
DO1 Planning, Release Create smaller releasable units to encourage more frequent deployments to staging with small,
regular releases to production.
DO2 Planning, Org
Design
The “Release engineer” is replaced with “cross-discipline delivery team”. No one person owns
the release process, it belongs to an integrated team who takes joint ownership.
DO3 Testing, Build Embrace the practice of ‘continuous builds’ and add ‘continuous testing’ to ensure that the
deliverables are of high enough quality to be released to production.
DO4 Configuration Infrastructure, platforms & application components and topologies are captured as code or
digitally recordable configuration format. This practice is encouraged to happen at the very
beginning of the SDLC so it can be used to recreate dev and test environments.
DO5 Build Provisioning of infrastructure and topology configuration is version controlled with app code.
DO6 Architect ‘Architected for Operations’ promotes concepts that enable a system to be more easily
administered once it is moved to production. This includes patching, starting/stopping/pausing,
scaling up and down, moving between SDLC environments, DR ready, cost sensitive, etc.
DO7 Architect ‘Instrumented for Operations’ promotes the use of monitors, logs, meters and other vehicles
that enable system triage and root cause analysis.
D08 Architect Scale-out WebOps. Deliver affordable, resilient architectures that scale linearly.
D09 Platform
Engineering
Platforms-on-demand. Deliver a set of template platforms that developers or testers can use to
quickly provision items in the reference architecture (database, app servers, etc.)
D10 Architect, Code Developers and architects are expected to “live with the application they wrote”. This means
that they are involved in production supports after release to learn lessons on how to make apps
better/faster/cheaper in production.

15. ID Affects Description
ES1 Enterprise Architecture Communities over Silos
ES2 Management Balanced Planning over The Extremes
ES3 Enterprise Architecture Governed Delivery over Ad-hoc Delivery
ES4 Architecture & Design Sharing and Reuse over Building from Scratch
ES5 Management Business Priorities over the Enterprise SOA Manifesto
Enterprise SOA Manifesto (2007)

16. SOA Manifesto (2009)
ID Affects Description
SO1 Management Respect the social and power structure of the organization.
SO2 Management Recognize that SOA ultimately demands change on many levels.
SO3 Management The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries.
SO4 Management Products and standards alone will neither give you SOA nor apply the service orientation paradigm
for you.
SO5 Standards SOA can be realized through a variety of technologies and standards.
SO6 Standards Establish a uniform set of enterprise standards and policies based on industry, de facto, and
community standards.
SO7 Architecture & Design Pursue uniformity on the outside while allowing diversity on the inside.
SO8 Analysis Identify services through collaboration with business and technology stakeholders.
SO9 Analysis Maximize service usage by considering the current and future scope of utilization.
SO10 Analysis Verify that services satisfy business requirements and goals.
SO11 Change Mgmt. Evolve services and their organization in response to real use.
SO12 Architecture & Design Separate the different aspects of a system that change at different rates.
SO13 Architecture & Design Reduce implicit dependencies and publish all external dependencies to increase robustness and
reduce the impact of change.
SO14 Architecture & Design At every level of abstraction, organize each service around a cohesive and manageable unit of
functionality.

17. Harmony SOA Tenets
ID Affects Description
HS1 Design Contract first development
HS2 Design Application framing
HS3 Enterprise
Architecture
Silo search & destroy
HS4 Enterprise
Architecture
Process driven business
HS5 Project Mgmt. Spiral outside; agile inside
HS6 Strategic Reuse Promote for reuse
HS7 Enterprise
Architecture
Governing for growth
HS8 Project Management Service as the unit of work
HS9 Configuration SOA Bill of Materials

18. OpenUP (Practices)
ID Affects Description
OU1 Analysis Know your audience
OU2 Analysis Separate the problem from the solution
OU3 Analysis Create a shared understanding of the domain
OU4 Analysis Use scenarios and use cases to capture requirements
OU5 Project Mgmt. Establish and maintain agreement on priorities
OU6 Project Mgmt. Make trade-offs to maximize value
OU7 Analysis Manage scope
OU8 Analysis Know when to stop
OU9 Analysis Maintain a common understanding
OU10 Analysis Foster a high-trust environment
OU11 All Share responsibility
OU12 All Learn continuously
OU13 Architecture & Design Organize around the architecture
OU14 Architecture & Design Create the architecture for what you know today

19. OpenUP (Practices)
ID Affects Description
OU15 Management Leverage the architecture as a collaborative tool
OU16 Management Cope with complexity by raising the level of abstraction
OU17 Management Organize the architecture into loosely coupled, highly cohesive components
OU18 Management Reuse existing assets
OU19 Standards Develop your project in iterations
OU20 Standards Manage risks
OU21 Architecture & Design Embrace and manage change
OU22 Analysis Measure progress objectively
OU23 Analysis Continuously re-evaluate what you do

20. ID Affects Description
EU1 Analysis Acknowledge Enterprise Business Modeling as a Discipline
EU2 Portfolio
Management
Acknowledge Portfolio Management as a Discipline
EU3 Enterprise
Architecture
Acknowledge Enterprise Architecture as a Discipline
EU4 Strategic Reuse Acknowledge Strategic Reuse as a Discipline
EU5 People
Management
Acknowledge People Management as a Discipline
EU6 Enterprise
Administration
Acknowledge Enterprise Administration as a Discipline
EU7 Software Process
Improvement
Acknowledge Software Process Improvement as a Discipline
EU8 Operations and
Support
Acknowledge Operations and Support as a Discipline
EU9 All Acknowledge Production as a Phase
EU10 All Acknowledge Retirement as a Phase
Enterprise Unified Process

21. BODIES OF KNOWLEDGE

22. About BoK’s
 ‘Bodies of Knowledge’ are a set of ideas, practices or techniques
that have been shown to provide value
 Typically, they are very ‘action oriented’ rather than ‘philosophy
oriented’
 BoK’s can be mined for specific activities that you may
incorporate into your SDLC

23. ID Affects Description
BA1 Analysis Elicit Requirements:: Techniques: Brainstorming, Document Analysis, Focus Group, Interface
Analysis, Interview, Observation, Prototyping, Requirements Workshop, Reverse Engineering,
Survey / Questionnaire
BA2 Analysis Structure requirements packages
BA3 Analysis Create business domain models
BA4 Analysis Analyze user requirements
BA5 Analysis Analyze functional requirements
BA6 Analysis Analyze quality of service requirements
BA7 Analysis Determine assumptions and constraints
BA8 Analysis Determine requirements attributes
BA9 Analysis Document requirements
BA10 Analysis Validate requirements
BA11 Analysis Verify requirements
BA12 Analysis Capture data and behavior models:: Techniques: Business rules, class model, CRUD matrix, data
dictionary, data transformation and mapping, entity relationship diagrams, metadata definition
BA13 Analysis Capture process and flow models:: Techniques: Activity diagram, data flow diagram, event
identification, flowchart, sequence diagram, state machine diagram & workflow models
Business Analysis Body of Knowledge
http://www.tmgmt.net/documents/BOKV1_6.pdf
BABOK identifies potential tasks with some techniques rather than philosophies or tenets.

24. Business Analysis Body of Knowledge
ID Affects Description
BA14 Analysis Usage Models:: Techniques: Prototyping, storyboards/screen flows, use case descriptions, use
case diagrams, user interface designs, user profiles, user stories
BA15 Analysis Create a requirements communication plan
BA16 Analysis Manage requirements conflicts
BA17 Analysis Determine appropriate requirements format
BA18 Analysis Create a requirements package
BA19 Analysis Conduct a requirements presentation
BA20 Analysis Conduct a formal requirements review
BA21 Analysis Obtain requirements signoff
BA22 Analysis Develop alternative solutions
BA23 Analysis Evaluate technology options
BA24 Analysis Facilitate the selection of a solution
BA25 Analysis Ensure the usability of the solution
BA26 Analysis Support the quality assurance process
BA27 Analysis Support the implementation of the solution
BA28 Analysis Communicate the solution impacts
BA29 Analysis Post implementation review and assessment

25. Business Analysis Body of Knowledge
ID Affects Description
BA30 Analysis Understand team roles for the project
BA31 Analysis Define business analyst work division strategy
BA32 Analysis Define requirements risk approach
BA33 Analysis Determine planning considerations
BA34 Analysis Select requirements activities
BA35 Analysis Estimate requirements activities
BA36 Analysis Manage requirements scope
BA37 Analysis Measure and report on requirements activity
BA38 Analysis Manage requirements change

26. IT Service Mgmt. (ITIL v3)
ID Affects Description
IT1 Operations Acknowledge Service Strategy (Financial mgmt, service portfolio management & demand
management)
IT2 Operations Acknowledge Service Design (service catalogue mgmt., service level mgmt., capacity mgmt.,
availability mgmt., IT service continuity mgmt., information security mgmt. & supplier mgmt.)
IT3 Operations Acknowledge Service Transition (transition planning and support, change management, service
asset and configuration mgmt., release and deployment mgmt., service validation and testing,
evaluation & knowledge mgmt.)
IT4 Operations Acknowledge Service Operation (Event mgmt., Incident mgmt., request fulfillment, problem
mgmt., access mgmt., monitoring and control, IT operations & service desk)
IT5 Operations Acknowledge Continual Service Improvement (CSI improvement process, Service Reporting)

27. Project Management Body of Knowledge
ID Affects Description
PM1 Project Mgmt. Perform project integration management
-Develop project charter
- Develop preliminary project scope statement
- Develop project management plan
- Direct and manage project execution
- Monitor and control project work
- Perform integrated change control
- Close project
PM2 Project Mgmt. Project scope management
-Scope planning
- Scope definition
- Create work breakdown structure
- Scope verification
- Scope control
PM3 Project Mgmt. Project time management
- Activity resource estimating
- Activity duration estimating
- Schedule development
- Schedule control
PM4 Project Mgmt. Project cost management
- Cost estimating
- Cost budgeting
- Cost control
PMBOK identifies potential tasks with some techniques rather than philosophies or tenets.

28. Project Management Body of Knowledge
ID Affects Description
PM5 Project Mgmt. Project quality management
- Quality planning
- Perform quality assurance
- Perform quality control
PM6 Project Mgmt. Project human resource management
- Human resource planning
- Acquire project team
- Develop project team
- Manage project team
PM7 Project Mgmt. Project communications management
- Communications planning
- Information distribution
- Performance reporting
- Manage stakeholders
PM8 Project Mgmt. Project risk management
- Risk management planning
- Risk identification
- Qualitative & quantitative risk analysis
- Risk response planning
- Risk monitoring and controlling
PM9 Project Mgmt. Project procurement management
-Plan purchases and acquisitions
- Plan contracting
- Request seller responses
- Select sellers
- Contract administration & closure

29. COBIT
ID Affects Description
CO1 Leadership Define a strategic IT plan.
CO2 Enterprise Arch. Define the information architecture.
CO3 Enterprise Arch. Determine technological direction.
CO4 Management Define the IT processes, organization and relationships.
CO5 IT Governance Manage the IT investment.
CO6 Management Communicate management aims and direction.
CO7 Management Manage IT human resources.
CO8 Multiple Manage quality.
CO9 Multiple Assess and manage IT risks.
CO10 Project Mgmt. Manage projects.
CO11 Multiple Identify automated solutions.
CO12 Multiple Acquire and maintain application software.
CO13 Operations Acquire and maintain technology infrastructure.
CO14 Operations Enable operation and use.
CO15 Multiple Procure IT resources.
CO16 Multiple Manage changes.
CO17 Operations Install and accredit solutions and changes.

30. COBIT
ID Affects Description
CO18 Operations Define and manage service levels.
CO19 Multiple Manage third-party services.
CO20 Operations Manage performance and capacity.
CO21 Operations Ensure continuous service.
CO22 Security Ensure systems security.
CO23 Management Identify and allocate costs.
CO24 OCM Educate and train users.
CO25 Operations Manage service desk and incidents.
CO26 Operations Manage the configuration.
CO27 Multiple Manage problems.
CO28 Information Arch. Manage data.
CO29 Operations Manage the physical environment.
CO30 Operations Manage operations.
CO31 Management Monitor and evaluate IT performance.
CO32 Management Monitor and evaluate internal control.
CO33 Management Ensure compliance with external requirements.
CO34 Management Provide IT governance.

31. Appendix

32. The MSI Enterprise SOA Manifesto
Communities over Silos
Enterprise Architecture focuses on creating portfolios of integrated software to fulfill a business mission. Although application silo's can often be
created more quickly, the long term process of integrating silo's of logic, data and policy create spaghetti architecture, demoralize teams,
stagnate innovation and increase long term maintenance costs. Communities (or application portfolio domains) should adhere to enterprise
standards while each zone tailors the localized rules and regulations.
Balanced Planning over The Extremes
Enterprise SOA attempts to balance 'planning' versus the extremes (too little/too much). The popularity of the Agile movement was largely a
knee-jerk reaction to the frustrations with "waterfall planning". Enterprise SOA blends long term planning with tight iterations. Think, "planning
in the large, agility in the small".
Governed Delivery over Ad-hoc Delivery
The enterprise must prioritize the needs of the many over the needs of the few. Applications must be architected to fit into an ecosystem of
applications. This will require adherence to guidelines and policies on technical standards and software processes, employed to protect the long
term interests of the community.
Sharing and Reuse over Building from Scratch
Portfolios of applications will have many common functional requirements. An implicit non-functional requirement in Enterprise SOA is to design
for sharing and reuse where appropriate.
Business Priorities over the Enterprise SOA Manifesto
I.T. systems are either a reflection of the business today or a projection of where the business is heading tomorrow. The I.T. approach must not
become a religious battle fought at the expense of the business. On occasion, it will be in the best interest of the business to violate the
principles of the Enterprise SOA Manifesto for the purpose of 'doing the right thing' for the business. Appropriate planning, governance and
leadership should make this the exception, not the rule.

33. OPENUP PRACTICES

34. OpenUP Practices
Know your audience
You cannot know how to make effective trade-offs if you do not know who the stakeholders are and what they really want. Get to know
your stakeholders. Better yet, work closely with them to ensure that you know their needs. Start by identifying all stakeholders, and then
maintain open and frequent communication and collaboration between them and the development team.
Separate the problem from the solution
Too often, we run headlong into a solution without understanding the problem. After all, we are taught how to solve problems, not how to
define problems, so that's easier. However, this limits your understanding of the problem, imposes artificial constraints, and makes it
difficult to balance trade-offs, or to even know what the trade-offs are. Make sure that you understand the problem before you define the
solution. By clearly separating the problem (what the customer needs) from the solution (what the system must do), it is easier to maintain
the proper focus, and easier to accommodate alternate ways of solving the problem.
Create a shared understanding of the domain
Domain experts often have limited technical expertise; developers, architects, and testers often have limited domain expertise; and
reviewers and other stakeholders often have limited time to commit to the project and learn the problem domain. As a result, people often
have an inconsistent or poor understanding of the problem domain, which causes communication problems and increases the likelihood of
delivering poor value to the stakeholders. Enhance and share all parties' understandings of the domain. A concise and shared
understanding of the problem domain enhances communication and project effectiveness. Start by defining the problem in the Vision
document. As your understanding increases, capture key domain concepts and terminology in the Glossary to ensure a consistent, shared
use of the language of the domain.
Use scenarios and use cases to capture requirements
Many companies still document requirements as a list of declarative statements, which are sometimes called the "shall statements." These
lists are often difficult for stakeholders to understand, because they require the end user to read through and mentally translate the list
into a visualization of how the requirements will interact with the system.
Make use of scenarios and use cases to capture functional requirements in a form that is easy for stakeholders to understand.
Nonfunctional requirements, such as performance, stability, or usability requirements, are important and can be documented as system-
wide requirements, using traditional techniques.

35. OpenUP Practices (cont’d)
Establish and maintain agreement on priorities
Making poor decisions in deciding what to develop next can result in wasted effort, delivering capabilities that are never used, or identifying
problems late in the project (resulting in delays and even project failure). Prioritize requirements for implementation by regularly working with
the stakeholders during product evolution. Make choices that deliver value and reduce risks, while building a system that can evolve.
Make trade-offs to maximize value
Cost-benefit trade-offs cannot be made independent of the architecture. Requirements establish the benefits of the system to the stakeholder,
while architecture establishes the cost. The cost of a benefit may influence the stakeholder's perceived value of the benefit. Work with the
stakeholders and team members to prioritize requirements and develop candidate architectures to implement those solutions. Use the candidate
architectures to evaluate the cost of the benefits. Candidate solutions are considered at a high level when determining architectural feasibility.
Different architectural perspectives can result in different assessments of cost versus benefit. The candidate architecture that provides the most
coverage at the lowest cost is selected for further development.
Manage scope
Change is inevitable. Although change presents opportunities to enhance stakeholder value, unconstrained change will result in a bloated,
deficient system and unmet stakeholder needs. Manage change while maintaining agreements with the stakeholders. Modern processes always
manage change, continually adapting to changes in the environment and stakeholder needs, assessing the impact of changes, making trade-offs,
and re-prioritizing work. Stakeholder and developer expectations must be realistic and aligned throughout the development lifecycle.
Know when to stop
Over-engineering a system not only wastes resources, but also leads to an overly complex system. Stop developing the system when the desired
quality is achieved. Remember that "Quality is conformance to the requirements" [CRO79]. This is what gives a sense of closure to the practice.
Separate the problem from the solution, ensuring that the solution does, indeed, solve the problem. After the critical requirements are
implemented and validated, the system is ready for stakeholder acceptance.

36. OpenUP Practices (Cont’d)
Maintain a common understanding
Project participants require a common understanding of a project to cooperate effectively. Otherwise, disorder sets in, because the team
members cannot align their understanding and interests, and will then work with different purposes.
Be proactive communicating and sharing information with project participants. Do not assume that everyone will just find what they need to
know, or that each person has the same understanding of the project as everyone else. Use work products (such as the Vision, Work Items List,
and Requirements) to align the understanding between the stakeholders and developers. Use the architecture to focus and align the interests of
the developers. At the end of each iteration, get agreement on whether the iteration goals have been reached and, if not, what actions must be
taken.
Foster a high-trust environment
People who do not feel safe will not communicate their ideas, take initiative, or admit their ignorance. In these low-trust work environments,
activities must be laboriously planned in detail, carefully supervised, and extensively audited. A team working in a low-trust environment may
not be able to keep up with rapid change.
Take actions that foster a high-trust environment:
•Manage by intent. Create an environment where teams manage themselves, and managers serve as mentors to teams to help them complete
their objectives.
•Tear down the walls. Work to remove both the physical and mental barriers that inhibit development of a common understanding among
project participants.
•Walk a mile (or 1.6 kilometers) in someone else's shoes. Respect and try to understand the perspectives of others before criticizing their ideas
or responding to their criticism.
•Respond to conversations with relevance. People, especially technical workers, often respond with argument or disagreement, which leads to
rivalry and establishes a pecking order in which only a few people contribute to the discussion. Develop and encourage behavior that values
curiosity and relevance over argument and disagreement.
•Always look to yourself first for the source of communication problems. Understand that everyone has a perspective that is largely invisible
to the individual (although it is often obvious to everyone else). Develop the habit of identifying the assumptions and prejudices within you that
lead to argument or lack of communication. Learn to overcome these in the moment of the conversation. This takes practice. There are times
when others may be intractable, but often the problem can be addressed by wrestling with your own perspective.
•Understand the constraints of the workplace culture. Some organizations operate in a way that allows people to admit mistakes, ask
questions, and experiment. Some organizations limit these expressions, but they may change, with time and effort. Some organizations have no
tolerance for error, and their workers put themselves in danger if they admit mistakes or experiment.

37. OpenUP Practices (Cont’d)
Share responsibility
There may be disadvantages for individuals when they work alone. Communication with the team can become sporadic, and then stop. People may
get into trouble and not ask for help, or not realize that the team is in trouble and needs their help. Their understanding of the project may become
misaligned with the rest of the team. In the worse situations, trust breaks down as individuals see the team working at different purposes to their
interests.
While individuals have primary responsibility for their work products, responsibility for work products is shared. Nothing is someone else's
responsibility. This may mean either taking up slack and working with someone who is lagging for some reason, or asking for help. Experienced
staff should be extra-vigilant and watch over less-experienced staff, encouraging them to ask for help if necessary.
Learn continuously
Not only is software development a fast-developing field where technical skills rapidly become obsolete, it is also an empirical process, where
software is developed in a manner that sometimes resembles trial and error. Furthermore, software is developed by teams of people who must
work together to achieve results.
Continuously develop both your technical and interpersonal skills. Learn from the examples of your colleagues. Take the opportunity to be both a
student of your colleagues, as well as a teacher to them. Always increase your personal ability to overcome your own antagonism toward other
team members.
Organize around the architecture
As projects grow in size, communication between team members becomes increasingly complex. While all team members understand the overall
system, they can focus primarily on the one or more subsystems that they are responsible for. Organizing around the architecture also helps with
communication by providing the team with a common vocabulary and shared mental model of the system. Communication between team
members becomes increasingly complex.
Organize the team around the architecture, and the vocabulary and a shared mental model of the system. However, be careful that individuals and
teams organized this way do not form a so-called silo mentality, where they focus strictly on their subsystems and become ignorant of the other
subsystems.
An architecture that reflects the organization's structure is not in itself evidence that the team has successfully organized around the architecture.
If organizations and teams are not organized around the architecture, then the architecture will naturally conform to the organization, as a result of
political and cultural influences. In the end, the architecture and the organization will almost always be a reflection of each other. The goal is to
guide team organization from the needs of the architecture as much as possible.

38. OpenUP Practices (Cont’d)
Create the architecture for what you know today
As Albert Einstein said, make everything as simple as possible, but no simpler. Software projects are resource-constrained, and the desire of
developers to create elegant solutions may lead to a system of greater complexity than the stakeholder requires. Efforts to future-proof a system in
a turbulent or uncertain environment will likely lead to code bloat, which increases overall costs and complexity with few real benefits.
Create architectures that address the stakeholder's real needs, and provide appropriate flexibility and speed for the requirements as they are
known today. Avoid the desire, no matter how well-intentioned, to speculate on future requirements and thereby over-engineer the architecture.
There is a distinction between over-architecting and building an architecture that is flexible and extensible. For example, there may not be an
apparent reason for creating three architectural layers in a system, but it is probable that the system will grow in ways one can't predict, so we
should architect for that.
Leverage the architecture as a collaborative tool
Lack of a common understanding by developers about a system leads to indecision and contrary opinions among developers, and can quickly
paralyze the project. Developers may have different mental models of the system and work at cross purposes to each other.
Create and evolve the system architecture with the intention of using it to align the developers' competing mental models of the system. A good
architecture facilitates collaboration by providing a common vocabulary for all discussions regarding the system under development.
Cope with complexity by raising the level of abstraction
Software is complex, and people have a limited capacity for coping with complexity. As a system gets larger, it is difficult for the team to develop a
common understanding of the system, because it's hard to see the bigger picture.
Use models to raise the level of abstraction to focus on important high-level decisions, such as relationships and patterns, rather than getting
bogged down in details. Modeling raises the level of abstraction, and allows the system to be more easily understood from different perspectives.
Organize the architecture into loosely coupled, highly cohesive components
Tight coupling between components makes a system fragile and difficult to understand. Software is expensive to create, so if existing components
can be reused, that may reduce effort required to create a system.
Organize the architecture of the system into components to maximize cohesion and minimize coupling. This improves comprehension, and
increases flexibility and opportunities for re-use.
Reuse existing assets
It is wasteful to build what you can simply reuse, download, or even buy.
Make every effort to reuse existing assets. Developers are often reluctant to reuse assets, because those assets do not exactly meet their needs, or
those assets are of poor quality. Be prepared to balance the savings you can realize using an existing asset, even if the asset requires you to make
some accommodation in the architecture or relax a constraint.

39. OpenUP Practices (Cont’d)
Develop your project in iterations
Developing a system in a single, linear pass is difficult, because it makes it expensive to incorporate changes and new knowledge. Worse, it can
delay the discovery and mitigation of risks, because development efforts are scheduled later in the lifecycle.
Divide your project into a series of time-boxed iterations, and plan your project iteratively. This iterative strategy enables you to incrementally
deliver capabilities (such as an executable, usable subset of implemented and tested requirements) that can be assessed by stakeholders at the
end of each iteration. This provides rapid and timely feedback loops, so that issues can be addressed and improvements made at a lower cost.
Also, this is accomplished while you still have sufficient budget and time left to do so, and you have not gone so far ahead that major rework is
required.
Iterative development enables teams to continuously improve software throughout the development lifecycle. Focus iterations on meeting the
next management milestone
A project can appear to make progress while risks and unresolved issues pile up. Focus on bringing closure to important project issues (such as
stakeholder concurrence regarding scope, and proving the proposed architecture).
Divide the project into phases (such as Inception, Elaboration, Construction and Transition), with each phase having a clearly visible
management milestone. The focus of each iteration within a phase is on achieving that milestone.
Manage risks
Deferring difficult and risky issues until later in a project significantly increases the risk of project failure. Such procrastination may lead to
investing in the wrong technologies, a bad design, or a set of requirements that may not address stakeholder needs.
Attack risks early, or they will attack you. Continuously identify and prioritize risks, and then devise strategies to mitigate them. Determine the
focus of iterations based on risks. For example, architecturally significant risks should be addressed early in the project, no later than the end of
the Elaboration phase, when the architecture has been proven and base-lined.

40. OpenUP Practices (Cont’d)
Embrace and manage change
Change is inevitable, and while change presents opportunities to enhance stakeholder value, unconstrained change will result in a bloated,
deficient system and unmet stakeholder needs. Furthermore, the later in the development cycle a change is made, the more the change is likely to
cost.
Embrace and manage change. Embracing change helps you to build a system that addresses stakeholder needs, and managing change allows you to
reduce costs and improve predictability of those changes. Changes made early in the project can usually be made with limited cost. As you progress
in your project, changes can become increasingly costly.
To satisfy customer needs, you typically need to introduce changes to the project, but the customer must be made aware of the impact that those
changes have on the project cost and schedule. Understand the impact of a change in the current phase, and isolate team members from
disruptive changes during the current iteration. Change requests are reviewed and prioritized during the current iteration, but are not acted upon
until assigned to a future iteration. If necessary, document the changes. For informal projects, a discussion with stakeholders may be enough.
Measure progress objectively
If you do not objectively know how your project is progressing, you do not really know if it is failing or succeeding. Uncertainty and change make a
software project's progress difficult to measure objectively, and people are prone to making objective assessments from subjective information.
Get a clear picture of project status by objectively measuring progress. The best measure of progress is the delivery of working software, which is
something that you do by taking an evolutionary approach. You can also define a set of objective metrics to collect during an iteration (for example,
requirements that were implemented and validated, number of defects issued compared with number fixed) and review them as part of the
iteration assessment.
Continuously re-evaluate what you do
On a regular basis, ask questions and verify assumptions about the project. Regularly meet with the team to track status and identify risks and
issues. This can be done daily when the team gathers to share the status of individual responsibilities and identify and address issues. At the end of
iterations, assess the status of what has been done and look for areas of improvement that can be addressed in the next iteration. Have a
retrospective review at the end of the project and capture lessons learned to run future projects in a more efficient way.
If we always challenge what we do and seek new, innovative ways to develop software, we improve how we work. This leads to improved project
results.

41. LEAN SOFTWARE
DEVELOPMENT

42. Lean Software Principles
Eliminate waste
Everything not adding value to the customer is considered to be waste (muda). This includes: unnecessary code and functionality, delay in the
software development process, unclear requirements, bureaucracy & slow internal communication
In order to be able to eliminate waste, one should be able to recognize and see it. If some activity could be bypassed or the result could be
achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Extra processes and features
not often used by customers are waste. Waiting for other activities, teams, processes is waste. Defects and lower quality are waste. Managerial
overhead not producing real value is waste. A value stream mapping technique is used to distinguish and recognize waste. The second step is to
point out sources of waste and eliminate them. The same should be done iteratively until even essential-seeming processes and procedures are
liquidated.
Amplify learning
Software development is a continuous learning process with the additional challenge of development teams and end product sizes. The best
approach for improving a software development environment is to amplify learning. The accumulation of defects should be prevented by running
tests as soon as the code is written. Instead of adding more documentation or detailed planning, different ideas could be tried by writing code and
building. The process of user requirements gathering could be simplified by presenting screens to the end-users and getting their input.The
learning process is sped up by usage of short iteration cycles – each one coupled with refactoring and integration testing.
Decide as late as possible
As software development is always associated with some uncertainty, better results should be achieved with an options-based approach, delaying
decisions as much as possible until they can be made based on facts and not on uncertain assumptions and predictions. The more complex a
system is, the more capacity for change should be built into it, thus enabling the delay of important and crucial commitments. The iterative
approach promotes this principle – the ability to adapt to changes and correct mistakes, which might be very costly if discovered after the release
of the system.
Deliver as fast as possible
In the era of rapid technology evolution, it is not the biggest that survives, but the fastest. The sooner the end product is delivered without
considerable defect, the sooner feedback can be received, and incorporated into the next iteration. The shorter the iterations, the better the
learning and communication within the team. Without speed, decisions cannot be delayed. Speed assures the fulfilling of the customer's present
needs and not what they required yesterday. This gives them the opportunity to delay making up their minds about what they really require until
they gain better knowledge. Customers value rapid delivery of a quality product. The Just-in-Time production ideology could be applied to software
development, recognizing its specific requirements and environment.

43. Lean Software Principles
Empower the team
There has been a traditional belief in most businesses about the decision-making in the organisation – the managers tell the workers how to do
their own job. In a Work-Out technique, the roles are turned – the managers are taught how to listen to the developers, so they can explain better
what actions might be taken, as well as provide suggestions for improvements. Most experienced project managers[who?] have simply stated the
key for a successful project – "Find good people and let them do their own job.“
Build integrity in
The customer needs to have an overall experience of the System – this is the so called perceived integrity: how it is being advertised, delivered,
deployed, accessed, how intuitive its use is, price and how well it solves problems.
Conceptual integrity means that the system’s separate components work well together as a whole with balance between flexibility, maintainability,
efficiency, and responsiveness. At the end the integrity should be verified with thorough testing, thus ensuring the System does what the customer
expects it to.
See the whole
Software systems nowadays are not simply the sum of their parts, but also the product of their interactions. Defects in software tend to
accumulate during the development process – by decomposing the big tasks into smaller tasks, and by standardizing different stages of
development, the root causes of defects should be found and eliminated. The larger the system, the more organisations that are involved in its
development and the more parts are developed by different teams, the greater the importance of having well defined relationships between
different vendors, in order to produce a system with smoothly interacting components.
Lean thinking has to be understood well by all members of a project, before implementing in a concrete, real-life situation. “Think big, act small, fail
fast; learn rapidly” – these slogans summarize the importance of understanding the field and the suitability of implementing lean principles along
the whole software development process. Only when all of the lean principles are implemented together, combined with strong “common sense”
with respect to the working environment, is there a basis for success in software development.