Real Time Web Analytics Journey through the clouds

About Me

My photo
Hello, My name is Megha Manohar. The content of this blog will mostly be technical or related to course work. Favorite websites - www.google.com www.twitter.com www.blogs.vmware.com https://devcentral.f5.com/blogs/us/macvittie www.screenr.com

Wednesday, April 12, 2017

Social media website testing in fashion industry domain (Ford industry)

Project description - Perform Exploratory, Usability, Functional, UI, Compatibility and Performance testing for a new social media website for Ford models industry, headquartered in NewYork. http://models.fordmodels.com/. The company developed a social media website where clients could create jobs and castings. Talents(models/Photographers etc) could apply for these jobs and castings. The website was developed for client users on web portal. Talensts could only use the website as a I/OS application. It was a difficult website to test since there were interdependencies between web and I/OS dependent functionalities. There were no clear requirements document. It was an Agile environment and we had daily scrum meetings and aggresive workschedule.

Role: Perform testing and act as a QA lead.

Environment - Staging environment

OS - Windows, Mac, I/OS

Browser - Safari, IE, Chrome, Edge

Tools - Bugzilla

 Test document - Available upon request

Activities:
  • Review work flows assigned to Project-castings
  • Create communication tools - Whatsapp and email group. Ensure team is on same page.
  • Create google docs for creating test cases
  • Enable team to assign components
  • Run smoke test, functional tests in supported browsers, Run regression testing
  • Create test bug reports using Bugzilla

Tuesday, January 31, 2017

ESXi 6.0 Enhancements

  • Scalability - Clusters size has been doubled to support up to 64 hosts. ESXi supports up to 480 logical CPUs, 12TB of RAM, and 1024 virtual machines.
  • Account Management - Local accounts on ESXi hosts can be managed by using new ESXCLI commands. These accounts can be centrally managed from a vCenter Server.
  • Account Lockout - ESXi 6.0 allows to configure an account lockout policy for failed SSH login attempts.
  • Password Complexity Rules - Rules have been moved from /etc/pam.d/passwd to ESXi host Advanced System Settings, enabling centrally managed settings.
  • User Audit - All changes triggered from a vCenter Server appear in the ESXi log with the vCenter Server username.
  • Flexible Lockdown Modes - A more granular ESXi lockdown is possible in vSphere 6.0 by adding 2 lockdown modes, "normal lockdown mode" and "strict lockdown mode”, where the DCUI is stopped. Exception Users can be configured further specify user access.
  • DCUI Smart Card Authentication - Only available to U.S. federal customers. Enables DCUI login using a Common Access Card (CAC) and Personal Identity Verification (PIV).

Prerequisites Installing VMware Vsphere 6 Enterprise plus in evaluation mode


Prerequisites-

1.Make sure your computer processor supports hardware Virtualization Technology (VT) and it is enabled in BIOS.
2. Ensure you have a minimum of 4 GB RAM
3. Download Vsphere 6 from https://my.vmware.com/en/group/vmware/evalcenter?p=vsphere6
4. Create a new virtual machine in VMware workstation or player. Browse the ESXi 5.5 installable ISO file you have downloaded. If you have the latest version of VMware, the easy install method will detect the OS automatically and adjust the virtual machine’s hardware by itself.

PXE install

What is needed: Internet connection
Important: Make sure the source and target are on the same network (look at the Subnet mask for this)
On Source PC:
1. Ideally for PXE install, both DHCP and TFTP servers are required. If you do not have dedicated servers for this, you could download a freeware tftpd32 standard edition from http://tftpd32.jounin.net/tftpd32_download.html. Save it to C drive. Extract the files to C:\tftpd32.335 which will be the root directory
2. Download pxelinux.0, menu.c32, and memdisk. Or, just extract files from a syslinux distribution. Place these three files in the C:\tftpd32.335 directory.
3. Copy initrd and linux files into C:\tftpd32.335
4.Create a subdirectory in C:\tftpd32.335 called "pxelinux.cfg"
5.
Create a default file within pxelinux.cfg subdirectory with following information
DEFAULT KIWI-Boot

LABEL KIWI-Boot
kernel linux
append initrd=initrd vga=normal ramdisk_size=512000 ramdisk_blocksize=4096 UPDATE_URL= PRESERVE_CHANGES=no
FORCE_IMAGE_UPDATE=yes UPDATE_MODE=image
IPAPPEND 1

LABEL Local-Boot
localboot 0


6. Run tftpd32.exe (in C:\tftpd32.335). If windows prompts you, allow the program to access the network.
7. Click the DHCP Server tab and enter "pxelinux.0" in the "Boot File" field. Fill out the other fields as per your local network(by doing a ipconfig /all). IP Pool starting address should contain the IP address of the target device(i.e where you want to install the software), Size of pool: This is the number of hosts which may be configured by Tftpd32, Boot file should point to pxelinux.0, WINS/DNS server should point to the DNS server IP
address, Default router should point to the IP address of the default gateway. Mask should point to the subnet mask.
8. Save the DHCP network set up
On target PC:
Turn your target computer on while connected to the network. In the BIOS, make sure that Network Adapter is first on the boot priority order.
Image downloading should happen soon after the target contacts the TFTPD32 (PXE server). See Log Viewer for log information.

Sunday, January 1, 2017

System Engineering Management

LECTURE SUMMARY AND KEY LEARNINGS FROM TEXT BOOK “SYSTEM ENGINEERING MANAGEMENT” BY BENJAMIN BLANCHARD

Summarize Lectures 1-9, 13, 15 and 16. For each lecture the summary should be ¾ to 1 page long. At the end of the summary identify 2 to 3 key learning’s and tell me why they are key. 2 to 3 sentences for each key learning’s ought to do it..

From the book. For chapters 1, 2, 3, 5 and 6 give me one key learning, tell me why it’s key and tell me how they are, or how they should, be applied at your place of work.


