Structural Engineering Topics

• Soil Mechanics
• Structural Mechanics
• Hydraulics and Hydrology
• Codes and Construction
• Risk management, uncertainty
• Project Planning & Scheduling
• Cost estimating
• Activity identification and sequencing

Software Engineering Topics

• Programming Languages
• Data structures, algorithms & complexity
• Operating Systems, Networking, Database, ...
• Object oriented design
• Systems architecture
• ??

Procedures, Processes, Methodologies, Practices

DOD SE Process Model (2008)

dap.dau.mil

DOD Systems Software Development (1988)

DOD-STD-2167A Standard

Waterfall Model

Wikipedia

Core Processes

• Software Requirements (Elicitation, Analysis, Specification, Validation)
• Software Design (including: Architecture, UI)
• Software Construction
• Software Testing
• Software Maintenance

Related Processes

• Software Configuration Management
• Software Engineering Management
• Software Engineering Process
• Software Engineering Modeling
• Software Quality
• Software Engineering Professional Practice
• Software Engineering Economics
• Computing and Mathematical Foundations

SWEBOK

Software Engineering Book of Knowledge, Vol. 3

SWEBOKv3.pdf (local copy)

Requirements Analysis

“Software requirements express the needs and constraints placed on a software product that contribute to the solution of some real-world problem. ... It is widely acknowledged amongst researchers and industry practitioners that software projects are critically vulnerable when the requirements- related activities are poorly performed”

Software Design

Both the process of defining the architecture, components, interfaces, etc. and the result of that process. “during software design, software engineers produce various models that form a kind of blueprint of the solution to be implemented. We can analyze and evaluate these models to determine whether or not they will allow us to fullfill the various requirements.”

Software Construction

“the detailed creation of working software through a combination of coding, verification, unit testing, integration testing, and debugging ... much design work is performed during the construction activity.”

Software Testing

“the dynamic verification that a program provides expected behaviors on a finite set of test cases, suitably selected from the usually infinite execution domain. Can also imply static testing.”

Software Maintenance

“all the activities required to provide cost-effective support to (previously delivered) software.”

“software products change or evolve ... once in operation, defects are uncovered, operating environments change and new user requirements surface.” These must be covered by software maintenance.

Criticims of Waterfall

Cost of Change

• Unknowns
• Uncertainty
• Risk
• Changes
• Software engineering isn't linear
• Creation of software is often a creative process

Disciplined Agile Delivery

“The Disciplined Agile Delivery (DAD) process framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value lifecycle, is goal-driven, is scalable and is enterprise aware.”

DAD

• People first
• Learning oriented
• Agile
• Hybrid
• IT solution focused
• Goal-driven
• Delivery focused
• Enterprise aware
• Risk and value driven
• Scalable

DAD Lifecycle

Goals

Disciplined Agile Principles

1. Our highest priority is to satisfy the stakeholder through early and continuous delivery of valuable solutions.
2. Welcome changing requirements, even late in the solution delivery lifecycle. Agile processes harness change for the customer’s competitive advantage.
3. Deliver consumable solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
4. Stakeholders and developers must work together daily throughout the project.
5. Build teams around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a delivery team is face-to-face conversation.
7. Consumable solutions are the primary measure of progress.
8. Agile processes promote sustainable delivery. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
13. Leverage and evolve the assets within your enterprise, collaborating with the people responsible for those assets to do so.
14. Visualize work to produce a smooth delivery flow and keep work-in-progress (WIP) to a minimum.
15. Evolve the enterprise to support agile, non-agile, and hybrid teams.

Lean Principles

• Eliminate waste; build in quality
• Create knowledge; defer commitment
• Deliver quickly; respect people
• Optimize the whole; visualize workflow
• Limit work-in-progress (WIP)

Reality over Rhetoric

• Requirements evolve throughout the lifecycle although the initial scope should still be agreed to at the beginning of the project.
• Simple designs are best although the architecture should be thought out early in the lifecycle.
• Teams should be self-organizing although they are still constrained (and enhanced) by your organizational ecosystem
• Delivery teams don't need prescriptive process definitions although they do need some high-level guidance to help organize their work.

• Development professionals know what to do although they're still not process experts.
• Development professionals should validate their own work to the best of their abilities although they likely aren't testing experts so therefore need help picking up the appropriate skills.
• Disciplined agile teams work in an iterative manner although still follow a lifecycle that is serial over time.

Foundations of DAD

or ... all the things DAD has integrated

Agile Practices adopted by DAD

• Scrum
• Extreme Programming (XP)
• Agile Modeling
• Agile Data
• Lean software development
• IBM Practrices Library
• OpenUP
• + others

Scrum

Scrum: key points for now

• Sprint-based (iterative, time-boxed)
• “Deliver potentially shippable software at the end of each sprint”
• User story based

