Explore

F23 MAD5234s2 Learning Activity 2 Instructions: Make a Software Build Plan Document, published with GITBOOK

Resources to use in doing this Learning Activity:

⁠

https://coda.io/d/Bringing-it-home-with-the-V-MODEL_dsgFOiZUw0i⁠

⁠

https://coda.io/d/Lecture-on-UML-Static-and-Object-Interaction-Diagrams_d3FTnhMADkI⁠

⁠

Use the same GITBOOK as for LA 1, and layer in the new content.

Hand in Date: End of Day Wednesday, September 13.

In terms of LA 2, you are updating your GITBOOK which I already have the link from LA 1.

There is no separate handin link for LA 2!

What you have in hand, as the outputs of your LA1:

Unified Process analysis.

Your Problem domain, that you are solving =User Stories and Requirements Document.

Business Process Discovery (Use Cases)

V Model.

UML DIagrams:

State Diagrams (where to park your methods and data fields).

New Elements for this iteration of the Build Plan for your Enterprise Application:

STD: State Transition Diagram mapping the INPUTS of the DOMAIN to the OUTPUTS of the RANGE:

https://www.linkedin.com/pulse/evolution-software-engineering-concepts-from-use-cases-sigurdson/⁠

⁠

The Behavior Execution Trace Graph (BET Graph):

⁠

Method Choregraphy (Object Interaction Diagram)

Software Quality Metrics

State an initial test plan.

Hand in for Learning Activty 2:

Update your GITBOOK. I will evaluate the URL you already submitted for LA 1.

This activity, designed with the utmost relevance to real-world applications, holds a weightage of 2% of your final grade. It's imperative to approach it with the dedication and commitment that you would in an actual IT industry scenario.

In the evolving world of technology, mastering the art of effective documentation is paramount. Not only does it streamline the software development process, but it also ensures clear communication among team members and other stakeholders. This activity aims to nurture this very skill in you.

Objective:

Your task is to produce a Software Build Plan.

But remember, the devil is in the details. Adhering to industry standards, you will craft this document in Markdown format. For those unfamiliar with Markdown, it's a lightweight markup language with plain-text-formatting syntax, extensively used in the IT industry for documentation, readme files, and more.

Submission:

Upon completion, you are required to publish your document to Leanpub, a renowned platform that bridges authors and readers, and is commonly used for publishing technical documentation and e-books.

By doing this, you are not only showcasing your technical prowess but also demonstrating the ability to leverage industry-standard tools and platforms, further solidifying your readiness for real-world challenges.

Evaluation:

Your submission will be assessed based on:

Adherence to the given guidelines and industry practices.

Clarity, coherence, and organization of the Software Build Plan.

Proficiency in using Markdown for documentation.

Successful publishing on Leanpub.

Closing Thoughts:

While this activity contributes to 2% of your final grade, the skills you cultivate here will greatly benefit you throughout your career. Consider this an investment in your professional future. Dive in with an open mind, and always remember: in the IT industry, it's as much about the process as it is about the final product.

Grading Rubric for Learning Activity 2: Software Build Plan

Grading Rubric

Grading Rubric

Criteria

Excellent (90-100%)

Good (70-89%)

Satisfactory (50-69%)

Needs Improvement (0-49%)

Document Structure and Organization

- Clear structure - Logical flow - Every section is purposefully placed and seamlessly connected

- Mostly clear structure - Some sections may not follow a logical order - Minor inconsistencies

- Structure present but lacking clarity - Several sections appear out of place

- Disorganized - No clear structure - Random placement of sections

Adherence to Markdown Syntax

- Perfectly formatted using Markdown - Effective use of headers, lists, links, etc.

- Few minor formatting errors - Good use of Markdown features

- Several formatting errors - Underutilization of Markdown features

- Extensive formatting errors - Limited to no use of Markdown features

Content Quality and Depth

- Comprehensive details - Depth in explanation - No ambiguity

- Covers most required elements - Minor areas lack depth or clarity

- Basic coverage of required elements - Significant lack of depth in areas

- Incomplete coverage of elements - Surface-level details with many ambiguities

Adherence to IT Industry Practices

- Reflects current industry standards - Demonstrates best practices

- Mostly reflects industry standards - Few areas may not be best practices

- Some reflection of industry standards - Several deviations from best practices

- Rarely reflects industry standards - Many deviations from best practices

Publishing on Leanpub

- Successfully published - Proper formatting retained in Leanpub version