LECTURE –1 SUMMARY:

What I learnt at the end of this lecture:
Inefficiency in organizations, not many universities offering System Engineering Management course.
Purpose of the class
Engineering Problems
Engineering Problems caused by
Solution to Engineering Problems
Introduction to system
Systems approach
Context diagram (Mentioned in Mid term)
Introduction to System Engineering Process
Six Areas of Focus for a System Engineer
What does a System Engineer develop?
C, S , Q ,F (Cost, Schedule, Quality, Functionality)
High Cohesion and Low Coupling (Mentioned in Mid term)

In the industries we work in, we see a lot of inefficiency. Most of my classmates said that their company is 40%-60% efficient. There was hardly anyone who said their company was >60% efficient. This inefficiency is because there is no System Engineeing process followed. Most courses offered in universities are Engineering courses and Management courses, but very few offer the System Engineering Management course. The purpose of this class was to make sure that each one of us understand what System Engineering is all about, what are the key learning’s of a System Engineer and given the job responsibilities of a system Engineer, what he/she should do. I am sure each one of us have achieved this.

Engineering problems that are mainly 2 of them causes inefficiencies in an organization : Product problems (bad quality, does not meet requirements, difficult to maintain etc) and Management problems(wrong estimation, costly, late deliverables etc). There is no Systems approach in place to tackle the problems, poor/no understanding of Systems Engineering process, poor requirements etc. The systems earlier (some 20 years ago) were relatively small. Hence, there was no need for a system engineering process in place. But things have changed now. We need an Engineering environment. We need someone who can see the big picture of the system, who can take the systems thinking approach that can take forward the project from its Inception to deployment and disposal. We need someone who can focus on all the aspects of the Project development Life cycle, one who can define the need/goal clearly, who can create accurate specifications, who can create engineering process methodologies in an organization. That someone is a system engineer.

A "system" is a dynamic and complex whole, interacting as a structured functional unit;
Energy, material and information flow among the different elements that compose the system; A structured, modular solution that has both internal interfaces between its modules and external interfaces with the environment in which it resides and which may maintain an internal sense of state. A system's components cooperate "..so that their combined activity generates the external behavior of the system"

A system can contain within another system. In other words, there could be sub system within a system and each sub system can be treated as a system by itself. Example: Braking system, Zoo, Dating system, Car engine etc

One who takes the systems approach( i.e a system engineer) can see the interdependence among various sub systems within the systems, can define the purpose/goal of each sub system and the system, can see the inputs and outputs and the flow of data/material between each of the subsystems, can see the feedback of information/data/material among the subsystems. Even while trouble shooting the system, a system engineer takes the “systems approach” One such example is Ishikawa diagram shown in Project portfolio.


Key learning’s: Because they exactly say what System Engineering process is and what a system engineer needs to do in brief.

1) System Engineering process: Basically following are the phases in a system Engineering process:-
· Conceptual Design (needs analysis and high level requirements)
· Preliminary Design (high level architecture and mid level requirements)
· Detailed Design (detailed requirements and manufacturing/development, validation and support plan
· Development/ Construction
· Operations and Support.
· Disposal
· Training
· Verification


2) Six Areas of Focus of a System Engineer:
· Requirements Specification
· Transitioning from Requirements to Design
· Technical Performance Measures
· Validating the Product
· Getting the Product into the Customers Hands
· Supporting the Product.

3) What does a system Engineer develop? : Specifications (MRD, PRD, High level design, Plans, User Interfaces, Operations). The chief goal of System Engineering is to create a product that balances cost (development and support), schedule, quality (or performance) and functionality



LECTURE –2 SUMMARY:


What I learnt at the end of this lecture:
Definition of System Engineering
Interdisciplinary field
System Thinking using Context diagram
Maintenance and Support and disposability is almost always neglected
System Engineering Process
Specification Driven Engineering
System Engineering Management

There are many definition for System Engineering, but the one I liked the most is “An interdisciplinary approach that encompasses the entire technical effort, and evolves into and verifies an integrated and life cycle balanced set of system; people, products, and process solutions that satisfy customer needs (EIA Standard IS-632, Systems Engineering, December 1994)”

There may be many diverse fields involved in a systems Engineering process. For example, in the defense industry, there is hardware, software, materials, COTS products, external agencies involved. By providing a systems (holistic) view of the development effort, System Engineer helps meld all the technical contributors into a unified team effort. A system engineer should know the responsibilities of each of the fields and meld their efforts into a system

The very basic question for a systems approach should be “Can this be maintained and supported?”. Inorder to know what a system exactly does, to get the system thinking approach , the very first step a system engineer has to do is to get to the white board and draw the system context diagram(mentioned in mid term). This helps everyone present in the meeting to know what the system in discussion will perform.

Key learning: Because this diagram shows the role of a System Engineer(Product Manager) in an organization.

Key learning: These are key because these are touch points a system engineer should concentrate on in an organization:-

System Engineering focuses on
Requirements
Architect
Technical Performace Measurements
Integration
Customer Acceptance
Validation
Support

Specification Driven Engineering: A system engineer will almost always need to produce specifications at each phase. Every time a specification is created, it needs to be reviewed and version needs to be maintained. In other words, a change control needs to be implemented for the specifications.

Managing the technical effort involved in the system engineering process is System Engineering Management.

LECTURE –3 SUMMARY:

What I learnt at the end of this lecture:
System Engineer – More on Roles and Responsibilities
Touch points of a System Engineer
Important question: What is the goal/problem?
Understanding the User/Stakeholder
Plan the solution (keeping high cohesion and low coupling in mind)
Keep the solution simple


A System Engineer needs to wear many hats. At the end of lecture 2, it may seem like the System Engineer has to literally get involved in every phase of project. This is not true. The challenge is to identify those functions (or tasks) that deal with the overall system as an entity and, when successfully completed, will have a positive impact on the many related and subordinated tasks that must be accomplished. Following are the touch points of a system Engineer:-

