Video Summary - GA2-220501094-AA1

Main ideas, concepts, and lessons

1) Session logistics and course status

Connectivity and session recording

The instructor addresses students about:
- Connectivity issues (blurry/pixelated screen, internet outages).
- The need to start the session despite network problems.
Recording and accessibility:
- The session is recorded once the connection begins.
- It will be uploaded to an unlisted YouTube channel.
- Then enabled on the platform under the recordings section.

Participation rules

Microphone handling
Proper use of chat
“Raising your hand” to participate
Being timely and specific, while respecting time limits

Course status

Students continue working on the learning activity that ends in “094” (dated August 11).
Learning Guide 1 ended June 26, but some apprentices still have pending assignments.
Goal: resolve pending work by Friday during a committee meeting.

2) Evidence 1: Technical data sheet design (technical specifications)

The first evidence focuses on creating technical data sheets to collect project information.

Key concepts

A technical data sheet is a document that:

Summarizes important details
Describes in detail the most relevant characteristics of an object/material/process
In this course context, it focuses on the software being developed/marketed

Why it matters:

Helps sell/promote the software/service by clearly stating benefits and accurate technical details
Emphasizes accuracy and clarity

Two types of technical specifications/data sheets

Commercial use
- Intended to captivate potential customers
- Must present information clearly and organized (e.g., categorized by model/type)
- Includes what customers need to decide/purchase
Internal use / production
- Helps the team understand composition and internal flow
- Useful for:
  - development/production understanding
  - maintenance
  - quickly detecting how the process works

Quality standard linkage (ISO 9000 / NTC reference)

The instructor emphasizes aligning with ISO 9000 (quality management standard).
ISO 9000’s purpose (as explained):
- Ensure conceptual/vocabulary alignment with quality standards
- Require approval through protocols and quality terms
- Enable:
  - customer satisfaction
  - continuous improvement
  - focus on meeting requirements
The evidence includes applying an ISO 9000-based approach.

Example structure fields mentioned

The instructor provides an example including:

Person responsible for completing the characterization form
Fields covering:
- Product characterization
- Description
- Architecture (including development)
- Hardware and software requirements
- Functional requirements
- Non-functional requirements
- Licensing/regulatory aspects
Change control
- Dates for creation/update
- What changed and why
- Approval/validation workflow (prepared/approved/validated by potentially different people)

3) Evidence 2: Technical data sheet preparation requirements

The second evidence requires producing the technical data sheet as a PDF and following required standards.

What students must do

Prepare the technical data sheet by:
- Carefully studying component concepts/characteristics
- Reviewing supplementary material
- Addressing relevant regulations/standards
Use ISO 9000 as a reference for designing the data sheet
Create the technical data sheet and upload it as a PDF
Follow a provided format/template file
Apply verification/critical reading:
- Do not blindly accept what the system/tool outputs
- Validate that what you are building matches reality (e.g., if something claims to be web-based, verify it)

Technical sheet sections (example/template content)

Title/name/structure
Product name and relevant features
Application type and scope (example: web + mobile for restaurant management)
Versioning (e.g., version 1 when built from scratch)
Module listing
Date of preparation, responsible person, and standard referenced
Product description
- objective, scope, main characteristics
System architecture
- examples referenced: layered, client-server, etc.
- students should research and select the most suitable architecture
Technologies definition
- Backend (server-side, database access, services)
- Frontend (user-facing part)
- technologies may be changed later (e.g., database choice)
System requirements
- Hardware requirements (processor power, memory)
- Software requirements (installed software, configuration)
- Connectivity/network requirements
Customer/client requirements
- what users need (devices, browsers, Android/iOS compatibility)
- network access and permissions
Product requirements
- functional requirements tied to modules
- non-functional requirements
- legal requirements, especially Law 1581 (personal data protection)
- product customers/verification stakeholders
Quality metrics
- efficiency, usability, security, reliability, maintainability, portability
Version control/change records
- dates, versions, what was fixed
- who prepared/approved/validated

