Software Engineering Process Framework

Software engineering process framework activities are complemented by several umbrella activities. The umbrella activities of a software process are:

Software tracking and control

Using project management software during the lifespan of the project helps to monitor work on each module, forecasting the development time, estimating required human and technical resource hours, and calculating a critical path for the project.

Risk management

Risk is an event that may or may not occur. Risk management is the process for identifying, assessing, and prioritizing risks of different types which might endanger the assets and earning capacity of a business. Once a risk has been identified, the risk manager will create a plan to minimize or eliminate the impact of negative events. Many project managers recognize that risk management is important because achieving a project’s goal depends on planning, preparation, results, and achieving strategic goals.

Software quality assurance (SQA)

Quality is defined as the sum of the total characteristics of a software entity that bears on its ability to satisfy or implied needs. The purpose of software project quality management is to ensure that the project will satisfy the needs for which it was undertaken. Managing the quality of a software project and its development processes must meet the requirements and satisfy the user’s experience.

A software package must conform to the written requirements of the project’s processes and deliverables. When the project is “fit for use,” the product can be used as it was intended, ensuring the product will satisfy the needs for which it was developed for. In the end, the customer will decide if the quality of the software is acceptable or not.

Formal Technical Reviews (FTR)

After completing each module, it is good practice to review the completed module conducted by the technical staff. The purpose is to detect quality problems and suggest improvements before they propagate to the next activity. The technical staff will focus on the quality of the software from the customer viewpoint.


Project and product measures are used to assist the software team in delivering the required software. This helps to ensure the stakeholder’s requirements are met. Since software itself cannot be measured directly, it is possible to measure a project by direct and indirect factors.  Examples of direct measurement are cost, lines of code, size of software. An example of an indirect measurement would be the quality of software.

Software configuration management (SCM)

A set of activities designed to control changes by identifying parts of the system that are likely to change, establishing relationships, defining mechanisms for managing different versions of the project.

  • Revision control
  • Establishment of baselines.

Re-usability measurement

Re-usability measurement defines a criterion for product reuse. Backing up each part of the software project can be corrected, or any kind of support can be given to them later to update or upgrade the software.

Work product preparation and production (models, documents, logs, forms, lists)

Documents that include project planning and activities to create models, documents, logs, forms, and lists are carried get started here.

The Software Life Cycle

A framework is a Standard way to build and deploy applications. The Software Process Framework is a foundation of complete software engineering process. A generic process framework encompasses  five activities which are given below one by one:

Communication: Understand stakeholder intent and requirements.

Always prepare for meetings.  If the project domain is unfamiliar, do some research on the topic and provide the findings to other members of the team so everyone understands the topics discussed. Appoint a person in charge of every meeting, prior to each meeting. Face-to-face meetings work better, but sometimes not always an option. Take notes, meeting minutes, and document decisions. Distribute notes and decisions to attendees. Upload the documents to a share network resource, in case you need to review prior decisions and notes. Always stay focused throughout the meeting; modularize the discussion. Once something is agreed to, move on; move on even if not agreement, or no clarity (table item). Listen to the needs of the client, do not start to form answers until they are finished. Thus,  there is less of a change you might miss an important detail. Use professional body language: do not roll your eyes nor shake your head.


Project management software can be used during the lifespan of the project to monitor work on each module, forecasting the development time, estimate required human and technical resource hours, and calculating a critical path for the project. Over planning wasted time, and under planning creates chaos. Work with the stakeholder to understand what is and is not in the scope of project.  Involved stakeholders in discussions, when appropriate. They will help to set priorities, deadlines, which keeps the project on time and on budget. Iterate on the planning, don’t try to do everything at once. Break down tasks into small tasks and have plan how to complete each one. Incorporate risk management throughout each phase of the project; consider what risks are possible as you plan and be realistic.

Managing the quality of a software project and its development processes must meet the requirements and satisfy the user’s experience. Define how you will achieve quality and accommodate change. Track the project of each iteration of the project often;  make adjustments each time plan reviewed. Don’t leave team members out of planning.


Adapt models from another project to this one, making needed changes. Explain why you are building each model and build a useful model, not perfect model. Thus, the built model so they can be changed. Do not create models that are not needed, this may waste time and take the project out of scope. When presenting a model ask for feedback on the model by all team members. Encourage team members to share feeling about the state of the model. Ask them what they like and what they do not like.  Using structure charts during the implementation of a system will show users the program modules and the relationships among them. Structure charts consist of rectangle that represent the program modules, with arrows and other symbols that provide additional information. This helps when the analysts and programmers understand the purpose of each module during the designing and testing each module before being run on the entire system.