Key learning:-

Touch points of a System Engineer:

Analysis
High Level Requirements Specification
Detail Requirements Specification
Functional
Technical Performance
Requirements Negotiation and Prioritization
Review and Baselining
Design
Transition from Requirements to Architecture
Validation with Use Cases
Trace Requirements
Preliminary Estimate and Schedule
Renegotiate Requirements
Updated Baselines
Detailed Design
Technical Performance Design
Review
Renegotiate Requirements, Schedule, Cost
Baseline
Implementation
Detailed Scheduling
Unit and Component Validation
Component Integration
Technical Performance Implementation
Validation
Test Plan development
Test Plan Review and Baselining
Test Case Execution and Reporting
Bug Prioritization and Fixing.


A system engineer has to identify the problem /true goal and outline the solution. A system engineer needs to find out why the problem exists inorder to document the results in the features specification (Marketing Requirements Document). He/She also needs to find out who the customers/ stakeholder are, their skill level, past history with the customer etc. He/she needs to ask the following questions:-
· What are we proposing to do
· Why are we doing this
· Who will benefit
· What are the benefits
· Do the benefits outweigh the cost
· Can the solution be supported at reasonable costs versus continued benefit.
· Can I perform acceptance/bring up/diagnostic test (quantifiable)


When a system engineer plans a solution to the problem, he/she has to think whether similar problem has been solved before, Can a solution be implemented for the problem, Can it be maintained and supported?. The planned solution should be reusable, should interface well with the rest of the components. The system Engineer should ensure that everyone in the team understands expectations, understands the purpose of specifications, tools and methods in place, Insure the overall cohesiveness and accuracy of the plan through all stages of development and support. Keep the solution simple. Any solution that is complicated to understand will be difficult to maintain. Should exhibit high cohesion and low coupling.

Key learning: Because if a system engineer does not determine “what”, how will he determine “how”?

A system engineer has to identify the problem /true goal and outline the solution. A system engineer needs to find out why the problem exists.
LECTURE –4 SUMMARY:


What I learnt at the end of this lecture:
Requirements Engineering
Communication: Do’s and Don’ts (in mid term)
How do I know that the requirements are good?
Validation of requirements
Requirements Checklist
Requirements Traceability Matrix


Everyone knows what to do once the requirements have been defined. However, the hardest part is defining requirements. A system Engineer has to do this precisely. He/She needs to understand user/customer environments, grasp abstract ideas, absorb pertinent facts from conflicting and confused sources, sort out what the real needs are and reorganize them into logical divisions, apply processes, H/W and S/W to the user/customer environments, communicate with different parties: customer, engineering team, senior management etc

Key learning: Requirements are key to any project. A lot of time should be spent on gathering requirements right. This key learning divides this phase further thus making it more understandable.

The basic steps of requirements engineering are. More details about this is included in project portfolio, assignment 4:
Inception: Concept and Scope
Elicitation: Define what is required at a high level
Elaboration: Refined and modify high level requirements
Negotiation: What’s in, what’s out, what’s the priority.
Specification: Document the requirements
Validation: Review and approve the requirements.

Inorder to determine what needs to be done, a system engineer needs to discover what is already happening in the system. Discovery/Analysis can be done by interviewing users, hiring consultants/analysts, reading existing documentation, meetings, surveys etc.

Validation of Good requirements should result in: 1) Functions: What the system had to do. 2) Performance: How well the functions have to be performed 3) Interfaces: Environment in which the system will perform. 4) Constraints: Limitations to the final solution. Good requirements should cover all the areas affected, should be unambiguous, Should be able to test, Should be consistent and error free, Should address “what”, Should not include functionality details, requirements should be traceable. Reviews and re-reviews are a must!!

Key learning: This is key because these questions need to be asked by a system engineer in every meeting and in every phase of the project.

Creating good requirements is a must for a system engineer. The system engineer should create good requirements as mentioned above and validate them. A good system engineer needs to ask 2 basic questions for any requirement:-
· Can I test the requirement
· Can it be maintained and supported

LECTURE –5 SUMMARY:

What I learnt at the end of this lecture:
More on requirements: Various angles to requirements
Marketing Requirement Document and what goes into it
Product Requirement Document and what goes into it
Functional decomposition
Operational requirements
Support requirements
Prioritize requirements
Traceability matrices

What is the difference between a system engineer and a developer? A system engineer can understand abstract ideas while ignoring inessential details, while a developer concentrates on only the relevant component. A system engineer should be able to grasp abstract ideas into his designs.

Key learning: Key because it says what goes into Requirements specifications.

There are 3 different dimensions to requirements depending on the level of details involved: - Features, Functions, Requirements. For each of these levels of abstraction, 3 different specification documents are produced.: Marketing Requirements Document, Product Requirements Document and Functional Requirements Document. A system engineer should take the lead in defining these documents with a holistic systems approach

MRD: Contains high level feature specific information. Details about the user: Who the users are, their skill level, knowledge of the product, past business with the users, market strategy of the product, technical performance measure(TPM’s), Environment in which the product should operate, Documentation details to be provided, Risks involved if the product is not implemented. It is a very good idea to include a context chart(covered in mid term) in the MRD.

Functional decomposition is process of taking an object, system, program etc. and breaking it down into its constituent components. This is a very important step a system engineer should get involved in. After this step, the PRD can be created.

PRD: PRD created by the system engineer serves as a bridge between features and detailed requirements. It contains function specific details: Preliminary cost and schedules, functional description of the product and a draft version of the User Interface, Operational requirements and Support requirements.
System engineer, please remember to remove unnecessary functions from the system(redundant). Also, prioritize functions: with the time constraint, budget, market in mind, a system engineer should be able to prioritize functions into Essential, Adaptable and Nice to have.

