Notes

Outline

Developing Software As If Your Life Depends On It! The skills and attitudes necessary for survival in today’s dot-and-dash market. A free-flowing foray into the world of software development as told by Steven Marcus. Marcus Software Designs, Inc. smarcus@MarcusSoftwareDesigns.com

Beginning Assumptions Attendees participate in SW development process. Attendees are competent in their respective technical areas. Attendees care about delivering quality software solutions. Attendees have a sense of humor.

Agenda Speaker Bio and Disclaimer. Put things into perspective. How we do software development. Processes. Summary.

Speaker Bio and Disclaimer Professional musician (too long). Chevron Corporation – 1981 – 1991. Marcus Software Designs, Inc. – established – 1990. My opinions. DAMA staff and personnel are not in any way responsible for the content and quality of this discussion. So please forgive them.

Why I am here To express and share ideas. To elicit feedback. I want to hear what you think. To have fun!

Putting things into perspective What is software development? Why do we it and for whom do we do it? Who does this stuff?

What is software development? The act of forming and evolving solutions that meet specific human needs; that is, a solution that solves one or many human problems. A highly creative discipline that incorporates other disciplines from psychoanalysis to number theory. An effort whose effects are unpredictable. A effort whose results are based on ever increasing levels of description.

Why do we do it and for whom do we do it? Satisfies our need to solve problems. Creative and fulfilling (when and if it works). Lucrative. We do it for people. The same reason we do anything else.

Who does this stuff? Creative types (Architects, Designers). Analytical types (Business analysts and specifiers). Engineering types (Designers, Programmers, Micro Modelers). Other - Loner types. People who cannot do anything else. People who were forced into it. Musicians.

The Attitude Software Development is not for everyone. Ruthless desire to achieve. Honest, open communication. Passion and commitment. Competent, informed, knowledgeable. Able to give and take criticism. Good poker player.

Metaphors of various fields Military Sports Music

Military Metaphor Potentially life or death situations for individuals and country (extremely high risk!) All troops go through training. Often troops serve together throughout engagement. Desertion is an option (although not necessarily honorable).

Sports Metaphor Scouts search for talent that meet standards. Team members practice before engaging in “for the money” events. Team players can elect not to play  with or against certain teams (can have an adverse effect on career due to contract disputes).

Musician Metaphors Musicians train to play and/or read music. Musicians rehearse before engagements alone and with others. Musicians perform as well as they are able. There are limits (and no limits) to what some musicians can do. Musicians choose with whom to perform and what pieces to play (even in an orchestra certain musicians can choose not to play certain passages. Could you tell?).

Similarities between the fields Each field has a leader. Each field requires many roles. Each field has a plan. Each plan has forms and structures (e.g. battle plans, plays, scores). Each form/structure developed by the few, rather than the many (e.g. general(s) develop battle plans, managers/coaches develop the plays, composers/conductors develop the score).

S I D E   B A R - Patterns Patterns, based on the concepts of Christopher Alexander and the software development contributions of Cunningham, Beck, the Gang of Four, and many others, have provided a huge conceptual contribution to the thoughts and vocabulary of the software/systems development community.

Software Development field Resources often not sufficiently trained. Team members come and go. Language (business and technical) problems. The UML (Unified Modeling Language) mitigates some confusion.

How do we do software development? Where do we start? What’s the vision? What’s The problem? What are the requirements? What’s the plan? What’s the design? What’s the solution? What’s the architecture? What’s the vision, again?

Slide 19

Slide 20

Slide 21

Slide 22

Slide 23

Slide 24

Slide 25

Slide 26

Slide 27

Slide 28

Slide 29

Slide 30

Slide 31

Slide 32

Slide 33

What’s the vision? The specific purpose of the software and/or system and its contribution to the enterprise. This must be externalized by the visionaries, and shared and internalized by each contributor/collaborator. No shared vision? Go home.

What’s the problem? The situation that the software/system remedies, contributes to, or creates. A problem is a difference between things as desired and things as perceived.

What’s the problem? Can you articulate the problem (clearly)? Is there a metric for achievement? Can you “prove” that what you think is the problem really is the problem?

Problem definition example

Duncker Diagram Example

Slide 39

What are the requirements? The set of needs, functions, and rules that the software/system seeks to meet, perform, and enforce.

Requirements - where do they come from? Fortunately, requirements are all over the place.  Every motion in the business is a requirement. Unfortunately, requirements are all over the place and it’s hard to tell what level of requirement to express. Requirements evolve. A satisfied requirement gives birth to a new requirement. Business partners are required to know the business requirements.  Software developers are not…

…requirements... Experienced business analysts should be well aware of common business structures (patterns) - or that analyst clearly lacks experience. Experienced application architects and designers should be well aware of common business structure design choices (patterns) - or that talent lacks experience.

Common Business Patterns Party Accountability Order (Transaction) Business-is-business

…requirements! You’re never going to know everything. There is no good reason not to start building. You do not really know anything until you build it. When in doubt, document the working assumptions and move on. Moving forward in an environment of uncertainty is a critical attribute of success. Any participant lacking this attitude will seriously impede progress. Remember, there will be “testing” to prove assumptions.

S I D E   B A R - The role of database in applications. Database is the technology we use to store data. Do not use vendor-specific proprietary tools. Of course, this all depends on the type of application. Operational - Transactional Planning - Reporting Controlling - Rules Based

Data Element Requirements Only useful in a context, that is its use (usefulness) is in a process. (NOTE: A report is the result of a process.) Data elements are often discovered over time. However, experienced domain participants should know the basic structures (patterns). Third party interfaces impose special data element considerations. Do not seek to integrate - seek to interface. Create adapters between applications and systems (internal* or external) *That is, unless the applications are developed using the same kernel (which includes runtime and persistent artifacts).

