UNITENIANS

Tweet

Tweet

Basically Chapter 4 explains design creates the representation or model of the software. Different than the analysis model , design model provides details such as software architecture , data structures , interfaces and components that are necessary to implement the system. Thus it is important because model design can assessed for quality and improvement before code , test and more users gets involved.

Apart from that , a good characterictis of a design must be :-

• implementation of all the expilcit requirements contained in the analysis model and it must accomodate all the implicit requirements desired by the customer
• must be readable , understandable guide for those who generate code and for those who test and subsequently support the software
• must provide a complete picture of the software , addressing the data , functional and behavioral domains from an implementation perspective

And design principles must include :-

• should not suffer from 'tunnel vision'
• should be traceable to the analysis model
• should not reinvent the wheel
• should minimize the intellectual distance between software and problem
• should exhibit uniformly and integration
• should be structure to accomodate changes
• should be structure to degrade gently
• design is not a coding ,coding is not design
• design should be assessed for quality as it is being created
• should be reviewed to minimize conceptual (semantic) errors

In model design , design concepts should cover :-

1. Abstraction that is divided into Procedural abstraction and Data abstractions
2. Architecture that basically describe the overall structure of the software
3. Patterns
4. Separations of concerns , its a rule of thumb to define how modules should be separated
5. Modularity , to divide into components
6. Information hiding
7. Functional Independence
8. Refinement
9. Aspects
10. Refactoring
11. OO Design concepts
12. Design classes

Tweet

Question 1 :
Method (s) best used to study the module.
There are several ways to study this module and there a ton of technique that can be apply to remember all the facts and keywords in chapter 1 such as :

• Mind map

This technique are the most popular to the student and all practitioner around the world. Mind map is proven effective by many successfull people in the world and has helped many in their daily such as work , studies and etc.

Second, we can also practise the use of questionnaire. By using the principle of 5W question

• what
• where
• who
• why
• when
• how

Question 4:
To summarize Chapter 8, this chapter mainly about on how software evolve when the project is been held.

Tweet

Practitioner’s myths:

• Myth: Once we write the program and get it to work, our job is done.

• Reality: Someone once said that the sooner you begin writing code, the longer it’ll take you to get done. Industry data indicate that between 60 and 80 percent of all effort expended on software will be expended after it is delivered to the customer for the first time.

Disscussion : If we were to start writing the codes before proper design and planning, the project would take longer to complete. This is because the programmers are building codes blindly. Having only a rough idea of how it is supposed to work and in the end, in order to amend these mistakes, much more time would be taken.

• Myth: Until i get the program running. I have no way of assessing its quality.

• Reality: One of the most effective software quality assurance mechanisms can be applied from the inception of a project – the formal technical review. Software reviews are a “quality filter” that have been found to be more effective than testing for finding certain classes of software errors.

Disscussion : Quality assessment can be done throughout project development from the moment the project is accepted by having software reviews. By reviewing software, whole software can be tested for its functionality and quality in one go.

• Myth: The only deliverable work product for a successful project is the working program.

• Reality: A working program is only one part of a software configuration that includes many elements. Documentation provides a foundation for successful engineering and a more importantly, guidance for software support.

Disscussion : When creating software, each stage of development should be documented and should be delivered to the client to provide assurance of project development as well as to give them an idea of how the project is going so far. Apart from that, each aspect of the software is documented in order to provide detailed description of how the software works.


Discussion done by : Talib, Lim Jia Hui, Gary Jordan, Shilpesh.

Tweet

Customer myths:

• Myth: A general statement of objectives is sufficient to begin writing programs – we can fill in the details later.

• Reality: Although a comprehensive and stable statement of requirement is not always possible, an ambiguous statement of objectives is a recipe for disaster. Unambiguous requirements are developed only through effective and continuous communication between customer and developer.

Disscussion : Requirements determine the desired outcome of a project because in the developer have to satisfy customer demands and as people say 'the customer is always right'. In the case of software engineering, the developer must meed customer demands and make necessary changes to comply with the customer's requirement. Continuous communication helps make this happen.

• Myth: Project requirements continually change, but change can be easily accommodated because software is flexible.

• Reality: It is true that software requirement change, but the impact of change varies with the time at which it is introduced. When requirement change are requested early, cost impact is relatively small. However, as time passes cost impact grows rapidly – resources have been committed a design framework has been established, and change can cause upheaval that requires additional resources and major design modification.

Disscussion : When a project is started, design and planning is done in order to reach a goal which is to meet the client's requirements. When these requirements change, the goal is changed as well and several unnecessary changes have to be made to the software down to the programming level and this would waste costs such as resources and time.

Discussion done by : Talib, Lim Jia Hui, Gary Jordan, Shilpesh.

Tweet

Software Myths :

Management myths :

• Myth : We already have a book that’s full of standards and procedures for building software. Won’t that provide with everything they need to know?

• Reality: The book of standards may very well exist, but is it used? Are software practitioners aware of its existence? Does it reflect modern software engineering practice? Is it adaptable? Is it streamlined to improve time to deliver while still maintaining a focus on quality? In many cases. The answer to all of these questions is no.

• Disscussion :Software engineering is an ever changing field that is always up to date with new technologies and resources. The book that we have is sufficient to get us started but further research is required in order to find the best and most up-to-date way of engineering a software.

• Myth : If we get behind schedule, we can add more programmers and catch up
  

• Reality : Brooks said “Adding people to a late software project makes it later.” As new people are added, people who were working must spend time educating the newcomers, thereby reducing the amount of time spent on productive development. People can be added but only in a planned and well-coordinated manner.

• Disscussion : More people means more minds at work in order to develop a software. The fact that these new people have not been around since the beginning of the project means that they are practically only seeing it for the first time and need to be brought to the same page as the developing team's current progress. This takes a lot of time and is not affordable at a late software project.

• Myth : If I decide to outsource the software project to a third party. I can just relax and let that firm build it.

• Reality : In an organization does not understand how to manage and control software projects internally, it will invariably struggle when it outsources software projects.

• Disscussion : When an organization outsources a project, they need to know exactly what they want from it as in the product of the software. The requirements gathered at the beginning of a project might change as software is developed and we also have to consider the fact that the developing firm makes a mistake in software development that conflicts with the desired outcome of the client.

Discussion done by : Talib, Lim Jia Hui, Gary Jordan, Shilpesh.

Tweet

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