Después de un semestre de clase con Ken Bauer puedo decir que agradezco mucho haber llevado esta materia con él y con sus métodos de enseñanza. Algo que me pareció sumamente importante fue que a Ken realmente le encanta dar clases, es su pasión y cada día se esfuerza en ser un mejor maestro. Esta cualidad hace que sus clases sean dinámicas y nosotros como alumnos queramos ir a su clase.
During this entire course we have been part of the flipped Learning project that Ken Bauer is trying to implement in Tecnológico de Monterrey. Flipped learning consists on students learning by themselves with the help of a teacher. This way, students see the teachers as someone more approachable and feel the need to ask the teacher more questions.
Each topic must be reviewed by the student at home. The basic information about the topic can be provided by the teacher to impose a small lead. However, the student need to go further than what the teacher them. During class, the students share their discoveries with the teacher and pronounce their doubts.
In my opinion, these systems works perfectly fine as I believe I have learned more this way. Here, you are encouraged to keep learning even when the topic has already been reviewed in class. I usually read the information for class, but to the blog posts at last minute. This way, I can reread what I found earlier and even look for more information regarding on something I have missed before. And in case I have any doubt, I can always ask Ken, even if we were supposed to have discussed the topic a month ago.
Here is a video of some of my classmates and I, giving our reviews on the curse: https://www.youtube.com/watch?v=TdTRLOi0J9Y&feature=youtu.be
During this semester, I had two classes that taught me new things. I don’t mean about theoric things, supposely I learn this every day. But I mean more about experience. Those classes were TC1018 (data structures) and TC1019 (intro to software engineering). In the first one, I had my first real challenge. To be honest, I’ve never had such a hard time with a course, not even OOP or literature (believe me, in my school was really hard). But this post is not about TC1018 and my crazy teacher. This post is about TC1019, a really different experience.
Since I remember, school has been about teachers speaking in the classroom (sometimes passing slides and spitting random words), leaving homework and handling a test which was about what they said. The same loop over 13 years (preschool doesn’t count). This semester was different. First: a class where your attendance is not important, where the teacher does not spits words, but rather makes you investigate and learn by your own (boosting your self-learning skills), where you grade yourself. One can think in two ways: a) this is the best teacher, since he achieved Teachvana, and he is not establishing any knowledge frontiers or b) this is the easiest course, I’ll probably not do anything and still achieve the perfect score. When I started this course, I was thinking like option B (I still do, a little). But as I learned new things, I started knowing what life is about. You don’t stop learning in school. If you do, you become obsolet in a short time. Returning to the non obligatory assistance and pseudo no-date assignments, I believe this teaches you to be responsible. I won’t deny it: I left most of the posts for the end of the month. But still, I
A functional requirement is something the product needs to work, perform an action and fulfill the purpose. It answers the question of “What does it do?”. They describe the minimal requirements of the product functionality. A non-funtional requirement is something that the product have to increase it quality. It answers the question of “How does it do it?”. Non-functional requirements are extras made to improve the functionality of the product.
To be more precise, in software engineer, functional requirements define the functions of the system, is the description of the feature required. It also includes description of the required functions. Some examples of functional requirements are calculations, technical details, data manipulation and processing.
Non-Functional requirements focus on quality factors and effectiveness. These factors are what give value to the software and make the functional requirements function appropriately.
Some non-functional requirements may be:
Sqa.org.uk. (2016). Functional and Non-Functional Requirements. [online] Available at: http://www.sqa.org.uk/e-learning/SDM03CD/page_02.htm [Accessed 13 Sep. 2016].
SearchSoftwareQuality. (2016). Functional vs non-functional requirements, what is the difference?. [online] Available at: http://searchsoftwarequality.techtarget.com/answer/Functional-vs-non-functional-requirements-what-is-the-difference [Accessed 13 Sep. 2016].
The waterfall method was the first Software Development Cycle Model used widely in Software Engineering. In this method, the process of software development is divided into separate phases, the outcome of one of phase acts as the input for the next phase sequentially.
A representation of different phases of waterfall model.
The phases of the waterfall method are:
1. Requirement Gathering & Analysis: Ask the client what their needs and expectations are.
2. System Design: Requirements for the System and Hardware specification to define overall architecture.
3. Implementation: Program is developed in small units and tested (Unit Testing).
4. Integration and Testing: All units are put together and tested for faults and failures.
5. Deployment: After functional and non functional testing, the product is delivered.
6. Maintenance: Regular updates and issue resolving.
The advantages of using the Waterfall Method are:
- Is easy to comprehend
- Allows for departmentalization and control
- Each stage can have a predetermined due time
Although, it has the disadvantage of being unable to go back if one of the steps has a mistake that was discovered in the next stages.
Tech Target. (2016). waterfall model. August 8th, 2016, from Tech Target Website: http://searchsoftwarequality.techtarget.com/definition/waterfall-model
http://www.tutorialspoint.com. (2016). SDLC – Waterfall Model. [online] Available at: http://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm [Accessed 12 Sep. 2016].
- 53% of software projects overrun their schedules and budgets
- 31% are cancelled
- Only 16% are completed
- Projects made by large American software companies approximate to only 42% of clients’ requests.
Source: Keyes, J. (2004). Software Configuration Management. Boca Raton: Auerbach
SCM basic tasks:
Development and production of:
- Configuration identification
- Configuration change control
- Configuration status accounting
- Configuration auditis
Integration: consists on putting together the individual software parts in one single big project.
- Merge: parallel development on the same stuff
- Assembly: development of different pieces
Software Configuration Management started in the 1950s, when configuration management, that was used for hardware and production control, was applied in software development.
Nearly all components that comprise modern information technology, such as Computer Aided Software Engineering (CASE) tools, Enterprise Application Integration (EAI) environments, Extract/Transform/Load (ETL) engines, Warehouses, EII, and Business Intelligence (BI), contain a great deal of metadata as well as his own repository and designer. That’s why metadata CM activities must be used in order to have effective information management.
The purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project’s software life cycle. Software Configuration Management involves identifying configuration items for the software project, controlling these configuration items and changes to them, and recording and reporting status and change activity for these configuration ítems.
Configuration Management is practiced in one or another form as part of any software engineering project where several individuals or organizations have to coordinate their activities.
Software Engineering Institute. Capability Maturity Model Integration, Version 1.1 CMMI for Systems Engineering and Software Engineering (CMMI-SE/SW, V1.1) (CMU/SEI-2000-TR-018, ADA388775). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2000.
The reason for using SCM system is to keep track of the changing entities of a software product in
What is a software development process?
The software development process is a structure imposed on the development of a software product. It is a splitting of software development work into distinct phases containing activities with the intent of better planning and management.
There are several models or methodologies, each describing approaches to a variety of tasks or activities that take place duri ng the process. Common methodologies include the waterfall, prototyping, iterative and incremental development, spiral development, rapid application development, extreme programming and various types of agile methodology.
SE processes are composed of many activities/steps:
- Requirement Analysis
- While the customer probably believe they know what the software is to do, it is common that you need to recognize incomplete, ambiguous or contradictory requirements.
- Software architecture
- Very self explanatory, code the design.
- Testing the software.
- For the purpose of future maintenance and enhancement.
- Training and support
- It is very important to have training classes for the most enthusiastic software users, incorporate the rest of the organization into adopting the new software.
Extreme programming (XP) is a popular Agile development process at many companies and industries because it stresses customer satisfaction.
In this process you don’t set a due date for the work, it delivers the software you need as you need it, it emphasizes teamwork, everyone is equal no matter what they do. It enables teams to be highly productive.
XP improves communication, simplicity, feedback, respect and courage in software development.
- Simplicity: We do what is needed and asked for, but no more. take small simple steps to our goal and mitigate failures as they happen.
- Communication: We communicate face to face daily. We work together on everything.
- Feedback: We demonstrate our software our software early and listen carefully and make any changes needed.
- Respect: Everyone is an important member of the team. Everyone contributes value to the project, even if it’s simply enthusiasm.
- Courage: We tell the truth about progress and estimates. Don’t fear anything because no one ever works alone. Adapt to changes when ever they happen.
XP tries to deliver the system to the customer as early as possible and implement changes as suggested. It has few and very simple rules to follow, that involves planning, managing, designing, coding and testing. You can see more about the rules here.