What’s the plan? A document that specifies, at varying degrees of granularity, a set of tasks, schedules, and human resources that map directly to work products. The ultimate work product is the solution.

Planning

S I D E  B A R - Iterative & Increment Steven’s definitions: Iterative: Exploring and discovering new requirements for a given function or set of functions. Scope does not change. Increment: Adding new functionality. Scope changes. NOTE: Both concepts cost money.

Slide 50

What’s the design? An informal or formal expression of a software/system design as interpreted from the business requirements. “Design” means different things to different roles. Steven’s take is: Analysis is the act of taking things apart. Design is the act of putting things together. Good designers inhale analysis and exhale design. The design comes from...

The Use Case or Story as Context Originally started as short description of the specific business situation. The use case as evolved into something so large and complex that its use is becoming questionable. eXtreme Programming (later) chooses to call it a “story”. A much more concise and “growable” starting point.

Use Case Structure Its most fundamental structure supports the “design-by-contract” pattern: Description/Goal: A short description and/or goal of the use case. The goal being what one wishes to achieve (thank you Mr. Cockbrun). Precondition: The state of the universe before activity can begin. Activity: The things that happen (The “time-ordered sequence of events”. Postcondition: The state of the universe after things happen. The above is a simplification. If you want to find out how poorly understood this is, try to get agreement on a format.

Popular Processes A set of guidelines that suggest an appropriate sequence of tasks to achieve the desired solution. Hacking Waterfall Rational Unified Process eXtreme Programming

Hacking Time-honored process of the untrained. Hard to predict schedule. Difficult to test, debug, and correct. Often the process of choice of the loner developer. Often undocumented. Useful life is short (often rewritten)

Waterfall Processes Traditional Big ‘n’ Company (e.g. Navigator, Method 1, etc.). Too large and complex to understand and determine the pathways for a given effort. Expensive – often accompanied by Big ‘n’ support (management and workforce). Downstream costs often exceed upstream expectations.

S I D E    B A R - Methodologies “Methodologies” are always changing due to the technologies that require new methods and time-to-market tactics. Methods matter – methodologies do not.

Rational Unified Process (RUP) A formal set of processes originally developed by Ivar Jacobson (Objectory). Evolved by Rational into the RUP. Very large and provides pathways for different types and sizes of projects.

eXtreme Programming Developer-centric methodology. Brings developer closer to business user. Short release time. Requires high level talent that understands good design to accommodate change as new requirements (or correct requirements) become available.

Pragmatics Make it work. Get the applications out the door. Make it right. Ensure that the implementation is congruent with the design. Make it better. Ensure that the application meets performance requirements and other hidden quality attributes. Again, like any requirement, many are not known until you build.

Steven’s Use Case Design Process Blend of Rational Unified Process (RUP) and eXtreme. Reflects the nature of most software development efforts. Provides clear pathway for all stakeholders. Provides appropriate* leveling for Project Planning and Project Management. *Steven thinks so.

Used Case Design Workflow

Talent – the roles Business Partners / Collaborators Project Planner Architect(s) Business Analysts (Use Case Specifier) Designers Object Modelers Data Architects Usability / Interface Designers Engineers Quality – Testers Programmers DBAs Configuration Manager

Business Collaborators Representatives from business operations. People that articulate (describe) the business needs, functions, and rules. An integral part of the process – not on the sidelines or part-time. Not enough represent commitment or representation? Go home! Not enough knowledge of business domain? Go home! (Or document every working assumption, build, and pray.)

Roles & Responsibilities

Scoping available talent Seasoned professional or novice. Mix of technologies and relevant knowledge base. Incentives to acquire and maintain talent. Insourcing versus Outsourcing.

Resource Challenges Resources (talent) are hard to find and keep. Often, particularly in this era of numerous and evolving technologies, there is a tendency for overselling (under-qualified candidates). Don’t be afraid to challenge or “test” candidates. Don’t break up an evolving or mature team. The cost to replace resources outweighs the cost of keeping them.

What’s the solution? A working software/system that expresses the requirements in a way that is incorporated into the processes of the enterprise.

Scoping the solution type Is the solution report-oriented? A planning requirement that uses operational information rather than creating the data. Is the solution transaction-oriented? Captures required information to transact. Simple validations. Is the solution control-oriented? Transactions are based upon events and relationships between n-ary objects.

What’s the architecture? An expression of the complete set of components and connections that form the structure of the software/system.

The role of Architecture and the Architect Answers “what goes where?” Domain of the Systems Architect and Application Architect. Modern architectures also follow patterns and experienced architects use them.

Slide 72

The Layered Architecture Clearly illustrates “what goes where”. Concepts/Packages/Functional granularity/Subsystems are separated for clear development partitioning. Illustrates common use of the pieces of the software/system.

The Layered Architecture Diagram

What’s the vision, again? An evolving and growing enterprise is always extending and changing its vision (although, hopefully, not its mission). In today’s environment the vision may change before the current vision is achieved. This has to be OK - because that’s the way it is.

Summary Software Development is unforgiving (since computers seem to be). Participants must aspire to new levels of ethical ruthlessness* to survive. As individuals we are responsible for ensuring each collaborator is as good as he or she can be. Or you may not survive. Good software takes commitment, knowledge, planning, and a relentless desire to achieve. Know where you are going. *Sounds like a good catch phrase.

Questions???

Thank you! If you have any questions please email me. If you’d like a list of references for this discussion, please email me. Steven Marcus Marcus Software Designs, Inc. 216 “F” Street, #88 Davis, CA  95616 Land - 925-521-9876 Fax   - 925-521-9875 Email - smarcus@MarcusSoftwareDesigns.com