Programmer can use the principles of software engineering to manage and improve the quality of the finished system. Working from a specific design, a program will use the purposed programming language to transform the program logic into a program module which the rest of the group can work on simultaneously. To simplify the integration of system components and reduce code development time an integrated development environment (IDE) will make programming easier. Coding each program must be tested to make sure it will function correctly, after the programs will be tested in groups, and finally running the entire system.

Before you write first line of code, make sure you understand problem to be solved and the design principles. Choose the best programming language for this problem, then select programming environment. Select data structures to match design and keep conditional logic simple and minimal. Follow coding standards at your site for variable names, this will help ensure the code can be easily maintained in the future. Write self-documenting code to help yourself and other developments. Create unit tests to help reduce bug and problems in the software. Create nested loops so they can be easily tested. A successful test is one that discovers a bug.


Once delivered to the client see if the client can provide feedback on how the application is work. Using the basis of the clients feedback we modify the products for supply better product. To ensure a successful deployment, if possible, try to use a staged deployment model:

#1- Development: A local developer’s workstation.

#1 – Testing: An integration environment where developers merge changes to test that they work together to create a working application. Unit testing will need to be performed on an individual program or modules. This will help to identify and remove execution errors that could cause the program to terminate abnormally, and logic errors that could have been missed during the desk checking. Integration testing will need to occur on two or more programs that might depend on each other.

#3 – Staging: This is where tested changes are run against a production-equivalent environment with data to ensure the application will work properly

#4 – Production – The live production environment.

If an environment of stage is not kept up to date this can lead to out of data testing and possible incorrect environment factors causing promoting a model or application to fail, thus causing rollback  in development.

Why Projects Fail

Executive Management, project Managers, and Team Members are the three sets of players for every project.  Project Management Institute, Inc. identifies four reasons why projects fail: lack of visibility, unclear objectives, resource workload, and gaps in communication.

Visibility into a project entails identifying tasks, reports, and schedules posted in real-time.  Many projects fail because key players are not informed of progress and updates thus leading to confusion.  Unclear objectives entail setting realistic goals and strategies.  Many projects fail because a lack of vision leads to chaos.  Resource workload entails the execution of a reasonable workload.  Overworked employees get burned out and ultimately quit.  Gaps in communication leaves key players uninformed.

Good practices should be communicated with the onset of every new project.  Executive Management must demonstrate effective leadership.  Project Managers must communicate to management and team members.  Team members must receive proper communication so they can effectively perform their job. Project Managers have been known to be overconfident in their abilities.  Overconfidence in meeting budgets, schedules, and project objectives can compromise the project and/or lead to disaster.  If new evidence presents itself along the way, do not ignore it.  Knowing when new evidence needs to be considered to re-evaluate a project could be crucial to success.

Due to eminent failure and unrecoverable costs, knowing when to pull the plug on a project may be a necessary evil.  While objectives need to be prioritized, it is important to understand that priorities and objectives change.  Projects require constant monitoring.  While these four points don’t explain everything that could go wrong, it serves as a reminder for all of us to consider.

Communication Management Plans

A communication management plan is a document that will help guide a project. It is part of the overall plan for the project’s communication for the lifetime of the project, and will also define the communication requirements and how information is distributed during for the project. The Project Manager take a proactive role in ensuring effective communications on a project, taking a contingency approach to communicating with employees and communicate on a personal level. They can also suggested methods or technologies for conveying the information to the team and stakeholders and what will be the frequency of communication.

Project communications management is an important part of the project life span. Failure to communicate during the starting phases of a project may result in an unclear project scope and unrealistic schedule for each phase. A communication management plan’s goal is to ensure a timely and appropriate generation, collections, dissemination, storage and disposition of project information. One of the main things which should be address is the communication requirements for stakeholder; the people who may be impacted by the success or failure of a project. Therefore, inclusion of their perception regarding the project is important for the communication management plan’s success. Having a communication plan for stakeholders is an important element in project management, and needs to be carefully formulated. Its layout generally includes the stakeholder identified roles and the designed management strategy. The information to be communicated must have an appealing format, meaningful content, and good level of detail.