A system engineer will have to decompose the product definition by decomposing the top-level features into functions and successive sub functions, translate higher performance requirements into detailed functional and performance design criteria for the identified functions and sub functions, identify all internal (between functions) and external interfaces, determine the functional characteristics of existing components and incorporate them into analysis and design. After performing the functional analysis defined above. i.e once we convert “what” to “how”, a detailed functional requirements document should be created. Context chart, Pseudo language, User Inferface wireframes and Functional Flow Block Diagram can be used in the Functional Requirements document.


Key learning:
.
Operational requirement(used in PRD) checklist: Key because these checklists could be used to determine the operational requirements and Support requirements that should go into the PRD. A system engineer can walk through these points.

Where will the system be used
What will be the environments at the location and what are the ranges
of the environmental measures.
What are all the use cases for the system or mission scenarios
What are the critical operational technical performance measures
How long will the system be in use
How are the various components to be used
What are the hours of operation, percentage of total capacity,

Support requirements(used in PRD) checklist:


How is the system to be supported by whom and for how long.

What is the Mean Time Between Failure (MTBF).
What is the Mean Time Between Repair (MTBR).
What is the Maintenance Down time (MDT)
What are the transport and storage requirements.
What diagnostic capabilities will be in the product
What test hardware and software will be required

LECTURE –6 SUMMARY:

What I learnt at the end of this lecture:
Detailed requirements
Data Flow diagrams
State tables
Data Analysis
Traceability Matrices

A system engineer will need to breakdown the requirements mentioned in the PRD to each departments. Eg Hardware, Software, Facilities, Support, Process/Procedure, Materials and Manufacturing etc.

How can a system engineer create detailed requirements: By decomposition of high level requirements (functional, performance and interface) into a coherent and detailed description of system functions. An individual developer or a team of developers can develop each system function. Each system function can be tested separately. The developer and the QA would use this artifact to work on their job.

Key learning: Detailed requirements checklist
Refine the data flow, control flow, and structure of information
Refine functions, but not down to the design level
Refine system interfaces to exact detail
Refine constraints and discovers new ones
Refines system behavior based on state and inputs

Everyone in an organization is in a hurry to build the product and does not give importance to detailed requirements. The goal of detailed requirements is to clearly defined, detailed, testable requirements. Data Flow diagrams(shows how the flow of data between the system and subsystems) State tables (This would help in coding a If, Then Else condition) , Data Analysis (for creation of databases), User Interface diagrams identifying functions(helpful in web designing)

A system engineer should use Traceability matrix at each stage from detailed requirements going forward. He/ Should should be able to trace each of the detailed requirement to functional requirement to PRD to MRD to Need/Goal to make sure that requirement is complete, confirm to the goal and can be tested.

Key learning: This helps because the TPM of the main component depends on the TPM’s of its sub components. As long as the TPM’s of sub components are within the promised numbers, the TPM’s of the main component will be within the number promised too.

Technical Performance Measures( TPM’s) identified in the MRD should be revisited at every step of the engineering process.

Key learning: Always use shall in design docs “the system shall perform this”

LECTURE –7 SUMMARY:

What I learnt at the end of this lecture:
What is System Engineering Management Plan (SEMP)?
What goes into SEMP?
SOW, Key tasks, WBS, Documentation tree, Cost projections, Milestones, Action Items, Meetings and Escalation
Review breakdown and a good way to review

System Engineering Management Plan (SEMP) is a one stop place to identify and integrate all major engineering activities. It oversees and rides on top of other management efforts. Earlier lectures talked about Specification documents, requirements etc, and the role of system engineer in these phases. SEMP talks about the planning, coordination and integration aspects of a system engineer.

What goes into SEMP?
Some artifacts that go into SEMP are:-
Statement of Work:- Agreement between the customer and the product provider. A System Engineer should read this, understand and clarify any questions he has.
Definition of Key Tasks:- Checklist that the System Engineer can use to see important tasks that need to be performed. See Homework Assignment 7 for more details
Work Break Down Structure: What should Main tasks, Subordinate tasks?
Specification / Documentation Tree:- One stop place for a system engineer to look at all the specifications used/required for the project
Technical Performance Measures
Program Schedules
Technical Reviews and Audits: I really liked this idea (Key learning):
: During reviews, it will be nice if a system engineer breaks them down and assigns specific component/page reviews to different people. Also, instead of reviewing the contents of the specification/code in a review meeting, it will be nice if the reviewers send their review comments before the meeting and the comments are reviewed instead. Saves time, More efficient too!! Saves $$$!!
Progress Reporting
Risk Management
Project Milestones: Find out the important Milestone dates and track them. Also, a system engineer can use the color coding scheme to differentiate between what has been accomplished/can be accomplished and what is in danger of getting completed. Execution is key: System Engineer should make sure that milestone dates can be met, ensure that the team is getting the resources and necessary information.

Key learning: There is no escaping from escalation if someone does not respond.

Action Items: Create Action Items at the end of every meeting. If the action item is not resolved the second time, escalate!

Key learning: Remember this!

Meetings: Do not have meetings for more than 2 hours. Ask everyone to come prepared to the meetings. A system engineer should take down Minutes of meeting. Send out the meeting agenda ahead of time. Invite relevant people.

LECTURE –8 SUMMARY:

What I learnt at the end of this lecture:
Process, understanding what goes into a top level process
Staffing for the various phases in product development process
Templates
Preliminary scheduling and costing
Estimating, issues involved
Baselining the phases in a process
Preliminary planning of a product whose Version X already exists

Process is a standard methodology with sub-processes that increase the likelihood of success, not guarantees success, and maximizes the efficiency of the resources executing the process. Every organization follows some process and documents them. It is important to follow the right process with best practices. The process should use standard specifications/templates, Standard planning, scheduling and reporting, should be used throughout the organization, should be used as guidelines to be tailored both before and during the efforts