- Successfully published - Few minor formatting issues in Leanpub version

- Published with significant issues - Multiple formatting errors on Leanpub

- Not published or inaccessible - Major issues in presentation on Leanpub

Overall Presentation and Professionalism

- Polished and professional appearance - Free from grammatical/spelling errors

- Mostly polished - Few minor grammatical/spelling errors

- Lacks a professional touch - Several grammatical/spelling errors

- Unpolished presentation - Riddled with grammatical/spelling errors

There are no rows in this table

⁠

Total Points: _/ 100

Comments:

⁠

It's essential for students to understand that while grades are important, the real value lies in applying the skills learned, understanding feedback, and consistently improving. Encourage them to focus on the learning process and see this rubric as a guide to areas of strength and improvement.

Learning Actiivity 2: Build the Software Specification Document:

Following the Work Product you creating in Learning Activity 1, you will study how to build the software specification document and software planning document, including:

Software quality metrics

The test plan

You will follow unified process development methodology.

Expected outputs for the software build plan are a document in markdown which could be given to another team for the purpose of constructing the product.

Deliverables must include doing software testing with the V model, following the steps of the software development lifecycle and the software testing life cycle make up the vertices of the V model, and how we get use cases from unified process which provides inputs to the use case testing aspects of the model. Output into Markdown language format and publish to Leanpub.

Software Specification and Planning Guide

Welcome students! Today, we'll be diving deep into building a Software Specification Document and Software Planning Document, emphasizing quality metrics and a test plan. Let's get started!

1. Introduction

Before we delve into the specifics, let's understand the importance of these documents. A well-defined specification and planning document ensure clarity, set clear expectations, and guide the entire development process.

⁠

2. Unified Process Development Methodology

Unified Process (UP) is an iterative and incremental software development process framework. The main goal of UP is to deliver a quality software product while addressing the primary concerns of stakeholders.

⁠

3. Building the Software Specification Document

A software specification document describes the functionality, the architecture (described with UML Diagrams), the interactions, and the dependencies of the software system.

The Elements that you should include in your SSD:

Introduction

Purpose of the document

Intended audience

Scope of the software

Functional Requirements: Articulated with Use Cases

Use cases from the Unified Process

Sequence diagrams

Activity diagrams

Non-Functional Requirements: Described with Software Quality Metrics

Performance metrics

Security requirements

Usability and accessibility criteria

System Architecture: Described with UML

High-level system architecture

Component diagrams: Described with UML ; can include systemic interactions of components within the system boundaries - and - interaction of the SUD with Externalities (components outside the SUD).

Dependencies

Software dependencies (database, OS versions, networking needs)

Hardware dependencies

⁠

4. Software Planning Document

This document outlines the plan for the entire development cycle, including timelines, resources, and milestones.

Components:

Project Overview

Introduction

Objectives

Stakeholders

Scope & Limitations

Resource Allocation

Team structure

Roles and responsibilities

Timeline and Milestones

Risk Assessment and Mitigation

⁠

5. Software Quality Metrics

To ensure software quality, consider the following metrics:

Functionality: Does the software perform its intended functions?

Reliability: How often does the software fail?

Usability: Is the software user-friendly?

Efficiency: Does the software make optimal use of resources?

Maintainability: Can the software be updated easily?

Portability: Can the software run in different environments?

⁠

6. The V Model in Software Testing

The V-Model demonstrates the relationships between each phase of the software development life cycle (SDLC) and its associated phase of testing.

Development Stages (Left Side of V):

Requirements Analysis

System Design

Architecture Design

Module Design

Testing Stages (Right Side of V):

Unit Testing (corresponds to Module Design)

Integration Testing (corresponds to Architecture Design)

System Testing (corresponds to System Design)

Acceptance Testing (corresponds to Requirements Analysis)

⁠

7. Use Cases in Unified Process and Testing

Use cases derived from UP serve as the foundation for creating test cases:

Identifying Use Cases: Extract use cases from your UP diagrams.

Formulating Test Cases: For each use case, create multiple test cases considering both the happy path and edge cases.

Mapping to V Model: Utilize these test cases during the testing phases in the V Model. For instance, system testing uses scenarios derived from system design use cases.

⁠

Conclusion:

By the end of this Lab, you should be able to produce a Software Specification Document and Software Planning Document, keeping in mind quality metrics and the V Model for testing. These documents should be clear and comprehensive enough to hand off to another team for construction.

Remember, clear documentation ensures smoother development processes and better software products!

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.