[Software] C.5 Human Aspects of Software Engineering

📋 This is my note-taking from what I learned in the class “Software Engineering Fundamentals - COMP 120-002”

Traits of Successful Software Engineers

• Sense of individual responsibility.
• Acutely aware of the needs of team members and stakeholders.
• Brutally honest about design flaws and offers constructive criticism.
• Resilient under pressure.
• Heightened sense of fairness.
• Attention to detail.
• Pragmatic adapting software engineering practices based on the circumstances at hand.

Behavioral Model for Software Engineering

Boundary Spanning Team Roles

Boundary Spanning Team Roles are the different ways team members work together with people outside of their own team or organization. This helps them achieve common goals and work better together.

• Ambassador: Represents team to outside constituencies
• Scout: Crosses team boundaries to collect information
• Guard: Protects access to team work products
• Sentry: Controls information sent by stakeholders
• Coordinator: Communicates across the team and organization

Effective Software Team Attributes

• Sense of purpose.
• Sense of involvement.
• Sense of trust.
• Sense of improvement.
• Diversity of team member skill sets.

Avoid Team “Toxicity”

A frenzied work atmosphere in which team members waste energy and lose focus on the objectives of the work to be performed.

High frustration caused by personal, business, or technological factors that cause friction among team members.

“Fragmented or poorly coordinated procedures” or a poorly defined or improperly chosen process model that becomes a roadblock to accomplishment.

Unclear definition of roles resulting in a lack of accountability and resultant finger-pointing.

“Continuous and repeated exposure to failure” that leads to a loss of confidence and a lowering of morale.

Symptoms of Team Toxicity

• A frenzied work atmosphere where team members waste energy and lose focus on work objectives.
• High frustration that causes friction among team members.
• Fragmented or poorly coordinated software process model that becomes a roadblock to accomplishment.
• Unclear definition of team roles resulting in a lack of accountability and resultant finger-pointing.
• Continuous and repeated exposure to failure that leads to a loss of confidence and poor morale.

Project Factors Affecting Team Structure

The following factors must be considered when selecting a software project team structure:

• the difficulty of the problem to be solved
• the size of the resultant program(s) in lines of code or function points
• the time that the team will stay together (team lifetime)

• the degree to which the problem can be modularized

  Modularization: 모듈화(큰 문제를 작은 단위로 쪼개어서 처리하기 위한 방법. 즉, 복잡한 시스템을 구성하는 부분들을 독립적인 모듈로 분리하여 개발하는 것을 의미)

• the required quality and reliability of the system to be built
• the rigidity of the delivery date
• the degree of sociability (communication) required for the project

Organizational Paradigms

1. Closed Paradigm: Structures a team along a traditional hierarchy of authority.
2. Random Paradigm: Structures a team loosely and depends on individual initiative of the team members.
3. Open Paradigm: Attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm.
4. Synchronous Paradigm: Relies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves.

패러다임

패러다임은 어떤 분야에서 특정한 이론, 방법, 규범, 패턴 등의 모음을 의미합니다. 컴퓨터 과학 분야에서는 프로그래밍 패러다임이라는 용어로 많이 사용됩니다. 프로그래밍 패러다임은 컴퓨터 프로그래밍에서 문제를 해결하기 위해 사용되는 기본적인 방식, 스타일, 구조, 원칙 등을 의미합니다.

각 패러다임은 자신만의 특징을 가지고 있으며, 그에 따라 적합한 문제를 다루는데 있어서 각기 장단점이 있습니다. 대표적인 프로그래밍 패러다임으로는 구조적 프로그래밍, 객체지향 프로그래밍, 함수형 프로그래밍 등이 있습니다.

Generic Agile Teams

Stress individual competency coupled with group collaboration as critical success factors.

People trump process and politics can trump people.

Agile teams as self-organizing and have many structures.

• An adaptive team structure
• Uses elements of Constantine’s random, open, and synchronous structures
• Significant autonomy

Communication among developers and stakeholders is important (consider adding customer rep to team).

Planning is kept to a minimum and constrained only by business requirements and organizational standards.

XP Team Values

• Communication – close informal verbal communication among team members and stakeholders and establishing meaning for metaphors as part of continuous feedback
• Simplicity – design for immediate needs nor future needs
• Feedback – derives from the implemented software, the customer, and other team members
• Courage – the discipline to resist pressure to design for unspecified future requirements
• Respect – among team members and stakeholders

Impact of Social Media

• Social processes around software development are highly depend on engineers’ abilities to connect with individuals who share similar goals and complementary skills.
• Value of social networking tools grows as team size increases or when a team is geographically dispersed.
• Privacy and security issues should not be overlooked when using social media for software engineering work.
• Benefits of social media must be weighed against the threat of uncontrolled disclosure of proprietary information.

Examples of Social Media

• Blogs → can be used share information with team members and customers
• Microblogs (e.g. Twitter) → allow posting of real-time messages to individuals following the poster
• Targeted online forums → allow participants to post questions or opinions and collect answers
• Social networking sites (e.g. Facebook, LinkedIn) → allows connections among software developers for the purpose of sharing information
• Social book marking (e.g. Delicious, Stumble, CiteULike) → allow developers to keep track of and share web-based resources

Team Decision Making Complications

• Problem complexity.
• Uncertainty and risk associated with the decision.
• Work associated with decision has unintended effect on another project object (law of unintended consequences).
• Different views of the problem lead to different conclusions about the way forward.
• Global software teams face additional challenges associated with collaboration, coordination, and communication difficulties.

Factors Affecting Global Software Development Teams

Software Engineering using the Cloud

Benefits

• Provides access to all software engineering work products
• Removes device dependencies and available every where
• Provides avenues for distributing and testing software
• Allows software engineering information developed by one member to be available to all team members

Concerns

• Dispersing cloud services outside the control of the software team may present reliability and security risks
• Potential for interoperability problems becomes high with large number of services distributed on the cloud
• Cloud services stress usability and performance which often conflicts with security, privacy, and reliability

Collaboration Tools

Namespace that allows secure, private storage or work products

Calendar for coordinating project events

Templates that allow team members to create artifacts that have common look and feel

Metrics support to allow quantitative assessment of each team member’s contributions

Communication analysis to track messages and isolates patterns that may imply issues to resolve

Artifact clustering showing work product dependencies

Artifact clustering

Artifact clustering은 작업 제품 간의 종속성을 보여주는 것입니다. 이 도구는 작업 제품이 서로 어떻게 관련되어 있는지 시각적으로 보여줍니다. 예를 들어, 여러 개의 문서, 그림 및 프로젝트 파일이 있을 때, 이러한 파일들이 어떻게 서로 연결되어 있는지 이해하기 쉬워집니다. Artifact clustering은 팀원들이 프로젝트를 이해하고 작업 제품 간의 의존성을 파악하고 관리하는 데 도움을 줍니다.

---

Back to Top

See other articles in Category Software