Software Methodology

A Software Development Methodology

Roy K. Clemmons

A Software Development Methodology is a process that organizes the activities related to producing software that fulfills the needs of a Business Domain. Activities include analyzing the business domain requirements, designing a solution that satisfies the requirements, implementing the solution, testing the solution, deploying the solution, and ongoing maintenance of the solution until the solution becomes undesirable.

Software methodologies tend to be procedural or object oriented. Procedural methodologies usually describe their solutions in terms of accomplishments; i.e. what is being done*.* Object oriented systems describe their solutions as collaborating objects.

The following object oriented methodology addresses the need for a reusable software development process.

Note: While the methodology below suggests a linear order, in reality, many activities can and should be done in parallel.

1. Business Model

Goal of the Business Model: Understand the problem domain enough to engage in intelligent conversation using the vocabulary of the domain itself, without the experts needing to stop and explain what they think of as basic concepts.

A. Understand the Domain

Define the high level business activities and processes that occur in the problem domain.

Questions:

What are the business processes and rules? Who are the users and their roles?

Artifacts:

Problem statements, initial glossary, user stories, and essential use cases

B. Process Model

Documents how people work with the system, taking into account the flow of the activities being performed. The main difference between the Business Process Model and the Process Modeling is that the Business Process Model doesn’t fully address the flow of artifacts, including but not limited to information, within a system - Process Models do.

Questions:

What is the flow of the data throughout the system?

Artifacts:

Data flow diagrams (DFDs), flow charts, Activity Diagrams

2. Analysis Model

Goal of Analysis: Understand a system’s inputs, operations, and outputs.

Questions:

What is being built? Why it should be built? How much it will likely cost to build (estimation), and in what order it should be built (prioritization)?

Artifacts:

Initial classes, conceptual models, collaborative diagrams, design class diagrams

3. Requirements Model

Goal of the Requirements Model: Identify the requirements needed to propose a solution.

Questions:

What is needed to build the system?

A. Develop Requirements Model

Goal: Define the functionality you are intending to provide from the business user perspective.

As each Use Case is identified, map it to the appropriate business requirement. This mapping clearly states what functionality the new system will provide to meet the business requirements. It also ensures no Use Cases exist without a purpose.

• Don’t overlook performance and security requirements

Artifacts:

Software Requirements Specification, Refined Use Case diagrams, Usage Scenarios, Activity Diagrams, Essential UI mock-ups

B. Develop Draft Conceptual Domain Model

Goal: The goal of a conceptual domain model is to identify the major domain entities, their general responsibilities, and their relationships within the problem domain. In the early stages of design, the emphasis is on finding obvious concepts expressed in the requirements. Later, the model will be refined and extended though successive design cycles.

Artifacts:

Conceptual Domain Model, Class Responsibility Collaborator (CRC) cards, class diagrams

4. Design Model

Goal: The goal of the Design Model is to propose a logical solution for the functionality identified in the Requirements Model.

The main artifacts of the Design are the Interaction and Class diagrams. Interaction diagrams illustrate object communication and Class diagrams illustrate object (or class) relationships needed for the implementation. Of the two, Interaction diagrams require the greatest level of effort and will take up the bulk of the time. However, when complete, Interaction Diagrams will not only depict object responsibilities but also the Design Patterns needed for implementation.

Creation of Interaction Diagrams requires knowledge of responsibility assignment principle and Design Patterns.

A. Real Use Cases

Goal: Extend (or finalize) the essential Use Cases developed in the Analysis. Include enough detail to allow implementation – the concrete input/outputs.

Something to consider early on is testing. How will the use cases be verified as functioning correctly?

Artifacts: Real Use Cases and their scenarios, storyboards, diagrams of User Interfaces, descriptions of low-level interactions

B. Interaction Diagrams

Goal: Illustrate object interaction and task fulfillment using messages

• Use Conceptual Domain Model from Requirements and Real Use Cases to create Interaction diagrams. Pay attention to pre and post conditions.
• Identify Design Patterns
• The bulk of the Design effort (and thus the project) will be spent assigning responsibilities and diagramming the interactions

Artifacts: Collaboration Diagrams, Sequence Diagrams

C. Class Diagrams

Goal: Specify the classes, interfaces and their relationships needed to implement the solution.

• Skeletal Class Diagrams can be created early as relationships become obvious
• CRC Cards are one way to provide the foundation for Class Diagrams
• Class Diagrams can be created in parallel with Interaction Diagrams
• Use the Interaction Diagrams and Conceptual Domain Models to provide final detail
• Specify behavior using Activity, Sequence and State diagrams

Artifacts: Class Diagrams, refined Interaction Diagrams, Activity diagrams, Sequence Diagrams, State Diagrams

1. System Architecture

Goal: Organize the solution into related logical subsystems.

Typically, applications are divided into areas of related functionality; Presentation Layer (User Interface), Business Layer (business rules) and Data Layer (data access). Organizing the application into a n-tier architecture promotes reusability, improves performance, increases scalability and portability, allows parallel development, and ongoing maintenance.

• • Design a System Architecture in layers and partitions
  • Illustrate architectural design using UML Package Diagrams
  • Apply Design Patterns to support architectural goals, for example: Model-View, Publish-Subscribe, Façade and Mediator patterns.

Artifacts: Component Diagram; block diagram of System Architecture

5. Implementation

Goal: Implement the solution specified in the Design Model.

• The implementation uses the artifacts from the Design Model to produce a solution to the requirements defined in the Requirements Model. In particular, the Interaction and Class diagrams are the primary input to the development of program code.
• It’s not unusual – even recommended – for code frameworks (snippets, prototypes, etc.) to be produced early to explore design concepts and ideas. However, the focus should return to the design once the experiments are complete.
• Expect and plan for some deviation from the design - not everything can be foreseen and new problems will emerge. The deviations should not be major nor cause major rework of the design (if any). There should be some resiliency in the design to accommodate deviations.
• Case tools that forward and reverse engineer source code can be valuable tools.
• In most cases, an Object oriented Programming (OOP) language will contain language constructs that map directly to the Class diagrams.

Artifacts: Unit tests, Golden Code

6. Testing

Goal: Produce a verifiable solution for the problem domain

• Testing should be a consideration throughout the life cycle of the project and appropriate tests devised.
• How will the defects be tracked?
• Unit testing must be performed through the implementation and required in code walkthroughs.
• Unit tests should be combined into test suites that are executed on a regular basis and before source code check-in.
• Be efficient in testing by testing dependencies. Every single method may not need a series of unit tests.
• Be knowledge of Bug Patterns – patterns of failure or common erroneous behavior.
• Use regression testing to insure previously working functionality wasn’t broken during an unrelated fix.

Artifacts: Verifiably proven system

7. Deployment Model

Goal: Define the physical architecture of the system.

• The Deployment Model can be developed early to capture the physical deployment characteristics of the solution - the hardware, operating system, and support software.
• Consider disaster recovery and backups.
• How will the software be distributed? Web? DVD?
• As the model develops the physical architecture will be updated to reflect the actual system being proposed.

Artifacts: Deployment Diagram

8. Maintenance

Goal: Continue to support the user by repairing defects as well as enhancing and optimizing deployed software.

• Changes need to be analyzed for their impact on the system and for their required level of effort
• Changes should be implemented and tested in the same manner as new development