4) Evidence 3: Technical references specification + economic conditions (feasibility + estimation)

The third evidence focuses on defining technical feasibility and economic conditions, including software cost estimation.

Core concepts

A software estimate predicts:
- how long development/maintenance will take (time estimate)
- how much it will cost (cost estimate)
Estimates are used to:
- plan project timeline and iterations
- build a budget
- analyze investment
- set software costs/pricing
- plan strategy for bids/auctions
Licensing tie-in:
- costs depend on license/product conditions (referenced from earlier forum discussion)

Software estimation techniques mentioned

Expert judgment
- experts gather requirements (e.g., meetings/meeting minutes) and estimate
Analogy
- compare the project to similar past projects
Decomposition
- break the problem into parts and estimate time/cost per segment
Estimation models
- algorithmic/numerical estimation using parameters (often still requires expert input)

Cost estimation components described

Direct and indirect costs include:

Work (human effort)
Material (resources)
Equipment
Services (suppliers/contractors)
Software needed
Hardware
Facilities/adaptation
Contingency for unforeseen events

Evidence 3 required document content (structure/instructions)

The technical and economic feasibility report should include:

Minimum required items:
- Cover page
- Table of contents
- Uploaded as PDF
Main sections:
- Introduction
  - purpose of the report
  - technical requirements and cost estimate needed to develop the software
- Scope
  - copied from previous evidence (already worked on/validated)
- Methodology used
  - as previously discussed in the course
- Technical analysis
  - based on chosen system architecture (example: client-server with multi-layered architecture)
  - describe:
    - backend authentication, encryption approach, frameworks, etc.
    - frontend/back-end distinction
  - consider:
    - data model choices (relational vs non-relational)
    - server/infrastructure decisions
  - feasibility of resources (who does what), such as:
    - software architects
    - backend developers
    - frontend developers
    - database specialists / full-stack profiles (as examples)
    - Feasibility conclusion
  - validate with tools/assistant/team discussion; mark as viable (checkmark)
    - Complexity of implementation
  - low/medium/high
    - Technical risks identified
  - examples:
    - data loss due to server failures
    - cost overruns
    - synchronization failures
    - Risk plan
  - what to do if those risks occur
    - Justification of architecture
  - security, performance, flexibility
  - comparison with other architectures previously studied
    - Technology justification
  - justify backend/frontend technologies, database types, etc.
    - Cost estimation part
  - use currency COP (Colombian pesos)
  - include a table with:
    - development staff elements
    - description, quantity, unit cost
    - reference “hours” as estimated effort
  - include connectivity/device costs and other resources considered for charging
    - Recommendations / final conclusion
  - after thorough technical and economic analysis, recommend proceeding
  - justify why (technical, economic, strategic reasons)

Instructor emphasis: be conscientious and realistically assess what you can charge for your work.

5) Q&A / clarifications at the end

Connectivity issues affected attendance; about 27 trainees were connected.
Student question about signatures in the first activity/evidence:
- instructor says signatures are required
- they may be completed fictitiously if needed (as stated)
Student asks about power outages/internet issues and evidence uploading:
- instructor reassures students to contact him if issues persist
Instructor continues monitoring pending Learning Guide 1 work (ended June 26) and offers mediation/support.

Speakers / sources featured

Instructor / Teacher (unnamed in subtitles): main presenter and course facilitator
Andrea: participant (greeting/acknowledgment)
Marlon: participant reporting blurry screen/internet issues
Manuela: participant asking about signatures
Lina: participant complimented for connecting despite issues
M.: referenced near the closing (possibly participant/signature line)
Colombian Law 1581 of 2012: personal data protection requirement referenced
ISO 9000 / NTC technical standard (2015 referenced): quality management alignment referenced
Unlisted YouTube channel: destination for recorded sessions

GA2-220501094-AA1–Evidencia 2 y 3

Key takeaways