What goes into a process? : Example Consider a software development firm. It will generally consist of various phases: Release definition, High Level Product Definition, Detailed Product Definition, Implementation, QA Validation, Alpha Beta testing, Launch Readiness, Customer Acceptance. For each of these phases, a process should identify the goal of the phase, Activities involved, Inputs, Outputs, Reviewers and Exit criteria for the phase.

Templates are standard documents used to optimize communication within and across the organization and thus optimize the process. Every company has standard set of templates that they use. A system engineer should know where these templates are used and should guise his/her team members to use them.

A system engineer should tailor the process as per the needs of the project and when the situation arises. Should define when the process should be tailored and who should review the tailored process.

Key learning: I don’t think there is need of bringing in Agile. Follow this and you don’t need one. This is what Agile does.

Sometimes, a system engineer should choose to provide few functionalities and provide the rest in phases. For example if the system engineer chooses to create functional documents for Feature 3,4 and 1 and decides to skip 2 and 5, the customer has the ability to change some requirements in 2 and 5 since the Functional documents of 2 and 5 are not baselined yet. This offers more flexibility to the customer.


Key learning: Because having a rough estimate always helps the customers and the provider to tweak their requirements based on the estimate.

A system engineer should provide a rough estimate of a project during the time he created the MRD. It does not matter if it is a wrong estimate, but it is important that there is a rough figure in place.

Scheduling and Costing will continue throughout the life of the project. Schedules and Costs must be aggressive but achievable. A system engineer should constantly monitor schedule and costs variances and update the estimates at each phase.

For a product whose Version X already exists and you are creating Version Y, breakdown the features into functions and estimate and design each function

LECTURE –9 SUMMARY:


What I learnt at the end of this lecture:
Architecture of a system
Architectural design and different types of representation of architectural models.
Archetypes
Flow Patterns
Design

“The architecture of a system is a comprehensive framework that describes its form and structure - its components and how they fit together” Jerrold Grochow.

Architectural design is about modeling the system. It shows how the system is structured and how its components work together. The process of architecture designing depends on experience, principles, heuristics, methodologies, iteration and critical reviews. Design is a step that developer takes responsibility in. With ever changing technology and requirements, it is important to build a system with an reusable architecture such that the components exhibit high cohesion and low coupling. It is good to include the architectural representation of the system in documents used during the system life cycle such as MRD, PRD, Detailed design. Having a good representation of the system gives a better understanding of the individual components, relationship between the components and interfaces.


Key learning: This will help you choose the Architecture design relevant to your project.
Top flow patterns recognized in Software Engineering are Transformation(transforms i/p in one format to another) and transaction(eg sum of 2 numbers)

Key learning’s:

Manager: Are we done with defining the Architecture?
System Engineer: Wait a minute, I’ll confirm by going through my Architecture checklist:

Key touch points in Architecture for a system engineer i.e a System Engineer needs to ensure whether the following are in place. Architecture Checklist:-
System Overview:
Describes the system in broad terms
Discussion of the Architectural Design Style and why it was chosen
Conceptual Integrity:
“If it’s complicated its wrong”
Identifies how the “ilities” impacted the architecture (really important)(TPM’s)
Subsystems and Organization:
Defines and describes the major subsystems
Minimizes the linkage between the subsystems
Change Scenarios:
Identify those components that might change or are at risk based on
the unstable requirements, external interfaces or underlying technology.
Reuse Analysis and Buy vs. Build Decisions:
Which components can be purchased or reused.
Approaches to Standard Areas (Archetypes):
Many systems have standard areas; the architecture should reflect these areas.
Requirements Traceability:
Each Requirement needs to be traced to at least one Architectural component
As mentioned earlier, each of the ilities needs to be addressed in the architectural documents.


LECTURE –11 SUMMARY:


What I learnt at the end of this lecture:
Some Technical Performance Measures
System Engineer needs to prioritizing TPMs
House of Quality
Reliability and steps a system engineer should follow to achieve reliability
Fault Tolerance and Error handling: System engineer should ensure this happens

Other names for TPM: Quality Requirements/ Design to Requirements/ Implied Requirements/ Technical Performance Measures
Some TPM’s are:-

Availability
Reliability
Supportability
Usability
Maintainability
Testability
Disposability
Portability (physical and platform).
Response Time
Throughput
Efficiency
Size
Weight
Security
Ergonomics
Safety

Specifying, designing, implementing and testing all the TPM’s will be costly. Hence, a system engineer will need to prioritize, resolve conflicts among TPMs and quantify them. A TPM matrix/House of Quality is used to prioritize TPM’s. The customer generally specifies tPMs. A system engineer should verify whether each of the TPMs is attainable. Recognizing a current benchmark for each of the TPMs is important.


Key learning: Mentioned again. This is important. If not, we cannot meet the desired numbers.
The TPMs must be measured at key milestones of the program to insure that they are being addressed and their targets met.

“The probability that a system or product will perform in a satisfactory(functional and operative requirements met?) manner for a given period of time(Mean Time Between Failure?) when used under specified operating conditions”. Reliability of a component with 3 components is the product of reliabilities of individual components. Adding Redundancy/Redundant components to the system increases reliability but there will be a cost for development, support and maintenance.

4 steps to achieve Reliability:
Identify the quantitative reliability requirements at the system level.
Decompose system into components and allocate the reliability requirements to each of the components
Design each component to meet reliability requirement (Use traceability matrix)
Review the reliability


Key learning: ‘Ilities’ are important for a product. To ensure reliability standards are met, a system engineer can use this checklist.

Reliability checklist

Have the reliability quantitative and qualitative requirements for the system been adequately defined from the beginning?
Have these requirements been properly allocated to the various subsystems (and downward) as applicable?
Is there a top-down / bottom-up traceability of these requirements?
Are the reliability requirements realistic? (Both needed and possible?)
Has the design complexity been minimized, e.g. number of components/parts?
Have system failure modes and effects been identified?
Are system, sub-system and component-part failure rates known?
Has the system or product wear our period been defined?
Have component parts with excessive failure rates been identified?

