Software Engineering Process (SEP)

Until 2005, Pennsylvania did not have a software development methodology that was sanctioned across the Commonwealth Enterprise. Recognizing the need for a software engineering standard, the Commonwealth formed the Business Solutions Center of Excellence (BSCoE) to develop an effective software engineering process (SEP).

SEP Version 1.0 BSCoE’s initial effort, SEP Version 1.0, integrates best practices and development tools into an effective methodology. The SEP Version 1.0 is a collection of artifacts, templates, and samples gathered from several standard software development life cycles (SDLC), including the Rational Unified Process (RUP), Microsoft Solutions Framework (MSF), Enterprise Project Management Methodology (EPMM), and Software Development Methodology (SDM). To discourage the traditional “waterfall” development approach and to emphasize the SEP’s iterative nature, BSCoE rendered SEP 1.0 as a set of nested wheels.

SEP Version 2.0 SEP Version 2.0 is a natural outgrowth of its predecessor. SEP 2.0 emphasizes process engineering–tailoring processes to the project at hand. The BSCoE SEP now combines the SEP Repository–a collection of guidance, tasks, and templates grouped by discipline–and the SEP Configuration, a process that integrates elements of the SEP Repository into project-specific development methodologies.

The table below summarizes the major differences between SEP 1.0 and SEP 2.0.

SEP 1.0	SEP 2.0 Repository
Static HTML	Customizable HTML with EPF
Documentation with static templates	Documentation generation with SPARX EA
No content configuration to match Development Case	Content configuration with EPF to match Development Case
No mandatory training	Mandatory training to emphasize mentoring
IBM Only tool support	Customizable tool support
No EPMM integration guidance	EPMM integration guidance
No Process Engineering guidance	Process Engineering guidance and mentoring

SEP 2.0 Engagements For access to the SEP, SEP 2.0 engagements are now mandatory, and are restricted to Pennsylvania state agencies and authorized contractors. The primary reason for BSCoE requiring an engagement is to increase communication between the BSCoE SEP team and the agencies and consulting firms using the SEP. We must have good communication channels set up with the SEP users in order to make improvements to the repository content and to the SEP Configuration. A second reason for good communication channels between the BSCoE SEP team and active projects is that the SEP 2.0 Repository now provides the tools for content reuse.  Users can now easily add process content that is specific to their project or agency.  If that content is valuable at an enterprise wide level, the BSCoE SEP team will integrate it with the base library making it available to other users of the SEP 2.0 Repository.  We must be in contact with the active SEP projects to ensure reuse happens whenever possible. Another reason for making initial contact mandatory is we want to make sure that the team understands that process engineering is not easy to do.  The BSCoE team wants to ensure you have the tools to succeed, and we cannot do that if we don't know about your project. Reverse engineering a process is necessary when a team already has a successful and productive software development process in place. We assess the process, compare it to the industry standard process BSCoE recommends, and then decide whether BSCoE can help improve the process. We may also find that parts of the team's process are valuable at an enterprise-wide level and use them in the SEP Repository. To request a SEP 2.0 engagement use the button below (Commonwealth of Pennsylvania agencies only).

SEP Configuration (SEPCon) A typical SEP Engagement will execute the SEPCon.   The SEPCon is a process built with activities that enable the creation of an instance of the SEP 2.0.  Each project builds a process instance.  Both training and mentoring are part of a SEPCon.  Following the activities outline in the SEPCon is critical for identifying the risks involved with a SEP 2.0 instancing project. One of the primary risks it helps to identify is the experience of the user's process engineering team.  The SEPCon is adjusted for different levels of experience, and we can increase training and mentoring time if we find low experience levels.  Over time, as the user team gains experience, the BSCoE team will do less mentoring.  Eventually the goal is to have an experienced team of process engineers at each agency. The teams will provide feedback to the BSCoE process team to help them refactor and add new content to the SEP Repository and make adjustments to the SEPCon.

SEP Training and Mentoring The BSCoE team has training in place that is tailored to each team's individual needs based on their experience.  Each engagement begins with an agency team assessment. The assessment gives the BSCoE team the information needed to assemble a tailored training plan for the engagement. Every engagement includes some degree of mentoring by BSCoE staff.  BSCoE mentors will work with your team to help you complete the initial process configuration tasks, and will continue working with your team until they feel confident enough to continue without mentoring.