Extreme Programming (XP)

Take the good things to extremes

• Coding guidelines and standards
• Code transparency
• Continuous integration
• Test Driven Development (TDD)
• Code Refactoring
• Pair programming
• Principles: Feedback -- Simplicity -- Embrace change

Agile Modeling

Methodology for effective modeling and documentation

• “Just enough modeling; just barely good enough” (KISS)
• Modeling at all phases of construction; model storming
• Document continuously, but late
• Executable specifications: executable customer tests
• Test Driven Development

Agile Data

Agile methods to work effectively with the data aspects your project

• Database refactoring: evolutionary improvement of dB schema
• Agile Data modeling for the dB
• DB regression testing
• Configuration management of data
• Developer sandboxes

Lean Software Development

Lean thinking applied to software development

• Eliminate waste
• Amplify learning
• Delay decisions
• Deliver fast, frequent delivery
• Find good people and let them work

Open Unified Process

Roles, Rights & Responsibilities

“People build solutions -- not processes, not tools, not practices -- people.”

Individuals and interactions over processes and tools.

role

a part that you play within a given situation. Includes stakeholders, team leads, team members, ...

right

something to which you have just claim

responsibility

an obligation that you have to someone else

Rights of Everyone

Responsibilities of Everyone

Roles

Stakeholder

• End users
• Principals
• Partners
• Insiders

Product Owner

“the one voice of the customer”, the stakeholder proxy

Team Member

Produces the actual solution for stakeholders: developers, programmers, ...

Team Lead

Team facilitator, guide, servant-leader, agile coach (ScrumMaster).

NOT: boss, manager or project manager

Remember: agile teams are self-organizing

Architecture Owner

Owns architecture decisions, facilitates creation and evolution of the overall solution design. Often the senior developer.

Inception

Typical Approach

Example Inception Phase Order

• Requirements envisioning
• Architecture envisioning
• Set up environment(s)
• Review UI prototype
• Lots of everything
• Release planning

Patterns for success

• Short and sufficient
• Ranged estimates
• Minimal but sufficient documentation

ANTI-Patterns for success

• No support for skills development
• No support for dedicated facilities
• Autocratic project management practices
• Jumping into construction
• Overly detailed work products
• Analysis paralysis

Project Vision

What's in a Vision?

• What are you going to produce?
• How long will it take?
• What will it cost?
• How are you going to build it?
• Do you understand the risks?

Vision Styles

• Detailed vision document/project charter/ business case (heavyweight, 20-50 pages)
• Lightweight vision statement (1-4 pages)
• Vision radiators
• Nothing at all

Bring Stakeholders to Agreement Around the Vision

The fundamental purpose of the Inception phase is to come to an agreement within your team and with your stakeholders regarding a strategy for the rest of the project.

=> Active stakeholder participation

=> Shared vision

Identifying the Initial Scope

Most agile teams do initial requirements modeling

• Answer fundamental business questions
• Improve productivity
• Reduced business risk
• Increased scalability

But only hours or days, not weeks or months No BRUF!

Modeling

• Use
  • User stories
  • Use case
  • Usage scenarios
• Domain: Entities and Relationships
  • ER or UML diagrams
  • CRC cards
• UI
  • Wireframes, Sketches & Diagrams
  • Flow diagram
• Non-functional (Quality of Service, or technical) requirements

Choose Work Management Strategy

• Formal change management, change control board, change requests/tickets
• Scrum product backlog
• Work item stack
• Work item pool
• No strategy!

Nonfunctional Requirements

Strategies for NFR's

• Technical stories
• Acceptance criteria for individual functional requirements
• An explicit list

Initial Technical Strategy (Architecture)

Level of Detail

• Detailed end-to-end
• Detailed interface
• High-level overview
• None

Inception Phase Case Study

User Stories

As a type of user, I want some goal so that some reason.

• Wikipedia
• Mountain Goat Software: User stories
• 10 tips for writing good user stories

INVEST

(see Bill Wake)

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

Vision Statement

Classical Software Requirements Elicitation and Modeling

Use Cases

Software Modeling & Design, by Hassan Gomaa Ch. 21

User Story vs. Use Case

• Use Case

  • Formal, UML specifications
  • Heavyweight, prescribed documentation
  • Attempt to define what systems are supposed to do; capture all requirements
  • Actors, Systems, Interactions

• User Story

  • Lightweight; short descriptions
  • Don't provide details needed to implement (which emerge organically later)
  • Actor, Action, Achievement; focused on value
  • Acceptance criteria

Use Cases can help with initial modeling

Some handwritten notes on UML: UML.pdf

Static Modeling

Conceptual Class Diagram

More Detailed Class Diagram

Dynamic Modeling

Sequence Diagram