Key learning: In order to implement fault tolerance capability, error handling should be introduced in each of the interfaces between the components of a system.


LECTURE –13 SUMMARY:

What I learnt at the end of this lecture:
Quality assurance: Why SE is important
Dimensions to Quality
SE’s role in Quality
Costs involved in Quality
Reviews: purpose

Quality is Meeting requirements, Fitness for Use, Degree that it changes the environment. A system engineer has knowledge about the whole system and about what needs to be done to ensure that it is efficient. Hence, it is the responsibility of a system engineer to ensure that Quality of a product is assured.

Key learning:

Quality is not just about testing. Its all about what is mentioned in the checklist below:

The six dimensions to Quality Assurance are (Quality checklist)

Quality Policy: For senior management, contains definition of quality, goals, guidelines, roles and responsibilities
Quality Objectives: must be Obtainable, Understandable and Scheduled
Quality Assurance: creates a framework for the implementation of quality practices and measurement of the quality. It is all about preparing an SQA plan for the project, identify evaluations to be performed, audits, reviews, standards, error reporting and feedback to the team
Quality Control
Select what needs to be controlled
Set a standard for decisions whether a corrective action needs to be taken
Establish the manner in which you will measure
Compare actual measurement to goal
Take action to bring non-conforming processes back to within limits
Quality Audit: There should be someone who verifies if the Quality team is doing his or her job right. Who are they?
Quality Program Plan

There are 2 types of costs associated to ensure that the product is of good quality: 1) Conformance (Preventive such as training, testing etc) costs and 2) Non conformance costs (rework costs, costs associated with fixing code)

A system engineer should ensure that the following are in place to ensure Quality:-
Detailed, testable functional requirements
Quantifiable “ilities” requirements traced through design, implementation and test
Reviews: “a formal technical review is them most effective filter from a quality assurance standpoint Unit Testing
Early Integration and System level testing
End to End testing by the developer
Change Control

I like this idea: Why not?: If I were the king, I would let my team members spend at least 30 mins of their daily time reviewing each other’s work. This will help reduce errors.

Reviews are very important right from the inception phase to disposability. The first review should be at the very beginning of the life cycle of a project. I.e review the needs/goals. Reviews can either be formal or informal depending on the size of the team.

Key learning: Remember to ask this to yourself in every meeting:

The three most important questions you can ask during a review:

Do I understand it
Do I believe it to be correct
Can I make it better.

Key learning: As a system engineer, you have been asked to conduct a review meeting for a design/code review/test scenarios, use this checklist.

Review checklist:

· Distribute the material to be reviewed at least 3 business days before the review
· Identify checklists for the material to be reviewed
· Divide the “checks” on the check list amongst the reviewers
· Return review comments to the author 1 business day before the review
· Reviewer follow up with the author of any comments that are not clear before the review

During the review:

Project the material begin reviewed on the wall/screen
review the comments with a “agree” and make to the change to the document that is being projected or a “disagree and here is why”.
Limit any discussion 3 minutes or less
Any issue taking more than 3 minutes should be taken off line and tracked as an action item.
Schedule any follow up review meeting within the next 48 hours.

For root cause analysis, you can use Ishikawa diagram or Fault tree analysis diagram

LECTURE –15 SUMMARY:

What I learnt at the end of this lecture:
Testing: System Engineer’s role in testing
Levels of testing in an organizations
Importance of development and QA team interaction
Test Plan, Test cases, Test reports
Test trace ability
White box testing (testing of each statement in the code) and Black box testing (testing of the functionality of the product)


Key learning: A system engineer’s role in testing. What should he/she do? Use this checklist:

System engineer’s role in Testing is to ensure that:-

· Requirements are stated in such a manner that they can be tested
· Test plans are in place
· Resources are in place to insure that tests can be created and run
· Test cases are run
· Test Reports are created and reviewed
· Tests cases are rerun when necessary
· User acceptance tests are reviewed and approved
· Manage the response to any failed acceptance case.

All products are error prone. The objective of testing is to minimize errors. Errors in a product can be sourced to poor understanding of requirements, errors in design implementation etc.

Testing should not just occur during the final phase of the product’s life cycle, but it should be a recurring activity right from the beginning. The QA team mainly executes testing. It is a good idea to involve the QA team early in the life cycle of the product, so that it is a parallel activity, such that the QA team can work on the test scenarios while the development team works on the design. Thus, the QA team can contribute to the design and hence the product right from the beginning. Following shows the phases when the QA should come into picture and what they need to do.

Requirements - walkthroughs of requirements
can these requirements be tested

test plans
Design - functional level testability
walkthroughs
trace requirements
Components - component walkthroughs
component tests
test case development
Integration - test cases run
analysis of errors
regression testing
System Test - system readiness
critical error analysis
regression testing
Maintenance - approval of proposed change


Key learning:

Customer: Are you ready to ship the product?
System Engineer: Let me run through the testing checklists (below) and Deployment checklist (Page 25) that my team has completed and let you know.


There are totally 11 levels of testing that takes place in most organizations:-


1. Unit or Module: Tests verify single program or modules. Conducted in isolation or special test environments.
2. Function Tests: Verify the correctness of a logical function
3. Integration Tests: Verify the external and internal function interfaces according to external specifications and design documents
4. System Tests: Validate the system's ability to meet stated requirements
5. System Integration: Validate the product’s ability to interface with other systems
6. Regression Tests: Validate and verify changes to the system
7. Alpha Testing: In house testing of the product done by “in-house users” (i.e. support, filed engineers, sales engineers)
8. Beta Testing: Done at a customer site.
9. Acceptance Tests: Validate the system or program to the user’s requirements
10. Installation Tests: Validate the installability and operability of the System.
11. Operational Diagnostic Tests. Test the product
during operations to insure correctness.


