UNITENIANS

Tweet

Tweet

This is what Module 9 is all about :- 

Software development process

A software development process is concerned primarily with the production aspect of software development, as opposed to the technical aspect, such as software tools. These processes exist primarily for supporting the management of software development, and are generally skewed toward addressing business concerns. Many software development processes can be run in a similar way to general project management processes. Examples are:

• Risk management is the process of measuring or assessing risk and then developing strategies to manage the risk. In general, the strategies employed include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Risk management in software project management begins with the business case for starting the project, which includes a cost-benefit analysis as well as a list of fallback options for project failure, called a contingency plan.
  • A subset of risk management that is gaining more and more attention is "Opportunity Management", which means the same thing, except that the potential risk outcome will have a positive, rather than a negative impact. Though theoretically handled in the same way, using the term "opportunity" rather than the somewhat negative term "risk" helps to keep a team focussed on possible positive outcomes of any given risk register in their projects, such as spin-off projects, windfalls, and free extra resources.
• Requirements management is the process of identifying, eliciting, documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. New or altered computer system^[1] Requirements management, which includes Requirements analysis, is an important part of the software engineering process; whereby business analysts or software developers identify the needs or requirements of a client; having identified these requirements they are then in a position to design a solution.
• Change management is the process of identifying, documenting, analyzing, prioritizing and agreeing on changes to scope (project management) and then controlling changes and communicating to relevant stakeholders. Change impact analysis of new or altered scope, which includes Requirements analysis at the change level, is an important part of the software engineering process; whereby business analysts or software developers identify the altered needs or requirements of a client; having identified these requirements they are then in a position to re-design or modify a solution. Theoretically, each change can impact the timeline and budget of a software project, and therefore by definition must include risk-benefit analysis before approval.
• Software configuration management is the process of identifying, and documenting the scope itself, which is the software product underway, including all sub-products and changes and enabling communication of these to relevant stakeholders. In general, the processes employed include version control, naming convention (programming), and software archival agreements.
• Release management is the process of identifying, documenting, prioritizing and agreeing on releases of software and then controlling the release schedule and communicating to relevant stakeholders. Most software projects have access to three software environments to which software can be released; Development, Test, and Production. In very large projects, where distributed teams need to integrate their work before release to users, there will often be more environments for testing, called unit testing, system testing, or integration testing, before release to User acceptance testing (UAT).
  • A subset of release management that is gaining more and more attention is Data Management, as obviously the users can only test based on data that they know, and "real" data is only in the software environment called "production". In order to test their work, programmers must therefore also often create "dummy data" or "data stubs". Traditionally, older versions of a production system were once used for this purpose, but as companies rely more and more on outside contributors for software development, company data may not be released to development teams. In complex environments, datasets may be created that are then migrated across test environments according to a test release schedule, much like the overall software release schedule.

Tweet

Software Implementation Best Practice #1: Proper Planning
Make sure that your implementation plan includes specific deliverables for each milestone, a clear definition of the scope of each step, and contingency plans that you can put into action should the schedule begin to slip. Remember, your implementation plan must extend beyond the go-live date. As the organization continues to change, the process must evolve with it. Some areas of your implementation plan that need to be carefully thought out (but are not limited to) are:
•    Data conversion: Conversion of data from the old software system to the new should begins early in the implementation process. Testing should be performed to ensure accurate data is transferred into the new system’s database. If inaccurate data is converted, the erroneous data may have a negative domino effect throughout the organization.
•    Disruption of business: Even the most successful implementations can disrupt a company’s business and lead to a reduction in productivity that can temporarily affect the bottom line. Detailed project plans can also contribute to shorter implementation timeframes.
•    Training: Every system user must be fully educated so they understand how the new system will be integrated into the overall company operation. All users must be trained to take full advantage of the system’s capabilities. Failure to educate and train all relevant personnel will guarantee implementation problems.
Software Implementation Best Practice #2: Continuous Monitoring
Monitoring should be integrated into all stages of the implementation project. As the implementation progresses, a careful audit of each milestone will help you ensure that the service provider is providing all of the products and services specified in the contract, and the internal implementation team is performing as it should.
Failure to properly monitor the progress of the implementation can also lead to scope creep (see Best Practice #4)—among other things.
Software Implementation Best Practice #3: Updating your Stakeholders
Your stakeholders have been part of the project since it first got off the ground (all those months ago), so don’t keep them in the dark at the implementation stage. Ensure that your project champions, subject matter experts (SMEs), and service provider work closely together throughout the implementation so that everyone is on the same page. A poorly managed and maintained project is often a factor in implementation failure. Communication is critical for its success. Audit each implementation milestone and provide detailed briefings and progress reports to your stakeholders on a regular basis.
Software Implementation Best Practice #4: Preventing Scope Creep
If scope creep happens, it’s often because we’ve allowed it to. Tasks change, deliverables aren’t met, and before we know it, our go-live timeline is shot to hell. Sometimes, scope creep is inevitable, however; a project plan that provides a focused and well-defined scope, and includes the appropriate resources (both human and budgetary) will help keep your implementation project on track—reducing the risk of creep.
Software Implementation Best Practice #5: Negotiating Additional Products or Services
Remember: The people involved in the original negotiations during a software selection are not the same people assigned to implementing it. Ideally, your goal should be to tie payments to the achievement of milestones in the implementation process, however; be prepared to negotiate the cost of additional products or services as the need arises. While most contracts state the obvious in terms of the license agreement, and ongoing support and maintenance requirements, they often say little about what service levels are to be met in order for the implementation to be considered complete. If you’re uncertain, have the service provider draw up a service level agreement (SLA) or statement of work (SOW) and attach it as an addendum to your contract.

Tweet

Tweet

• System software
• Application software
• Engineering/scientific software
• Embedded software
• Product-line software
• Web applications
• AI Software