Stakeholder Management is an important discipline that any project manager can use to win support from others, helping to ensure that the projects succeed where others may have failed. Analysis of the project’s stakeholder is the technique used to identify the key people who have to be won over the life span of a project. Building the support that will help the project succeed. A project manager can use the opinions of the main stakeholders to shape projects at an early stage, making it more likely they will support you. Their input can also improve the quality of your project. A project which has gained main support from the stakeholders may win more resources, making more possible that the projects will be successful. By communicating with stakeholders early and frequently, the project manager can ensure that they fully understand what the team is doing and understand the benefits the project.

If issues starts to arise an escalation procedures for will help to resolving issues and may result in a revision procedures for updating the communication management plan. For communication to success each member of the project team needs to have a mixture of technical and soft skills, like social networking communication. If communication is still an issue a glossary of communication terminology can be used to help the project team communication on a more common ground. One popular communications method is weekly reporting method, when every employee composes an e-mail report, communicating the to team about information on their activities of the preceding week, plans for the following week, and any other information deemed relevant to the group.

In conclusion, a communication management plan is an extremely important part of leading a successful project. Project managers define how to format communications with their team members and stakeholders. Having a successful and clear relationship with stakeholders helps a project gain support and resources for a team. The support of stakeholders, a team’s hard and soft skills set contribute greatly to a project’s success and defined by the communication management plan.

Software Quality Management

Quality is defined as the sum of the total characteristics of a software entity that bears on its ability to satisfy or implied needs. The purpose of software project quality management is to ensure that the project will satisfy the needs for which it was undertaken. Managing the quality of a software project and its development processes must meet the requirements and satisfy the user’s experience. Businesses often make quality management a serious discipline a major component of their IT risk reduction strategy.

A software package must conform to the written requirements of the project’s processes and deliverables. When the project is “fit for use” is when the product can be used as it was intended, ensuring the product will satisfy the needs for which it was developed for. In the end the customer will decide of the quality of the software is acceptable or not. Design of experiments is a technique that helps to identify which variables have the most influence on the overall outcome of a process for understanding which variables affect the final outcome is an important part of quality planning.

There are many scope aspects of IT projects that affect the quality of a project are. The biggest aspect is the system’s functionality, the degree to which a system performs its intended function. A system must contain the features that have characteristics which are appealing to the intended user. After the user interacts with a system it must generates outputs which are shown on the screens and reports, it is important to define clearly what the screens and reports look like for a system. A system’s performance will address how the software package will perform to the customer’s intended use. To design a system with high-quality performance, project stakeholder must address many issues. Reliability is the ability of a product or service to perform as expected under normal conditions. Lastly, maintainability addresses the ease of performing maintenance on a product. If a software system breaks down after being implementing within a system, project team must review the project to fix the problem to give the user a future satisfying experience.

Planning quality management is the ability to anticipate situations and prepare actions that bring about the desired outcome. Having a plan for the software development life span help to stop a lot of the issues which comes from developing a software system. The first step is to define the quality to match the requirements of both the business and achieving a satisfying user experience. The second step is to broadcast a simple quality metrics, this helps to reduce defeats, as well as keeping the quality on the minds of the whole development team and expose when efforts fall short. Another possible step it to keep fine tuning the project’s goals to make sure the requirements are being meet and each user test of the system has a satisfying experience. Getting the requirements right the first design phase means the software would need to be reworked less and less retesting and troubleshooting code to test for bugs. Designing a simple application helps to lessen the risk for bugs and is easier to test and rework if needed.

Agile and UML

Agile as a process

Agile is a process by which a team can manage a project by breaking it up into several stages and involving constant collaboration with stakeholder and continuous improvement and iteration at every stage. The benefits of using agile are:

  • Enables teams to deliver value fast
  • Greater quality and predictability
  • Greater aptitude to respond to change
Agile Methodology
Agile Methodology

The agile methodology begins with clients describing how the final product will be used and what problem it will solve. This clarifies the customers expectations to the project team. Once the work starts, the team can cycle through a process of planning, executing, and evaluating. Collaboration is always continuous and key, among team members and stakeholders to make informed decisions about the project.

The main development values of using agile are:

  • Individuals and Interactions over processes and tools
  • Working Software over comprehensive documentation
  • Customer Collaboration over contract negotiation
  • Responding to Change over following a plan

Using agile requires each small team to be led by a scrum master whose main job is to clear away all obstacles to completing work. Work is done in short cycles called sprints, but the team meets daily to discuss current task and roadblocks that need clearing.

Agile Method Sprints
Agile Method Sprints


UML as a documentation system

