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:
Unified Process analysis. Your Problem domain, that you are solving =User Stories and Requirements Document. Business Process Discovery (Use Cases) 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:
The Behavior Execution Trace Graph (BET Graph):
Method Choregraphy (Object Interaction Diagram) 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
Needs Improvement (0-49%)
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:
Unified Process Development Methodology Building the Software Specification Document Software Planning Document The V Model in Software Testing Use Cases in Unified Process and Testing 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:
Functional Requirements: Articulated with Use Cases Use cases from the Unified Process Non-Functional Requirements: Described with Software Quality Metrics 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). Software dependencies (database, OS versions, networking needs) 4. Software Planning Document
This document outlines the plan for the entire development cycle, including timelines, resources, and milestones.
Components:
Roles and responsibilities 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): 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!