For each of the above, test libraries should be established. For each of the milestone testing mentioned above, test plans and test cases should be created. Further each test case should be traceable to requirements in the design document from which the test scenarios were generated. At the end, the QA manager should approve the generated test report that says whether the test cases passed/failed

LECTURE –16 SUMMARY:

What I learnt at the end of this lecture:
Why Maintenance and Support?
Levels of Support
Repair policies
How are Maintenance and Support quantified? - Effectiveness Requirements


Support of a product is almost always never considered during the early design of a product. Support is required because it drives the long term life of a product. It’s the back end of the entire process. It is not as easy as other steps in System Engineering. IBM’s DB2 product that I work on has more version upgrade, enhancements involved than creating a new feature. Maintenance & Support requirements should be considered as part of the requirements, as one of the constraints of the context diagram, else a failure of the product will occur. Prime Mission related elements of the system must be designed for supportability and maintenance.

There are different levels of support in an organization:-
Organizational: Performed at the organizational(customer site) operational site with the available resources, personal and tools. Limited to Limited to checks, cleaning and simple servicing
Intermediate: Performed by specialized labor with special equipment to diagnose production issues, Can be mobile support provider.
Depot: This represents the highest level of support. This depot generally has Specialized facilities and equipment. The support service generally carried out here can be a Complete overhaul and rebuilding as well as deeply embedded issues that can’t be fixed at the other levels.
It is important that a system engineer determines early during the design phase, whether the product is non-repairable, partially repairable or fully repairable. If the component is repairable and or partially repairable then tools and training need to be provided for diagnostics and repair. If it is non repairable, then find out the parts that are non repairable and stock the replacement parts.

Key learning:
Can the component A be maintained and supported? Run through this checklist to find out if you can.


Maintenance & Support checklist: Should address the following items

Spare and repair parts
Test and support equipment
Personal and training
Transportation and handling
Facilities for support activities
Computer systems (and support for those systems)
Design issues as self-test provisions, built in vs. external tests,
Support personal and their skill, training and positioning.

How are Maintenance and Support quantified? Effectiveness Requirements just as Operational effectiveness requirements eg. Availability of Support, Logistics Response time, Maintenance down time, Life cycle costs for maintenance and support.

Just as we have detail design and development phase, detailed logistics and maintenance support plan should be prepared and baselined with the above said details.

Resources required for Support: Personnel, Training, Training equipment, training simulators, training manuals, special facilities, devices and training software, Supply Support (Defect reports, PMR reports, transportation etc), Technical data.

Black day: We just had one for 16 hours at our lab while I write this!!. Who is overwhelmed by work to get the facility up and running? : system engineer. Every company has a Back up and Disaster recovery plan and so does mine to tackle this problem.

Maintenance: This and enhancements to the product should go through the the entire life cycle from inception to elicitation to design to implementation, deployment and again maintenance. In my organization, the enhancements or maintenance are reported in a tool and assigned to the developers based on the criticality of the bug and the available resources.


Key learning: Are we ready to ship the product?

Deployment checklist: What needs to be done to complete the deployment process?
Target environment has been identified and the product has been configured to meld into that environment
Setup procedures have been written and tested before the product is sent to the user
The user has been fully trained on the product and has passed tests to prove it.
The product is setup at the user site and a bring up test is run
“Acceptance Tests” are run
System Diagnostic tests are run
The “reverse flow” of a bug reporting and product updates are tested.
First line maintenance personnel have been trained and demonstrated required capability.
“Crash” recovery systems have been tested.
The user/customer have signed off the product.

Upgrades are sometimes more difficult that actually implementing the product from the beginning. More specific to the project that I work on, it is difficult because the code needs to be implemented in the existing product. The existing code may not be ideal, given the technology upgrades available, but reengineering the whole product is costly and a different project plan altogether.

Key learning: A system engineer gets an upgrade version request from a customer. How should he address this? Follow this checklist.

Upgrade checklist:
A clear description of an operationally suitable core system including identification of sub-systems and components most likely to evolve.
Establishment of a process for obtaining, evaluating and integrating operational feedback, technology advancements, and emerging commercial products.
Planning for evolutionary upgrade evaluation, requirements validation and program initiation.
Description of the management approach for evolutionary upgrades within a block and the constraints and controls associated with incremental delivery of capability.
Risk analysis of the development approach, both technical and managerial.

Chapter 1: System Engineering Management, Benjamin Blanchard

Key learning: System of Systems : “basically an SOS may be defined as: A collection of component systems that produce results unachievable by the individual systems alone. Each system in the SOS structure is likely to be operational in its own right, as well be contributing in the accomplishment of some higher-level mission requirement. The life-cycles of the individual systems may vary somewhat as there will be additions and deletions at different times, as long as the mission requirements for any given system are met. Thus there may be some new developments in progress at the same time as other elements are being retired for disposal”

Why is this a key learning and Application at work: The above statement forms the basis of Systems Engineering. If we did not have systems within systems making it an abstract system, then there would not be a real need for System Engineering approach to a project.

The DB2 Admin tool that I work on is a system. Within this system, there are other systems such as the DB2 Server, z/os operating system, Vmware virtualization server, Application programs system. Each of these are independent systems by itself that are capable of functioning independently. When all these systems are plugged in together, they form the DB2 Admin tool system. Further, the lifecycle of each of the systems vary. There are frequent upgrades that are made to individual systems and hence there are upgrades made to the final Admin tool as well.

Chapter 2: System Engineering Management, Benjamin Blanchard

Key learning: Section 2.7.4 Page 80-87 Pages 412-418 Appendix A Case study) :Application of Functional Analysis
Summary: Any system should undergo functional analysis. In this, the system is broken down into its individual functional components along with interfaces. Each component should have its own inputs, outputs, constraints and mechanisms. By identifying such functional components, a feasibility study (Page 436 Section B.11) can be made and thus requirements such as hardware, software, people, facilities, data etc can be recognized. A good functional analysis also enables to determine an open architecture approach to the system.

