F23 MAD5234s2 Learning Activity 2 Instructions: Make a Software Build Plan Document, published with GITBOOK
F23 MAD5234s2 Learning Activity 2 Instructions: Make a Software Build Plan Document, published with GITBOOK
Resources to use in doing this Learning Activity:
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:
New Elements for this iteration of the Build Plan for your Enterprise Application:
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:
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
Criteria
Excellent (90-100%)
Good (70-89%)
Satisfactory (50-69%)
Needs Improvement (0-49%)
Criteria
Excellent (90-100%)
Good (70-89%)
Satisfactory (50-69%)
Needs Improvement (0-49%)
1
Document Structure and Organization
- Clear structure<br>- Logical flow<br>- Every section is purposefully placed and seamlessly connected
- Mostly clear structure<br>- Some sections may not follow a logical order<br>- Minor inconsistencies
- Structure present but lacking clarity<br>- Several sections appear out of place
- Disorganized<br>- No clear structure<br>- Random placement of sections
2
Adherence to Markdown Syntax
- Perfectly formatted using Markdown<br>- Effective use of headers, lists, links, etc.
- Few minor formatting errors<br>- Good use of Markdown features
- Several formatting errors<br>- Underutilization of Markdown features
- Extensive formatting errors<br>- Limited to no use of Markdown features
3
Content Quality and Depth
- Comprehensive details<br>- Depth in explanation<br>- No ambiguity
- Covers most required elements<br>- Minor areas lack depth or clarity
- Basic coverage of required elements<br>- Significant lack of depth in areas
- Incomplete coverage of elements<br>- Surface-level details with many ambiguities
4
Adherence to IT Industry Practices
- Reflects current industry standards<br>- Demonstrates best practices
- Mostly reflects industry standards<br>- Few areas may not be best practices
- Some reflection of industry standards<br>- Several deviations from best practices
- Rarely reflects industry standards<br>- Many deviations from best practices
5
Publishing on Leanpub
- Successfully published<br>- Proper formatting retained in Leanpub version
- Successfully published<br>- Few minor formatting issues in Leanpub version
- Published with significant issues<br>- Multiple formatting errors on Leanpub
- Not published or inaccessible<br>- Major issues in presentation on Leanpub
6
Overall Presentation and Professionalism
- Polished and professional appearance<br>- Free from grammatical/spelling errors
- Mostly polished<br>- Few minor grammatical/spelling errors
- Lacks a professional touch<br>- Several grammatical/spelling errors
- Unpolished presentation<br>- 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!
Table of Contents:
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:
4. Software Planning Document
This document outlines the plan for the entire development cycle, including timelines, resources, and milestones.
Components:
5. Software Quality Metrics
To ensure software quality, consider the following metrics:
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.
7. Use Cases in Unified Process and Testing
Use cases derived from UP serve as the foundation for creating test 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.
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.