The Unifies Modeling Language (UML) is a general-purpose, development, modeling language that is intended to provide a standard way to visualize the design of a system. There are several types of UML diagrams that each serves a different purpose regardless of whether it’s being designed before or after the implementation.

The two main categories of UML diagrams are:

  • Behavioral
  • Structural
Unified Modeling Language
Unified Modeling Language (UML)

Documentation with a Software Project

How a project design is getting documented in the SSDs, the operation contracts, the class diagrams, the sequence diagrams, and the communication diagrams?

The more documentation the better to help future developer maintain and upgrade the code. Many people who might be part of the project might not have a coding background but will need to understand what is being implementing and how to stage the project.


What is the team that documents are also doing the coding?

It would depend on the size of the team and scope of the project. It the team changes or new people join the team they will need to get up to speed on which stage the project is and what their part would be. Also, if there is an error in project and the developer is no one with the project, the new document available will help any future developer to understand and fix and broken parts to the code.


Do you think it is overkill if these documents are sent overnight to offshore, and code returned the next morning, as a regular part of the development process?

It’s not overkill be would it depend on the reason behind sending the code to a remote team. Also, it would be depending on the how detailed and organized the documents are. If there is an error in the logic or implementation the returned code would have minimal or no benefit on the project or module. This is the return for sandbox testing and staging development

Project Phases and Estimate

How accurate do you think an “order of magnitude” cost estimate should be?

A Rough Order of Magnitude (ROM) estimate is an unreliable estimate of the cost and effect to complete a project. This estimate is developed early in the project when there is a lack of detailed information. Some experts say the ROM estimate should be at least ±50% but can variety.


Can you compare and contrast a business case for a software project with a business case for replacing windows in a house where energy savings are being used as the reason for replacement?

Both cases would follow the normal project management steps, yet the risk and time line of each would depend on the size of each project. The tools used and skills required to for a software project are different then for replacing a window. After each project is complete there is the issue how much maintain it will require. A software project depending on the number of features and platform may require a on-going team to help maintain and fix bugs as they appear, where replacing a window may not require any maintained depending on the structure and natural factors.

Project Phase Software Project Replacing a Window

Show the need and return on investment

System doesn’t meet the needs of our users and/or environment Save money on energy bill or needs to be replaced

Create schedule, tasks, and allocate resources

System requirements, number of developer & testers, budget allocation How big is the window jam and vender selection; check the rough opening

Assign tasks to team member and paperwork

Create UML diagrams and assign development tasks How many people will it take to replace the window

Monitor progress and control changes

After end module is compete testers will ensure it works to specification Check for gaps, level, and squareness
Project Close

Closing paperwork & lessons learned

Launch the new system and deliver to users Clean area and verify installation

Agile Methodology vs. Waterfall Model

Waterfall project methodology


A model in which every stage of a product’s life cycle takes place in sequence and emphasizes a logical progression of steps. Before moving to the next phase, there is usually a review and sign off process to ensure that all defined goals have been meet. Ideal for projects that have a specific documentation and fixed requirements, estimated timeline, ample resources, and well understood technology.

7 non-overlapping stages

  1. Requirements
  2. Analysis
  3. Design
  4. Coding/Implementation
  5. Testing
  6. Operating/Deployment
  7. Maintenance


  • Upfront documentation and planning stages allow for large or shifting teams to remain informed and move towards a common goal
  • Forces structured and disciplined organization
  • Simple to understand, follow, and arrange tasks
  • Defines milestones and deadlines


  • Design is not adaptive to change
  • Delays testing until end of development life cycle
  • Does not consider error correction
  • Does not handle requests for change, scope adjustments or updates


Agile Methodology

1 Fzz56Ps_vQSTPHDO9IomXw.png

An approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-function teams and their customers/end users. Contains a set of different projects that are iterations of different stages; focused on improving the quality and feedback from users.


  • The client is involved throughout the project and can give feedback to change the product and its features as best suitable for the business and the client.
  • Change requests are easier to implement as the agile methodology follows an adaptive planning method, with plenty of room to accommodate change requests as they come.


  • Requires experience and quick decision-making ability to accept some changes and postpone other changes for the next sprint.
  • Does not work well if the client or the team does not understand agile methodology and could not keep up with the fast-paced environment.
Agile Waterfall
Iterations Stages
Constant Business Interaction Communication is varied between high/low iterations
Scrum master Project Manager
Can go back to previous iteration Cannot go back to previous stages
Increased speed Increased Quality
Flexible Structed and rigid