Project Line, Systems and Software Engineering Personas
In 2014 I researched the additional aspects of Project Line Engineering for the Systems and Software Engineering personas.
Personas
Charles, Configuration Lead. Charles is in the engineering organization. He is supporting the team(s) by administrating and creating stream and baseline configurations. He has a good product line overview and makes decisions on the best options for component versions.
Susan, Systems Engineer. Performs requirements analysis, modeling, and simulation to manage complexity. She collaborates with lead engineers from various hardware and software disciplines to design the system to meet stakeholders’ needs.
Pete, Project manager. Pete is managing the schedule and scope of the Mobile AMR 2013 UK project. He creates and assigns tasks across the team. He makes sure reviews are made and approvals are given. He makes sure the state of artifacts is kept by initiating that baselines are taken. He tracks project measures and makes sure artifacts progress to completion.
Pam, Product Manager. Pam is in the marketing organization. She works closely with customers to understand market needs and opportunities, and defines and manages products and variants to meet customer needs
Marco, Development team lead. Leads the Meter Reader platform, development team. His agile team delivers feature components to the AMR product line.
Tony, Systems Tester. Performs automated and manual testing to validate hardware and system requirements.
Dan, Embedded Software Developer. Creates the software design model and implements the System Engineering model. Designs, implements, and unit test the software model using Model-Driven Development.
Allison, Tools Administrator. Installs, Configures and Maintains tools in production. Maintains project templates and creates tool repositories using templates.
AMR Product Teams
AMR Mobile Product team
The personas appear in two types of development teams.
- The AMR Product teams deliver product variants for multiple markets
- The AMR Platform team delivers reusable components for the product teams
the Platform team
The AMR Mobile Product team is responsible for delivering the mobile product variants to the US, EU, and UK markets. The team reuses and refines components delivered by the platform component teams. The AMR Meter Reader platform component team is responsible for delivering reusable components for the AMR project line. The teams share resources for stared tasks, e.g Configuration management, Build, and Tool Administration. Separating the responsibilities of Project and Platform teams is significant and captures patterns of organizing teams and practices around effectively developing product lines.
AMR Mobile Product team
The personas appear in two types of development teams.
- The AMR Product teams deliver product variants for multiple markets
- The AMR Platform team delivers reusable components for the product teams
the Platform team
The AMR Mobile Product team is responsible for delivering the mobile product variants to the US, EU, and UK markets. The team reuses and refines components delivered by the platform component teams. The AMR Meter Reader platform component team is responsible for delivering reusable components for the AMR project line. The teams share resources for stared tasks, e.g Configuration management, Build, and Tool Administration.
Separating the responsibilities of Project and Platform teams is significant and captures patterns of organizing teams and practices around effectively developing product lines.
Susan, the System Engineer
Susan
Systems Engineer
B.Sc., Mechanical Engineering M.Sc., Systems Engineering
“I see the big picture to manage the complexity of the system”
Susan has been with the current company for about 10 years and has over 20 years of systems engineering experience in the industry. Her current project is building a smarter hybrid car. She has a BSc. in Mechanical Engineering and a graduate degree in Systems Engineering.
As part of her daily job, Susan uses a host of tools that include modeling and simulation, requirements analysis to manage complexity. She collaborates with lead engineers from various hardware and software disciplines to design the system to meet stakeholders’ needs, but also interacts with stakeholders to manage their expectations and to complete the project on time and within budget. She constantly monitors and investigates how all the pieces in the system fit and work together, but currently, it is not always easy to get a big picture view of the entire system or up-to-date information on components in the system.
Responsibilities
- Collaborate with domain leads to perform. requirements definition, modeling, top-level functional designs to organize and coordinate other engineering activities. Susan collaborates with product management, project management, test, and design. Lifecycle cost analysis is performed by IPT (Integrated Product Team) lead.
- Act as the primary interface between management, customers, suppliers, and specialty engineers in the systems development process.
- Susan works closely with marketing to understand customers’ needs and works with tools architects to ensure tools/processes match everyone’s needs.
- Support change review board.
- Ensure complete requirements traceability from business requirements to systems to subsystems.
Goals
- Manage the complexity of the system.
- Detailing the requirements of the system.
- Defining, characterizing, and documenting. subsystems and the interactions among them.
- Organize and coordinate systems development activities and processes.
Pain Points
- Get a big picture view of the entire system or up-to-date information on components in the system- large dependency of tools knowing how to extract needed information.
- Maintain awareness of changes throughout the systems development process, more importance on the solid process for change management (change records, review proposed changes). This includes both formal (reviews, propose changes) and informal (drafting, fewer reviews of each change, in preparation for peer reviews) change control. There are two main pain points here : (1) changes to requirements coming from different sources (2) communicating the change with the team.
- Maintain and communicate to ensure all stakeholders are on the same page about the system requirements, design, and so on. This is part of the formal change control (stakeholder reviews as part of the change.
Charles the Configuration Lead
Charles
Configuration Lead
“Help me make informed decisions quickly”
Responsibilities
- Identify where different members of the cross-function team are to be involved.
- Oversees preparation of reports, such as statistical and data analysis reports, for all engineering processes.
- Oversees policies, procedures, protocols, and controls that govern operations.
- Balance across products and identify what is common across products and reuse.
- Ensure architecture integrity in the system and make all architectural design decisions
- Review and approve architectural changes
Goals
- Organize and coordinate systems development activities and process
- Work with Systems Integration Organization to ensure integration of components from various disciplines into a coherent and effective system.
Pain Points
- Have appropriate tools to help with productivity and process guidance – heavily reliant on a requirements management tool (DOORS), users must be effectively trained.
- Create a baseline of artifacts stored in all tools used in product development.
- Efficiently perform review and approval.