April 8, 2023

Confidential

Tailoring the SDLCUpdating the SDLC to include DevOps, Agile and more.

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

Investigate Integrate & QAAnalysis Design Release OperateConstruct Consume EvolveStrategize

Solution LifecyclePortfolio Lifecycle

SDLC Extensions

EA & Bus. Process Lifecycle ExtensionsSOA Service Lifecycle ExtensionsCompliance & Security Extensions

Channel & UI Extensions

ITIL & Cloud Operating Model Extensions

Common Information Model

Model Driven Engineering

Product Line Variability

Special PurposeExtensions

Organizational DesignRolesPositionsResponsibilities

Org Units / CentersReporting StructuresMeasurements

SDLC TailoringRolesDisciplinesActivities

WorkflowsPhilosophiesBest Practices

Philosophies& Practices

Processes and Bok Influences

Software processes and bodies of knowledge are mined for ‘best philosophies’ to direct your SDLC efforts.

Tailored Philosophies

PRACTICE INDEX

Scrum

ID Affects DescriptionSC1 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’

ID Affects DescriptionTD1 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

ID Affects DescriptionFD1 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

ID Affects DescriptionLS1 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

ID Affects DescriptionAM1 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

ID Affects DescriptionXP1 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)

ID Affects DescriptionXP12 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)

ID Affects DescriptionXP24 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)

April 8, 2023 Confidential

DevOps

ID Affects DescriptionDO1 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.

ID Affects DescriptionES1 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)

SOA Manifesto (2009)ID Affects DescriptionSO1 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.

Harmony SOA Tenets

ID Affects DescriptionHS1 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

OpenUP (Practices)

ID Affects DescriptionOU1 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

OpenUP (Practices)

ID Affects DescriptionOU15 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

ID Affects DescriptionEU1 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

BODIES OF KNOWLEDGE

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

ID Affects DescriptionBA1 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.

Business Analysis Body of KnowledgeID Affects DescriptionBA14 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

Business Analysis Body of Knowledge

ID Affects DescriptionBA30 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

IT Service Mgmt. (ITIL v3)

ID Affects DescriptionIT1 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)

Project Management Body of Knowledge

ID Affects DescriptionPM1 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.

Project Management Body of Knowledge

ID Affects DescriptionPM5 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

COBIT

ID Affects DescriptionCO1 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.

COBIT

ID Affects DescriptionCO18 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.

Appendix

The MSI Enterprise SOA Manifesto

Communities over SilosEnterprise 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 ExtremesEnterprise 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 DeliveryThe 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 ScratchPortfolios 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 ManifestoI.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.

OPENUP PRACTICES

OpenUP Practices

Know your audienceYou 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 solutionToo 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 domainDomain 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 requirementsMany 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.

OpenUP Practices (cont’d)Establish and maintain agreement on prioritiesMaking 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 valueCost-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 scopeChange 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 stopOver-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.

OpenUP Practices (Cont’d)Maintain a common understandingProject 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 environmentPeople 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.

OpenUP Practices (Cont’d)

Share responsibilityThere 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 continuouslyNot 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 architectureAs 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.

OpenUP Practices (Cont’d)

Create the architecture for what you know todayAs 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 toolLack 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 abstractionSoftware 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 componentsTight 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 assetsIt 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.

OpenUP Practices (Cont’d)Develop your project in iterationsDeveloping 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 risksDeferring 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.

OpenUP Practices (Cont’d)Embrace and manage changeChange 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 objectivelyIf 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 doOn 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.

LEAN SOFTWARE DEVELOPMENT

Lean Software PrinciplesEliminate wasteEverything 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 communicationIn 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 learningSoftware 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 possibleAs 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 possibleIn 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.

Lean Software PrinciplesEmpower the teamThere 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 inThe 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 wholeSoftware 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.