Why is this a key learning and Application at work:

From the functional perspective, the DB2 Admin tool has many components: Utilities, Object compare, ALC, RDEF, Migrate etc. All these functional components are integrated and data and information flows from one component to another and into the DB2 server. If the inputs, outputs, constraints and mechanisms were not identified for each of them, then it would not have been possible to design the system and allocate resources to each of them.

Functional analysis of a component with DB2 Admin tool:

Utilities:
Inputs: DB2 database data. Catalog tables, DB2 Server, Application programs
Outputs: Utilities functionality on DB2 Admin tool
Constraints: Version 8 and Version 7 only
Mechanisms: Compatible on z/os Version 2
Interfaces with ALC, Migrate
Resources identified: Mike, John (from Utilities), Mary (from ALC and Migrate for interfacing)
COTS identified: HGS z/os server


Key learning: Fig 3.1 Page 125. The diagram talks about the major steps of system design and development.

Why is this a key learning and Application at work: The diagram can serve as a checklist for the system’s design and development during the life cycle. It says what goes into each of the phases such as Conceptual design, Preliminary design, Detailed design, Production, Maintenance and Support, Disposal cycles. Using this diagram(in the text book), we can tailor it to the phases of the project(shown in figure below)



Chapter 5: System Engineering Management, Benjamin Blanchard

Key learning:

Appendix D: Design Review Checklist (Pages 478 – Pages 500) :

Why is this a key learning?

During the informal review throughout the system design and development process, reviews are required, The checklists mentioned in the Appendix can be used as important points that need to be completed during the design reviews.

Examples of Application of some checklists at work:

Checklist 1: Talks about Feasibility analysis. I often use a feasibility study to evaluate alternatives to design something in the project. Ever since I read this section, I have been marking the points present in this checklist to perform the feasibility study.

Checklist 5: Functional Analysis and Allocation: It is important for me to determine the dependencies of the components I work on on the rest of them, This checklist helps me determine the interfaces and inputs, outputs and constraints for each component

Checklist 19: Very useful for screen definition languages such as ISPF/web designing.

Chapter 6: System Engineering Management, Benjamin Blanchard

Page 277, Fig 6.6 talks about System Engineering tasks.

Why is this a key learning?
This can serve as a checklist for a System Engineer.

Application of key learning at work:

Following System Engineering tasks applies to the system engineer in my project:-

Perform needs analysis from the APAR documentation sent by the customer and conduct feasibility study to determine whether to fulfill the requirement as an APAR/ Line item
Prepare the system MRD and PRD
Prepare the test and evaluation Master Plan (TEMP)
Prepare the SEMP (System Engineering Management Plan. Check Fig 6.5 on page 274 of the text book for a template)
Accomplish the functional analysis and the allocation of requirements : Determine the affected sub system: Utilities/Migrate/RDEF/ OC
Accomplish system analysis synthesis and design integration: Create the Functional specification and Admin/OC Requirements design documents
Plan, coordinate and conduct formal design review meetings
Initiate and maintain production/construction liaison(ship the PTF) and customer service(sales) activites.


Wednesday, August 24, 2016

VMware View

I was introduced to (Virtual desktop Infrastructure )VDI in 2010, when I worked at Wyse. Wyse does a lot of cool lab stuff. That is where I got to try Xendesktop and VMware View. Like the market's most loved combo, Wyse also used Xendesktop on ESXi. At that time, HDX was the cool thing, it still is but if you discount the bandwidth consumption, then we have the very popular PCOIP. Overall, I was a happy XenD user who was using the Windows 7 desktop and some host shared applications. All that changed when I joined VMware. I had to love VMware View. But trust me, it didnt take long for me to start loving View, but only after we migrated to View 5.0:). Overall, I am a big fan of VDI and can vouch for it anytime. We had about 3000 odd users who used the View desktops. Or should I say 5 images and 3000 linked clone desktops? Whoa! but it worked like magic. But its not easy when you are in IT and trying to run a VDI shop, trying to convince the apple, Mac users to move to VDI. It took a while for us to convince the users to migrate from their physical laptops that they were so used to working with. A managed desktop system was a new concept for most of them and were not willing to let go of their personal wallpaper, musical calenders etc. Little did they realise the average annual cost saving of about $350 that came with the VDI.  Very few users were power users,  so VDI worked perfectly for them. Thanks VDI for taking virtualization one step further and making our lives easy! Cant wait to try out my brand new HD video game on Xend.

Preview on Feedage: journey-through-the-clouds Add to My Yahoo! Add to Google! Add to AOL! Add to MSN
Subscribe in NewsGator Online Add to Netvibes Subscribe in Pakeflakes Subscribe in Bloglines Add to Alesti RSS Reader
Add to Feedage.com Groups Add to Windows Live iPing-it Add to Feedage RSS Alerts Add To Fwicki

Friday, July 15, 2016

Work station for my VMware View VDI desktop

Its been 5 years since I have been using VDI desktops. I have used Citrix Xendesktop and VMware View. I love both and I simply cannot work without them. With VDI, I dont have to worry about carrying my laptop everywhere. I have VMware View app installed on my Ipad, so I can login remotely as well. I dont have to worry about losing my laptop during travel. All my data is stored in NAS  and is regularly backed up. But, what I probably have to worry about is printing with USB printers. Not all USB printers are redirected on the desktop, so I had to do some trial and error before I could nail down to the one that works perfectly. What is probably a disadvantage for some, while I see it as an advantage is customizations. I have a customised desktop with all the required  software, so I cannot install any software I wish. Well, its good in a way since I dont have to worry about the routine MSFT patch updates. I also got a Techni mobile work station that was one of the easiest to assemble, no guessing involved. Here's a quick picture.