Explore

Doing a First Implementation of Unified Process

Activity Learning Outcome:

⁠

https://coda.io/@peter-sigurdson/f23-mad-5234-software-quality-engineering-class-notebook⁠

⁠

Case Study of South West Airline: [This is not something we are processing here: I am showing you this to see what a Real World Complexity Business Domain looks like)

⁠

https://www.evernote.com/shard/s323/sh/d53bee04-f47d-2996-2e4c-7874155f4440/7c56b467f192e68c86e8335ca55315ce⁠

⁠

Learning Outcomes:

GITBOOK Markdown Journal on building a taxonomy and nomeclature

Write a markdown Document in GitBooks: To document your work in this activity, which will be:

Select a Business Domain to work the Unified Process Methodology on.

Applying UP, you will

Come up with some user stories

Create a Requirements Document from your User Stories.

Do Use Case Discovery:

Actor : external to SUD : initiates Actions or receives Value Updates

Goal

figure out what work steps they do, to implement their Goal (Formalized descriptions of Business Processes)

Make our UML Diagrams.

Forward Generate Java Code from UML.

Last step of UP: make the Traceability Matrix. Figure out what your Test Oracles will be.

Commit your Code to GitHUB repository.

Write your Markdown Documentation and publish it. Submit your Published URL.

Because we don’t have real users to interact with, we will use Chat GPT as a Role Play partner:

⁠

Loading…⁠

⁠

All your Documentation will be done with GItBooks and Markdown

⁠

https://coda.io/d/How-to-use-GITBOOK-with-Markdown-language-to-write-a-technical-b_dV7OHq9OZvG/How-to-use-GITBOOK-with-Markdown-language-to-write-a-technical-b_suptJ?utm_campaign=embed&utm_medium=web&utm_source=V7OHq9OZvG#_lu8Fk⁠

⁠

This will be your Reflection Journal on your ideas for how to Build a Taxonomy and Nomenclature of Software Defects:

In this activity you will think deeply, and mentally simulate and reflect upon all the things that MIGHT go wrong with a Software Program:

Your Output will be a Reflection Journal in Markdown, posted to the GITBOOK

Static Analysis: can be done with UML: Class Interaction Diagrams, Object Interaction Diagrams

Dynamic Analysis: methods for seeing how the program stands up under run time loading and user IO

Build a Taxonomy and Nomenclature of Software Defects

Welcome, software developers and analysts!

This exercise will challenge you to explore and define the vast and intricate world of software defects.

Your aim? To think critically, categorize effectively, and understand deeply.

Objective:

Develop a reflective journal on the taxonomy and nomenclature of software defects. Post your findings and thoughts to GITBOOK using Markdown.

⁠

Introduction

Every software, no matter how meticulously crafted, has defects. These defects range from minor nuisances to major system crashes.

Understanding and categorizing these defects can provide insights into software development processes, testing methodologies, and overall system reliability.

⁠

Instructions:

1. Static Analysis:

Static analysis involves examining the software without executing it. It's like proofreading a book before publishing.

Tasks:

UML Analysis: Utilize UML (Unified Modeling Language) to understand and capture defects.

Class Interaction Diagrams: Understand relationships between classes. Look for:

Missing associations.

Redundancies.

Inappropriate inheritance.

Object Interaction Diagrams: Investigate how objects interact within the system.

Incorrect message sequences.

Missing or redundant object interactions.

2. Dynamic Analysis:

Dynamic analysis involves examining the software during its execution. It's witnessing the performance of a play on stage.

Tasks:

Conduct various runtime tests to understand how the software behaves during execution.

Load Testing: Determine how the software behaves under heavy loads.

User IO Analysis: Understand how the software interacts with user inputs and outputs. Look for:

Inappropriate error messages.

Inefficient data handling.

Unexpected software behavior based on user input.

⁠

Reflection Journal:

As you journey through this exercise, maintain a reflective journal in Markdown format. Here's a template to get you started:

markdownCopy code

# Reflection Journal on Software Defects Taxonomy

## Date:

## Static Analysis Reflection:

### Class Interaction Diagrams:

- **Observation 1**:

- **Description**:

- **Potential Impact**:

... (Continue for other observations)

### Object Interaction Diagrams:

- **Observation 1**:

- **Description**:

- **Potential Impact**:

... (Continue for other observations)

## Dynamic Analysis Reflection:

### Load Testing:

- **Observation 1**:

- **Description**:

- **Potential Impact**:

... (Continue for other observations)

### User IO Analysis:

- **Observation 1**:

- **Description**:

- **Potential Impact**:

... (Continue for other observations)

## Overall Thoughts:

...

⁠

Submission:

Once you've completed your reflection journal, post it to GITBOOK. Ensure you adhere to Markdown best practices for readability and clarity.

⁠

Conclusion:

Software defects are not irritating nuisances. They provide us with an Intrumentation Window into the workings of our own mental processes of how we approach coding, a profound opportunity for learning and self-improvement.

By understanding their taxonomy and nomenclature, you not only become better at identifying and rectifying them but also enhance your holistic understanding of software development.

Dive deep, reflect, and learn. The world of software architecture awaits your exploration!

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.